عوامل زیادی از جمله، راندمان، مقیاس‌پذیری، دسترس‌پذیری، اطمینان‌پذیری، هزینه و مدیریت در انتخاب نوع معماری سرور نقش دارن. در این مقاله، روش های پیکربندی که به طور متداول برای سرور استفاده می‌شن رو معرفی می‌کنیم و در مورد هر کدوم‌شون یک توضیح مختصر (از جمله مزایا و معایب) هم ارائه می‌دیم. توجه داشته باشین که تمامی این روش های پیکربندی یا setupهایی که در این نوشتار بهشون پرداختیم رو می‌تونین در کنار بقیه setupها هم ازشون استفاده کنین. البته که هر محیط الزامات خاص خودش رو داره. به همین خاطر شما باید معایب و مزایا هر پیکربندی بر اساس اولویت های خودتون بسنجید تا پیکربندی موردنظرتون رو پیاده سازی کنید.
پیکربندی همه چیز بر روی تنها یک سرور
یکی از این روش های پیکربندی برای مواقعی هست که کُل محیط روی یک سرور قرار می‌گیرن. برای یک وب اپلیکیشن معمولی، این محیط شامل وب‌سرور، سرور اپلیکیشن و سرور دیتابیس هست. یک نمونۀ رایج از این setup، پشتۀ LAMP است که مخفف Linux، Apache، MySQL و PHP روی یک سرور است. یک نمونه از موارد کاربرد این setup برای مواقعی است که می‌خواین سریعاً یک اپلیکیشن رو راه‌اندازی کنین. از یک setup ساده مثل این می‌شه برای تِست ایده یا اجرا و بالا آوردن یک صفحه وب استفاده کرد.
متأسفانه، این setup به لحاظ مقیاس‌پذیری و جداسازی مؤلفه‌ها چیز زیادی برای عرضه نداره. علاوه بر این، اپلیکیشن و دیتابیس از منابع (CPU، حافظه، I/O و غیره) یک سرور یکسان استفاده می‌کنن. به همین دلیل، راندمان‌شون ضعیف خواهد بود و ریشه‌یابی مشکل هم سخت خواهد بود. علاوه بر این، در صورت استفاده از یک سرور دیگه بلافاصله نمی‌شه اون رو به صورت افقی مقیاس‌بندی کرد. 
پیکربندی یک سرور جداگانه برای دیتابیس
سیستم مدیریت دیتابیس DBMS(Database Management Systems) رو می‌شه از بقیۀ محیط جدا کرد و بدین ترتیب، رقابت اپلیکیشن و دیتابیس بر سر استفاده از منابع رو کاهش داد. علاوه بر این، با حذف دیتابیس از (demilitarized zone)DMZ یا اینترنت عمومی می‌شه امینت رو ارتقاء داد.
این setup می‌تونه خیلی سریع اپلیکیشن رو راه‌اندازی کنه و مانع این بشه که اپلیکیشن و دیتابیس بر سر استفاده از منابع یک سیستم یکسان به مشکل بخورن. علاوه بر این، می‌تونین به صورت عمودی و جداگانه اپلیکیشن‌ها و دیتابیس رو مقیاس‌بندی کنین. این کار رو می‌تونین با اضافه کردن منابع به سروری که نیاز به افزایش ظرفیت داره انجام بدین. در این نوع setup، حذف دیتابیس از DMZ موجب ارتقای امنیت می‌شه.
این روش پیکربندی سرور، پیچیده‌تر از پیکربندی تک سرور است. در این setup، عملکرد شبکه بین دو تا سروری که به لحاظ جغرافیایی از هم دور هستن به مشکل می‌خوره مثلاً تأخیر زیادی خواهد داشت. علاوه بر اون، اگر پهنای باند برای حجم داده‌هایی که ارسال می‌شن خیلی کم باشه، عملکرد شبکه با مشکل مواجه می‌شه. تصویر زیر استفاده از سرور جداگانه برای دیتابیس رو نشون می‌ده:
پیکربندی Load balancer (پروکسی معکوس)
برای ارتقای عملکرد و اطمینان‌پذیری می‌شه لودبالانسرها(Load Balancer) رو به محیط سرور اضافه کرد؛ برای انجام این کار می‌شه حجم کاری (workload) رو روی چند تا سرور توزیع کرد. اگر یکی از سرورهای Load Balancer به مشکل بخوره، سایر سرورها تا زمانی‌که مشکل سرور برطرف بشه ترافیک رو مدیریت می‌کنن. علاوه بر این، این setup می‌تونه با استفاده از یک اپلیکیشن لایه 7، پروکسی معکوس رو لایه‌بندی کنه و بدین ترتیب به چند تا اپلیکیشن از طریق دامنه و پورت یکسان سرویس‌دهی کنه. HAProxy، Nginx و Varnish از جمله نرم‌افزارهایی هستن که می‌تونن بارِ پروکسی معکوس رو متوازنسازی کنن.
یک نمونه از موارد کاربرد این setup در محیط‌هایی هست که لازمه مقایس اونا رو با افزودن سرورهای بیشتر افزایش داد که نام دیگه‌اش هم مقایس‌بندی افقی است. وقتی یک لود بالانسر رو راه‌اندازی می‌کنین، این لود بالانسر ظرفیت محیط رو به نحوی بالانس می‌کنه که می‌شه با افزودن سرورهای بیشتر به اون، مقیاس‌بندیش کرد. علاوه بر این، این setup با محدود کردن اتصال کلاینت به حجم و فرکانس حساس می‌تونه مانع حملات (distributed denial-of-service)DDOS بشه.
اگر لود بالانسر منابع کافی نداشته باشه یا پیکربندی ضعیفی داشته باشه، راه‌اندازی اون می‌تونه گلوگاهی (performance bottleneck) در راندمان ایجاد کنه. علاوه بر این، باعث بروز موارد پییچده‌ای می‌شه که نیازمند بررسی بیشتر هستن، برای مثال اینکه عملیات SSL termination کجا باید اجرا بشه و مدیریت اپلیکیشن‌هایی که از stickysessionها استفاده می‌کنن. علاوه بر این، لود بالانسر یک نقطۀ واحد شکست هست؛ به عبارت دیگه، اگه لود بالانسر به مشکل بخوره کل سرویس با مشکل مواجه می‌شه. setup با قابلیت دسترسی(Highavailability) زیرساختی بدون نقطۀ واحد شکست است. تصویر زیر راه‌اندازی لود بالانسر رو نشون می‌ده.
راه‌اندازی شتاب‌دهندۀ HTTP
از شتاب‌دهنده HTTP یا همون پروکسی معکوس(Reverse Proxy) با قابلیت cache می‌شه برای کاهش مدت زمان لازم برای ارائه اطلاعات با کاربر از طریق تکنیک‌های مختلف استفاده کرد. اصلی‌ترین تکنیکی که به همراه شتاب‌دهندۀ HTTP استفاده می‌شه cache کردن جواب‌های سرور وب با اپلیکیشن در حافظه است؛ در این حالت، به درخواست‌های آتی برای همان مطالب سریع‌تر می‌شه پاسخ داد و نیاز به تعامل با سرورهای وب یا اپلیکیشن به حداقل می‌رسه. Varnish، Squid و Nginx از جمله نرم‌افزارهایی هستن که قادر به شتاب‌دهی HTTP هستن. یکی از نمونه کاربردهای این setup در محیط‌هایی با وب اپلیکیشن‌های پویا با حجم بالای محتوا یا محیط‌هایی است که در آن واحد به صورت مشترک به فایل‌های زیادی دسترسی پیدا می‌کنن.
شتاب‌دهی HTTP می‌تونه با کاهش بارِ CPU روی وب سرور ( از طریق cache کردن و فشرده‌سازی) راندمان سایت رو بالا ببره و ظرفیت کاربر رو افزایش بده. علاوه بر این، از این setup می‌شه به عنوان یک لود بالانسر پروکسی معکوس یا نرم‌افزار cache استفاده کرد و از حملات DDOS جلوگیری کرد. متأسفانه، اگر نرخ cache-hit پایین باشه راندمان کاهش پیدا می‌کنه و برای اینکه عملکرد بهتری داشته باشه لازمه که اونو تنظیم (tune) کرد. تصویر زیر راه‌اندازی شتاب‌دهندۀ HTTP رو نشون می‌ده.
راه‌اندازی Primary-replica Database Replication
یکی از راه‌های بهبود عملکرد سیستم دیتابیسی که readهای زیادی در مقایسه با write انجام می‌ده (مثل CMS) استفاده از primary-replica database replication است. لازمۀ replication یک نود(node) اولیه و یک یا بیش از یک نود replica است. در این setup، تمامی به روزرسانی‌ها به node اولیه ارسال می‌شن و readها رو می‌شه در تمامی nodeها توزیع کرد. یک نمونه کاربرد این setup، افزایش عملکرد read لایۀ دیتابیس اپلیکیشن است. راه‌اندازی primary-replica database replication با توزیع readها در replicaها عملکرد read دیتابیس رو بهبود می‌بخشه. از طرف دیگه، از این Setup فقط برای به‌روزرسانی‌ها استفاده می‌شه و زمانی صرف پاسخ‌دهی به درخواست‌های read نمی‌کنه و بدین ترتیب عملکرد write رو بهبود می‌بخشه.
برخی از معایب primary-replica database replication اینه که اپلیکیشنی که به دیتابیس دسترسی پیدا می‌کنه باید مکانیزمی داشته باشه که مشخص کنه به‌روزرسانی‌ها و درخواست‌های read رو به کدوم یکی از nodeهای دیتابیس ارسال کنه. علاوه بر این، اگر node اولیه با مشکل رو‌به‌رو بشه تا زمان رفع مشکل، هیچ به‌روزرسانی روی دیتابیس انجام نمی‌شه. علاوه بر این، این setup، در صورت خرابی node اولیه، قابلیت failover تعبیه نشده. تصویر زیر primary-replica replication setup با یک نود replica رو نشون می‌ده.
ترکیب پیکربندی ها
بارِ سرورهای cache و هم‌چنین سرورهای اپلیکیشن رو می‌شه متوازنسازی کرد و از database replication در یک محیط واحد استفاده کرد. هدف از ترکیب این تکنیک‌ها اینه که بدونه بروز مشکلات و پییچدگی‌های زیاد حداکثر استفاده رو از تک تک اونا ببریم. تصویر زیر، یک نمونه دیاگرام از این نوع محیط سرور است:
برای مثال فرض کنین لود بالانسر به نحوی پیکربندی شده که درخواست‌های ایستا (مثل تصاویر، CSS، JavaScript و غیره) رو تشخیص بده و این درخواست‌ها رو مستقیماً به سرورهای cache بفرسته و سایر درخواست‌ها رو به سرورهای اپلیکیشن ارسال کنه.
وقتی کاربر درخواست برای محتوای پویا رو ارسال می‌کنه، فرایندش به این شکله:
- کاربر از http://example.com (لود بالانسر) درخواست محتوای پویا می‌کنه.
- لود بالانسر درخواست رو به app-backend ارسال می‌کنه.
- App-backend دیتابیس رو می‌خونه و محتوای درخواستی رو به لود بالانسر باز می‌گردونه.
- لود بالانسر داده‌های درخواستی رو به کاربر باز می‌گردونه.
زمانی‌که کاربر درخواست محتوای ایستا داره، چنین فرایندی طی می‌شه:
- لود بالانسر cache-backend رو بررسی می‌کنه تا مطمئن بشه محتوای درخواستی cache شده (cache-hit) یا نه (cache-miss).
- اگر متحوا cache-hit شده باشه به این معنیه که محتوای درخواستی رو به لود بالانسر برمی‌گردونه و به سراغ مرحلۀ آخر این فرایند می‌ره و داده رو به کاربر برمی‌گردونه. اگر محتوا cache-miss شده باشه، سرور cache درخواست رو از طریق لود بالانسر به app-backend می‌فرسته.
- لود بالانسر درخواست رو از طریق app-backend فوروارد می‌کنه.
- App-backend دیتابیس رو می‌خونه و محتوای درخواستی رو به لود بالانسر ارسال می‌کنه.
- لود بالانسر پاسخ رو به cache-backend فوروارد می‌کنه.
- Cache-backend محتوا رو cache می‌کنه و اونو به لود بالانسر برمی‌گردونه.
- لود بالانسر داده‌های درخواستی رو به کاربر ارسال می‌کنه.
چنین محیطی کماکان دو تا نقطۀ واحد شکست داره: لود بالانسر و سرور اولیه دیتابیس، اما تمامی مزایای اطمینان‌پذیری و عملکردی که در قسمت قبل بهشون اشاره کردیم رو داره.
سخن پایانی
حالا که با تعدادی از پیکربندی های پایۀ سرور آشنا شدین، می‌دونین چه نوع setup باید برای اپلیکیشن‌تون استفاده کنین. اگر قصد دارید عملکرد محیط‌‌تون رو بهبود ببخشین توجه داشته باشین که برای جلوگیری از بروز سریع پیچیدگی‌ها بهتره فرایند تکراری رو اجرا کنین.
