وقتی درخواست های زیادی به یک سایت یا برنامه می رسند، یک سرور ممکن است نتواند به تنهایی پاسخ گوی همه آنها باشد. لود بالانسر (Load Balancer) در مسیر ترافیک قرار می گیرد و درخواست ها را بر اساس قواعد مشخص میان چند سرور توزیع می کند. این کار به استفاده بهتر از ظرفیت سرورها کمک می کند و، در صورت طراحی و تنظیم درست، می تواند دسترس پذیری سرویس را بهبود دهد.
فهرست مطالب
خلاصه سریع: لود بالانسر در یک نگاه
لود بالانسر ابزاری برای هدایت ترافیک ورودی به چند سرور یا مقصد پردازشی است. به جای اینکه تمام درخواست ها به یک سرور برسند، لود بالانسر طبق یک روش انتخاب، مقصد هر درخواست را تعیین می کند. در بسیاری از پیاده سازی ها، وضعیت سلامت مقصدها نیز بررسی می شود تا درخواست های تازه به سرورهای سالم هدایت شوند. با این حال، لود بالانسر به تنهایی افزایش ظرفیت یا دسترس پذیری دائمی را تضمین نمی کند؛ تعداد و ظرفیت سرورها، تنظیمات بررسی سلامت و پایداری خود زیرساخت نیز موثرند.
لود بالانسر چیست؟
لود بالانسر یک ابزار یا سرویس است که در مسیر ترافیک قرار می گیرد و درخواست های کاربران را میان چند مقصد، مانند سرورهای اجرای یک برنامه، توزیع می کند. این ابزار می تواند نرم افزاری، سخت افزاری یا بخشی از خدمات یک ارائه دهنده ابری باشد.
فرض کنید یک فروشگاه اینترنتی روی سه سرور اجرا می شود. کاربر نشانی فروشگاه را باز می کند و درخواست او به لود بالانسر می رسد. لود بالانسر طبق تنظیمات خود، یکی از سرورهای مناسب را برای رسیدگی به آن درخواست انتخاب می کند. بنابراین کاربران لازم نیست نشانی هر سه سرور را بدانند و درخواست ها نیز مجبور نیستند همگی به یک سرور برسند.
توزیع بار همیشه به معنی تقسیم مساوی تعداد درخواست ها نیست. ممکن است سرورها ظرفیت متفاوتی داشته باشند یا روش انتخاب مقصد، تعداد اتصال های فعال و عوامل دیگری را در نظر بگیرد. این روش ها را در بخش الگوریتم های مقاله بررسی می کنیم.
تفاوت لود بالانسر و لود بالانسینگ چیست؟
این دو اصطلاح به هم مرتبط اند، اما معنی یکسانی ندارند:
لود بالانسر (Load Balancer): ابزار یا سرویسی که درخواست ها را دریافت می کند و به مقصد مناسب می فرستد.
لود بالانسینگ (Load Balancing): فرایند توزیع بار میان چند مقصد.
برای نمونه، در فروشگاه سه سروری بالا، جزء قرار گرفته در مسیر درخواست ها «لود بالانسر» است و تقسیم درخواست ها میان سرورها «لود بالانسینگ» نام دارد. دانستن این تفاوت کمک می کند هنگام بررسی انواع لود بالانسر و الگوریتم های آن، ابزار را با روش توزیع ترافیک اشتباه نگیریم.
چه زمانی به لود بالانسر نیاز داریم؟
لود بالانسر زمانی مطرح می شود که یک سرویس چند مقصد قابل استفاده داشته باشد و بخواهیم ترافیک ورودی را میان آنها هدایت کنیم. رشد تعداد کاربران، اجرای چند نسخه از یک برنامه و نیاز به ادامه پاسخ گویی هنگام خرابی یکی از سرورها، از موقعیت های رایج استفاده از آن هستند. در پیاده سازی هایی که بررسی سلامت تنظیم شده است، مقصد ناسالم می تواند از چرخه دریافت درخواست های تازه کنار گذاشته شود.
در مقابل، اگر سایت فقط روی یک سرور اجرا می شود، گذاشتن لود بالانسر در جلوی همان سرور به تنهایی ظرفیت پردازش را بیشتر نمی کند. انتخاب این راهکار باید بر اساس معماری برنامه، الگوی ترافیک و نیاز واقعی به دسترس پذیری انجام شود.
لود بالانسر چگونه کار می کند؟
لود بالانسر در مسیر ارتباط کاربر با سرورهای یک سرویس قرار می گیرد. وقتی کاربر صفحه ای را باز می کند یا درخواستی به برنامه می فرستد، درخواست ابتدا به نقطه ورودی سرویس می رسد. لود بالانسر سپس بر اساس تنظیمات خود، یک مقصد مناسب را از میان سرورهای آماده انتخاب می کند و ترافیک را به آن هدایت می کند.
برای درک این مسیر، همان فروشگاه اینترنتی بخش اول را در نظر بگیرید: فروشگاه روی سه سرور اجرا می شود، اما کاربر فقط یک نشانی از فروشگاه می بیند. لود بالانسر درخواست های رسیده به آن نشانی را دریافت می کند و تعیین می کند هر درخواست به کدام سرور برسد. روش انتخاب مقصد می تواند ساده، مانند انتخاب نوبتی سرورها، یا وابسته به وضعیت اتصال ها و ظرفیت تنظیم شده برای هر سرور باشد. جزئیات این روش ها را در بخش الگوریتم ها بررسی می کنیم.
مسیر یک درخواست از کاربر تا سرور
مسیر معمول یک درخواست را می توان در چهار گام خلاصه کرد:
۱. ارسال درخواست: کاربر نشانی سایت را باز می کند و مرورگر او درخواستی برای دریافت صفحه یا داده می فرستد.
۲. رسیدن به لود بالانسر: درخواست به نقطه ورودی سرویس می رسد؛ جایی که لود بالانسر ترافیک را دریافت می کند.
۳. انتخاب مقصد: لود بالانسر با توجه به تنظیمات، روش توزیع بار و وضعیت مقصدها، سروری را برای رسیدگی به درخواست انتخاب می کند.
۴. دریافت پاسخ: سرور انتخاب شده درخواست را پردازش می کند و پاسخ از مسیر تعریف شده در آن معماری به کاربر می رسد. شکل دقیق مسیر برگشت پاسخ، به نوع لود بالانسر و پیاده سازی آن بستگی دارد.
در این فرایند، کاربر معمولا با همان نشانی سایت کار می کند و لازم نیست بداند درخواستش را کدام سرور پردازش کرده است.
لود بالانسر از کجا می فهمد یک سرور آماده است؟
یکی از قابلیت های مهم در بسیاری از پیاده سازی ها، بررسی سلامت سرور یا Health Check است. لود بالانسر در فاصله های مشخص بررسی می کند که مقصدها شرایط پاسخ گویی را دارند یا نه. این بررسی، بسته به نوع سرویس و تنظیمات، می تواند اتصال به یک پورت یا دریافت پاسخ مناسب از یک مسیر مشخص در برنامه باشد.
برای مثال، ممکن است سرور فروشگاه روشن باشد، اما برنامه فروشگاه روی آن درست پاسخ ندهد. اگر بررسی سلامت فقط باز بودن یک پورت را بسنجد، شاید این مشکل را تشخیص ندهد. به همین دلیل باید بررسی سلامت را متناسب با عملکرد واقعی برنامه تنظیم کرد. بررسی سلامت به لود بالانسر برای انتخاب مقصد درخواست های تازه کمک می کند؛ در مقابل، مانیتورینگ سرور وضعیت منابع، عملکرد و خطاهای سرور را در طول زمان بررسی می کند تا تیم فنی بتواند علت اختلال را پیدا کند.
اگر مقصدی بر اساس قواعد تعیین شده ناسالم تشخیص داده شود، لود بالانسر می تواند ارسال درخواست های تازه به آن را متوقف کند و از مقصدهای آماده دیگر استفاده کند. پس از رفع مشکل و تایید دوباره سلامت، آن مقصد می تواند به چرخه دریافت ترافیک برگردد. رفتار دقیق هنگام ناسالم شدن همه مقصدها در همه محصولات یکسان نیست و باید برای ابزار انتخابی بررسی شود.
اگر یکی از سرورها از کار بیفتد چه می شود؟
فرض کنید فروشگاه روی سه سرور اجرا می شود و یکی از آنها از دسترس خارج می شود. اگر بررسی سلامت به درستی تنظیم شده باشد، لود بالانسر پس از تشخیص مشکل، درخواست های تازه را به دو سرور سالم هدایت می کند. این کار می تواند از قطع کامل سرویس جلوگیری کند، به شرط آنکه سرورهای باقی مانده ظرفیت کافی داشته باشند.
با این حال، لود بالانسر نمی تواند هر مشکلی را به تنهایی حل کند. اگر هر سه سرور، پایگاه داده مشترک یا خود مسیر ورود ترافیک دچار مشکل شود، وجود لود بالانسر به معنای دسترس پذیر ماندن سرویس نیست. بنابراین توزیع بار یکی از اجزای طراحی زیرساخت پایدار است و نتیجه نهایی به معماری کل سرویس بستگی دارد.
انواع لود بالانسر کدام اند؟
مهم ترین تفاوت فنی لود بالانسرها این است که برای انتخاب مقصد، چه اطلاعاتی از ارتباط کاربر را بررسی می کنند. برخی بر اساس اطلاعات اتصال شبکه تصمیم می گیرند و برخی می توانند جزئیات درخواست برنامه، مانند مسیر یک درخواست وب، را نیز در نظر بگیرند. این تفاوت معمولا با عنوان لود بالانسر لایه ۴ و لایه ۷ توضیح داده می شود.
لود بالانسر لایه ۴ چگونه کار می کند؟
لود بالانسر لایه ۴ در لایه انتقال شبکه کار می کند. این نوع برای هدایت ترافیک از اطلاعاتی مانند آدرس IP، پورت و نوع ارتباط استفاده می کند و برای انتخاب مقصد، نیازی به بررسی مسیر صفحه یا محتوای درخواست HTTP ندارد.
برای مثال، اگر چند سرور یک سرویس را روی یک پورت مشخص ارائه دهند، لود بالانسر لایه ۴ می تواند اتصال های ورودی را میان آن سرورها توزیع کند. این روش زمانی مناسب است که تصمیم گیری بر اساس اطلاعات اتصال کافی باشد یا بخواهیم ترافیک یک پروتکل را بدون تعریف قواعد مربوط به محتوای درخواست هدایت کنیم. البته امکانات دقیق هر محصول به نوع پیاده سازی آن بستگی دارد.
لود بالانسر لایه ۷ چگونه کار می کند؟
لود بالانسر لایه ۷ در لایه کاربرد کار می کند و می تواند برای هدایت درخواست های وب، اطلاعاتی مانند نام میزبان یا مسیر درخواست را بررسی کند. این قابلیت اجازه می دهد برای بخش های مختلف یک برنامه، قواعد متفاوتی تعریف شود.
فرض کنید یک سایت، بخش فروشگاه و بخش وبلاگ دارد. در یک پیاده سازی لایه ۷ می توان درخواست های مسیر /shop/ را به سرورهای فروشگاه و درخواست های مسیر /blog/ را به سرورهای وبلاگ فرستاد. این کار زمانی مفید است که مقصد درخواست به آدرس یا ویژگی های HTTP آن بستگی داشته باشد. نحوه رسیدگی به ترافیک HTTPS نیز به تنظیمات خاتمه TLS و معماری انتخاب شده وابسته است.
تفاوت لود بالانسر لایه ۴ و لایه ۷ چیست؟
| معیار | لایه ۴ | لایه ۷ |
|---|---|---|
| مبنای رایج تصمیم گیری | اطلاعات اتصال، مانند IP و پورت | اطلاعات درخواست برنامه، مانند نام میزبان و مسیر |
| نمونه کاربرد | توزیع اتصال ها میان چند مقصد یک سرویس | فرستادن مسیرهای مختلف سایت به گروه های متفاوت سرور |
| آگاهی از درخواست HTTP | برای تصمیم گیری به آن متکی نیست | می تواند از آن برای تصمیم گیری استفاده کند |
| انتخاب مناسب | وقتی قواعد مبتنی بر اتصال کافی است | وقتی به قواعد مبتنی بر درخواست نیاز داریم |
لایه ۷ همیشه انتخاب بهتر نیست. انتخاب میان این دو به نوع ترافیک، قواعد هدایت مورد نیاز، معماری برنامه و امکانات ابزار بستگی دارد. بعضی زیرساخت ها نیز از ترکیب چند نوع لود بالانسر در بخش های مختلف مسیر ترافیک استفاده می کنند.
لود بالانسر از نظر شیوه پیاده سازی چه انواعی دارد؟
لایه ۴ و لایه ۷ توضیح می دهند لود بالانسر چگونه درباره ترافیک تصمیم می گیرد. دسته بندی زیر به این مربوط است که راهکار چطور ارائه و مدیریت می شود.
لود بالانسر نرم افزاری
در این روش، توزیع ترافیک با نرم افزاری انجام می شود که روی سرور یا بخشی از زیرساخت اجرا می شود. Nginx و HAProxy از نمونه ابزارهایی هستند که می توان برای این کار به کار برد. مزیت این رویکرد، امکان تنظیم آن متناسب با معماری برنامه است؛ در مقابل، پیکربندی، پایش، تامین ظرفیت و پایداری اجرای آن نیز باید مدیریت شود. مستندات Nginx، توزیع درخواست های HTTP میان گروهی از سرورها را به عنوان یکی از کاربردهای آن توضیح می دهد.
لود بالانسر سخت افزاری
لود بالانسر سخت افزاری با استفاده از تجهیز اختصاصی در زیرساخت پیاده سازی می شود. انتخاب آن معمولا به نیازهای شبکه، امکانات محصول، ظرفیت مورد انتظار و شیوه مدیریت زیرساخت سازمان بستگی دارد. سخت افزاری بودن به تنهایی نشانه مناسب تر بودن یک راهکار نیست؛ باید قابلیت ها و هزینه کل نگهداری آن با نیاز پروژه سنجیده شود.
لود بالانسر ابری
در این روش، ارائه دهنده خدمات ابری امکان توزیع ترافیک را به عنوان بخشی از خدمات زیرساخت فراهم می کند. تیم فنی همچنان باید مواردی مانند مقصدها، قواعد هدایت و بررسی سلامت را متناسب با برنامه تنظیم کند، اما مدیریت بخش هایی از زیرساخت لود بالانسر بر عهده ارائه دهنده است. خدمات ابری نیز بسته به محصول می توانند انواع متفاوتی برای ترافیک شبکه و برنامه داشته باشند.
الگوریتم های توزیع بار چگونه کار می کنند؟
لود بالانسر پس از مشخص شدن مقصدهای قابل استفاده، برای هر درخواست یا اتصال جدید یکی از آنها را بر اساس روش تنظیم شده انتخاب می کند. بعضی روش ها سرورها را به نوبت انتخاب می کنند؛ بعضی تعداد اتصال های فعال را می سنجند؛ و بعضی از یک ویژگی ثابت، مانند نشانی کاربر، برای انتخاب مقصد استفاده می کنند.
همه ابزارها نام ها و امکانات یکسانی ندارند. برای مثال، معیار «کمترین اتصال فعال» با معیار «کمترین درخواست در حال پردازش» یکی نیست. هنگام انتخاب الگوریتم باید دید ابزار مورد استفاده دقیقا چه چیزی را اندازه می گیرد.
الگوریتم نوبتی یا Round Robin
در روش Round Robin، مقصدها به ترتیب انتخاب می شوند. اگر سه سرور آماده داشته باشیم، درخواست های پیاپی می توانند به ترتیب به سرور اول، دوم و سوم برسند و سپس انتخاب از ابتدا تکرار شود.
این روش ساده است و وقتی سرورها ظرفیت مشابهی دارند و زمان پردازش درخواست ها تفاوت زیادی ندارد، می تواند نقطه شروع مناسبی باشد. اما برابر بودن تعداد درخواست ها لزوما به معنی برابر بودن فشار کاری نیست: ممکن است یک درخواست در چند لحظه تمام شود و درخواست دیگر پردازش سنگینی داشته باشد.
الگوریتم نوبتی وزن دار یا Weighted Round Robin
اگر سرورها ظرفیت یکسانی نداشته باشند، می توان در ابزارهای پشتیبانی کننده برای آنها وزن تعیین کرد. در روش نوبتی وزن دار، سروری با وزن بیشتر سهم بیشتری از ترافیک می گیرد.
برای مثال، اگر سرور دوم از نظر ظرفیت قوی تر از سرور اول باشد، می توان وزن بالاتری برای آن تعریف کرد تا درخواست های بیشتری دریافت کند. البته وزن باید با توجه به ظرفیت واقعی و رفتار برنامه تنظیم شود؛ اختصاص وزن بالا به یک سرور، ظرفیت آن را افزایش نمی دهد. Nginx توزیع درخواست ها بر اساس وزن سرورها را در تنظیمات گروه سرورها پشتیبانی می کند.
الگوریتم کمترین اتصال فعال یا Least Connections
در روش Least Connections، اتصال جدید به سروری هدایت می شود که در زمان انتخاب، تعداد اتصال های فعال کمتری دارد. این روش می تواند برای سرویس هایی مفید باشد که اتصال ها مدت های متفاوتی باز می مانند؛ زیرا انتخاب صرفا بر اساس نوبت انجام نمی شود.
با این حال، کمتر بودن تعداد اتصال ها همیشه به معنی آزادتر بودن منابع سرور نیست. یک اتصال ممکن است کار سنگینی انجام دهد و اتصال دیگر تقریبا بیکار باشد. بنابراین نتیجه این الگوریتم نیز باید با داده های عملکردی سرویس بررسی شود.
انتخاب بر اساس درخواست های در حال پردازش
برخی لود بالانسرهای کاربردی می توانند مقصد را بر اساس تعداد درخواست هایی که هنوز پردازش آنها تمام نشده است انتخاب کنند. این معیار برای ترافیک درخواست و پاسخ HTTP مطرح است و نباید آن را با تعداد اتصال های باز یکی دانست؛ یک اتصال ممکن است در طول عمر خود چند درخواست را حمل کند. برای نمونه، AWS الگوریتم Least Outstanding Requests را در کنار روش نوبتی برای گروه های مقصد لود بالانسر کاربردی ارائه می کند.
این روش زمانی ارزش بررسی دارد که مدت پردازش درخواست ها متفاوت است. با این حال، تعداد درخواست های در جریان نیز تصویر کاملی از مصرف پردازنده، حافظه یا وضعیت پایگاه داده به دست نمی دهد.
انتخاب بر اساس نشانی کاربر یا هش
در روش های مبتنی بر هش، ویژگی مشخصی از درخواست یا اتصال برای انتخاب مقصد به کار می رود. یکی از نمونه ها استفاده از نشانی IP مبدا است تا درخواست های یک مبدا، تا جای ممکن، به همان سرور هدایت شوند. ابزارهایی مانند Nginx و HAProxy روش هایی از این نوع دارند.
این روش ممکن است برای برنامه ای که به حفظ ارتباط کاربر با یک مقصد نیاز دارد مفید باشد، اما نباید آن را راه حل قطعی مدیریت نشست دانست. چند کاربر می توانند پشت یک IP مشترک باشند، IP کاربر ممکن است تغییر کند و با تغییر تعداد سرورها، مقصد انتخاب شده نیز ممکن است عوض شود. برای اطلاعات مهم نشست کاربر، معماری برنامه باید به طور مستقل بررسی شود.
کدام الگوریتم برای یک پروژه مناسب تر است؟
پاسخ به نوع درخواست ها، ظرفیت سرورها و رفتار برنامه بستگی دارد:
اگر سرورها مشابه اند و درخواست ها رفتار نسبتا یکسانی دارند، روش نوبتی نقطه شروع ساده ای است.
اگر ظرفیت سرورها متفاوت است، روش وزن دار می تواند سهم ترافیک را با ظرفیت آنها هماهنگ تر کند.
اگر مدت اتصال ها تفاوت زیادی دارد، کمترین اتصال فعال ارزش بررسی دارد.
اگر تعداد درخواست های در حال پردازش برای سرویس معیار مناسب تری است، می توان روش مبتنی بر این تعداد را در ابزارهای پشتیبانی کننده ارزیابی کرد.
اگر هدایت تکراری یک کاربر یا مبدا به یک مقصد لازم است، باید روش های مبتنی بر هش و محدودیت های آنها بررسی شوند.
بهترین انتخاب را نمی توان فقط از نام الگوریتم تعیین کرد. پس از پیاده سازی، باید زمان پاسخ، نرخ خطا، تعداد اتصال ها و مصرف منابع هر سرور را زیر بار واقعی یا آزمون بار سنجید. اگر یکی از سرورها همچنان بیش از حد تحت فشار است، ممکن است لازم باشد وزن ها، الگوریتم، ظرفیت سرورها یا خود برنامه اصلاح شود.
لود بالانسر در زیرساخت دواپس چه کاربردی دارد؟
وقتی یک برنامه روی چند سرور یا چند نسخه هم زمان اجرا می شود، لود بالانسر یک نقطه ورود برای ترافیک فراهم می کند و درخواست ها را میان مقصدهای آماده هدایت می کند. این ساختار به تیم فنی اجازه می دهد ظرفیت سرویس را با اضافه کردن مقصدهای جدید توسعه دهد؛ البته مقصد تازه باید پیش از دریافت ترافیک، به درستی راه اندازی و آماده پاسخ گویی شده باشد.
لود بالانسر در زمان استقرار نسخه جدید هم کاربرد دارد. برای مثال، تیم فنی می تواند نسخه تازه برنامه را روی یک مقصد آماده کند، سلامت آن را بررسی کند و سپس طبق برنامه استقرار، ترافیک را به آن برساند. هنگام خارج کردن یک سرور از سرویس نیز باید به درخواست ها یا اتصال های در جریان توجه شود تا کاربران تا جای ممکن با اختلال روبه رو نشوند. روش اجرای این مراحل به ابزار لود بالانسینگ و معماری برنامه بستگی دارد.
افزایش ظرفیت و توزیع ترافیک
اگر تعداد کاربران افزایش یابد، می توان در یک معماری مناسب نسخه های بیشتری از برنامه اجرا کرد و آنها را به مجموعه مقصدهای لود بالانسر افزود. به این روش مقیاس پذیری افقی می گویند: ظرفیت با افزودن مقصدهای پردازشی بیشتر توسعه پیدا می کند.
البته اضافه کردن سرور همیشه گلوگاه را رفع نمی کند. اگر همه نسخه های برنامه به یک پایگاه داده وابسته باشند و مشکل اصلی در همان پایگاه داده باشد، افزودن سرورهای برنامه ممکن است تاثیر محدودی داشته باشد. برای تصمیم درست باید زمان پاسخ، نرخ خطا و مصرف منابع بخش های مختلف سرویس بررسی شود.
کمک به تداوم سرویس هنگام خرابی یک مقصد
وقتی یکی از مقصدها ناسالم تشخیص داده شود، لود بالانسر می تواند درخواست های تازه را به مقصدهای آماده دیگر هدایت کند. این قابلیت به تداوم پاسخ گویی کمک می کند، اما تنها در صورتی موثر است که مقصدهای باقی مانده ظرفیت کافی داشته باشند و اجزای مشترک، مانند پایگاه داده، نیز در دسترس باشند.
پایداری خود لود بالانسر هم بخشی از طراحی است. اگر تمام ترافیک از یک نقطه ورود عبور کند و آن نقطه از کار بیفتد، سالم بودن سرورهای پشت آن به تنهایی کافی نیست. به همین دلیل در سرویس های حساس، معماری نقطه ورود و شیوه بازیابی آن نیز باید بررسی شود.
برای شناخت نقش افزونگی، تشخیص خرابی و انتقال سرویس در حفظ دسترسی کاربران، مقاله معماری دسترس پذیری بالا را بخوانید.
آیا Nginx می تواند لود بالانسر باشد؟
بله. Nginx علاوه بر نقش وب سرور، می تواند درخواست های HTTP را به گروهی از سرورهای پشت خود بفرستد و ترافیک را میان آنها توزیع کند. در پیکربندی آن، مقصدها در یک گروه تعریف می شوند و روش توزیع بار متناسب با نیاز سرویس انتخاب می شود. برای نمونه، Nginx از روش هایی مانند توزیع نوبتی و کمترین اتصال فعال پشتیبانی می کند.
اینکه یک ابزار چند قابلیت دارد، به معنی یکسان بودن نقش آن قابلیت ها نیست. Nginx ممکن است در یک پروژه محتوای وب را ارائه دهد و در پروژه ای دیگر درخواست ها را به چند سرور برنامه هدایت کند. اگر می خواهید نقش وب سرور و جایگاه Nginx را در مقایسه با Apache بهتر بشناسید، مقاله مقایسه Nginx و Apache سربروس این تفاوت ها را توضیح می دهد.
هنگام انتخاب Nginx برای توزیع بار باید امکانات مورد نیاز پروژه را در نسخه و پیکربندی مورد استفاده بررسی کرد. برای مثال، شیوه بررسی سلامت مقصدها در همه نسخه ها و روش های پیکربندی آن یکسان نیست.
لود بالانسر در Kubernetes چه نقشی دارد؟
در Kubernetes، برنامه می تواند در چند Pod اجرا شود و یک Service مسیر پایداری برای دسترسی به مجموعه Podهای مرتبط فراهم کند. اگر لازم باشد یک Service از بیرون کلاستر در دسترس قرار بگیرد، یکی از گزینه ها استفاده از نوع LoadBalancer است؛ پشتیبانی و شیوه فراهم شدن لود بالانسر خارجی به محیط اجرای کلاستر و ارائه دهنده زیرساخت بستگی دارد.
برای ترافیک وب، ممکن است قواعد هدایت بر اساس نام دامنه یا مسیر نیز لازم باشد. در چنین سناریویی، Ingress همراه با یک کنترلر مناسب می تواند دسترسی HTTP و HTTPS به سرویس های داخل کلاستر را مدیریت کند. بنابراین نباید Service از نوع LoadBalancer و Ingress را دو نام برای یک تنظیم واحد دانست؛ هر کدام در معماری دسترسی به سرویس نقش خود را دارند.
اگر با مفهوم Pod، Service و ساختار کلاستر آشنا نیستید، ابتدا مقاله کوبرنتیز چیست؟ را بخوانید؛ سپس تفاوت مسیر ترافیک داخل کلاستر و ورود ترافیک از بیرون روشن تر می شود.
هنگام پیاده سازی لود بالانسر به چه نکاتی توجه کنیم؟
پیش از انتخاب ابزار یا سرویس لود بالانسینگ، این پرسش ها باید برای همان پروژه پاسخ داده شوند:
مقصدها چه زمانی آماده دریافت ترافیک هستند؟ بررسی سلامت باید با عملکرد واقعی برنامه هماهنگ باشد.
با خارج شدن یک مقصد چه می شود؟ ظرفیت مقصدهای باقی مانده و وضعیت درخواست های در جریان باید بررسی شود.
نشست و داده کاربر کجا نگهداری می شود؟ برنامه نباید بدون طراحی مشخص، به باقی ماندن همیشگی کاربر روی یک سرور وابسته باشد.
گلوگاه واقعی کجاست؟ افزایش تعداد سرورهای برنامه، مشکل پایگاه داده یا سرویس مشترک را خودکار حل نمی کند.
خود نقطه ورود چقدر پایدار است؟ خرابی لود بالانسر یا مسیر دسترسی به آن نیز باید در طراحی سرویس در نظر گرفته شود.
موفقیت را چگونه می سنجیم؟ زمان پاسخ، نرخ خطا، وضعیت مقصدها و توزیع بار باید پس از راه اندازی پایش شوند.
پاسخ این پرسش ها تعیین می کند پروژه به چه نوع لود بالانسر، چه الگوریتمی و چه سطحی از ظرفیت و افزونگی نیاز دارد. در بخش ششم، نکات اصلی را جمع بندی می کنیم و به پرسش های رایج پاسخ می دهیم.
جمع بندی؛ چه زمانی از لود بالانسر استفاده کنیم؟
لود بالانسر درخواست های ورودی را میان چند مقصد آماده توزیع می کند. این قابلیت زمانی ارزشمند است که یک برنامه روی چند سرور یا چند نسخه اجرا شود و بخواهیم ترافیک را مدیریت کنیم، ظرفیت را با افزودن مقصدهای جدید توسعه دهیم یا هنگام خرابی یک مقصد، درخواست های تازه را به مقصدهای دیگر برسانیم.
انتخاب راهکار مناسب از نام ابزار شروع نمی شود؛ ابتدا باید مشخص شود سرویس چه نوع ترافیکی دارد، مقصدها چگونه آماده بودن خود را نشان می دهند، چه میزان قطعی قابل قبول است و گلوگاه واقعی زیرساخت کجاست. سپس می توان درباره لایه ۴ یا ۷، شیوه پیاده سازی و الگوریتم توزیع بار تصمیم گرفت. پس از راه اندازی نیز زمان پاسخ، نرخ خطا و وضعیت مقصدها باید پایش شوند تا مشخص شود توزیع ترافیک در عمل به هدف پروژه رسیده است یا نه.
سوالات متداول درباره لود بالانسر
آیا لود بالانسر سرعت سایت را بیشتر می کند؟
گاهی می تواند به حفظ عملکرد سایت زیر بار کمک کند، اما افزایش سرعت را تضمین نمی کند. اگر کندی به دلیل فشار بیش از حد روی یک سرور برنامه باشد، توزیع درخواست ها میان چند سرور با ظرفیت کافی می تواند مفید باشد. اگر گلوگاه در پایگاه داده، کد برنامه یا یک سرویس مشترک باشد، افزودن لود بالانسر به تنهایی مشکل را برطرف نمی کند.
آیا برای استفاده از لود بالانسر حتما به چند سرور نیاز است؟
برای بهره بردن از توزیع بار میان سرورها، باید بیش از یک مقصد قابل استفاده وجود داشته باشد. می توان لود بالانسر را در جلوی یک مقصد نیز قرار داد، اما در آن حالت تقسیم ترافیک میان چند مقصد انجام نمی شود و خرابی همان مقصد همچنان می تواند سرویس را مختل کند.
آیا لود بالانسر مانع قطعی سایت می شود؟
لود بالانسر می تواند اثر خرابی یکی از مقصدها را کاهش دهد، به شرط آنکه مشکل به موقع تشخیص داده شود و مقصدهای دیگر سالم و دارای ظرفیت کافی باشند. اما خرابی پایگاه داده مشترک، از دسترس خارج شدن همه مقصدها یا اختلال در خود مسیر ورود ترافیک همچنان می تواند باعث قطعی شود. بنابراین دسترس پذیری بالا به طراحی کل زیرساخت وابسته است.
تفاوت لود بالانسر و Reverse Proxy چیست؟
Reverse Proxy در جلوی سرورها قرار می گیرد، درخواست کاربر را دریافت می کند و آن را به سرور پشت خود می فرستد. لود بالانسینگ یکی از کارهایی است که بعضی Reverse Proxyها می توانند انجام دهند: انتخاب مقصد از میان چند سرور و توزیع ترافیک بین آنها. برای مثال، Nginx می تواند هم در نقش Reverse Proxy و هم برای توزیع درخواست های HTTP میان چند سرور پیکربندی شود. پس نام این دو، دو قابلیت مرتبط را توصیف می کند و همیشه به دو دستگاه جداگانه اشاره ندارد.
لود بالانسر لایه ۴ بهتر است یا لایه ۷؟
هیچ کدام برای همه پروژه ها بهتر نیست. اگر انتخاب مقصد بر اساس اطلاعات اتصال، مانند IP و پورت، کافی باشد، لایه ۴ می تواند نیاز پروژه را برآورده کند. اگر لازم است درخواست های وب بر اساس نام دامنه یا مسیر به مقصدهای متفاوت بروند، قابلیت های لایه ۷ مناسب تر است. انتخاب نهایی به نوع ترافیک و قواعدی بستگی دارد که برنامه واقعا نیاز دارد.
کدام الگوریتم توزیع بار بهترین است؟
الگوریتم واحدی برای همه سرویس ها بهترین نیست. روش نوبتی برای شروع در میان سرورهای مشابه ساده است؛ روش وزن دار می تواند ظرفیت متفاوت سرورها را در نظر بگیرد؛ و کمترین اتصال فعال برای اتصال هایی با مدت متفاوت قابل بررسی است. نتیجه هر انتخاب باید با داده های عملکردی همان سرویس سنجیده شود.
برای طراحی زیرساخت پایدار به کمک نیاز دارید؟
اگر سایت یا برنامه شما با افزایش ترافیک، کندی یا قطعی روبه رو است، ابتدا باید مشخص شود مشکل از ظرفیت سرورها، تنظیمات توزیع بار، پایگاه داده یا بخش دیگری از زیرساخت ناشی می شود. تیم سربروس می تواند معماری فعلی را بررسی کند و بر اساس نیاز پروژه، راهکار مناسبی برای مدیریت ترافیک، پایش و پایداری سرویس پیشنهاد دهد.
