Load Balancer و 5 روش توزیع بار

Load Balancer موضوعی هست که از زمانی که وارد این حیطه شدم، یکی از موضوعات تکراری هست که خیلی درباره ش ازم سوال پرسیده میشه! مثلا اینکه چطوری میتونیم کاری کنیم که سایتمون تحت هیچ شرایطی از دسترس خارج نشه؟ و همیشه سرعت و کیفیتش پایدار بمونه ؟

مقدمه راه اندازی لودبالانسر

مقدمه

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

برای شروع باز هم یه سری سوالات پرتکرار رو مطرح میکنم و در ادامه سعی میکنم بهشون پاسخ بدم ..

• میشه کاری کنیم که سایت Down نشه و همیشه در دسترس باشه؟
• ترافیک سایت من خیلی بالاست، میتونم کاری کنم که تحت هیچ شرایطی با کندی مواجه نشم؟
• اگر سایتم روی چندتا سرور میزبانی بشه و بار بینشون پخش بشه، اطلاعات بینشون چطوری باهم sync میشه ؟
• مگه میشه یه کاربر به سرور اول وصل شه و یه کاربر دیگه به سرور دوم ؟ خب اطلاعات این دوتا سرور چطوری باهم یکسان هست ؟

جواب همه سوالهای بالا مثبت هست، و باید بگم که با استفاده از load balancer و تکنولوژی هایی که برای توزیع بار میشه استفاده کرد، میشه به سوالات بالا پاسخ داد.

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

حالا بیاین یکم فراتر فکر کنیم!

در نظر بگیرید شما یه سایت فوق العاده پرترافیک مثل دیجی کالا دارید که در هر لحظه ممکنه صدها یا شاید هزاران کاربر در حال مشاهده و کار روی وبسایت شما باشند! از طرفی، شما هم سایتتون بهترین کیفیت رو از لحاظ برنامه نویسی داره، و هم مدیر سرورتون بخوبی سرور شما رو از لحاظ نرم افزاری کانفیگ کرده، آیا همین موارد برای میزبانی ترافیک شما کافیه ؟

پاسخ منفی هست! یه سرور که قراره میزبان سایتی با این حجم از ترافیک باید از نظر سخت افزار و شبکه هم قدرتمند باشه!

گاهی افراد ترجیح میدن یه سرور گرون قیمت تهیه کنن، که قابلیت پردازشی بالایی هم داره، که خب من این مورد رو تحسین میکنم، اگر میدونین سایت شما ترافیک زیادی خواهد داشت و شما هم از لحاظ مالی مشکلی ندارین، خوبه که سرور قدرتمند تهیه کنین! چون در نهایت نتیجه ش رو روی سایتتون می بنین! ولی آیا این کار بهترین راه هست؟

اگر هنوز ترافیک سایتتون تا اون حد خیلی زیاد نشده، باز هم نظر شما روی خرید سرور گرانتر با ظرفیتهای بالاتر هست ؟!

پاسخ من اینه که اگر از لحاظ دانش فنی و نیروی انسانی، کسی رو در مجموعه تون دارین که بتونه کارهای شبکه رو در حد راه اندازی Load Balancer یا HA Proxy مدیریت کنه، قطعا بهتره به جای یه سرور خیلی گرون که منابعش از نیاز شما بسیار زیادتر هست، دو یا سه تا سرور ارزونتر تهیه کنید، و این سه سرور رو در یک Pool قرار دهید و با Load Balancer بار ترافیکتون رو بین سرورهای مختلف توزیع کنید!

اینجوری به اندازه نیازتون با بودجه مناسب، زیرساخت خوب راه اندازی کرده اید و مزیت برترش هم این هست که به همون مقدار کاربری که دارید سایتتون با کیفیت بهتری نمایش داده میشه و با آپتایم بیشتری در دسترس هستید، و همچنین کاربراتون کمتر با مشکلات کندی و ارورهای سمت سرور سری 500 مثل خطای 503 که مربوط به کمبود منابع هست مواجه میشن!

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

Load balancer چیست ؟

اگر به زبون ساده بخوام بگم، لودبالانسر مثل یه پلیس راهنمایی و رانندگی میمونه! که در مقابل همه سرورهامون ایستاده و ترافیک های ورودی رو بین سرورهای مختلف پخش میکنه و برای هر درخواستی که سمت سرور میاد یک مسیر رو مشخص میکنه و میگه که توسط کدوم سرور هندل بشه تا درخواست با بیشترین سرعت و بهترین کیفیت پردازش بشه؛ یه مسئولیت مهم لودبالانسر اینه که تضمین کنه هیچکدوم از سرورها در حالت high load قرار ندارن مگه اینکه همگی با هم high load بشن که در این صورت نشونه این هست که فشار ترافیک ورودی از ظرفیت تمام مجموعه سرورها بیشتر هست و یا باید سرورهای اصلی ارتقا پیدا کنند، یا اینکه باید سرورهای جدیدی رو به مجموع سرورهای متصل به لودبالانسر اضافه کنیم.

اگر یه سروری از سرورهای متصل به لودبالانسر از دسترس خارج بشه، لود بالانسر ترافیک رو بلافاصله بین سرورهای دیگه پخش میکنه و درواقع سرور خارج از دسترس رو از مدار خارج میکنه! اینجوری ترافیک کاربرا بلافاصله به سمت سرورهای دیگه که در دسترس هستن هدایت میشه و مانع از تجربه خطاهای سمت سرور توسط کاربران سایت میشه؛ همچنین اگر سرور جدیدی به مجموعه سرورها اضافه بشه، لودبالانسر بصورت اتوماتیک شروع میکنه به سمت اون سرور ریکوئست ارسال میکنه و بعد هم ترافیک رو به سمتش هدایت میکنه.

تصویر زیر میتونه تو درک موضوع بهتر کمکتون کنه:

الگوریتم های مختلف توزیع بار

روشهای توزیع بار بین سرورها انواع مختلفی داره که هر کدوم از این روشها مزایای خودشونو دارن، در واقع اینکه کدوم روش توزیع بار رو انتخاب کنید بستگی به نیازهای شما داره …

1. روش Round Robin:

تو این روش، درخواست ها بصورت متوالی بین گروهی از سرورها توزیع میشن

2. روش کمترین اتصالات (Least Connections)

در این روش درخواست های جدید به سمت سروری ارسال میشه که در اون لحظه، کمترین تعداد کانکشن با کاربران رو داره. ظرفیت محاسبات نسبی هر سرور معیار معرفی یک سرور بعنوان سروری هست که کمترین اتصالات رو در اون لحظه داره.

3. روش کمترین زمان (Least Time)

این روش بر اساس یک فرمول عمل میکنه! و تو این فرمول باید سرور هم در سریعترین زمان پاسخ رو بده و هم حال کمترین کانکشن های فعال رو داشته باشه؛ در واقع این روش هر دو معیار “زمان پاسخ سریع” و “تعداد کانکشنهای کم” رو با هم ترکیب میکنه. (اگ تو لودبالانسر از وب سرور Nginx Pluseاستفاده کنین، میتونین این روش رو داشته باشین)

4. روش بر اساس رمزگذاری (Hash)

این روش درخواست ها رو بر اساس کلیدواژه ای که شما ارایه می کنید توزیع میکنه مثل آدرس IP یا آدرس URL درخواست!

5. روش IP Hash

تو این روش، آدرس IP کاربر هست که مشخص میکنه کدوم سرور باید ریکوئست رو دریافت و هندل کنه

6. روش تصادفی با دو انتخاب (Random with Two Choices)

تو این روش، لودبالانسر دو سرور رو بصورت تصادفی انتخاب می کنه و درخواست رو به سروری که انتخاب شده میفرسته و درنهایت مجدد از الگوریتم (Least Connections) استفاده میکنه! یعنی بعد از اینکه دوتا سرور رو بصورت تصادفی انتخاب کرد، میاد میبینه روی اون دوتا سرور کدوم تعداد کانکشنهای کمتری دارن، در نتیجه ریکوئست رو به همون سرور ارسال می کنه.

مزایای توزیع بار یا Load Balancing

1. کاهش قابل توجه Downtime

2. قابل گسترش بودن (Scalable)

3. افزونگی (Redundancy) – این مورد در این باره صدق میکنه که اگر بخواهیم میتونیم برای لودبالانسر هم HA (High Availability) داشته باشیم، به این معنی که اگر خود لودبالانسر از دسترس خارج شد، یه لودبالانسر دیگه جایگزینش بشه.

4. انعطاف پذیری (Flexibility)

5. بهینه بودن (Efficiency) – استفاده از لودبالانسر باعث افزایش سرعت و عملکرد بهینه کل سیستم میشه

6. لودبالانسر های نرم افزاری میتونن یه سری امکانات اندازه گیری و آنالیز ترافیک رو در اختیار ما قرار بدن! مثلا کمکمون میکنن ضعف هایی که ممکنه بر اساس ترافیک بالا روی سرورها رخ بدن رو شناسایی کنیم که این مورد تو خیلی از جاهایی که میخوایم اتوماسیون راه اندازی کنیم کاربرد داره و نتیجه شون میتونه باعث بشه که در کسب و کارمون تصمیمات اساسی بگیریم.

7. تو مدل 7 لایه ای شبکه OSI ، فایروالهای شبکه تو لایه های اول تا سوم (لایه اول -Physical Wiring ، لایه دوم -Data Link و لایه سوم-Network) قرار دارن، درحالی که لودبالانسر تو لایه های چهارم تا هفتم قرار داره (لایه چهارم-Transport ، لایه پنجم -Session ، لایه ششم-Presentation و لایه هفتم-Application)

لودبالانسر ها توانمدیهای مختلفی دارن، مثلا :

در لایه چهارم: ترافیک رو براساس داده ای که از لایه شبکه (Network) و لایه انتقال (Transport) میگیره، منتقل میکنه! مثل آدرس  IP و پورت TCP

در لایه هفتم: به فرایند توزیع بار، این امکان رو میده که هر جا که نیاز بود محتوا رو تغییر بده! بعنوان مثال بتونه هر وقت نیاز شد مسیریابی ر و تغییر بده، و براساس المانهایی مانند HTTP Header ، SSL Session ID  و یا اطلاعاتی که در یک فرم html ساده قرار داره، تصمیم بگیره.

8. بهترین مزیت Load Balancing این هست که امکانات لایه های چهارم و هفتم رو در مناطق مختلف جغرافیایی گسترش میده! بعنوان نمونه خیلی از افراد و سازمانهای پیش رو در زمینه ارایه خدمات ابری، تو فکر این هستن که برنامه هایی که ماهیتا در بستر ابری قابل  پیاده سازی هستن رو توسعه بدن! که این مساله خودش میتونه منجر به تغییر بزرگی در توانمندی های لودبالانسرها بشه. فکرشو بکنین شما بتونین تو هرجایی از دنیا به سادگی یه لودبالانسر داشته باشین که خود این لودبالانسر به سادگی تو یه بستر ابری که خودش خیلی اصولی ایجاد شده، درست شده باشه! البته در کنار مزیتهایی که این قضیه داره، حتما چالشهایی رو هم برای شرکتهای ارایه کننده در پی خواهد داشت.

راه اندازی لودبالانسر با Nginx

توزیع بار بین جند برنامه کاربردی (application instance) یکی از رایجترین روشها برای بهینه سازی منابع، افزایش بازدهی، کاهش تاخیر و اطمینان از نحوه کارکرد تنظیمات در هنگام مقابله با خطاهاست.

Nginx این امکان رو داره که ازش بعنوان یک لودبالانسر برای پروتکل HTTP استفاده کنیم، و ترافیک رو بین چند سرور توزیع کنیم تا هم راندمان رو افزایش بدیم، هم به سادگی قابلیت توسعه داشته باشه، و همچنین پایداری برنامه های تحت وب (web application ها) رو بطور قابل ملاحظه ای افزایش بدیم.

انواع روش های Load Balance در Nginx

روشهای مختلف توزیع بار رو در قسمت های قبلتر تو همین مقاله توضیح دادم، تو این قسمت میخوام بصورت کاربردی بهتون بگم که برای راه اندازی لودبالانسر با Nginx از کدوم روش ها میتونیم استفاده کنیم و بصورت عملی تر توضیح بدم.

بطور کلی با سه روش زیر توی Nginx عملیات توزیع بار رو انجام بدیم:

1. روش round-robin : که درخواست ها رو با روش round-robin بین سرورها توزیع میکنه.
2. روش کمترین اتصالات (Least Connections): در این روش لودبالانسر درخواست ها رو به سمت سروری هدایت میکنه که کمترین تعداد کانکشن باز رو داره!
3. روش IP Hash: یک تابع Hash مشخص میکنه که لودبالانسر درخواست رو به کدوم سرور باید ارسال کنه (بر اساس آی پی کاربر)

راه اندازی Load Balancer در Nginx به روش Round Robin

ساده ترین تنظیمات برای راه اندازی لودبالانسر میتونه بصورت زیر باشه:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }

تو مثال بالا ما سه تا Instance از برنامه های مشابه رو بصورت مجزا داریم که در سه سرور srv1 و srv2 و srv3 در حال اجرا هستند. تو مثال بالا تمام درخواست ها به گروه سرورهای myapp1 پروکسی شده اند و Nginx از روش توزیع بار HTTP استفاده میکنه تا درخواست ها رو بین سرورهای مختلف پخش کنه.

اجرای معکوس پروکسی (در اصطلاح از همون Reverse Proxy استفاده میکنیم) در Nginx شامل توزیع بار برای درخواست های زیر هست:

HTTP ، HTTPS ، FastCGI ، uwsgi ، SCGI ، memcached و gRPC.

برای توزیع بار درخواست های HTTPS در Nginx در مثال بالا، کافیه به جای http از https استفاده کنیم.

جهت پیاده سازی لودبالانسر برای درخواست های FastCGI ، uwsgi، SCGI، memcached یا gRPC میتونین از اطلاعات موجود درلینک های fastcgi_pass ، uwsgi_pass ، scgi_pass ، memcached_pass و grpc_pass استفاده کنین.

راه اندازی Load Balancer در Nginx به روش کمترین اتصالات (Least  Connections )

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

در روش توزیع بار least-connected ، در واقع Ngnix تمام تلاشش رو میکنه که سر یه سروری که خیلی درگیر هست رو خلوت کنه و نذاره دچار overload بشه! و جلوی اینکه سمت یه سرور درخواست های خیلی زیاد بره بگیره و به جاش این درخواست ها رو که از توان یه سرور خارجه به سمت سرور دیگه ای که سرش خلوت تره بفرسته.

اگر بخواهیم از روش Least Connected استفاده کنیم، کافیه دستور “ least_conn” رو در بعنوان تنظیمات پیش فرض گروه سرورها اضافه کنیم:

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

راه اندازی Load Balancer در Nginx به روش IP Hash (یا Session persistence )

توجه به این نکته حائز اهمیت هست بدونین اینه که تو روش های توزیع بار Round Robin و least-connected ، درخواست های بعدی که توسط یه کاربر به سمت سرور ارسال میشه میتونه بین سرورهای مختلفی پخش بشه! در واقع در این بین تضمینی نیست هر کاربر الزاما به یه سرور خاص متصل بشه و تمام درخواستهاش توسط فقط یه سرور هندل بشه..

اگر در نحوه عملکرد برنامه های تحت وب شما، نیاز هست که کارهای هر کاربر حتما توسط یه سرور هندل بشه – بعبارت دیگه session هر کاربر پایدار (persistent) باشه که همیشه درخواستهای هر کاربر فقط روی یه سرور باشه و در سرورهای دیگه پخش نشه و روی سرورهای مختلف کاربرای مختلف سرویس دهی بشن – باید از روش توزیع بار ip-hash استفاده کنیم.

در روش ip-hash آی پی کاربر بعنوان کلید هشینگ (hashing key) استفاده میشه، به این معنی که آی پی هر کاربر مشخص کننده این هست که چه سروری در گروه سرورها باید برای پاسخدهی به درخواستهای کاربر انتخاب بشه. این روش در واقع از این اطمینان حاصل میکنه که هر درخواست کاربر توسط دقیقا همون سرور قبلی سرویس دهی بشه ، مگر اینکه سرور قبلی کلا در دسترس نباشه!

اگر بخواهیم از روش Least Connected استفاده کنیم، کافیه دستور “ip_hash” رو در بعنوان تنظیمات پیش فرض گروه سرورها اضافه کنیم:

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

وزن دهی در توزیع بار (یا Weighted load balancing )

تو مثالهای بالا تمام سرورها برای اینکه درخواست ها به سمتشون بیاد، از شانس برابری بهره مند بودن! درواقع سرورها در شرایط مساوی، شانسشون برابر بود؛ در این قسمت میخوام یه آپشنی رو معرفی کنم که میتونیم این توازن رو بهم بزنیم! در مثالهای بالا وزنی برای سرورها مشخص نشده و تو فرۀیند توزیع بار با همه سرورها به یه صورت رفتار میشه!

بخصوص در روش Round-Robin ، روش کلی کار به معنی توزیع تقریبا مساوی درخواست ها بین سرورهاست، بدون توجه به اینکه سروری بر دیگری اولویت داشته باشد! – البته به شرطی که به اندازه کافی درخواست به سرورهای مختلف ارسال شده باشد و تمام درخواست ها در بازه ی زمانی مساوی پردازش شوند!

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

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

در واقع با تنظیمات بالا، به ازای هر 5 درخواستی که به سمت لودبالانسر میاد، 3 تاشو میفرسته سمت سرور srv1 و 1 دونه شو میفرسته سمت سرور srv2 و درنهایت 1 دونه هم میفرسته سمت سرور srv3.

از وزن دهی میتونیم در همه الگورتیم هایی که توسط nginx پشتیبانی میشه استفاده کنیم، یعنی هم در Least Connected و هم در IP Hash و هم در Round Robin !

بررسی صحت کارکرد لودبالانسر

پیاده سازی روش Reverse Proxy در Nginx بصورت بررسی صحت in-band یا passive صورت میگیره! به اینصورت که خود nginx بصورت داخلی تست انجام میده، و اگر از سرور خاصی که مدنظرش هست جوابی دریافت نکرد یا جوابی همراه با یه پیغام خطا دریافت کرد، اون سرور رو از مدار خارج میکنه و برای مدتی از ارجاع درخواست های بعدی به اون سرور خودداری میکنه!

با استفاده از دستور max_fails میتونیم برای nginx مشخص کنیم برای اتصال به هر سروری که موقتا از رده خارج کرده نهایتا چند بار دوباره تلاش کنه و بعد از چندبار تلاش ناموفق اون سرور رو کلا بذاره کنار؟

میتونیم از دستور fail_timeout هم برای مشخص کردن حداکثر فرصت nginx برای اتصال دوباره به سرور از رده خارج شده ی موقتی استفاده کنیم.

درواقع با دو دستور بالا میتونیم مشخص کنیم در یک بازه زمانی مشخص (fail_timeout) لودبالانسر nginx نهایتا چندبار (max_fails) میتونه برای برقراری ارتباط مجدد با سرور از رده خارج موقتی تلاش ناموفق داشته باشه!؟

بصورت پیش فرض مقدار max_fails برابر با 1 هست و زمانی که برابر 0 تنظیم بشه، در واقع به این معنی هست که کل فرایند بررسی صحت کار لودبالاتسر (Health Check) رو غیرفعال کرده ایم.

دستور fail_timeout هم در واقع مشخص میکنه هر سرور نهایتا چه مقدار میتونه از دسترس خارج باشه ؟ (Fail شده باشه)

بعد از اتمام زمان fail_timeout که پس از از رده خارج شدن یه سرور از مدار رخ میده، Nginx با ارسال درخواست های live از سمت کاربر شروع به بررسی دقیق سرور میکنه و اگر سرور در دسترس قرار گرفته باشه، اون سرور رو در گروه سرورها بعنوان سرور سالم علامت گذاری میکنه و مجدد به مدار واردش میکنه!

اطلاعات بیشتر در این باره

علاوه بر دستوراتی که بالاتر ذکر کردم، از دستورات دیگه ای هم میتونین تو nginx استفاده کنین که نحوه توزیع بار رو میتونین باهاش کنترل کنین..

برای اطلاعات جزئی تر و دقیقتر به لینک زیر برین:

http://nginx.org/en/docs/

نکته آخری هم که میخوام بگم اینه که nginx یه نسخه plus داره که امکانات خیلی ویژه ای از قبیل application load balancing ، application health checks ، activity monitoring  و on-the-fly reconfiguration داره که با مراجعه به مقالات زیر میتونین اطلاعات کاملتری درباره ش کسب کنین:

• Load Balancing with NGINX and NGINX Plus
• Load Balancing with NGINX and NGINX Plus part 2

منابع

این مقاله حاصل ترکیب تجربه م در گنجه هاست و چند مقاله با هم هست که لینک مراجع رو در قسمت زیر ذکر کرده م:

• http://nginx.org/en/docs/http/load_balancing.htm
• http://nginx.org/en/docs/http/ngx_http_upstream_module.html
• https://avinetworks.com/what-is-load-balancing
• https://www.nginx.com/resources/glossary/load-balancing

امیدوارم این مقاله هم مفید بوده باشه

سبز باشید.