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

به عنوان سیستمی که برای کاهش بار روی یکی از سرورها ضروری بود، DLP (سیستم پیشگیری از نشت اطلاعات) را از InfoWatch انتخاب کردیم. یکی از ویژگی های پیاده سازی، قرار دادن عملکرد متعادل کننده در یکی از سرورهای "مبارزه" بود.

یکی از مشکلاتی که با آن مواجه شدیم عدم امکان استفاده از منبع NAT (SNAT) بود. چرا این مورد نیاز بود و چگونه مشکل حل شد، در ادامه توضیح خواهیم داد.

بنابراین، در ابتدا نمودار منطقی سیستم موجود به این صورت بود:

ترافیک ICAP، SMTP، وقایع از رایانه های کاربر در سرور Traffic Monitor (TM) پردازش شد. در همان زمان، سرور پایگاه داده پس از پردازش وقایع روی TM به راحتی با بار مقابله کرد، اما بار روی خود TM سنگین بود. این از ظاهر یک صف پیام در سرور مانیتور دستگاه (DM) و همچنین از بارگیری CPU و حافظه روی TM مشهود بود.

در نگاه اول، اگر سرور TM دیگری را به این طرح اضافه کنیم، می توان ICAP یا DM را به آن سوئیچ کرد، اما تصمیم گرفتیم از این روش استفاده نکنیم، زیرا تحمل خطا کاهش یافته است.

شرح راه حل

در روند جستجوی راه‌حل مناسب، بر روی نرم‌افزارهای آزادانه توزیع شده مستقر شدیم حفظ شده است با هم LVS. زیرا keepalived مشکل ایجاد یک Failover Cluster را حل می کند و همچنین می تواند متعادل کننده LVS را مدیریت کند.

آنچه ما می خواستیم به آن برسیم (کاهش بار روی TM و حفظ سطح فعلی تحمل خطا) باید طبق طرح زیر عمل می کرد:

هنگام بررسی عملکرد، مشخص شد که مجموعه سفارشی RedHat نصب شده روی سرورها از SNAT پشتیبانی نمی کند. در مورد ما، ما قصد داشتیم از SNAT استفاده کنیم تا اطمینان حاصل کنیم که بسته های دریافتی و پاسخ به آنها از همان آدرس IP ارسال می شوند، در غیر این صورت تصویر زیر را دریافت می کنیم:

این غیر قابل قبول است. به عنوان مثال، یک سرور پروکسی که بسته ها را به یک آدرس IP مجازی (VIP) ارسال کرده است، انتظار پاسخ از سوی VIP را دارد، اما در این مورد از IP2 برای جلسات ارسال شده به پشتیبان می آید. یک راه حل پیدا شد: لازم بود جدول مسیریابی دیگری در پشتیبان ایجاد شود و دو سرور TM با یک شبکه جداگانه مانند شکل زیر متصل شود:

تنظیمات

ما طرحی متشکل از دو سرور را با خدمات ICAP، SMTP، TCP 9100 و یک load balancer نصب شده روی یکی از آنها پیاده سازی خواهیم کرد.

ما دو سرور RHEL6 داریم که مخازن استاندارد و برخی از بسته ها از آنها حذف شده است.

خدماتی که به تعادل نیاز داریم:

• ICAP – tcp 1344;

• SMTP – tcp 25.

سرویس انتقال ترافیک از DM – tcp 9100.

ابتدا باید شبکه را برنامه ریزی کنیم.

آدرس IP مجازی (VIP):

• IP: 10.20.20.105.

سرور TM6_1:

• IP خارجی: 10.20.20.101;

• IP داخلی: 192.168.1.101.

سرور TM6_2:

• IP خارجی: 10.20.20.102;

• IP داخلی: 192.168.1.102.

سپس انتقال IP را در دو سرور TM فعال می کنیم. نحوه انجام این کار در RedHat توضیح داده شده است اینجا.

ما تصمیم می گیریم که کدام یک از سرورهایی که خواهیم داشت، اصلی و کدام یک پشتیبان باشد. اجازه دهید Master TM6_1 باشد، نسخه پشتیبان TM6_2 باشد.

در پشتیبان گیری، جدول مسیریابی متعادل کننده و قوانین مسیریابی جدید ایجاد می کنیم:

[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancer

دستورات بالا تا زمانی که سیستم راه اندازی مجدد نشود کار می کند. برای اطمینان از حفظ مسیرها پس از راه اندازی مجدد، می توانید آنها را وارد کنید /etc/rc.d/rc.local، اما بهتر است از طریق فایل تنظیمات /etc/sysconfig/network-scripts/route-eth1 (توجه: در اینجا از نحو متفاوتی استفاده شده است).

Keealived را روی هر دو سرور TM نصب کنید. ما از rpmfind.net به عنوان منبع توزیع استفاده کردیم:

[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpm

در تنظیمات keepalived، یکی از سرورها را به عنوان Master و دیگری را به عنوان پشتیبان اختصاص می دهیم. سپس ما VIP و خدمات را برای تعادل بار تنظیم می کنیم. فایل تنظیمات معمولاً در اینجا قرار دارد: /etc/keepalived/keepalived.conf.

تنظیمات برای سرور TM1

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state MASTER 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 151 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

virtual_server 10.20.20.105 1344 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 25 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 9100 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

تنظیمات برای سرور TM2

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state BACKUP 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 100 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

ما LVS را روی Master نصب می کنیم که ترافیک را متعادل می کند. نصب متعادل کننده برای سرور دوم منطقی نیست، زیرا ما فقط دو سرور در پیکربندی داریم.

[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm

متعادل کننده توسط keepalived مدیریت می شود که قبلاً آن را پیکربندی کرده ایم.

برای تکمیل تصویر، اجازه دهید keepalived را به autostart در هر دو سرور اضافه کنیم:

[root@tm6_1 ~]#chkconfig keepalived on

نتیجه

بررسی نتایج

اجازه دهید keepalived را در هر دو سرور اجرا کنیم:

service keepalived start

بررسی در دسترس بودن یک آدرس مجازی VRRP

بیایید مطمئن شویم که VIP روی Master است:

و هیچ VIP در پشتیبان گیری وجود ندارد:

با استفاده از دستور ping، در دسترس بودن VIP را بررسی می کنیم:

اکنون می توانید master را خاموش کرده و دوباره دستور را اجرا کنید ping.

نتیجه باید یکسان بماند و در پشتیبان گیری شاهد VIP خواهیم بود:

بررسی تعادل سرویس

برای مثال SMTP را در نظر بگیرید. بیایید دو اتصال را به 10.20.20.105 به طور همزمان راه اندازی کنیم:

telnet 10.20.20.105 25

در مستر باید ببینیم که هر دو اتصال فعال هستند و به سرورهای مختلف متصل هستند:

[root@tm6_1 ~]#watch ipvsadm –Ln

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

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

منبع: www.habr.com