Çfarë duhet të bëni nëse fuqia e një serveri nuk është e mjaftueshme për të përpunuar të gjitha kërkesat dhe prodhuesi i softuerit nuk siguron balancimin e ngarkesës? Ka shumë opsione, nga blerja e një balancuesi të ngarkesës deri te kufizimi i numrit të kërkesave. Cila është e saktë duhet të përcaktohet nga situata, duke marrë parasysh kushtet ekzistuese. Në këtë artikull do t'ju tregojmë se çfarë mund të bëni nëse buxheti juaj është i kufizuar dhe keni një server falas.

Si një sistem për të cilin ishte e nevojshme të zvogëlohej ngarkesa në një nga serverët, ne zgjodhëm DLP (sistem parandalimi i rrjedhjes së informacionit) nga InfoWatch. Një tipar i zbatimit ishte vendosja e funksionit të balancuesit në një nga serverët "luftarak".

Një nga problemet që hasëm ishte pamundësia për të përdorur Source NAT (SNAT). Pse ishte e nevojshme kjo dhe si u zgjidh problemi, ne do të përshkruajmë më tej.

Pra, fillimisht diagrami logjik i sistemit ekzistues dukej kështu:

Trafiku ICAP, SMTP, ngjarjet nga kompjuterët e përdoruesve u përpunuan në serverin e Traffic Monitor (TM). Në të njëjtën kohë, serveri i bazës së të dhënave u përball me lehtësi me ngarkesën pas përpunimit të ngjarjeve në TM, por ngarkesa në vetë TM ishte e rëndë. Kjo ishte e dukshme nga shfaqja e një radhe mesazhesh në serverin e monitorit të pajisjes (DM), si dhe nga ngarkesa e CPU-së dhe memories në TM.

Në pamje të parë, nëse shtojmë një server tjetër TM në këtë skemë, atëherë ose ICAP ose DM mund të kalojnë në të, por ne vendosëm të mos e përdorim këtë metodë, pasi toleranca e gabimeve ishte zvogëluar.

Përshkrimi i zgjidhjes

Në procesin e kërkimit për një zgjidhje të përshtatshme, ne u vendosëm në softuer të shpërndarë lirisht mbajtur gjallë së bashku me LVS. Sepse keepalived zgjidh problemin e krijimit të një grupi dështimi dhe gjithashtu mund të menaxhojë balancuesin LVS.

Ajo që donim të arrinim (ulja e ngarkesës në TM dhe ruajtja e nivelit aktual të tolerancës së gabimeve) duhet të kishte funksionuar sipas skemës së mëposhtme:

Gjatë kontrollimit të funksionalitetit, doli që asambleja e personalizuar RedHat e instaluar në serverë nuk mbështet SNAT. Në rastin tonë, ne kemi planifikuar të përdorim SNAT për të siguruar që paketat hyrëse dhe përgjigjet ndaj tyre të dërgohen nga e njëjta adresë IP, përndryshe do të merrnim foton e mëposhtme:

Kjo është e papranueshme. Për shembull, një server proxy, pasi ka dërguar pako në një adresë IP Virtuale (VIP), do të presë një përgjigje nga VIP, por në këtë rast do të vijë nga IP2 për seancat e dërguara në kopje rezervë. U gjet një zgjidhje: ishte e nevojshme të krijohej një tabelë tjetër rutimi në rezervë dhe të lidheshin dy serverë TM me një rrjet të veçantë, siç tregohet më poshtë:

Cilësimet

Ne do të implementojmë një skemë prej dy serverësh me shërbime ICAP, SMTP, TCP 9100 dhe një balancues ngarkese të instaluar në njërin prej tyre.

Ne kemi dy serverë RHEL6, nga të cilët janë hequr depot standarde dhe disa paketa.

Shërbimet që na duhen për të balancuar:

• ICAP – tcp 1344;

• SMTP – tcp 25.

Shërbimi i transmetimit të trafikut nga DM – tcp 9100.

Së pari, ne duhet të planifikojmë rrjetin.

Adresa IP virtuale (VIP):

• IP: 10.20.20.105.

Serveri TM6_1:

• IP e jashtme: 10.20.20.101;

• IP e brendshme: 192.168.1.101.

Serveri TM6_2:

• IP e jashtme: 10.20.20.102;

• IP e brendshme: 192.168.1.102.

Më pas aktivizojmë përcjelljen e IP-së në dy serverë TM. Si ta bëni këtë përshkruhet në RedHat këtu.

Ne vendosim se cili nga serverët që do të kemi është ai kryesor dhe cili do të jetë ai rezervë. Le të jetë master TM6_1, rezervë të jetë TM6_2.

Në kopje rezervë ne krijojmë një tabelë të re të kursimit të balancuesit dhe rregullat e rrugëtimit:

[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

Komandat e mësipërme funksionojnë derisa sistemi të rindizet. Për të siguruar që rrugët të ruhen pas një rindezjeje, mund t'i futni ato /etc/rc.d/rc.local, por më mirë përmes skedarit të cilësimeve /etc/sysconfig/network-scripts/route-eth1 (shënim: këtu përdoret sintaksë e ndryshme).

Instaloni keepalived në të dy serverët TM. Ne përdorëm rpmfind.net si burim shpërndarjeje:

[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

Në cilësimet keepalived, ne caktojmë një nga serverët si master, tjetrin si rezervë. Më pas vendosim VIP dhe shërbime për balancimin e ngarkesës. Skedari i cilësimeve zakonisht gjendet këtu: /etc/keepalived/keepalived.conf.

Cilësimet për serverin 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
        }
    }
}

Cilësimet për serverin 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 
        } 
}

Ne instalojmë LVS në master, i cili do të balancojë trafikun. Nuk ka kuptim të instaloni një balancues për serverin e dytë, pasi ne kemi vetëm dy serverë në konfigurim.

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

Balancuesi do të menaxhohet nga keepalived, të cilin e kemi konfiguruar tashmë.

Për të përfunduar figurën, le të shtojmë keepalived në autostart në të dy serverët:

[root@tm6_1 ~]#chkconfig keepalived on

Përfundim

Kontrollimi i rezultateve

Le të ekzekutojmë keepalived në të dy serverët:

service keepalived start

Kontrollimi i disponueshmërisë së një adrese virtuale VRRP

Le të sigurohemi që VIP-i të jetë në master:

Dhe nuk ka VIP në kopje rezervë:

Duke përdorur komandën ping, ne do të kontrollojmë disponueshmërinë e VIP-së:

Tani mund të mbyllni masterin dhe të ekzekutoni përsëri komandën ping.

Rezultati duhet të mbetet i njëjtë, dhe në kopje rezervë do të shohim VIP:

Kontrollimi i balancimit të shërbimit

Le të marrim SMTP për shembull. Le të hapim dy lidhje në 10.20.20.105 njëkohësisht:

telnet 10.20.20.105 25

Në master duhet të shohim që të dy lidhjet janë aktive dhe të lidhura me serverë të ndryshëm:

[root@tm6_1 ~]#watch ipvsadm –Ln

Kështu, ne kemi zbatuar një konfigurim tolerant ndaj gabimeve të shërbimeve TM duke instaluar një balancues në një nga serverët TM. Për sistemin tonë, kjo zvogëloi ngarkesën në TM përgjysmë, gjë që bëri të mundur zgjidhjen e problemit të mungesës së shkallëzimit horizontal duke përdorur sistemin.

Në shumicën e rasteve, kjo zgjidhje zbatohet shpejt dhe pa kosto shtesë, por ndonjëherë ka një numër kufizimesh dhe vështirësish në konfigurim, për shembull, kur balanconi trafikun UDP.

Burimi: www.habr.com