استفاده از Nginx به عنوان Load Balancer
سلام, اگر شما یه SysAdmin یا Developer هستید حتما با وب سرور Nginx آشنایی دارید. امروز توی این پست می خوام راهنماییتون کنم که چطور با Nginx یه Load Balancer ساده راه اندازی کنید.
آشنایی با مفهوم Load Balancing
خوب اجازه بدید خیلی ساده بگم چون احتمالا خودتون می دونید, Load Balancing یعنی تقسیم بار بین چند تا سرور, یعنی وظیفه ی پاسخ دادن به درخواست هایی که از سمت کلاینت میاد فقط به عهده ی یه سرویس دهنده نباشه و بین چند تا سرویس دهنده با الگوریتم های مختلف پخش بشه.
مزیت این کار چیه ؟ خوب اول اینکه سرویس شما همیشه در دسترس هست, چون اگر یکی از سرویس دهنده ها مشکل براش پیش بیاد بقیه سرویس دهنده ها جاش رو می گیرن, ولی اگه شما فقط ۱ سرویس دهنده داشته باشید و از دسترس خارج بشه کل سرویس شما ( مثلا وب سایت ) از کار میفته.
مزیت دومش اینه که می تونید منابعتون رو مدیریت شده مصرف کنید! یعنی نسبت به حجم باری که روی وب سایتتون هست تعداد سرویس دهنده ها رو کم یا زیاد کنید.
تا اینجا چند بار از مفهوم سرویس دهنده استفاده کردم, دلیل اینکه نگفتم سرور و گفتم سرویس دهنده پارسی رو پاس داشتن نبود... دلیلش این هست که وقتی می گیم سرور خود به خود یاد یه سرور HP G8 میفتیم با شونصد گیگ رم و ۸۰۰ تا CPU... اینطوری توی ذهنمون جا افتاده... در حالی که سرویس دهنده ( سرور ) ما می تونه یه VPS باشه, می تونه یه VM باشه یا حتی یه Docker Container.
پیاده سازی Load Balancing با استفاده از Nginx:
برای پیاده سازی Load Balancing ابزار های دیگه ای هم هست مثل HA Proxy, اما خوب راه انداختن Load Balancing با Nginx خیلی ساده هست.
بریم سر اصل مطلب, فرض کنید ما یه Rest API داریم که روی پورت 80 پاسخ می ده و می خوایم روی این سرویس API خودمون Load Balancing پیاده کنیم.
به مثال زیر نگاه کنید:
upstream api {
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
}
server {
listen 80;
location / {
proxy_pass http://api;
}
}
خوب چه اتفاقی داره اینجا میفته ؟ ما اینجا با استفاده از کلمه ی کلیدی server یه بلاک تعریف کردیم و توش مشخص کردیم که هر درخواستی روی پورت 80 رسید رو از طریق HTTP بفرست روی یه سرویسی به اسم api.
اما این api چی هست ؟ api یه بلاک دیگه توی Nginx هست که ما با استفاده از کلمه ی کلیدی upstream تعریفش کردیم, در واقع مرکز اصلی Load Balancing توی Nginx همین بلاک upstream هست. اون api هم که جلوی upstream نوشتیم یه اسم دلخواه هست و هر چیزی می تونه باشه.
خوب پس تا اینجا ما به پورت ۸۰ گوش کردیم و هر درخواستی که اومد سمت این پورت رو فرستادیم سمت یه upstream به اسم api. اما این چیزایی که توی upstream نوشتیم چی هست ؟ خوب همونطور که مشخصه و شما هم انسان باهوشی هستید احتمالا متوجه شدید که ما توی این upstream سه تا سرور ( سرویس دهنده ) تعریف کردیم, فرض کنید این سه تا ip در واقع ip سه تا VM هست و سرویس api ما روی هر سه تا ماشین بالاس.
همونطور که قبلا گفتم شما می تونید حتی از یه Docker Container هم یه عنوان سرویس دهنده استفاده کنید... خوب چجوری ؟ اجازه بدید یه دونه Container فرضی به استک سرویس دهنده هامون اضافه کنیم.
upstream api {
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
server 192.168.1.13:34800 // یه کانتینر که روی پورت 34800 جواب می ده
}
به همین راحتی!
حتی ما می تونیم پامون رو فراتر بزاریم و درخواستمون رو بفرستیم روی یه دامین دیگه!
upstream api {
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
server 192.168.1.13:34800 // یه کانتینر که روی پورت 34800 جواب می ده
server srv5.example.com; // اینجا
}
خوب اصل قضیه تموم شد! به همین راحتی شما یه Load Balancer دارید.
اما همونطور که گفتم Load Balancing الگوریتم های مختلفی داره, اینی که ما استفاده کردیم بهش می گن round-robin که در واقع درخواست ها رو نوبتی و به ترتیب می فرسته روی سرویس دهنده ها.
الگوریتم های دیگه ای هم هست مثل ip_hash که به اینصورت کار می کنه که هر یک کلاینت رو فقط به یه سرور وصل می کنه. یکی از کاربرد های مهم این الگوریتم این هست که شما می تونید session کاربر رو حفظ کنید ( مثلا لاگین بودن کاربر ).
مثال:
upstream api {
ip_hash; // مشخص کردن الگوریتم
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
}
خوب توضیحات من تموم شد, امیدوارم مفید بوده باشه! برای اطلاعات بیشتر می تونید این صفحه رو بخونید.
مطلبی دیگر از این انتشارات
JWT یا JSON Web Token چیست؟؟( قسمت دوم )
مطلبی دیگر از این انتشارات
مانیتورینگ Nginx با استفاده از Grafana
مطلبی دیگر از این انتشارات
es6در let