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

💡 لود بالانسر، پلیس راهنمایی ترافیک سرورها

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

🔶 زیرساخت چندسروری روی سرور اختصاصی

برای ساخت معماری لود بالانسینگ به سرورهایی با منابع اختصاصی و شبکه پرسرعت نیاز دارید. سرورهای وب‌داده با پورت 10Gbit/s و حفاظت DDoS ارائه می‌شوند؛ مشخصات را در صفحه سرور اختصاصی ایران ببینید 👇

لود بالانسر چیست و چطور ترافیک را بین سرورها تقسیم می‌کند؟

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

به زبان ساده، Load Balancer چیست؟ تشبیه صف بانک

یک بانک شلوغ را در نظر بگیرید. اگر همه مشتری‌ها جلوی یک باجه صف بکشند، باجه‌های دیگر بیکار می‌مانند و صف طولانی می‌شود. دستگاه نوبت‌دهی همان لود بالانسر است: هر مشتری را به اولین باجه خالی می‌فرستد و اگر یک باجه تعطیل شود، دیگر کسی را به آن ارجاع نمی‌دهد. در این تشبیه، سرورها باجه‌ها هستند و الگوریتم توزیع بار، قانون نوبت‌دهی.
        Users 🌐
           ⬇️
  [ Virtual IP : 203.0.113.10 ]
           ⬇️
  [ Load Balancer (HAProxy) ]
     ⬇️         ⬇️         ⬇️
 [ web1 ✅ ]  [ web2 ✅ ]  [ web3 ❌ down ]
     ⬇️         ⬇️
     [ Database / Shared storage ]
در نمودار بالا، لود بالانسر با بررسی سلامت (Health Check) متوجه شده است که web3 پاسخ نمی‌دهد و ترافیک را فقط بین web1 و web2 تقسیم می‌کند. وقتی web3 دوباره چند بررسی پیاپی را با موفقیت پشت سر بگذارد، به چرخه برمی‌گردد و کاربران در این فاصله فقط به سرورهای سالم می‌رسند.

لایه ۴ یا لایه ۷؛ لود بالانسر در کدام لایه کار می‌کند؟

لود بالانسر لایه ۴ فقط آدرس IP و شماره پورت را می‌بیند و اتصال TCP یا UDP را بدون خواندن محتوایش به سرور مقصد می‌فرستد. این نوع سریع و سبک است و برای دیتابیس، ایمیل یا هر پروتکل غیر HTTP به کار می‌آید. لود بالانسر لایه ۷ درخواست HTTP را کامل می‌خواند و می‌تواند بر اساس آدرس، هدر یا کوکی تصمیم بگیرد؛ مثلاً درخواست‌های /api را به یک گروه سرور و تصاویر را به گروه دیگر بفرستد.
مستندات HAProxy همین تفاوت را در دو حالت کاری توضیح می‌دهد: در حالت TCP هر اتصال یک جریان داده ساده است، اما در حالت HTTP درخواست و پاسخ به‌طور کامل تحلیل می‌شوند تا بتوان تقریباً بر اساس هر محتوایی قانون تعریف کرد. هزینه این انعطاف، پردازش بیشتر روی لود بالانسر است.

بررسی سلامت سرورها (Health Check)

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

لود بالانسر چیست و چطور ترافیک را بین سرورها تقسیم می‌کند؟

🔸 نکته فنی: بررسی سلامت فعال و غیرفعال

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

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

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

۱- لود بالانسر سخت‌افزاری

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

۲- لود بالانسر نرم‌افزاری؛ HAProxy، Nginx و LVS

این نوع روی یک سرور لینوکسی معمولی اجرا می‌شود و روی سرورهای اختصاصی انتخاب رایج است. HAProxy یک لود بالانسر و پراکسی متن‌باز تخصصی است که از هر دو حالت TCP و HTTP پشتیبانی می‌کند؛ در زمان نگارش این مقاله، صفحه مستندات رسمی HAProxy نسخه 3.4 را آخرین نسخه LTS معرفی می‌کند. Nginx که بیشتر به‌عنوان وب‌سرور شناخته می‌شود، با بلوک upstream کار لود بالانسر HTTP را هم انجام می‌دهد و با ماژول stream اتصال‌های TCP و UDP را توزیع می‌کند.
گزینه سوم Keepalived است. طبق معرفی رسمی خودش، توزیع بار لایه ۴ را با ماژول IPVS هسته لینوکس انجام می‌دهد و پیاده‌سازی کامل VRRP (نسخه ۲ و ۳) را هم برای High Availability دارد. در بسیاری از معماری‌ها، Keepalived کنار HAProxy می‌نشیند: HAProxy بار را تقسیم می‌کند و اگر خود سرور لود بالانسر از کار بیفتد، Keepalived آدرس IP سرویس را به سرور دوم منتقل می‌کند.

۳- لود بالانسر ابری و DNS

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

الگوریتم‌های رایج توزیع بار

◀️ Round Robin: درخواست‌ها به نوبت بین سرورها پخش می‌شوند؛ روش پیش‌فرض Nginx است. در HAProxy این الگوریتم حداکثر از ۴۰۹۵ سرور فعال در هر backend پشتیبانی می‌کند.
◀️ Weighted Round Robin: سرور قوی‌تر وزن بیشتری می‌گیرد؛ در مثال مستندات Nginx، وقتی یک سرور وزن ۳ دارد و دو سرور دیگر وزن پیش‌فرض ۱، از هر ۵ درخواست ۳ مورد به سرور اول می‌رسد.
◀️ Least Connections: درخواست جدید به سروری می‌رود که کمترین اتصال فعال را دارد. مستندات HAProxy آن را برای نشست‌های طولانی مثل LDAP و SQL توصیه می‌کند و برای نشست‌های کوتاه HTTP چندان مناسب نمی‌داند.
◀️ Source / IP Hash: آدرس IP کاربر هش می‌شود تا هر کاربر همیشه به یک سرور برسد؛ در روش پیش‌فرض HAProxy، با تغییر تعداد سرورهای فعال این نگاشت برای بسیاری از کاربران عوض می‌شود.
◀️ URI و Header Hash: در HAProxy می‌توان آدرس درخواست یا یک هدر را هش کرد تا درخواست‌های یک آدرس همیشه به یک سرور برسند و از کش همان سرور پاسخ بگیرند.

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

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

جدول زیر الگوریتم‌های اصلی را بر اساس مستندات رسمی HAProxy و Nginx کنار هم می‌گذارد:
الگوریتمنحوه تصمیم‌گیریکاربرد مناسبنام در HAProxy / Nginx
Round Robinنوبتی و بر اساس وزنسرورهای هم‌توان و درخواست‌های کوتاهroundrobin / پیش‌فرض
Least Connectionsکمترین اتصال فعالنشست‌های طولانی، WebSocket و دیتابیسleastconn / least_conn
IP Hashهش IP کاربرنیاز به ماندن کاربر روی یک سرورsource / ip_hash
URI Hashهش آدرس درخواستکش و سرورهای محتواuri / hash
Randomانتخاب تصادفیمجموعه سرورهای بزرگ و متغیرrandom / random

مقایسه HAProxy، Nginx و Keepalived

این سه ابزار رقیب مستقیم نیستند و اغلب کنار هم استفاده می‌شوند. جدول زیر نقش هر کدام را خلاصه می‌کند:
ویژگیHAProxyNginx متن‌بازKeepalived
نقش اصلیلود بالانسر و پراکسیوب‌سرور و پراکسی معکوستوزیع لایه ۴ و IP شناور
لایه کاریلایه ۴ و ۷لایه ۷؛ با ماژول stream لایه ۴لایه ۴ (IPVS)
بررسی سلامت فعالدارد (check)فقط در NGINX Plusدارد (لایه ۴ تا ۷)
High Availabilityبا Keepalivedبا Keepalivedداخلی، با VRRP نسخه ۲ و ۳

طراحی High Availability با چند سرور اختصاصی؛ حذف نقطه شکست واحد

بسیاری از پروژه‌های لود بالانسینگ در اصل برای رسیدن به High Availability یا دسترس‌پذیری بالا راه می‌افتند؛ یعنی سرویس با خرابی هیچ جزء منفردی از کار نیفتد. برای همین باید «نقطه شکست واحد» (Single Point of Failure یا SPOF) را بشناسید: هر جزئی که اگر خراب شود، کل سرویس متوقف می‌شود. برای درک بهتر معیارهای پایداری، مقاله آپتایم چیست را هم بخوانید.
اما خود لود بالانسر هم می‌تواند نقطه شکست واحد باشد. اگر همه ترافیک از یک سرور HAProxy عبور کند و آن سرور خاموش شود، داشتن ده سرور وب سالم فایده‌ای ندارد. راه‌حل رایج، دو لود بالانسر و یک IP شناور است.

۱- دو لود بالانسر با IP شناور (VRRP و Keepalived)

در این الگو، دو سرور HAProxy داریم که Keepalived روی هر دو اجرا می‌شود. با پروتکل VRRP، یکی از آن‌ها Master می‌شود و IP مجازی سرویس را در اختیار می‌گیرد؛ دیگری در حالت Backup منتظر می‌ماند. اگر Master از دسترس خارج شود، Backup ظرف چند ثانیه IP را تحویل می‌گیرد و ترافیک بدون تغییر DNS ادامه پیدا می‌کند.

📚 آنچه استاندارد VRRP می‌گوید

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

۲- فعال/غیرفعال یا فعال/فعال؟

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

۳- لایه داده را فراموش نکنید

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

⚠️ محدودیت‌های مهم High Availability

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

سناریوی نمونه؛ فروشگاهی که در کمپین فروش کند می‌شود

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

طراحی High Availability با چند سرور اختصاصی؛ حذف نقطه شکست واحد

چه زمانی به لود بالانسر نیاز دارید و چطور شروع کنید؟

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

۱- نشانه‌های نیاز به لود بالانسر

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

۲- معماری حداقلی را طراحی کنید

یک معماری حداقلی و قابل‌اتکا شامل دو سرور لود بالانسر (HAProxy با Keepalived)، دو یا چند سرور اپلیکیشن و یک لایه داده مشترک است. در پروژه‌های کوچک‌تر، می‌توان HAProxy و وب‌سرور را روی یک سرور مشترک اجرا کرد، اما در این حالت منابع بین دو نقش تقسیم می‌شود. برای انتخاب ظرفیت شبکه هم مقاله پورت 1 گیگ یا 10 گیگ را ببینید.

۳- یک پیکربندی نمونه HAProxy

نمونه زیر یک لود بالانسر HTTP با الگوریتم Round Robin و بررسی سلامت روی مسیر /health را نشان می‌دهد. آدرس‌ها فرضی‌اند؛ پیش از استفاده، آن‌ها را با آدرس‌های شبکه خودتان جایگزین کنید:
frontend web_in
    bind *:80
    mode http
    default_backend web_servers

backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /health
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check
📌 یادتان باشد: پس از هر تغییر، فایل پیکربندی را با دستور haproxy -c -f /etc/haproxy/haproxy.cfg اعتبارسنجی کنید و بعد سرویس را reload کنید، نه restart، تا اتصال‌های جاری قطع نشوند.

۴- امنیت و شبکه را هم در نظر بگیرید

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

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

اگر می‌خواهید معماری چندسروری با HAProxy، Nginx و Keepalived را روی سرور اختصاصی بسازید، سرورهای وب‌داده این مشخصات را دارند:
✅ سرورهای HPE DL360 Gen9 با دو پردازنده Xeon E5-2680 v4، رم 64GB ECC و دیسک NVMe
✅ پورت 10Gbit/s روی شبکه‌ای با آپلینک 100Gbit برای ترافیک بین کاربران و لود بالانسر
✅ حفاظت DDoS با ظرفیت ۱۰۰ گیگابیت بر ثانیه، فایروال سخت‌افزاری و امنیت چندلایه
✅ خرید IPv4 اضافه از پنل کاربری (تا ۳ سابنت روی سرور اختصاصی ایران) و امکان IP Announcement رنج IP شخصی
✅ تحویل آنی پس از پرداخت و پنل مدیریت با کنسول KVM، ری‌استارت و نصب مجدد سیستم‌عامل
✅ بررسی پیکربندی سفارشی از طریق تیکت یا تماس و مشاوره پیش از خرید با تیم فنی ۲۴ ساعته
🚀 بیشتر بدانید: برای سفارش IP اضافه یا اجاره رنج IP، صفحه خدمات آی‌پی وب‌داده را ببینید و اگر درباره IP ثابت سرور سؤال دارید، مقاله آی‌پی اختصاصی چیست را بخوانید.

سوالات متداول درباره لود بالانسر

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

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

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

سه نوع اصلی سخت‌افزاری، نرم‌افزاری و ابری‌اند؛ Round Robin DNS هم ساده‌ترین روش است. برای شروع روی سرور اختصاصی، لود بالانسر نرم‌افزاری مثل HAProxy یا Nginx منطقی‌ترین انتخاب است؛ هزینه لایسنس ندارد، مستندات کاملی دارد و روی هر سرور لینوکسی اجرا می‌شود. نوع سخت‌افزاری معمولاً برای سازمان‌های بزرگ توجیه دارد.

اگر فقط توزیع بار می‌خواهید، HAProxy تخصصی‌تر است و بررسی سلامت فعال را در همان نسخه متن‌باز دارد. اگر علاوه بر توزیع بار به وب‌سرور، سرو فایل‌های استاتیک و کش هم نیاز دارید، Nginx گزینه چندکاره‌ای است؛ ولی بررسی سلامت فعالش فقط در NGINX Plus ارائه می‌شود. ترکیب رایج این است که HAProxy جلوی سرورها باشد و Nginx روی خود سرورهای وب.

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

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

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

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

جمع‌بندی؛ از یک سرور به معماری پایدار

پس اگر کسی بپرسد لود بالانسر چیست، جواب کوتاه این است: نقطه ورودی که درخواست‌ها را با الگوریتمی مثل Round Robin یا Least Connections بین چند سرور پخش می‌کند و با بررسی سلامت مداوم، سرور خراب را از چرخه بیرون می‌گذارد. برای اینکه خود لود بالانسر به نقطه شکست واحد تبدیل نشود، الگوی رایج دو سرور HAProxy با Keepalived و یک IP شناور است.
توصیه ما این است که پیش از خرید سرورهای بیشتر، گلوگاه واقعی را پیدا کنید، لایه داده را برای کار با چند سرور آماده کنید و بعد با یک معماری حداقلی شروع کنید. در کنار آن، بکاپ منظم و حفاظت شبکه را فراموش نکنید؛ چون High Availability جای هیچ‌کدام را نمی‌گیرد. سرورهای اختصاصی وب‌داده با پورت 10Gbit/s، حفاظت DDoS و امکان خرید IP اضافه، پایه مناسبی برای این مسیر هستند و تیم فنی شبانه‌روزی پیش از خرید، نیازتان را بررسی می‌کند.
اگر درباره طراحی لود بالانسر یا تعداد سرورهای لازم سوالی دارید، در بخش نظرات بپرسید؛ تیم فنی وب‌داده پاسخ می‌دهد.
منابع: Cloudflare Learning: What is load balancing?؛ HAProxy 3.4 Configuration Manual؛ nginx documentation: Using nginx as HTTP load balancer؛ nginx documentation: ngx_stream_upstream_module؛ Keepalived: Load balancing and high availability for Linux؛ IETF RFC 9568: Virtual Router Redundancy Protocol (VRRP) Version 3
به اشتراک بگذارید
وب داده
وب داده

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

مقاله‌ها: 197

نوشته‌ای مرتبط

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *