Bir serverin gücü bütün sorğuları emal etmək üçün kifayət deyilsə və proqram istehsalçısı yük balansını təmin etmirsə nə etməli? Yük balanslaşdırıcısının alınmasından tutmuş sorğuların sayını məhdudlaşdırmağa qədər bir çox variant var. Hansının düzgün olduğunu mövcud şərtlər nəzərə alınmaqla vəziyyət müəyyən etməlidir. Bu yazıda büdcəniz məhduddursa və pulsuz serveriniz varsa nə edə biləcəyinizi sizə xəbər verəcəyik.

Serverlərdən birinin yükünü azaltmaq lazım olan bir sistem olaraq InfoWatch-dən DLP (məlumat sızmasının qarşısının alınması sistemi) seçdik. Tətbiqin bir xüsusiyyəti balanslaşdırıcı funksiyanın "döyüş" serverlərindən birinə yerləşdirilməsi idi.

Qarşılaşdığımız problemlərdən biri mənbə NAT-dan (SNAT) istifadə edə bilməmək idi. Bunun niyə lazım olduğunu və problemin necə həll edildiyini daha ətraflı təsvir edəcəyik.

Beləliklə, əvvəlcə mövcud sistemin məntiqi diaqramı belə görünürdü:

ICAP trafiki, SMTP, istifadəçi kompüterlərindən gələn hadisələr Traffic Monitor (TM) serverində işlənmişdir. Eyni zamanda, verilənlər bazası serveri TM-də hadisələri emal etdikdən sonra yükün öhdəsindən asanlıqla gəldi, lakin TM-də yük ağır idi. Bu, Cihaz Monitoru (DM) serverində mesaj növbəsinin görünüşündən, həmçinin TM-də CPU və yaddaş yükündən aydın görünürdü.

İlk baxışdan bu sxemə başqa bir TM server əlavə etsək, ya ICAP, ya da DM ona keçə bilərdi, lakin nasazlığa dözümlülük azaldığı üçün bu metoddan istifadə etməməyə qərar verdik.

Həll təsviri

Uyğun bir həll axtarışı prosesində biz sərbəst paylanmış proqram təminatı üzərində qərarlaşdıq sağ qaldı ilə birlikdə LVS. Çünki keepalived uğursuzluq klasterinin yaradılması problemini həll edir və həmçinin LVS balanslaşdırıcısını idarə edə bilir.

Əldə etmək istədiyimiz şey (TM-də yükü azaltmaq və mövcud nasazlıqlara dözümlülük səviyyəsini saxlamaq) aşağıdakı sxemə uyğun işləməli idi:

Funksionallığı yoxlayarkən məlum oldu ki, serverlərdə quraşdırılmış xüsusi RedHat montajı SNAT-ı dəstəkləmir. Bizim vəziyyətimizdə, daxil olan paketlərin və onlara cavabların eyni IP ünvanından göndərilməsini təmin etmək üçün SNAT-dan istifadə etməyi planlaşdırdıq, əks halda aşağıdakı şəkli alacağıq:

Bu qəbuledilməzdir. Məsələn, virtual IP (VIP) ünvanına paketlər göndərən proksi server VIP-dən cavab gözləyəcək, lakin bu halda o, ehtiyat nüsxəyə göndərilən sessiyalar üçün IP2-dən gələcək. Bir həll tapıldı: ehtiyat nüsxədə başqa bir marşrutlaşdırma cədvəli yaratmaq və aşağıda göstərildiyi kimi iki TM serverini ayrıca şəbəkə ilə birləşdirmək lazım idi:

Parametrlər

ICAP, SMTP, TCP 9100 xidmətləri və onlardan birində yük balanslaşdırıcısı quraşdırılmış iki serverin sxemini həyata keçirəcəyik.

Standart depolar və bəzi paketlər silinmiş iki RHEL6 serverimiz var.

Balanslaşdırmalı olduğumuz xidmətlər:

• ICAP – tcp 1344;

• SMTP – tcp 25.

DM-dən trafikin ötürülməsi xidməti – tcp 9100.

Əvvəlcə şəbəkəni planlaşdırmalıyıq.

Virtual IP ünvanı (VIP):

• IP: 10.20.20.105.

Server TM6_1:

• Xarici IP: 10.20.20.101;

• Daxili IP: 192.168.1.101.

Server TM6_2:

• Xarici IP: 10.20.20.102;

• Daxili IP: 192.168.1.102.

Sonra iki TM serverində IP yönləndirməni işə salırıq. Bunu necə etmək RedHat-da təsvir edilmişdir burada.

Sahib olduğumuz serverlərdən hansının əsas, hansının isə ehtiyat nüsxəsi olacağına qərar veririk. Qoy master TM6_1, ehtiyat nüsxə TM6_2 olsun.

Yedəkləmə zamanı yeni balanslaşdırıcı marşrut cədvəli və marşrutlaşdırma qaydaları yaradırıq:

[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

Yuxarıdakı əmrlər sistem yenidən işə salınana qədər işləyir. Yenidən başladıqdan sonra marşrutların qorunub saxlanmasını təmin etmək üçün onları daxil edə bilərsiniz /etc/rc.d/rc.local, lakin parametrlər faylı vasitəsilə daha yaxşıdır /etc/sysconfig/network-scripts/route-eth1 (qeyd: burada fərqli sintaksis istifadə olunur).

Keepalived-i hər iki TM serverinə quraşdırın. Dağıtım mənbəyi kimi rpmfind.net-dən istifadə etdik:

[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

Saxlanılan parametrlərdə biz serverlərdən birini master, digərini ehtiyat kimi təyin edirik. Sonra yük balansı üçün VIP və xidmətləri təyin etdik. Parametrlər faylı adətən burada yerləşir: /etc/keepalived/keepalived.conf.

TM1 Server üçün parametrlər

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 Server üçün parametrlər

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 
        } 
}

Trafiki tarazlaşdıracaq LVS-ni master-a quraşdırırıq. İkinci server üçün balanslaşdırıcı quraşdırmağın mənası yoxdur, çünki konfiqurasiyada yalnız iki serverimiz var.

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

Balanslaşdırıcı artıq konfiqurasiya etdiyimiz keepalived tərəfindən idarə olunacaq.

Şəkli tamamlamaq üçün hər iki serverdə autostart-a keepalived əlavə edək:

[root@tm6_1 ~]#chkconfig keepalived on

Nəticə

Nəticələrin yoxlanılması

Gəlin hər iki serverdə keepalived-i işə salaq:

service keepalived start

VRRP virtual ünvanının mövcudluğunun yoxlanılması

VIP-nin master-da olduğuna əmin olaq:

Və ehtiyatda VIP yoxdur:

Ping əmrindən istifadə edərək VIP-in mövcudluğunu yoxlayacağıq:

İndi master-ı bağlaya və əmri yenidən işə sala bilərsiniz ping.

Nəticə eyni qalmalıdır və ehtiyat nüsxədə VIP görəcəyik:

Xidmət balansının yoxlanılması

Məsələn, SMTP-ni götürək. 10.20.20.105-ə eyni vaxtda iki əlaqəni işə salaq:

telnet 10.20.20.105 25

Master-da hər iki əlaqənin aktiv olduğunu və müxtəlif serverlərə qoşulduğunu görməliyik:

[root@tm6_1 ~]#watch ipvsadm –Ln

Beləliklə, biz TM serverlərindən birində balanslaşdırıcı quraşdıraraq TM xidmətlərinin nasazlığa davamlı konfiqurasiyasını həyata keçirmişik. Sistemimiz üçün bu, TM-də yükü yarıya endirdi, bu da sistemdən istifadə edərək üfüqi miqyas çatışmazlığı problemini həll etməyə imkan verdi.

Əksər hallarda, bu həll tez və əlavə xərclər olmadan həyata keçirilir, lakin bəzən konfiqurasiyada, məsələn, UDP trafikini balanslaşdırarkən bir sıra məhdudiyyətlər və çətinliklər var.

Mənbə: www.habr.com