Load balancer چگونه کار می کند؟

Load balancing چیست؟ Load Balancer چگونه کارمی کند؟

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

مقدمه - معرفی Load Balancer

در بازار پویای امروزی که محور آن برنامه‌های کاربردی است، سازمان‌ها بیش از پیش تحت فشار هستند تا اطلاعات، خدمات و تجربه‌هایی را که مشتریان انتظار دارند، به‌سرعت، با قابلیت اطمینان بالا و به‌صورت ایمن ارائه دهند. عملکردهای کلیدی شبکه و اپلیکیشن مانند متعادل‌سازی بار (Load Balancing)، رمزنگاری، شتاب‌دهی (Acceleration) و امنیت، می‌توانند از طریق کنترل‌کننده‌های تحویل برنامه یا ADC‌ها (Application Delivery Controllers) ارائه شوند؛ تجهیزاتی فیزیکی یا مجازی که به‌عنوان پروکسی برای سرورهای فیزیکی عمل می‌کنند.

با انفجار تعداد برنامه‌های کاربردی و فشارهای ناشی از چرخه سخت‌گیرانه ادغام و استقرار مستمر (CI/CD)، جای تعجب نیست که بازار ADCها تا سال 2020 به حدود 2.9 میلیارد دلار در سال رسیده باشد.

اما پیش از آنکه به آینده نگاه کنیم، بهتر است بدانیم چطور به این نقطه رسیده‌ایم. متعادل‌سازی بار مبتنی بر شبکه، اساس عملکرد ADCها را تشکیل می‌دهد. در اواسط دهه 1990، اولین تجهیزات سخت‌افزاری Load Balancer به سازمان‌ها کمک کردند تا برنامه‌های خود را از طریق توزیع بار کاری بین سرورها و شبکه‌ها مقیاس‌پذیر کنند. این دستگاه‌ها در ابتدا مستقل از برنامه‌ها بودند و خارج از سرورهای برنامه قرار داشتند؛ به همین دلیل می‌توانستند با استفاده از روش‌های ساده شبکه، بار را متعادل کنند. اساس کار این دستگاه‌ها به این شکل بود که یک "آدرس IP مجازی" به دنیای بیرون ارائه می‌کردند و وقتی کاربری تلاش می‌کرد متصل شود، اتصال را با استفاده از ترجمه دوطرفه آدرس شبکه (bi-directional NAT) به مناسب‌ترین سرور واقعی هدایت می‌کردند.

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

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

ADCهای امروزی، نتیجه تکامل از Load Balancerهای اولیه از طریق فرایند مجازی‌سازی سرویس‌ها هستند. اکنون با نسخه‌های کاملاً نرم‌افزاری، ADCها می‌توانند نه‌تنها دسترس‌پذیری را افزایش دهند، بلکه به سازمان‌ها کمک کنند تا برنامه‌هایی مقیاس‌پذیر، با عملکرد بالا و ایمن ارائه دهند؛ درست همان چیزی که کسب‌وکار به آن نیاز دارد. با این حال، همه این خدمات مجازی‌شده، زیرساخت‌های اشتراکی و مسیر‌یابی هوشمند بدون پایه‌ای محکم در فناوری متعادل‌سازی بار امکان‌پذیر نبودند.

برای درک بهتر چگونگی مواجهه سازمان‌ها با چالش‌های پیچیده بازار در حال تغییر، بیایید پایه‌ی تحویل برنامه را بررسی کنیم: مبانی متعادل‌سازی بار – Load Balancing 101.

مفاهیم پایه: واژه‌نامه

پیش از ورود به جزئیات، بهتر است مفاهیم پایه و واژگان رایج در دنیای متعادل‌سازی بار (Load Balancing) را مرور کنیم. اگر همه‌ی تولیدکنندگان تجهیزات متعادل‌سازی بار از یک واژه‌نامه مشترک استفاده می‌کردند، این کار بسیار ساده‌تر بود؛ اما متأسفانه، هر تولیدکننده‌ای اصطلاحات خاص خود را دارد. با کمی توضیح، می‌توان این ابهام را برطرف کرد.

نود (Node)، میزبان (Host)، عضو (Member) و سرور (Server)

بیشتر کنترل‌کننده‌های تحویل برنامه (ADC) از مفاهیمی مانند نود، میزبان، عضو یا سرور استفاده می‌کنند. برخی هر چهار اصطلاح را دارند، ولی معانی آن‌ها لزوماً یکسان نیست. با این حال، همه‌ی این اصطلاحات تلاش می‌کنند دو مفهوم پایه را بیان کنند:

• مفهوم اول - که معمولاً با نام‌هایی مثل نود یا سرور شناخته می‌شود - اشاره به همان سرور فیزیکی یا مجازی دارد که ترافیک را از ADC دریافت می‌کند. این معادل آدرس IP سرور فیزیکی است؛ یعنی اگر Load Balancer در کار نباشد، همان IP که نام دامنه (مثلاً www.example.com) به آن resolve می‌شود. در ادامه‌ی این متن، از اصطلاح Host (میزبان) برای اشاره به این مفهوم استفاده می‌کنیم.

• مفهوم دوم - که بیشتر با عنوان Member (عضو) شناخته می‌شود (گرچه برخی شرکت‌ها به آن Node هم می‌گویند) - کمی دقیق‌تر از Host است و معمولاً شامل شماره پورت TCP برای برنامه‌ای است که قرار است ترافیک به آن برسد. مثلاً فرض کنید دامنه‌ی www.example.com به آدرس 172.16.1.10 اشاره دارد. این همان Host است. حالا اگر یک برنامه (مثلاً سرور وب) روی پورت 80 در حال اجرا باشد، Member به صورت 172.16.1.10:80 تعریف می‌شود.
  به‌عبارت ساده‌تر، Member ترکیبی از آدرس IP و شماره پورت برنامه است. در ادامه‌ی متن، این مفهوم را با عنوان Service (سرویس) معرفی می‌کنیم.

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

برای مثال، یک میزبان (172.16.1.10) می‌تواند چند سرویس داشته باشد: HTTP، FTP، DNS و غیره. با تعریف مجزای هر سرویس (مثلاً 172.16.1.10:80 برای HTTP، 172.16.1.10:21 برای FTP و 172.16.1.10:53 برای DNS)، ADC می‌تواند متعادل‌سازی بار و پایش سلامت (Health Monitoring) را برای هر سرویس به‌صورت جداگانه انجام دهد، نه فقط برای خود میزبان.

بنابراین، در اکثر تکنولوژی‌های مبتنی بر Load Balancing، یک اصطلاح نماینده‌ی میزبان (Host) یا سرور فیزیکی است و اصطلاح دیگر نماینده‌ی سرویس‌های در حال اجرا روی آن - که ما در این متن آنها را به ترتیب Host و Service می‌نامیم.

Pool، Cluster و Farm

یکی از اصول Load Balancing، توزیع ترافیک ورودی برنامه بین چندین مقصد در سمت سرور است - از جمله پیاده‌سازی‌هایی در فضای ابری خصوصی یا عمومی. بنابراین، باید مفهومی برای مجموعه‌ای از سرویس‌های مقصد وجود داشته باشد.

ما این مفهوم را Cluster (کلاستر) می‌نامیم (برخی آن را Pool یا Farm هم می‌نامند). کلاستر مجموعه‌ای از سرویس‌های مشابه است که روی یک یا چند میزبان اجرا می‌شوند.
برای مثال، همه‌ی سرویس‌هایی که صفحه‌ی اصلی وب‌سایت شرکت را ارائه می‌دهند در یک کلاستر به نام «صفحه اصلی وب‌سایت شرکت» قرار می‌گیرند و همه‌ی سرویس‌های تجارت الکترونیکی در کلاستر دیگری به نام «e-commerce» دسته‌بندی می‌شوند.

Virtual Server (سرور مجازی)

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

جمع‌بندی

با آشنایی با این مفاهیم، اکنون درک اولیه‌ای از سازوکار Load Balancing داریم. ADC، سرورهای مجازی را به دنیای بیرون نمایش می‌دهد. هر سرور مجازی به یک کلاستر از سرویس‌ها اشاره دارد که روی یک یا چند میزبان فیزیکی یا مجازی اجرا می‌شوند.

هرچند «شکل ۲» ممکن است نمایانگر یک پیاده‌سازی واقعی در دنیای واقعی نباشد، اما ساختار پایه‌ای مناسبی برای ادامه‌ی بحث درباره فرآیند متعادل‌سازی بار و تحویل برنامه ارائه می‌دهد.

نحوه عملکرد Load Balancing

با تعریف واژگان مشترک، حالا می‌توانیم یک تراکنش ساده از نحوه‌ی تحویل برنامه به کاربر را بررسی کنیم. همان‌طور که در تصویر نشان داده شده، کنترل‌کننده‌ی تحویل برنامه (ADC) معمولاً به‌صورت درون‌خطی (In-line) بین کلاینت و میزبان‌هایی قرار می‌گیرد که سرویس‌های مورد نیاز کلاینت را فراهم می‌کنند.
مانند بسیاری از موارد دیگر در تحویل برنامه، این موقعیت قرارگیری یک قانون سخت‌گیرانه نیست، بلکه بیشتر بهترین روش در پیاده‌سازی‌ها به‌شمار می‌رود.

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

فرآیند پایه‌ای تحویل برنامه به‌صورت زیر است:

• کلاینت تلاش می‌کند تا به سرویس متصل شود.

• ADC اتصال را می‌پذیرد و پس از تصمیم‌گیری درباره اینکه کدام میزبان باید اتصال را دریافت کند، آدرس IP مقصد (و در صورت لزوم پورت مقصد) را به IP و پورت سرویس انتخاب‌شده تغییر می‌دهد. (توجه داشته باشید که آدرس IP مبدأِ کلاینت تغییر نمی‌کند.)

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

• ADC بسته‌ی بازگشتی میزبان را دریافت کرده و حالا آدرس IP مبدأ (و در صورت لزوم پورت) را به IP و پورت سرور مجازی تغییر می‌دهد، سپس بسته را به کلاینت ارسال می‌کند.

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

این مثال ساده ممکن است در ظاهر ابتدایی به نظر برسد، اما چند نکته کلیدی در آن نهفته است. نخست، از دید کلاینت، همه چیز ساده است: بسته‌ها را به سرور مجازی می‌فرستد و پاسخ را از همان سرور دریافت می‌کند. دوم، فرآیند NAT انجام می‌شود. در این مرحله، ADC آدرس IP مقصدی را که کلاینت ارسال کرده (آدرس سرور مجازی) با آدرس IP میزبان واقعی که قرار است درخواست را دریافت کند، جایگزین می‌کند. سومین نکته همان چیزی‌ست که باعث می‌شود این NAT «دوطرفه» باشد: بسته‌ی بازگشتی از طرف میزبان دارای IP مبدأ میزبان است. اگر این IP بدون تغییر به کلاینت ارسال شود، کلاینت تصور می‌کند که پاسخ از منبعی ناشناخته آمده و آن را رد می‌کند. در نتیجه، Load Balancer با استفاده از اطلاعات مربوط به همان اتصال، آدرس مبدأ را به آدرس سرور مجازی بازنویسی کرده و مشکل را برطرف می‌کند.

تصمیم‌گیری در تحویل برنامه (Application Delivery)

در این مرحله، معمولاً دو سوال مطرح می‌شود:

• Load Balancer چگونه تصمیم می‌گیرد که اتصال به کدام میزبان ارسال شود؟

• اگر میزبان انتخاب‌شده در دسترس نباشد، چه اتفاقی می‌افتد؟

بیایید از سوال دوم شروع کنیم. اگر میزبان در دسترس نباشد، به درخواست پاسخ نمی‌دهد و اتصال در نهایت با Time Out مواجه می‌شود. این وضعیت قطعاً ایده‌آل نیست، زیرا تضمینی برای دسترس‌پذیری بالا (High Availability) فراهم نمی‌کند. به همین دلیل، بیشتر فناوری‌های Load Balancing شامل مانیتورینگ سلامت (Health Monitoring) هستند تا پیش از ارسال ترافیک، از فعال بودن میزبان‌ها اطمینان حاصل کنند.

مانیتورینگ سلامت در سطوح مختلفی انجام می‌شود:

• سطح پایه، صرفاً یک پینگ به خود میزبان می‌فرستد.

• سطح بالاتر، وضعیت سرویس‌ها را بررسی می‌کند، مثل برقراری اتصال TCP یا حتی تعامل واقعی با برنامه از طریق اسکریپت.

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

و حالا به سوال اول می‌رسیم: چگونه ADC تصمیم می‌گیرد که ترافیک به کدام سرویس ارسال شود؟

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

الگوریتم‌های متداول Load Balancing عبارت‌اند از:

• Round Robin: به ترتیب میزبان‌ها را انتخاب می‌کند.

• Least Connections: میزبان با کمترین اتصال فعال را انتخاب می‌کند.

• Dynamic Ratio: براساس عملکرد و پاسخ‌گویی واقعی میزبان‌ها تصمیم می‌گیرد.

در ADCهای پیشرفته‌تر، الگوریتم‌ها می‌توانند داده‌های مانیتورینگ را با هم ترکیب کنند تا وابستگی سرویس‌ها (Service Dependency) را هم در نظر بگیرند. مثلاً اگر میزبانی دو سرویس دارد و یکی از آن‌ها از کار بیفتد، سرویس دیگر نیز از فهرست حذف می‌شود، چون هر دو برای انجام کار کاربر مورد نیازند. این موضوع با پیچیده‌تر شدن خدمات تحت وب اهمیت بیشتری پیدا می‌کند.

آیا هر ترافیکی باید Load Balance شود؟

Load Balancer تنها در آغاز اتصال تصمیم می‌گیرد ترافیک به کدام میزبان برود، اما پس از آن باید بداند که آیا باید بقیه‌ی ترافیک را نیز Load Balance کند یا خیر.

دو چالش اصلی در این مرحله وجود دارد:

1. نگهداری اتصال (Connection Maintenance)
   در پروتکل‌هایی مثل FTP (پورت ۲۱) یا Telnet (پورت ۲۳) که اتصال بلندمدت TCP دارند، Load Balancer باید اطمینان حاصل کند که همه بسته‌ها به همان سرویس اولیه هدایت شوند. این کار نیازمند دو قابلیت است:

   1. حفظ جدول اتصال (Connection Table)

   2. مانیتور کردن اتصال و حذف آن پس از پایان ارتباط

2. پایداری یا چسبندگی اتصال (Persistence / Server Affinity)
   در بسیاری از موارد مانند HTTP (پورت ۸۰)، کلاینت چند اتصال کوتاه برقرار می‌کند که همگی به یک هدف مربوط می‌شوند (مثلاً خرید اینترنتی). در این شرایط مهم است که تمام اتصالات به یک میزبان خاص ارسال شوند و بین میزبان‌ها جابه‌جا نشوند.

روش‌های ایجاد Persistence:

• Keep-Alive: اتصالات کوتاه را به اتصال بلند مدت تبدیل می‌کند.

• Source IP Affinity: اتصال‌ها را براساس IP کلاینت به میزبان ثابت هدایت می‌کند.

• SSL Session ID: حتی با تغییر IP، اتصال به همان میزبان اولیه ادامه پیدا می‌کند.

• Cookie-Based: Cookie مخصوصی در مرورگر کلاینت درج می‌شود و در درخواست‌های بعدی به آن ارجاع می‌شود.

در ADCهای هوشمندتر، امکان بررسی محتوای بسته‌ها و ساخت جدول چسبندگی براساس داده‌هایی مثل نام کاربری هم وجود دارد. البته در این روش، سازمان باید اطمینان حاصل کند که این اطلاعات در هر درخواست وجود داشته باشند، در غیر این صورت ارتباط قطع می‌شود.

نتیجه‌گیری

در ابتدا، Load Balancer صرفاً برای توزیع بار و دسترسی‌پذیری طراحی شده بود. اما با پیشرفت فناوری، به یک پلتفرم جامع برای تحویل برنامه‌ها (Application Delivery) تبدیل شده است؛ پلتفرمی که نه‌تنها دسترسی، بلکه امنیت و کارایی برنامه‌ها را نیز تضمین می‌کند.

امروزه ADCها قابلیت‌هایی چون:

• تخلیه پردازش SSL/TLS

• کش (Caching)

• فشرده‌سازی

• مدیریت نرخ ترافیک

• دیواره آتش برای برنامه‌ها

• دسترسی از راه دور

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