Kaj storiti, če moč enega strežnika ne zadostuje za obdelavo vseh zahtev, proizvajalec programske opreme pa ne zagotavlja uravnoteženja obremenitve? Možnosti je veliko, od nakupa obremenitve do omejitve števila zahtev. Katera je pravilna, je treba ugotoviti glede na situacijo ob upoštevanju obstoječih razmer. V tem članku vam bomo povedali, kaj lahko storite, če je vaš proračun omejen in imate brezplačen strežnik.

Kot sistem, za katerega je bilo potrebno zmanjšati obremenitev enega od strežnikov, smo izbrali DLP (information leakage prevention system) podjetja InfoWatch. Značilnost izvedbe je bila postavitev funkcije balanserja na enega od "bojnih" strežnikov.

Ena od težav, na katero smo naleteli, je bila nezmožnost uporabe izvornega NAT (SNAT). Zakaj je bilo to potrebno in kako je bila težava rešena, bomo podrobneje opisali.

Torej je na začetku logični diagram obstoječega sistema izgledal takole:

ICAP promet, SMTP, dogodki iz uporabniških računalnikov so bili obdelani na strežniku Traffic Monitor (TM). Hkrati se je strežnik baze podatkov zlahka spopadel z obremenitvijo po obdelavi dogodkov na TM, vendar je bila obremenitev samega TM velika. To je bilo razvidno iz pojava čakalne vrste sporočil na strežniku Device Monitor (DM) ter iz obremenitve CPU in pomnilnika TM.

Na prvi pogled, če tej shemi dodamo še en strežnik TM, bi lahko nanj preklopili bodisi ICAP bodisi DM, vendar smo se odločili, da te metode ne bomo uporabili, saj se je toleranca napak zmanjšala.

Opis rešitve

V procesu iskanja ustrezne rešitve smo se odločili za prosto distribuirano programsko opremo keepalived skupaj z LVS. Ker keepalived rešuje problem ustvarjanja samodejne gruče in lahko upravlja tudi izravnalnik LVS.

Kar smo želeli doseči (zmanjšati obremenitev TM in ohraniti trenutno raven tolerance napak), bi moralo delovati po naslednji shemi:

Pri preverjanju funkcionalnosti se je izkazalo, da prilagojeni sklop RedHat, nameščen na strežnikih, ne podpira SNAT. V našem primeru smo načrtovali uporabo SNAT, da bi zagotovili, da so dohodni paketi in odgovori nanje poslani z istega naslova IP, sicer bi dobili naslednjo sliko:

To je nesprejemljivo. Na primer, strežnik proxy, ki je poslal pakete na naslov Virtual IP (VIP), bo pričakoval odgovor od VIP-a, vendar bo v tem primeru prišel iz IP2 za seje, poslane v varnostno kopijo. Rešitev je bila najdena: na varnostni kopiji je bilo treba ustvariti še eno usmerjevalno tabelo in povezati dva strežnika TM z ločenim omrežjem, kot je prikazano spodaj:

Nastavitve

Izvedli bomo shemo dveh strežnikov s storitvami ICAP, SMTP, TCP 9100 in na enem nameščenim izenačevalnikom obremenitve.

Imamo dva strežnika RHEL6, iz katerih so bili odstranjeni standardni repozitoriji in nekateri paketi.

Storitve, ki jih moramo uravnotežiti:

• ICAP – tcp 1344;

• SMTP – tcp 25.

Storitev prenosa prometa iz DM – tcp 9100.

Najprej moramo načrtovati omrežje.

Navidezni naslov IP (VIP):

• IP: 10.20.20.105.

Strežnik TM6_1:

• Zunanji IP: 10.20.20.101;

• Notranji IP: 192.168.1.101.

Strežnik TM6_2:

• Zunanji IP: 10.20.20.102;

• Notranji IP: 192.168.1.102.

Nato omogočimo IP forwarding na dveh TM strežnikih. Kako to storiti je opisano na RedHat tukaj.

Odločimo se, kateri od strežnikov bomo imeli glavni in kateri bo rezervni. Naj bo glavni TM6_1, rezervni TM6_2.

Pri varnostnem kopiranju ustvarimo novo usmerjevalno tabelo izravnalnika in pravila usmerjanja:

[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

Zgornji ukazi delujejo, dokler se sistem znova ne zažene. Če želite zagotoviti, da se poti ohranijo po ponovnem zagonu, jih lahko vnesete v /etc/rc.d/rc.local, vendar bolje prek nastavitvene datoteke /etc/sysconfig/network-scripts/route-eth1 (opomba: tukaj je uporabljena druga sintaksa).

Namestite keepalived na oba strežnika TM. Kot distribucijski vir smo uporabili 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

V nastavitvah keepalived enega od strežnikov določimo kot glavnega, drugega kot rezervnega. Nato nastavimo VIP in storitve za izravnavo obremenitve. Datoteka z nastavitvami se običajno nahaja tukaj: /etc/keepalived/keepalived.conf.

Nastavitve za strežnik 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
        }
    }
}

Nastavitve za strežnik 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 
        } 
}

Na master namestimo LVS, ki bo uravnal promet. Nima smisla nameščati balanserja za drugi strežnik, saj imamo v konfiguraciji le dva strežnika.

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

Balancer bo upravljal keepalived, ki smo ga že konfigurirali.

Za popolnost slike dodajmo keepalived samodejnemu zagonu na obeh strežnikih:

[root@tm6_1 ~]#chkconfig keepalived on

Zaključek

Preverjanje rezultatov

Zaženimo keepalived na obeh strežnikih:

service keepalived start

Preverjanje razpoložljivosti virtualnega naslova VRRP

Prepričajmo se, da je VIP na masterju:

In pri varnostnem kopiranju ni VIP-ja:

Z ukazom ping bomo preverili razpoložljivost VIP-ja:

Zdaj lahko zaustavite master in znova zaženete ukaz ping.

Rezultat bi moral ostati enak, pri varnostni kopiji pa bomo videli VIP:

Preverjanje uravnoteženja storitve

Vzemimo za primer SMTP. Zaženimo dve povezavi na 10.20.20.105 hkrati:

telnet 10.20.20.105 25

Na glavnem bi morali videti, da sta obe povezavi aktivni in povezani z različnimi strežniki:

[root@tm6_1 ~]#watch ipvsadm –Ln

Tako smo implementirali konfiguracijo storitev TM, ki je tolerantna na napake, z namestitvijo izravnalnika na enega od strežnikov TM. Za naš sistem je to zmanjšalo obremenitev TM za polovico, kar je omogočilo rešitev problema pomanjkanja horizontalnega skaliranja z uporabo sistema.

V večini primerov se ta rešitev izvede hitro in brez dodatnih stroškov, včasih pa obstajajo številne omejitve in težave pri konfiguraciji, na primer pri uravnoteženju prometa UDP.

Vir: www.habr.com