لودبالانسر

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

زمانی از Load Balancer استفاده کنید که یک وب‌سایت، API یا سرویس داخلی روی چند ابرک اجرا می‌شود و می‌خواهید:

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

شیوه‌ کار

Load Balancer ترافیک را از طریق Listener دریافت می‌کند. Listener مشخص می‌کند Load Balancer روی کدام پروتکل و پورت منتظر درخواست باشد. هر Listener یک Server Pool دارد که ابرک‌های مقصد، یعنی Memberها، در آن قرار می‌گیرند. Server Pool مشخص می‌کند درخواست به کدام پورت Member و با کدام الگوریتم فرستاده شود. برای نمونه، می‌توانید درخواست‌های HTTP ورودی روی پورت 80 را به پورت 8080 ابرک‌ها بفرستید.

هر Load Balancer یک آدرس مجازی (VIP) در شبکه‌ی خصوصی دارد. اگر Load Balancer را از نوع External بسازید، Elastic IP متصل به این آدرس نقطه‌ی ورود عمومی است و درخواست‌ها از اینترنت به آن می‌رسند. اما در حالت Internal، نقطه‌ی ورود خود Private VIP است و درخواست باید از مسیرهای مجاز داخل VPC به آن برسد.

Health Check به‌شکل دوره‌ای سلامت Memberها را بررسی می‌کند و برای هر درخواست دوباره اجرا نمی‌شود. وقتی درخواستی به Listener می‌رسد، Load Balancer فقط Memberهای سالم را در نظر می‌گیرد و الگوریتم انتخاب‌شده یکی از آن‌ها را انتخاب می‌کند. سپس درخواست از شبکه‌ی خصوصی به IP و پورت Member فرستاده می‌شود و پاسخ از مسیر Load Balancer به درخواست‌کننده برمی‌گردد. Memberها برای دریافت ترافیک از Load Balancer به IP عمومی نیاز ندارند.

پیش از شروع

برای ساخت Load Balancer این موارد را آماده کنید:

• یک VPC در ریجن موردنظر،
• یک Subnet که Load Balancer و Memberها در آن قرار بگیرند،
• دست‌کم یک ابرک آماده در همین Subnet که برنامه روی IP خصوصی و پورت مقصد آن در حال اجرا باشد،
• قوانین شبکه‌ای که اجازه‌ی رسیدن ترافیک Load Balancer به پورت مقصد ابرک‌ها را بدهند،
• تصمیم درباره‌ی عمومی یا خصوصی بودن نقطه‌ی ورود،
• یک مسیر Health Check که پاسخ قابل‌اعتماد و قابل‌تکرار بدهد، مانند health/.

پیش از ساخت Listener، از روی یکی از ابرک‌ها بررسی کنید که برنامه روی آدرس خصوصی و پورت موردنظر پاسخ می‌دهد و پاسخ Health Check فقط زمانی موفق است که برنامه آماده‌ی دریافت درخواست باشد. هم‌چنین مطمین شوید فایروال سیستم‌عامل و قوانین امنیتی VPC ترافیک Load Balancer را مسدود نمی‌کند.

ساخت Load Balancer

در پنل کاربری سرور ابری وارد بخش «لودبالانسر» شوید و روی دکمه‌ی «ساخت لودبالانسر» کلیک کنید. محل استقرار، اندازه، شبکه، Listener، Memberها و Health Check را در همین صفحه مشخص می‌کنید.

انتخاب AZ

در بخش «AZ»، دیتاسنتری را انتخاب کنید که می‌خواهید Load Balancer در آن ساخته شود. Load Balancer و ابرک‌های مقصد باید در یک Subnet و یک زون باشند، پس زون را متناسب با محل ابرک‌های برنامه انتخاب کنید.

انتخاب اندازه‌ی Load Balancer

در بخش «اندازه‌ی لودبالانسر»، ظرفیت متناسب با سرویس‌تان را انتخاب کنید. هر گزینه این اطلاعات را نشان می‌دهد:

• Concurrent Connection

  ظرفیت اتصال‌های هم‌زمان، یعنی تعداد اتصال‌هایی که هم‌زمان برقرار می‌مانند.

• SSL Connections Per Second

  ظرفیت برقراری اتصال‌های SSL در هر ثانیه.

• قیمت

  مبلغ نمایش‌داده‌شده برای گزینه‌ی انتخابی. هزینه‌ی منابع وابسته، مانند Elastic IP، جداگانه محاسبه می‌شود.

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

تعیین نوع دسترسی و شبکه

در بخش «دسترسی شبکه»، مشخص کنید چه کسانی باید به Load Balancer دسترسی داشته باشند:

• خارجی (External)

  برای وب‌سایت، API عمومی یا سرویسی که باید از اینترنت دردسترس باشد. نقطه‌ی ورود این نوع Elastic IP متصل به Load Balancer است. Memberها می‌توانند فقط آدرس خصوصی داشته باشند و برای هر کدام IP عمومی جداگانه نیاز نیست.

• داخلی (Internal)

  برای ارتباط بین سرویس‌ها یا لایه‌های خصوصی داخل شبکه‌ی VPC. نقطه‌ی ورود این نوع Private VIP است و برای دریافت ترافیک عمومی از اینترنت طراحی نشده است. کاربر باید از داخل VPC و مسیر مجاز شبکه به آن دسترسی داشته باشد.

سپس در بخش «VPC و ساب‌نت»، ابتدا VPC و بعد Subnet موردنظر را انتخاب کنید. Memberها باید در همین VPC و Subnet باشند.

انتخاب External ابرک‌های مقصد را عمومی نمی‌کند. ترافیک از نقطه‌ی ورود عمومی دریافت می‌شود و از شبکه‌ی خصوصی به Memberها می‌رسد.

توجه داشته باشید که Internal به معنی رایگان بودن منابع، امنیت خودکار برنامه یا دسترسی از هر شبکه‌ای نیست و هم‌چنان باید مسیر شبکه و قوانین دسترسی را درست تنظیم کنید.

تنظیم Listener

در بخش «Listener»، پروتکل و پورت ورودی را مشخص کنید. دست‌کم یک Listener باید تعریف شود.

• پروتکل

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

• پورت

  پورت ورودی باید عددی بین 1 تا 65535 باشد.

برای نمونه، برای دریافت ترافیک HTTP روی پورت 80، پروتکل HTTP و پورت 80 را انتخاب کنید. انتخاب شماره‌ی پورت به‌تنهایی پروتکل یا رمزنگاری اتصال را تعیین نمی‌کند. برای نمونه، وارد کردن پورت 443 به‌تنهایی HTTPS را فعال نمی‌کند.

در «تنظیمات پیشرفته» این موارد نمایش داده می‌شوند:

• Client Data Timeout

  زمان انتظار برای داده در سمت کاربر. واحد نمایش‌داده‌شده میلی‌ثانیه است.

• Member Data Timeout

  زمان انتظار برای داده در سمت مقصد. واحد نمایش‌داده‌شده میلی‌ثانیه است.

• حداکثر تعداد کانکشن

  سقف تعداد اتصال‌ها برای Listener. این مقدار ظرفیت انتخاب‌شده‌ی Load Balancer را افزایش نمی‌دهد.

اگر پنل برای پورت ورودی خطای تکراری بودن نشان داد، Listener موجود را ویرایش کنید یا پورت دیگری انتخاب کنید.

تنظیم Server Pool

در بخش «Server Pool»، پورت برنامه روی ابرک‌های مقصد و الگوریتم توزیع ترافیک را مشخص کنید.

• پورت مقصد

  پورتی که برنامه روی Memberها به آن گوش می‌دهد. این پورت می‌تواند با پورت ورودی Listener متفاوت باشد. برای نمونه، پورت ورودی 80 و پورت مقصد 8080. مقدار را باید همان پورتی وارد کنید که برنامه روی آن در حال اجراست.

• الگوریتم

  روش انتخاب Member بعدی برای دریافت درخواست.

• Session Persistence

  اگر برنامه باید درخواست‌های یک IP مبدا را همیشه به Member یکسان بفرستد، گزینه‌ی «Session Persistence بر اساس IP مبدا» را بررسی و اگر به آن نیاز دارد فعال کنید.

الگوریتم را از میان این گزینه‌ها انتخاب کنید:

• Round Robin

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

• Least Connections

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

• Source IP

  Member را بر پایه‌ی IP مبدا انتخاب می‌کند. با تغییر مجموعه‌ی Memberها ممکن است این نگاشت تغییر کند. برای سناریوهای وابسته به IP مبدا مناسب است.

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

انتخاب ابرک‌های مقصد

در بخش «ابرک»، دست‌کم یک ابرک برای Server Pool انتخاب کنید. فقط ابرک‌های VPC و Subnet انتخاب‌شده در فهرست نمایش داده می‌شوند. در کادر جست‌وجو ابرک موردنظر را پیدا کنید و نام، آدرس IPv4 خصوصی و وزن آن را بررسی کنید. اگر فهرست خالی است، انتخاب VPC و Subnet و وجود ابرک در آن‌ها را بررسی کنید.

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

وزن (Weight) سهم نسبی Member در توزیع ترافیک است. اگر ابرک‌ها ظرفیت مشابهی دارند، برای شروع وزن یکسان در نظر بگیرید. وزن بیش‌تر ظرفیت خود ابرک را افزایش نمی‌دهد.

تنظیم Health Check

Health Check به این پرسش پاسخ می‌دهد: «آیا این Member اکنون آماده‌ی دریافت ترافیک است؟» این بررسی درستی کامل برنامه، صحت داده‌ها یا سلامت وابستگی‌های کسب‌وکار را نشان نمی‌دهد.

در بخش «Health Check» این فیلدها را تنظیم کنید:

• پروتکل

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

• حداکثر تلاش ناموفق

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

• فاصله‌ی بررسی (ثانیه)

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

• Timeout (ثانیه)

  حداکثر زمان انتظار برای پاسخ هر بررسی. این مقدار را با زمان پاسخ طبیعی برنامه هماهنگ کنید.

• حداکثر تلاش مجدد

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

توجه داشته باشید که Timeout و فاصله‌ی بررسی در این بخش بر حسب ثانیه‌اند. آن‌ها را با Timeoutهای Listener، که بر حسب میلی‌ثانیه نمایش داده می‌شوند، اشتباه نگیرید.

برای بررسی HTTP، یک Endpoint سبک و مشخص مانند health/ در برنامه در نظر بگیرید. این Endpoint باید:

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

توجه داشته باشید که اگر Health Check را به صفحه‌ای وصل کنید که برای کاربر عادی ساخته شده یا همیشه پاسخ موفق می‌دهد، ممکن است Load Balancer Member را سالم تشخیص دهد، در حالی که مسیر واقعی برنامه مشکل دارد.

پس از ساخت، وضعیت هر Member یکی از این مقادیر است:

• Healthy

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

• Unhealthy

  بررسی‌ها ناموفق بوده‌اند و Load Balancer ممکن است Member را از توزیع خارج کند.

• در حال بررسی

  هنوز برای نتیجه‌گیری به تعداد کافی بررسی انجام نشده است.

تغییر وضعیت بلافاصله پس از اصلاح برنامه رخ نمی‌دهد، چون فاصله‌ی بررسی و تعداد تلاش‌ها روی زمان تشخیص اثر می‌گذارند.

اگر Member ناسالم است، ابتدا IP خصوصی و پورت آن را بررسی کنید. سپس برنامه را از داخل همان شبکه و روی همان پورت آزمایش کنید، قوانین امنیتی VPC و فایروال سیستم‌عامل را بررسی کنید و آدرس و پورت Health Check را با برنامه تطبیق دهید. در پایان کد وضعیت و زمان پاسخ Endpoint را بررسی کنید.

اگر همه‌ی Memberها سالم‌اند اما برنامه خطا دارد، Health Check ممکن است فقط برقراری اتصال یا پاسخ یک مسیر را بررسی کند. وضعیت برنامه، وابستگی‌های آن، نشست کاربر، پایگاه داده و لاگ‌های سرویس را جداگانه بررسی کنید.

نام‌گذاری و تایید

در بخش «نام لودبالانسر»، یک نام مشخص و توصیفی وارد کنید. برای نمونه، web-prod-lb برای ورودی وب‌سایت در محیط پروداکشن.

سپس خلاصه‌ی تنظیمات را در ستون سمت چپ بررسی کنید. این خلاصه شامل AZ، اندازه و نوع دسترسی، VPC و Subnet، پروتکل و پورت Listener، پورت مقصد، الگوریتم و Memberهای انتخاب‌شده، تنظیمات Health Check، نام و مبلغ نمایش‌داده‌شده است. در پایان روی دکمه‌ی «ساخت لودبالانسر» کلیک کنید و منتظر تکمیل عملیات بمانید.

اگر Load Balancer ساخته نمی‌شود، VPC ،Subnet و AZ انتخاب‌شده را بررسی کنید و مطمین شوید منابع وابسته یا محدودیت منابع حساب‌تان مانع ساخت نیستند. اگر External را انتخاب کرده‌اید، وضعیت Elastic IP و سازگاری آن با VPC را هم بررسی کنید.

آزمایش سرویس

پس از تکمیل ساخت، وضعیت Load Balancer و Listener را در پنل بررسی کنید و مطمین شوید دست‌کم یک Member سالم است. سپس از شبکه‌ای که باید به سرویس دسترسی داشته باشد، چند درخواست سبک و پیاپی به آدرس ورودی و پورت Listener بفرستید. برای External از Elastic IP و برای Internal از Private VIP استفاده کنید. پاسخ برنامه و لاگ ابرک‌ها را بررسی کنید تا مطمین شوید ترافیک به Memberها می‌رسد.

اگر Source IP یا Session Persistence فعال باشد یا اتصال ماندگار داشته باشید، ممکن است همه‌ی درخواست‌ها به یک Member برسند. برابر نبودن تعداد درخواست‌ها به‌تنهایی نشانه‌ی خرابی نیست. اگر امکانش را دارید، یک Member آزمایشی را برای مدتی کوتاه از دسترس خارج کنید و رفتار Health Check را ببینید. این آزمایش را روی سرویس تولیدی بدون برنامه‌ی بازگشت انجام ندهید.

پاسخ موفق Load Balancer به‌تنهایی نشان نمی‌دهد که همه‌ی Memberها درست کار می‌کنند. وضعیت هر Member، لاگ برنامه و مسیر شبکه را جداگانه بررسی کنید.

اگر از بیرون به Load Balancer External دسترسی ندارید، Elastic IP متصل به آن را بررسی کنید و پورت Listener را با پورتی که در درخواست استفاده می‌کنید تطبیق دهید. هم‌چنین قوانین ورودی و مسیر درگاه شبکه را بررسی کنید و مطمین شوید دست‌کم یک Member سالم است.

اگر از یک سرویس داخلی به Load Balancer Internal دسترسی ندارید، مطمین شوید درخواست را از شبکه‌ی مجاز داخل VPC می‌فرستید و Private VIP و پورت Listener را درست استفاده می‌کنید. مسیر و قوانین دسترسی بین مبدا و Subnet مربوط به Load Balancer را هم بررسی کنید. عمومی نبودن سرویس به معنی دسترسی خودکار از هر Subnet یا شبکه‌ی متصل نیست.

نمونه‌ آموزشی: یک سرویس داخلی با دو مقصد

فرض کنید یک سرویس داخلی روی دو ابرک با آدرس‌های 10.20.1.10 و 10.20.1.11 در Subnet 10.20.1.0/24 و یک دیتاسنتر اجرا می‌شود و برنامه روی پورت 8080 پاسخ می‌دهد. برای این سرویس، Load Balancer را از نوع Internal بسازید، Listener را روی پروتکل HTTP و پورت 80 تنظیم کنید، پورت مقصد را 8080 بگذارید و الگوریتم Round Robin را انتخاب کنید. برای Health Check از پروتکل HTTP روی پورت 8080 استفاده کنید. اگر پنل فیلد مسیر و کد پاسخ را نمایش می‌دهد، مسیر health/ و پاسخ 200 را وارد کنید.

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

ابتدا از یک مبدا مجاز داخل VPC، پاسخ برنامه را روی هر دو ابرک بررسی کنید. سپس Load Balancer را بسازید و منتظر نتیجه‌ی پایش بمانید. برای آزمایش ورودی، با مرورگر یا ابزار HTTP به /<http://<PRIVATE_VIP درخواست بفرستید و <PRIVATE_VIP> را با آدرس اختصاص‌یافته‌ی واقعی جایگزین کنید.

توجه داشته باشید که HTTP در این نمونه فقط برای آزمایش در شبکه‌ی آزمایشی است. اطلاعات حساس یا ورود کاربران را روی اتصال بدون رمزنگاری آزمایش نکنید.

حذف Load Balancer

پیش از حذف Load Balancer، مصرف‌کننده‌های VIP را به آدرس دیگری منتقل کنید و Listenerها و Memberهای وابسته را بررسی کنید. اثر حذف را روی DNS، سرویس‌های وابسته و قوانین شبکه هم بررسی کنید. اگر Elastic IP به Load Balancer متصل است، وضعیت اتصال آن را طبق گزینه‌های پنل مدیریت کنید. سپس حذف را تایید کنید و تا پایان عملیات وضعیت منبع را پیگیری کنید.

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

محدودیت‌ها

آروان‌کلاد زیرساخت Load Balancer را مدیریت می‌کند. اجرای برنامه، تنظیمات شبکه و آماده بودن Memberها بر عهده‌ی شماست. Health Check به تصمیم مسیریابی کمک می‌کند، اما درست بودن منطق برنامه یا بازیابی از خرابی کامل یک دیتاسنتر را تضمین نمی‌کند. اگر همه‌ی Memberها ناسالم باشند، Health Check به‌تنهایی سرویس را بازیابی نمی‌کند.

محدودیت‌های Load Balancer این‌ها هستند:

• Load Balancer فقط در یک زون ساخته می‌شود و Load Balancer و Memberهای آن باید در یک Subnet باشند.
• Global Load Balancing، مسیریابی خودکار بین زون‌ها و توزیع بار بین چند Subnet پشتیبانی نمی‌شود.
• هر Listener فقط یک Server Pool دارد.
• Load Balancer ابرک یا برنامه‌ی شما را به‌شکل خودکار نمی‌سازد.
• Load Balancer جایگزین مقیاس‌دهی برنامه، پشتیبان‌گیری، طراحی بازیابی از خرابی (Disaster Recovery) یا اصلاح خطای برنامه نیست.