معرفی لود بالانسر: دروازهٔ توزیع بار در شبکه های چندسروری

لود بالانسر: دروازهٔ توزیع بار

اگر از شما بپرسند لود بالانسر چیست، پاسخ کوتاه و ساده‌ای وجود دارد: دروازه‌ای که درخواست‌های کاربران را دریافت کرده و با استفاده از قواعد مشخص، آن‌ها را بین چند سرور پخش می‌کند. کاربران تنها یک آدرس را مشاهده می‌کنند، در حالی که پشت صحنه، چندین سرور در حال پاسخگویی هستند. در این راهنما، از مسیر یک درخواست شروع کرده و با بررسی لایه‌های مختلف، الگوریتم‌ها و ابزارها، به معماری چندسروری می‌پردازیم.

در یک نگاه

• لود بالانسر علاوه بر پخش بار، سرورهای خراب را نیز از مدار خارج می‌کند.
• انتخاب الگوریتم بدون در نظر گرفتن رفتار درخواست‌ها، می‌تواند توزیع نامتوازن ایجاد کند.
• بررسی سلامت سرورها، مرز بین یک پخش‌کنندهٔ ساده و لود بالانسر واقعی است.
• حتی خود لود بالانسر نیز می‌تواند نقطهٔ شکست واحد باشد و باید برای آن نیز برنامه‌ریزی کرد.

چرا یک سرور همیشه کافی نیست؟

پیش از هر تصمیمی، باید به محدودیت‌های یک سرویس تک سروری توجه کرد:

• در ساعات اوج، منابع سخت‌افزاری مانند پردازنده و حافظه به ظرفیت خود می‌رسند و ارتقای سخت‌افزار هزینه‌بر خواهد بود، در حالی که افزودن سرورها ظرفیت را به صورت خطی افزایش می‌دهد.
• هر قطعهٔ سخت‌افزاری که خرابی آن کل سرویس را متوقف کند، نقطهٔ شکست واحد است. از سرور وب گرفته تا دیسک و منبع تغذیه، همه می‌توانند این نقش را ایفا کنند.
• هر به‌روزرسانی سیستم‌عامل یا ارتقای اپلیکیشن روی یک سرور، به معنای توقف سرویس است، مگر اینکه سرور دیگری در همان لحظه پاسخگو باشد.

مسیر یک درخواست و نقش لود بالانسر

وقتی کاربر یک آدرس را باز می‌کند، لود بالانسر پشت صحنه چهار کار اساسی انجام می‌دهد:

• شناسایی ورودی: IP و پورت مقصد را شناسایی کرده و اتصال شبکه را برقرار می‌کند. در لایهٔ چهار، فرایند در همین مرحله متوقف می‌شود.
• خواندن درخواست: در لایهٔ هفت، دامنه، مسیر، هدرها و کوکی‌ها را بررسی کرده و می‌تواند گروه مقصد را بر اساس این اطلاعات انتخاب کند.
• سنجش سلامت مقاصد: سرورهای ناسالم از فهرست انتخاب حذف شده و پس از بازگشت به حالت عادی، دوباره به مدار اضافه می‌شوند.
• انتخاب مقصد: بر اساس الگوریتم تعیین‌شده، سرور مناسب را انتخاب کرده و اتصال را برقرار می‌کند یا ترافیک را به آن هدایت می‌نماید.

لایهٔ ۴ یا لایهٔ ۷؟

انتخاب لایه، معماری شما را شکل می‌دهد و پس از راه‌اندازی، تغییر آن دشوار است. لود بالانسر لایهٔ چهار تنها اطلاعات انتقال مانند IP، پورت و پروتکل را بررسی کرده و اتصال را به مقصد می‌سپارد. در مقابل، لود بالانسر لایهٔ هفت درخواست را به طور کامل می‌خواند و می‌تواند بر اساس آدرس، هدرها یا کوکی‌ها تصمیم‌گیری کند.

الگوریتم‌های توزیع بار و انتخاب مناسب

الگوریتم تعیین می‌کند که درخواست بعدی به کدام سرور هدایت شود. جدول زیر معیار تصمیم‌گیری، کاربرد و ریسک هر الگوریتم را نشان می‌دهد:

انتخاب الگوریتم لود بالانسر: دو پرسش کلیدی

پیش از انتخاب الگوریتم، دو پرسش اساسی مطرح می‌شود: آیا کاربران باید همیشه به یک سرور مشخص متصل شوند؟ و آیا درخواست‌ها کوتاه یا طولانی‌مدت هستند؟ پاسخ به این پرسش‌ها، الگوریتم مناسب را مشخص می‌کند.

• اگر کاربران باید به یک سرور خاص متصل شوند، از هش IP یا کوکی استفاده کنید. اما اگر سشن‌ها در سرویس مشترکی نگهداری می‌شوند، این محدودیت ضروری نیست.
• در درخواست‌های کوتاه، الگوریتم نوبتی عملکرد بهتری دارد. در حالی که برای اتصال‌های طولانی، شمارش اتصال‌های فعال تصویر دقیق‌تری از بار سرورها ارائه می‌دهد.

بررسی سلامت سرورها؛ کور پخش نکنید

لود بالانسر بدون بررسی سلامت، ترافیک را به صورت کور پخش می‌کند و ممکن است بخشی از درخواست‌ها به سرور خراب برسد. دو روش برای بررسی سلامت وجود دارد:

• لود بالانسر به صورت دوره‌ای درخواست‌هایی را به سرورها ارسال می‌کند و خرابی را پیش از رسیدن کاربران تشخیص می‌دهد. مثلاً در HAProxy، با فعال کردن گزینهٔ check، هر مقصد به طور پیش‌فرض هر ۲۰۰۰ میلی‌ثانیه بررسی می‌شود. پس از سه شکست پیاپی، سرور از مدار خارج و پس از دو موفقیت پیاپی دوباره وارد مدار می‌شود.
• از روی شکست درخواست‌های واقعی کاربران، سلامت سرورها سنجیده می‌شود. Nginx در ماژول upstream از این روش با پارامترهای max_fails و fail_timeout استفاده می‌کند. بررسی سلامت فعال، بخشی از اشتراک تجاری NGINX Plus است.

در انتخاب روش بررسی سلامت، دقت و عمق بررسی مهم است. هرچه بررسی سبک‌تر باشد، فشار کمتری به سرورها وارد می‌شود، اما ممکن است خرابی‌های نیمه‌کاره را دیرتر تشخیص دهد.

سه خانوادهٔ لود بالانسر

• دستگاه‌های اختصاصی با توان پردازشی بالا و پشتیبانی سازنده، اما هزینهٔ خرید و لایسنس سنگین و وابستگی به یک برند. برای کسب‌وکارهای کوچک و متوسط، توجیه اقتصادی ندارد.
• HAProxy، لود بالانسر و پراکسی تخصصی برای هر دو حالت TCP و HTTP. مستندات رسمی آن، نسخهٔ ۳.۴ را آخرین نسخهٔ LTS معرفی می‌کند.
• Nginx با بلوک upstream، نقش لود بالانسر HTTP و با ماژول stream، توزیع TCP و UDP را بر عهده دارد.
• Keepalived با ماژول IPVS هستهٔ لینوکس و پیاده‌سازی کامل VRRP، توزیع بار لایهٔ چهار را ارائه می‌کند.

• سرویس‌های ابری و CDN، لود بالانسر مدیریت‌شده ارائه می‌دهند و می‌توانند ترافیک را میان مناطق جغرافیایی تقسیم کنند. ساده‌ترین روش، چند رکورد A برای یک دامنه است، اما بدون بررسی سلامت و با کنترل محدود.

لود بالانسر، نقطهٔ شکست احتمالی

اگر همهٔ ترافیک از یک سرور لود بالانسر بگذرد و آن سرور خاموش شود، وجود ده سرور وب سالم، بی‌فایده است. راه‌حل رایج، دو لود بالانسر و یک IP شناور است. هر دو سرور Keepalived را اجرا می‌کنند، یکی نقش فعال و دیگری آمادهٔ جایگزینی دارد. با از دسترس خارج شدن سرور فعال، سرور آماده در چند ثانیه IP را تحویل می‌گیرد و ترافیک بدون تغییر در DNS ادامه می‌یابد.

استاندارد RFC 9568 از IETF، VRRP نسخهٔ سه را معرفی می‌کند که مسئولیت یک روتر مجازی را به صورت پویا به یکی از روترهای شبکهٔ محلی می‌سپارد و در صورت در دسترس نبودن سرور فعال، این مسئولیت را جابه‌جا می‌کند. فاصلهٔ پیش‌فرض ارسال پیام‌های وضعیت در این استاندارد، یک ثانیه است.

الگوی فعال/غیرفعال یا فعال/فعال؟

• در الگوی فعال/غیرفعال، فقط یک لود بالانسر کار می‌کند و دیگری آماده است. ساده‌تر است، اما نیمی از ظرفیت بیکار می‌ماند.
• در الگوی فعال/فعال، هر دو لود بالانسر همزمان ترافیک می‌گیرند، مثلاً با دو IP شناور و دو رکورد DNS. ظرفیت بیشتر و بهره‌وری بالاتر، اما پیکربندی و عیب‌یابی سخت‌تر.

طراحی لایهٔ داده به صورت جداگانه

لود بالانسر، درخواست‌ها را تقسیم می‌کند، اما داده را همگام نمی‌کند. برای جلوگیری از مشکلاتی مانند خروج کاربر از حساب یا عدم دسترسی به فایل‌ها، راه‌حل‌هایی مانند ذخیرهٔ سشن در سرویس مشترکی مثل Redis، ذخیره‌ساز مشترک برای فایل‌ها و تکرار دیتابیس پیشنهاد می‌شود.

نمونه‌های پیکربندی

• نمونهٔ اول، یک بک‌اند HAProxy با توزیع نوبتی و بررسی سلامت روی مسیر /health است. آدرس‌ها نمونه هستند و باید با شبکهٔ شما تطبیق داده شوند.
• نمونهٔ دوم، همان کار در ماژول upstream نسخهٔ متن‌باز Nginx، با الگوریتم کمترین اتصال و بررسی غیرفعال است.

اشتباهات رایج در راه‌اندازی لود بالانسر

• استفادهٔ دائمی از چسبندگی نشست، در حالی که می‌توان سشن را در یک سرویس مشترک نگهداری کرد و توزیع را متعادل‌تر نمود.

چک لیست راه‌اندازی سرور وب با لود بالانسر

• اختصاص IP اختصاصی برای هر لود بالانسر و IP شناور برای سرویس.
• اطمینان از کافی بودن پورت شبکه و پهنای باند برای اوج بار و ترافیک داخلی.
• قرارگیری سشن‌ها، فایل‌های آپلودی و کش در یک لایهٔ مشترک، نه روی دیسک یک سرور.
• بررسی سلامت واقعی با آستانهٔ مشخص و خارج کردن سرورهای ناسالم از مدار.
• پایش و هشدار برای لود بالانسر، سرورها و دیتابیس.
• تمرین سناریوی خرابی یک سرور و لود بالانسر در محیط آزمایشی.
• برنامهٔ نسخهٔ پشتیبان و بازگردانی مستقل از معماری چندسروری.

پرسش‌های رایج دربارهٔ لود بالانسر

تفاوت لود بالانسر با پراکسی معکوس چیست؟

پراکسی معکوس درخواست کاربر را دریافت کرده و آن را به سرور پشت خود ارجاع می‌دهد، حتی اگر تنها یک سرور در پشت آن باشد. در حالی که لود بالانسر نوعی پراکسی است که درخواست را میان چند سرور تقسیم کرده و سلامت آن‌ها را ارزیابی می‌کند. به همین دلیل، ابزارهایی مانند Nginx و HAProxy هر دو نقش را ایفا می‌کنند و مرز بین این دو در عمل کمرنگ است.

چه زمانی به لود بالانسر نیاز داریم؟

هنگامی که ارتقای سخت‌افزاری یک سرور دیگر پاسخگو نیست، هر ری‌استارت یا به‌روزرسانی به قطعی سرویس منجر می‌شود، یا زمانی که در قرارداد با مشتریان تعهد دسترس‌پذیری داده‌اید. در مقابل، اگر سایت کوچک است و یک سرور بار را به راحتی تحمل می‌کند، معماری چندسروری تنها هزینه و پیچیدگی اضافه می‌آورد.

برای شروع حداقل چند سرور لازم است؟

از نظر فنی، دو سرور کافی است: لود بالانسر روی یکی یا هر دو و وب سرور روی هر دو. با این حال، برای حذف واقعی نقطهٔ شکست واحد، معماری رایج شامل دو لود بالانسر با IP شناور، حداقل دو سرور اپلیکیشن و یک لایهٔ دادهٔ تکرارشده است. تعداد نهایی به ترافیک، بودجه و میزان تحمل قطعی کسب‌وکار شما بستگی دارد.

آیا لود بالانسر جلوی حملهٔ DDoS را می‌گیرد؟

خیر، لود بالانسر به تنهایی نمی‌تواند از حملات DDoS جلوگیری کند. برخی لود بالانسرها با محدودسازی نرخ درخواست و قواعد لایهٔ هفت، بخشی از حملات سبک را مهار می‌کنند، اما حملهٔ حجمی لایهٔ سه و چهار ظرفیت پورت و شبکه را پر می‌کند و باید در لایهٔ بالادست فیلتر شود. تقسیم بار میان چند سرور، جایگزین محافظت شبکه‌ای نیست.

آیا چند رکورد DNS جای لود بالانسر را می‌گیرد؟

این روش ساده و ارزان است، اما سه ضعف عمده دارد: سلامت سرورها بررسی نمی‌شود، پاسخ‌ها در DNS کش می‌شوند و تغییر فوری امکان‌پذیر نیست، و کاربرانی که به سرور خراب هدایت می‌شوند، بازخورد مشخصی دریافت نمی‌کنند. این روش می‌تواند نقطهٔ شروع خوبی برای سایت‌های کوچک با ترافیک پایدار باشد، اما معماری نهایی نیست.

آیا چسبندگی نشست همیشه لازم است؟

فقط در اپلیکیشن‌هایی که سشن را روی حافظهٔ همان سرور نگه می‌دارند، ضروری است. اگر سشن را در سرویس مشترکی مانند Redis قرار دهید، این قید حذف می‌شود، توزیع بار متعادل‌تر می‌شود و خرابی یک سرور دیگر نشست کاربران را از بین نمی‌برد. بنابراین، این الگو راه‌حل پایدارتری است.

آیا لود بالانسر تأخیر پاسخ را افزایش می‌دهد؟

در عمل، تأخیر ناچیزی اضافه می‌کند، اما با توزیع بار، زمان پاسخ سرورها را کاهش می‌دهد. اگر لود بالانسر لایهٔ هفت باشد، پردازش بیشتری دارد، اما این هزینه در برابر انعطاف مسیریابی معمولاً ارزش دارد. تنها نکته این است که خود لود بالانسر را به نقطهٔ پرترافیک و بی‌پایش تبدیل نکنید.

جمع‌بندی

در این راهنما، با لود بالانسر و نحوهٔ توزیع درخواست‌ها میان چند سرور با استفاده از الگوریتم‌هایی مانند توزیع نوبتی و کمترین اتصال آشنا شدیم. همچنین، تفاوت لایهٔ چهار و هفت، سه خانوادهٔ سخت‌افزاری، نرم‌افزاری و ابری، نقش HAProxy، Nginx و Keepalived و الگوی IP شناور برای حذف نقطهٔ شکست واحد را بررسی کردیم.

هدف نهایی، ایجاد سرویسی است که با رشد ترافیک بزرگ شود و با خرابی یک سرور از کار نیفتد. توصیه می‌شود قبل از خرید سرورهای بیشتر، گلوگاه واقعی را پیدا کرده، لایهٔ داده را برای چند سرور آماده کنید و سپس با یک معماری حداقلی شروع کنید. نسخهٔ پشتیبان و محافظت شبکه‌ای نیز در این طراحی نقش مهمی دارند.

سه تصمیم کلیدی عبارتند از: لایهٔ کاری لود بالانسر (چهار یا هفت)، الگوریتم توزیع بار متناسب با رفتار درخواست‌ها، و معماری بدون نقطهٔ شکست واحد با IP شناور. با روشن بودن این سه عامل، معماری چندسروری شما قابل اعتماد و پایدار خواهد ماند.

اگر پرسشی باقی مانده، در بخش نظرات مطرح کنید تا بررسی کنیم.

منابع و مراجع

• مرکز آموزشی Cloudflare: برای درک مفاهیم اولیه لود بالانسینگ و آشنایی با انواع روش‌های توزیع بار، مرکز آموزشی Cloudflare منبع مناسبی است.
• کتاب راهنمای پیکربندی HAProxy: این کتاب راهنما، مرجعی جامع برای پیکربندی و مدیریت HAProxy است. با مطالعه این کتاب، می‌توانید به درک عمیق‌تری از نحوه کار و پیکربندی HAProxy دست یابید.
• مستندات ماژول upstream و ماژول stream در Nginx: برای استفاده از قابلیت‌های لود بالانسینگ در Nginx، مطالعه مستندات ماژول upstream و ماژول stream ضروری است. این مستندات، راهنمایی دقیق برای پیکربندی و استفاده از این ماژول‌ها ارائه می‌دهند.
• مستندات رسمی Keepalived: Keepalived یک ابزار قدرتمند برای مدیریت لود بالانسینگ و قابلیت‌های High Availability است. مطالعه مستندات رسمی این ابزار، به شما کمک می‌کند تا با قابلیت‌ها و پیکربندی‌های مختلف آن آشنا شوید.
• استاندارد IETF RFC 9568 درباره VRRP نسخه سه: این استاندارد، جزئیات و مشخصات فنی VRRP نسخه سه را ارائه می‌دهد. مطالعه این استاندارد، به درک عمیق‌تر از نحوه کار و پیاده‌سازی VRRP کمک می‌کند.

یادگیری و مطالعه مداوم، کلید موفقیت در حوزه فناوری اطلاعات است. با مطالعه منابع ذکرشده، می‌توانید دانش خود را در زمینه لود بالانسینگ و High Availability گسترش دهید و به درک بهتری از این مفاهیم و تکنیک‌ها دست یابید.