Load Balancer هتزنر چیست؟

Hetzner Load Balancer جلوی سرورهای شما قرار می‌گیرد و درخواست‌های کاربران را بین چند سرور تقسیم می‌کند. به‌جای اینکه تمام ترافیک مستقیماً وارد یک VPS شود، کاربر ابتدا به Load Balancer متصل شده و سپس درخواست به یکی از Backend Serverها فرستاده می‌شود.
یک ساختار ساده می‌تواند به این شکل باشد:
User → Load Balancer → Server 1 / Server 2 / Server 3
این روش زمانی کاربردی است که ترافیک سایت یا اپلیکیشن بالا رفته و نمی‌خواهید کل سرویس به یک سرور وابسته باشد.

مثال ساده برای وردپرس

فرض کنید یک فروشگاه وردپرسی دارید و یک VPS دیگر پاسخگوی تمام کاربران نیست. می‌توانید چند Web Server مشابه مثل web-01، web-02 و web-03 داشته باشید و Load Balancer را جلوی آن‌ها قرار دهید.
در این حالت کاربر فقط به Load Balancer متصل می‌شود و درخواست‌ها در پشت صحنه بین سرورها پخش می‌شوند. اگر یکی از سرورها خراب شود، Health Check می‌تواند آن را از چرخه خارج کند.

بخش Targets چیست؟

در تصویر اول بخش Targets دیده می‌شود. Target همان سروری است که Load Balancer باید درخواست را به آن ارسال کند.
با انتخاب Add targets سه گزینه دیده می‌شود:
Cloud Server: برای اضافه کردن مستقیم VPSهای Hetzner Cloud.
Label: برای انتخاب خودکار سرورها بر اساس Label.
Dedicated Server: برای استفاده از سرور اختصاصی به‌عنوان Target، در صورتی که شرایط حساب و شبکه اجازه دهد.
Targetها باید از نظر Network Zone با Load Balancer سازگار باشند.

Cloud Server چه کاربردی دارد؟

اگر چند VPS داخل Hetzner Cloud دارید، ساده‌ترین روش استفاده از Cloud Server است.
مثلاً:
web-01
web-02
web-03
این سه سرور را به Load Balancer اضافه می‌کنید تا ترافیک بین آن‌ها تقسیم شود. اگر Load Balancer و سرورها داخل یک Private Network قرار داشته باشند، می‌توانید ارتباط Backend را از طریق Private IP انجام دهید.

استفاده از Private Network

برای سرویس‌های واقعی بهتر است در صورت امکان ارتباط Load Balancer با Backend Serverها از طریق Private Network انجام شود:
Internet → Load Balancer → Private Network → Web Servers
در این ساختار کاربران مستقیماً با Backendها ارتباط ندارند و Load Balancer درخواست‌ها را از طریق شبکه خصوصی به سرورها منتقل می‌کند.

گزینه Label چیست؟

اگر تعداد Serverها زیاد باشد، می‌توانید به‌جای انتخاب دستی از Label استفاده کنید.
برای مثال روی تمام Web Serverها قرار دهید:
role=web
سپس Load Balancer می‌تواند سرورهای دارای همین Label را به‌عنوان Target شناسایی کند. برای پروژه‌های کوچک انتخاب مستقیم Cloud Server راحت‌تر است، اما Label در زیرساخت‌های بزرگ و اتوماتیک بسیار کاربردی است.

بخش Services چیست؟

تصویر دوم مربوط به Services است. اینجا مشخص می‌کنید Load Balancer درخواست را روی چه Protocol و Port دریافت کند و آن را به کدام Port روی Target ارسال کند.
در تصویر تنظیمات به شکل زیر است:
Protocol: HTTP
Source Port: 80
Destination Port: 80
یعنی کاربر درخواست HTTP را روی Port 80 به Load Balancer می‌فرستد و Load Balancer همان درخواست را به Port 80 سرور Backend منتقل می‌کند.

Source Port و Destination Port چه تفاوتی دارند؟

Source Port پورتی است که Load Balancer روی آن درخواست کاربران را دریافت می‌کند. Destination Port پورتی است که برنامه شما روی Backend Server اجرا می‌شود.
مثلاً اگر Node.js روی Port 3000 اجرا شود:
User → Load Balancer:80 → Server:3000
در این حالت Source Port را 80 و Destination Port را 3000 قرار می‌دهید.

Health Check چیست؟

Health Check بررسی می‌کند که هر Target سالم و آماده دریافت درخواست هست یا نه. اگر یک Server از دسترس خارج شود، Load Balancer می‌تواند ارسال ترافیک به آن را متوقف کند.
در تصویر تنظیمات Health Check شامل این موارد است:
Interval: 15s
Timeout: 10s
Retries: 3
Path: /
یعنی تقریباً هر 15 ثانیه وضعیت Target بررسی می‌شود و اگر پاسخ مناسب دریافت نشود، سرور می‌تواند Unhealthy در نظر گرفته شود.

بهتر است Health Check روی چه مسیری باشد؟

برای پروژه ساده مسیر / قابل استفاده است، اما در پروژه‌های حرفه‌ای بهتر است یک Endpoint مخصوص مثل زیر داشته باشید:
/health
یا:
/healthcheck
مثلاً وقتی همه بخش‌های برنامه سالم هستند این مسیر پاسخ 200 OK بدهد. اگر سرویس اصلی، دیتابیس یا Application مشکل داشت، پاسخ خطا برگردد تا Load Balancer متوجه شود آن Backend آماده نیست.

Status Codeهای Health Check

در تصویر عبارت 2??, 3?? دیده می‌شود؛ یعنی پاسخ‌های خانواده 2xx و 3xx می‌توانند در این تنظیم به‌عنوان پاسخ قابل قبول شناخته شوند.
مثلاً:
200 OK
204 No Content
301
302
برای Endpoint اختصاصی Health Check بهتر است معمولاً پاسخ مشخص 200 OK داشته باشید.

HTTP Timeout چیست؟

در تصویر مقدار HTTP Timeout: 50s دیده می‌شود. این مقدار مشخص می‌کند ارتباط HTTP تا چه زمانی می‌تواند در حالت انتظار باقی بماند.
برای سایت معمولی مقدار پیش‌فرض معمولاً کافی است، اما اگر API یا Uploadهای طولانی دارید ممکن است نیاز به تنظیم متفاوتی داشته باشید.

Sticky Sessions چیست؟

در تصویر Sticky Sessions: Disabled است. Sticky Session باعث می‌شود درخواست‌های یک کاربر تا حد امکان به همان Backend Server قبلی ارسال شوند.
مثلاً اگر User A ابتدا به Server 1 فرستاده شود، درخواست بعدی او نیز ترجیحاً به همان Server برود.
برای WordPress الزاماً لازم نیست Sticky Session فعال شود. اگر معماری شما درست طراحی شده باشد، Session، فایل‌ها و دیتابیس نباید به یک Web Server خاص وابسته باشند.

Proxy Protocol چیست؟

در تصویر Proxy Protocol: Disabled است. وقتی Load Balancer جلوی Server قرار دارد، Backend ممکن است IP خود Load Balancer را ببیند. Proxy Protocol می‌تواند اطلاعات Connection اصلی از جمله IP واقعی کاربر را به Backend منتقل کند.
این گزینه را فقط زمانی فعال کنید که Nginx، HAProxy یا Application شما برای دریافت Proxy Protocol تنظیم شده باشد. فعال کردن آن بدون تنظیم Backend ممکن است باعث اختلال در سرویس شود.

IP واقعی کاربر در HTTP

برای HTTP و HTTPS معمولاً Headerهایی مانند X-Forwarded-For برای انتقال IP اصلی کاربر استفاده می‌شوند.
برای مثال Backend می‌تواند از:
X-Forwarded-For
برای تشخیص Client IP استفاده کند. بنابراین در بسیاری از پروژه‌های HTTP نیازی به فعال کردن Proxy Protocol نیست.

بخش Algorithm چیست؟

تصویر سوم مربوط به Algorithm است. Algorithm مشخص می‌کند درخواست‌های جدید چگونه بین Targetهای سالم تقسیم شوند.
دو گزینه اصلی دیده می‌شود:
Round Robin
Least Connections
در تصویر Round Robin انتخاب شده است.

Round Robin چیست؟

در Round Robin درخواست‌ها به‌ترتیب بین Serverها تقسیم می‌شوند.
مثلاً اگر سه Server داشته باشید:
درخواست 1 → Server 1
درخواست 2 → Server 2
درخواست 3 → Server 3
درخواست 4 → Server 1
و این چرخه ادامه پیدا می‌کند.
اگر Serverهای شما تقریباً منابع و قدرت یکسانی داشته باشند، Round Robin انتخاب ساده و مناسبی است.

Least Connections چیست؟

در Least Connections درخواست جدید به سروری ارسال می‌شود که Connection فعال کمتری داشته باشد.
مثلاً:
Server 1 → 90 Connection
Server 2 → 70 Connection
Server 3 → 20 Connection
در این شرایط Server 3 شانس بیشتری برای دریافت درخواست جدید دارد.
این الگوریتم زمانی مفید است که مدت Connectionها با هم تفاوت زیادی داشته باشد.

Round Robin بهتر است یا Least Connections؟

اگر Serverها قدرت مشابهی دارند و Requestها کوتاه و تقریباً یکسان هستند، Round Robin انتخاب خوبی است.
اگر بعضی درخواست‌ها یا Connectionها مدت زیادی باز می‌مانند، Least Connections می‌تواند ترافیک را متعادل‌تر توزیع کند.
برای شروع یک سایت معمولی می‌توانید از Round Robin استفاده کنید و بعداً بر اساس رفتار واقعی سرورها تصمیم بگیرید.

Health Check چه ارتباطی با Algorithm دارد؟

Algorithm فقط بین Targetهای سالم تصمیم‌گیری می‌کند.
مثلاً:
Server 1 → Healthy
Server 2 → Unhealthy
Server 3 → Healthy
اگر Server 2 توسط Health Check ناسالم تشخیص داده شود، نباید درخواست جدید دریافت کند و ترافیک بین Server 1 و Server 3 تقسیم می‌شود.

بخش Labels چیست؟

پایین تصویر سوم بخش Labels قرار دارد. Labelها به‌صورت Key/Value برای مرتب‌سازی و مدیریت Resourceها استفاده می‌شوند.
مثلاً:
env=production
project=shop
role=frontend
team=web
اگر تعداد Server، Firewall، Network و Load Balancer زیاد شود، Labelها پیدا کردن Resourceهای مرتبط با هر پروژه را بسیار راحت‌تر می‌کنند.

یک تنظیم ساده برای دو Web Server وردپرسی

فرض کنید دو Server دارید:
web-01
web-02
هر دو را داخل یک Private Network با Load Balancer قرار می‌دهید.
تنظیم پیشنهادی ساده:
Targets: web-01 و web-02
Protocol: HTTP
Source Port: 80
Destination Port: 80
Health Check: /health
Algorithm: Round Robin
در این حالت درخواست کاربران بین هر دو Web Server تقسیم می‌شود.
برای سایت واقعی بهتر است HTTPS نیز تنظیم شود تا کاربران از Port 443 و اتصال SSL استفاده کنند.

مثال برای Node.js روی Port 3000

فرض کنید برنامه Node.js روی Port 3000 اجرا می‌شود ولی می‌خواهید کاربر سایت را بدون وارد کردن Port باز کند.
تنظیم می‌تواند این باشد:
Source Port: 80
Destination Port: 3000
ساختار:
User → Load Balancer:80 → Node.js Server:3000
بنابراین کاربر فقط example.com را باز می‌کند و Load Balancer درخواست را به Port 3000 Backend می‌فرستد.

آیا اضافه کردن Target به‌تنهایی کافی است؟

خیر. برای اینکه Load Balancer درست کار کند باید چند بخش همزمان درست تنظیم شده باشند:

• تمام Targetها Application موردنظر را اجرا کنند.
• Destination Port روی Serverها باز باشد.
• Firewall اجازه Connection از Load Balancer را بدهد.
• Health Check پاسخ صحیح دریافت کند.
• Database و فایل‌های موردنیاز بین Nodeها هماهنگ باشند.
• Session کاربران به یک سرور خاص وابسته نباشد، مگر اینکه Sticky Session استفاده شود.
• SSL و IP واقعی کاربران به‌درستی مدیریت شوند.

خلاصه تصاویر

Targets: مشخص می‌کند Load Balancer ترافیک را به کدام Serverها ارسال کند. می‌توانید Cloud Server، Label یا در شرایط مناسب Dedicated Server را انتخاب کنید.
Services: Protocol، Source Port، Destination Port، Health Check، HTTP Timeout، Sticky Sessions و Proxy Protocol را مشخص می‌کند. در تصویر HTTP از Port 80 به Port 80 تنظیم شده است.
Algorithm: مشخص می‌کند ترافیک چگونه بین Targetها تقسیم شود. Round Robin درخواست‌ها را به‌ترتیب پخش می‌کند و Least Connections سروری را ترجیح می‌دهد که Connection کمتری دارد.

جمع‌بندی

Hetzner Load Balancer برای زمانی مناسب است که یک سایت یا Application روی چند Server اجرا شود و نخواهید تمام سرویس به یک Node وابسته باشد.
در Targets سرورهای Backend را مشخص می‌کنید، در Services Protocol و Portها را تنظیم می‌کنید و با Health Check مطمئن می‌شوید فقط Serverهای سالم ترافیک دریافت می‌کنند.
در بخش Algorithm نیز می‌توانید بین Round Robin و Least Connections انتخاب کنید. برای چند Web Server مشابه، ترکیب Round Robin + Health Check + Private Network نقطه شروع مناسبی است.
Load Balancer به‌تنهایی High Availability کامل ایجاد نمی‌کند؛ Database، فایل‌ها، Sessionها و سایر بخش‌های Application نیز باید طوری طراحی شوند که خرابی یک Server کل سایت را از دسترس خارج نکند.