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

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

در یک نگاه

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

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

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

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

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

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

---

مسیر یک درخواست؛ لود بالانسر چهار تصمیم می‌گیرد

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

۱

ورودی را می‌شناسد: IP و پورت مقصد را می‌بیند و اتصال شبکه را می‌پذیرد؛ در لایهٔ چهار کار همین‌جا متوقف می‌شود.

۲

درخواست را می‌خواند: در لایهٔ هفت، دامنه، مسیر، هدر و کوکی را می‌بیند و می‌تواند گروه مقصد را بر همان اساس انتخاب کند.

۳

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

۴

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

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

---

لایهٔ ۴ یا لایهٔ ۷؟ معیار انتخاب

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

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

---

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

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

▍ دو پرسش پیش از انتخاب الگوریتم

◀️ آیا یک کاربر باید همیشه به یک سرور مشخص برود؟ اگر پاسخ بله است، هش IP یا کوکی لازم می‌شود؛ اگر سشن را در سرویس مشترکی نگه می‌دارید، این قید را لازم ندارید.

◀️ هر درخواست کوتاه است یا طولانی؟ برای درخواست‌های کوتاه، نوبتی تعادل بهتری می‌سازد؛ برای اتصال‌های طولانی، شمردن اتصال‌های فعال تصویر واقعی‌تری از بار هر سرور می‌دهد.

---

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

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

لود بالانسر خودش دوره‌ای به سرورها درخواست می‌فرستد و خرابی را پیش از رسیدن کاربران می‌بیند. در HAProxy با فعال کردن گزینهٔ check، هر مقصد به‌طور پیش‌فرض هر ۲۰۰۰ میلی‌ثانیه بررسی می‌شود؛ پس از سه شکست پیاپی از مدار خارج و پس از دو موفقیت پیاپی دوباره وارد می‌شود؛ یعنی با تنظیمات پیش‌فرض، سرور خراب حدود شش ثانیه بعد کنار گذاشته می‌شود.

از روی شکست درخواست‌های واقعی کاربران قضاوت می‌شود. نسخهٔ متن‌باز Nginx در ماژول upstream از همین روش با پارامترهای max_fails و fail_timeout استفاده می‌کند و طبق مستندات رسمی، بررسی سلامت فعال بخشی از اشتراک تجاری NGINX Plus است.

آنچه بررسی می‌کنید هم مهم است: باز بودن پورت، پاسخ موفق یک درخواست HTTP، یا یک نقطهٔ سنجش عمیق‌تر که به دیتابیس هم سر می‌زند. هرچه بررسی سبک‌تر باشد فشار کمتری به سرورها می‌آورد، اما خرابی‌های نیمه‌کاره را دیرتر می‌بیند.

---

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

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

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

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

---

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

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

طبق استاندارد RFC 9568 از IETF که در آوریل ۲۰۲۴ منتشر شد و جای RFC 5798 را گرفت، VRRP نسخهٔ سه مسئولیت یک روتر مجازی را به‌صورت پویا به یکی از روترهای شبکهٔ محلی می‌سپارد و در صورت در دسترس نبودن سرور فعال، این مسئولیت را جابه‌جا می‌کند؛ فاصلهٔ پیش‌فرض ارسال پیام‌های وضعیت در این استاندارد یک ثانیه است.

▍ فعال/غیرفعال یا فعال/فعال؟

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

▍ لایهٔ داده را جداگانه طراحی کنید

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

---

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

نمونهٔ اول یک بک‌اند HAProxy با توزیع نوبتی و بررسی سلامت روی مسیر /health است؛ آدرس‌ها نمونه‌اند و باید با شبکهٔ شما تطبیق داده شوند:

نمونهٔ دوم همان کار در ماژول upstream نسخهٔ متن‌باز Nginx، با الگوریتم کمترین اتصال و بررسی غیرفعال:

---

پنج اشتباه رایج در راه‌اندازی

✕

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

✕

افزودن سرور وب بدون آماده کردن لایهٔ داده؛ نتیجه‌اش خروج کاربران از حساب یا گم شدن فایل‌های آپلودی است.

✕

بررسی سلامت سست یا نبود آن؛ آستانه‌های خیلی دیرپاسخ، کاربران را به سرور خراب می‌فرستند.

✕

پایش نکردن خود لود بالانسر؛ مصرف پردازنده، تعداد اتصال فعال و نرخ خطای آن باید دیده شود.

✕

مهاجرت یک‌بارهٔ همهٔ کاربران به معماری جدید، بدون انتشار تدریجی و آزمون سناریوی خرابی.

---

چک‌لیست پیش از راه‌اندازی

✓

برای هر لود بالانسر یک IP اختصاصی و برای سرویس یک IP شناور در نظر گرفته شده است.

✓

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

✓

سشن‌ها، فایل‌های آپلودی و کش در لایه‌ای مشترک قرار گرفته‌اند، نه روی دیسک یک سرور.

✓

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

✓

پایش و هشدار برای خود لود بالانسر، سرورها و دیتابیس فعال است.

✓

سناریوی خرابی یک سرور و خرابی یک لود بالانسر را در محیط آزمایشی تمرین کرده‌اید.

✓

برنامهٔ نسخهٔ پشتیبان و بازگردانی مستقل از معماری چندسروری نوشته شده است.

---

پرسش‌های پرتکرار درباره لود بالانسر

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

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

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

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

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

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

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

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

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

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

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

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

لود بالانسر تأخیر پاسخ را بیشتر می‌کند؟

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

---

جمع‌بندی

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

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

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

اگر پرسشی در این مسیر برایتان ماند، در بخش نظرات بنویسید تا بررسی کنیم.

منابع: مرکز آموزشی Cloudflare دربارهٔ لود بالانسینگ، کتاب راهنمای پیکربندی HAProxy، مستندات ماژول upstream و ماژول stream در Nginx، مستندات رسمی Keepalived و استاندارد IETF RFC 9568 دربارهٔ VRRP نسخهٔ سه.