معماری های رایج راه اندازی سرور ها؛ مزایا و معایب
زمانیکه تصمیم میگیرید که برای سرور های خودتون یک معماری رو انتخاب کنید، باید فاکتور های مختلفی رو در نظر بگیرید، فاکتور هایی مثل کارایی، تغییر پذیری، دسترس پذیری، اطمینان پذیری، هزینه و راحتی مدیریت در انتخاب معماری موثرند.
در ادامه لیستی از معماری های رایج رو به همراه توضیحات کوتاه از هرکدوم به همراه مزایا و معایبشون قرار میدم. در نظر داشته باشین که تمام مواردی که در اینجا گفته میشود میتواند در حالت های مختلفی با یکدیگر ترکیب شوند و اینکه در هر معماری، نیازمندی های متفاوتی وجود دارد و اینکه هیچ گزینه ی “کاملا” صحیحی همواره وجود ندارد.
-
همه ی چیز بر روی یک سرور
تمام سرویس ها بر روی یک سرور راه اندازی میشوند. به عنوان مثال برای یک سایت پرستاشاپ یا وردپرسی شامل وب سرور، اپلیکیشن سرور، دیتابیس سرور و میل سرور میشود. به این روش رایج LAMP استک میگویند. (مخفف Linux, Apache, MySql, PHP)
- موارد استفاده
زمانیکه قصد راه اندازی سریع یک اپلیکیشن (مثل وردپرس یا پرستاشاپ) رو دارید، این ساده ترین روش راه اندازیست.
- مزایا
- سادگی
- معایب
- اپلیکیشن و دیتابیس از منابع مشترک (CPU و Memory و هارد و شبکه) استفاده میکنند که جدا از امکان کاهش کارایی، امکان مشخص کردن اینکه بین اپلیکیشن و دیتابیس کدام کارایی پایینتری دارد را نیز مشکل میکند.
- ساختار مشخص و قابل درک دقیقی ندارد.
- امکان ایزوله سازی و تغییر ساختار به سختی وجود دارد.
-
دیتابیس سرور و اپلیکیشن سرور مجزا
قسمت مدیریت سیستم دیتابیس میتواند جدا از سایر سرویس ها راه اندازی شود تا از مشترک بودن منابع دیتابیس و اپلیکیشن جلوگیری کرد. همچنین با این کار شما دیتابیس خودتون رو از DMZ خارج کردید پس قاعدتا افزایش امنیت رو خواهید داشت.
- موارد استفاده
برای زمانیست که میخواهید یک اپلیکیشن را سریعا راه اندازی کنید ولی قصد دارید که از اشتراک منابع بین سرور دیتابیس و اپلیکیشن جلوگیری کنید.
- مزایا
- اپلیکیشن و دیتابیس به منابع مشترک وابسته نیستند.
- شما میتوانید بصورت جداگانه به هرکدام از سرور ها منابع اضافه کنید.
- با توجه به اینکه دیتابیس خودتون رو از روی اینترنت خارج کردید و البته با در نظر گرفتن نحوه ی راه اندازیتون، افزایش امنیت رو هم خواهید داشت احتمالا.
- معایب
- نسبت به تک سرور، راه اندازی دشوار تری دارد.
- در صورتی که در شبکه و اتصال بین دو سرور اختلال و یا کندی اتفاق بیفتد، مشکل کارایی میتواند افزایش یابد. (به عنوان مثال دو سروری که در یک رک و در یک روتر هستند کارایی شبکه بالاتری نسبت به دو سروری که در دیتاسنتر متفاوت در دو قاره ی متفاوت هستند، دارند.
-
لود بالانسر (ریورس پراکسی)
لود بالانسر سروری است که به زنجیره ی سرور ها اضافه میشود تا کارایی را افزایش دهد و اطمینان پذیری را با پخش کارها بین چند سرور بالا ببرد. به این صورت عمل میکند که اگر یک اپلیکیشن سرور دچار خطا و مشکل شود، لود بالانسر ترافیک را به سمت دیگر سرور ها هدایت میکند و تا زمانیکه مشکل سرور داون شده حل شود، این کار را ادامه میدهد.
- موارد استفاده
زمانیکه شما نیاز دارید تا چندین سرور را همزمان استفاده کنید و شبکه سرور های مورد استفاده را گسترش دهید.
همچنین میتواند چندین اپلیکیشن مختلف رو تحت یک دامنه و پورت ارائه نماید. (از طریق لایه ۷ و ریورس پراکسی)
- مزایا
- امکان افزایش عرضی ساختار
- توانایی مقاومت و محافظت در برابر حملات DDOS با محدود سازی کانکشن های کاربر به حد معقول در لحظه
- معایب
- در صورتی که لود بالانسر منابع کمی داشته باشد یا به درستی تنظیم نشده باشد، میتواند تبدیل به یک گلوگاه شود و کارایی را تحت تاثیر قرار دهد.
- پیچیدگی زیادی به سیستم اضافه میکند. مواردی مثل اینکه SSL چطور اعمال گردد و یا چطور اپلیکیشن هایی که به سشن ها وابستگی دارند را هماهنگ سازی نمایید.
- لود بالانسر تک نقطه ی حساس و پاشنه ی آشیل زنجیره میباشد. در صورتی که لود بالانسر از کار بیفتد، کل سیستم شما از کار خواهد افتاد. یک سیستم با دسترس پذیری بالا (HA)، سیستمی است که تنها به یک حلقه از زنجیره متکی نباشد.
-
تسریع کننده وب
تسریع کننده ی وب یا سیستم کش وب در پشت پراکسی، میتواند در کاهش زمان ارائه محتوا به کاربر از طریق برخی تکنیک ها موثر باشد. تکنیک اصلی مورد استفاده در تسریع کننده وب این هست که پاسخ های وب سرور یا اپلیکیشن سرور را در حافظه ذخیره میکند تا در درخواست های بعدی برای آن محتوا، سریعتر و بدون مراجعه به اپلیکیشن سرور پاسخ کاربر را بدهد و با این کار از تعاملات غیر ضروری با وب سرور و یا اپلیکیشن سرور خودداری میکند.
- موارد استفاده
محیط هایی که دارای محتوای زیاد در سطح وب اپلیکیشن هستند و یا درخواست فایل های مشابه زیادی دارند.
- مزایا
- افزایش کارایی سایت با کاهش لود سی پی یو در وب سرور که از طریق کش کردن و فشرده سازی حاصل میشود و سبب افزایش توانایی کاربر برای استفاده بیشتر میگردد.
- میتواند به عنوان ریورس پراکسی لود بالانسر نیز استفاده شود.
- برخی از برنامه های کش کردن میتوانند در مقابل حملات DDOS از سیستم محافظت نمایند.
- معایب
- میبایست خیلی دقیق تنظیمات انجام شود تا کارایی لازم دریافت گردد.
- در صورتی که میزان استفاده از کش ها(کش-هیت) پایین باشد سبب کاهش کارایی میگردد.
-
رپلیکیشن دیتابیس Master-Slave
یکی از راه های افزایش کارایی یک سیستم دیتابیسی که تعداد بیشتری عملیات خواندن را به نسبت عملیات های نوشتن انجام میدهد، استفاده از سیستم مستر-اسلیو میباشد. در این معماری، یک دیتابیس به عنوان دیتابیس اصلی و مادر انتخاب میشود و یک یا چند نسخه از همان دیتابیس به عنوان گره های اسلیو فعالیت میکنند. در این حالت، تمام به روز رسانی ها (نوشتن اطلاعات) به دیتابیس مستر ارسال میشود اما در عوض هنگام اجرای دستورات خواندن، از دیتابیس های اسلیو آن استفاده میگردد.
- موارد استفاده
زمانیکه خواندن های زیادی در دیتابیس وجود دارد، میتوانید با تقسیم این پردازش ها بین چندین دیتابیس سرور، سرعت پردازش های اپلیکیشن در دیتابیس را افزایش دهید.
- مزایا
- با پخش کردن درخواست های خواندن بین چندین دیتابیس سرور، سرعت عملیات های خواندن افزایش پیدا میکند.
- افزایش سرعت نوشتن در دیتابیس مستر بدلیل آنکه دیتابیس سرور مستر دیگر درگیر پردازش اطلاعات خواندن نمیباشد.
- معایب
- در دسترسی اپلیکیشن به دیتابیس باید حتما مکانیزمی مشخص گردد که کدام دیتابیس مستر است و عملیات نوشتن بر روی آن صورت میگیرد و کدام دیتابیس ها اسلیو هستند و عملیات های خواندن بر روی آنها صورت میگیرد.
- روز رسانی ها در اسلیو ها ممکن است آسنکرون(غیر همزمان) باشد که ممکن است در برخی لحظات محتواها به روز نباشند.
- در صورتی که دیتابیس مستر دچار مشکل شود، هیچ به روز رسانی در وبسایت انجام نمیشود تا مشکل حل گردد.
- تحمل خطایی به صورت پیش فرض برای دیتابیس مستر وجود ندارد.
در هر ۵ معماری بالا، معایب خطرناکی وجود دارد که میتواند زنجیره ی سرویس دهی را مختل سازد. اما میتوان با ترکیب آنها به یک معماری ایده آل تر رسید.
معماری ترکیبی لود بالانسر + کش + رپلیکیشن
برای این مثال، اینطور در نظر بگیرید که لود بالانسر طوری تنظیم شده است که محتوای درخواست استاتیک (مثل تصاویر، فایل های CSS و جاوا اسکریپت و …) را شناسایی کند و آنها را به صورت مستقیم به سرور های کش ارسال میکند و باقی درخواست ها را به اپلیکیشن سرور ها میفرستد.
روند اتفاقاتی که اگر کاربر یک درخواست برای محتوای داینامیک ارسال کند بصورت زیر میشود:
- کاربر یک درخواست محتوای داینامیک به سایت میفرستد. (لود بالانسر)
- لود بالانسر درخواست را به سرور های اپلیکیشن ارسال میکند.
- سرور های اپلیکیشن درخواست خواندن را از دیتابیس دریافت و پاسخ را به لود بالانسر بازمیگرداند.
- لود بالانسر پاسخ و دیتا را به کاربر بازمیگرداند.
و اگر که کاربر محتوای استاتیک را بخواهد، روند کارها بصورت زیر خواهد بود:
- کاربر یک درخواست محتوای داینامیک به سایت میفرستد. (لود بالانسر)
- لود بالانسر، به سرور های کش مراجعه میکند تا متوجه شود که محتوا کش شده است (کیش-هیت) یا کش نشده است (کیش-میس)
- اگر “کش-هیت” اتفاق بیفتد، محتوا از سرور های کش به لود بالانسر منتقل میشود و مرحله ۸ این سلسله اتفاق میفتد.(لود بالانسر به کاربر پاسخ را برمیگرداند.) اگر “کش-میس” اتفاق بیفتد، سرور های کش، درخواست رو به برای ارسال به اپلیکیشن سرور ها، به لود بالانسر منتقل میکنند.
- لود بالانسر درخواست را به سرور های اپلیکیشن میفرستد.
- سرور های اپلیکیشن، عملیات خواندن را از دیتابیس ها انجام و محتوای درخواستی را به لود بالانسر پاسخ میدهند.
- لود بالانسر محتوا را به سرور های کش ارسال میکنند.
- سرور های کش، محتوا را در سیستم ثبت و کش میکنند و به لود بالانسر بازمیگردانند.
- لود بالانسر دیتای مورد درخواست را به کاربر پاسخ میدهد.
همچنان در معماری ترکیبی بالا، دو نقطه ی مرگ آور وجود دارد.(لود بالانسر و دیتابیس سرور مستر) اما با این حال قابلیت اطمینان و کارایی بالایی را به همراه دارد که تمام مزایای معماری های رایج را دارد.
حالا با تمام موراد بالا که توضیح داده شد، با مفاهیم اولیه راه اندازی سرور ها از لحاظ تئوری آشنا هستید و ایده های لازم را برای راه اندازی خواهید داشت. روند های بالا تو اپلیکیشن هایی مثل پرستاشاپ، وردپرس، وی بولتین، مجنتو و جوملا و… که درصد بالایی از درخواست ها در دیتابیس سرور عملیات های خواندن هستند و عموما هم در زمان هایی که بازدید ها مقداری افزایش پیدا میکنند فشار زیادی به دیتابیس وارد میشود صدق میکند.