Mitä tehdä, jos yhden palvelimen teho ei riitä kaikkien pyyntöjen käsittelemiseen ja ohjelmiston valmistaja ei tarjoa kuormituksen tasapainotusta? Vaihtoehtoja on monia kuormantasaajan ostamisesta pyyntöjen määrän rajoittamiseen. Kumpi on oikea, on määritettävä tilanteen mukaan ottaen huomioon vallitsevat olosuhteet. Tässä artikkelissa kerromme, mitä voit tehdä, jos budjettisi on rajallinen ja sinulla on ilmainen palvelin.

Järjestelmäksi, jota varten oli tarpeen vähentää yhden palvelimen kuormitusta, valitsimme InfoWatchista DLP:n (tietovuotojen estojärjestelmä). Toteutuksen ominaisuus oli tasapainotustoiminnon sijoittaminen yhteen "taistelu"-palvelimista.

Yksi kohtaamistamme ongelmista oli Source NAT:n (SNAT) käyttökyvyttömyys. Miksi tätä tarvittiin ja kuinka ongelma ratkaistiin, kuvataan lisää.

Joten alun perin olemassa olevan järjestelmän looginen kaavio näytti tältä:

ICAP-liikenne, SMTP, käyttäjien tietokoneiden tapahtumat käsiteltiin Traffic Monitor (TM) -palvelimella. Samaan aikaan tietokantapalvelin selviytyi helposti kuormituksesta TM:n tapahtumien käsittelyn jälkeen, mutta itse TM:n kuormitus oli raskas. Tämä kävi ilmi viestijonon ilmestymisestä Device Monitor (DM) -palvelimelle sekä TM:n suorittimen ja muistin kuormituksesta.

Ensi silmäyksellä, jos lisäämme tähän järjestelmään toisen TM-palvelimen, joko ICAP tai DM voitaisiin vaihtaa siihen, mutta päätimme olla käyttämättä tätä menetelmää, koska vikasietokyky pieneni.

Ratkaisun kuvaus

Sopivan ratkaisun etsinnässä päädyimme vapaasti levitettävään ohjelmistoon pysyä hengissä yhdessä LVS. Koska keepalived ratkaisee vikasietoklusterin luomisen ongelman ja voi myös hallita LVS-tasapainotinta.

Sen, mitä halusimme saavuttaa (vähentää TM:n kuormitusta ja säilyttää nykyinen vikasietokyky), olisi pitänyt toimia seuraavan kaavion mukaisesti:

Toimivuutta tarkasteltaessa kävi ilmi, että palvelimille asennettu mukautettu RedHat-kokoonpano ei tue SNATia. Meidän tapauksessamme aioimme käyttää SNATia varmistamaan, että saapuvat paketit ja vastaukset niihin lähetetään samasta IP-osoitteesta, muuten saamme seuraavan kuvan:

Tätä ei voida hyväksyä. Esimerkiksi välityspalvelin, joka on lähettänyt paketteja Virtual IP (VIP) -osoitteeseen, odottaa vastausta VIP:ltä, mutta tässä tapauksessa se tulee IP2:lta varmuuskopiointiin lähetetyille istunnoille. Ratkaisu löytyi: varmuuskopioon oli luotava toinen reititystaulukko ja yhdistettävä kaksi TM-palvelinta erilliseen verkkoon alla olevan kuvan mukaisesti:

Asetukset

Toteutamme järjestelmän kahdesta palvelimesta, joissa on ICAP-, SMTP-, TCP 9100-palvelut ja yhdelle asennettuna kuormantasaaja.

Meillä on kaksi RHEL6-palvelinta, joista on poistettu vakiovarastot ja osa paketeista.

Palvelut, jotka meidän on tasapainotettava:

• ICAP – tcp 1344;

• SMTP – tcp 25.

Liikenteen siirtopalvelu DM:ltä – tcp 9100.

Ensin meidän on suunniteltava verkko.

Virtuaalinen IP-osoite (VIP):

• IP: 10.20.20.105.

Palvelin TM6_1:

• Ulkoinen IP: 10.20.20.101;

• Sisäinen IP: 192.168.1.101.

Palvelin TM6_2:

• Ulkoinen IP: 10.20.20.102;

• Sisäinen IP: 192.168.1.102.

Tämän jälkeen otamme IP-välityksen käyttöön kahdella TM-palvelimella. Kuinka tämä tehdään, on kuvattu RedHatissa täällä.

Päätämme, mikä meillä on pääpalvelimista ja mikä varapalvelimista. Olkoon isäntä TM6_1, varmuuskopio TM6_2.

Varmuuskopiossa luomme uuden tasapainotusreititystaulukon ja reitityssäännöt:

[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

Yllä olevat komennot toimivat, kunnes järjestelmä käynnistetään uudelleen. Voit varmistaa, että reitit säilyvät uudelleenkäynnistyksen jälkeen, syöttämällä ne sisään /etc/rc.d/rc.local, mutta paremmin asetustiedoston kautta /etc/sysconfig/network-scripts/route-eth1 (huomaa: tässä käytetään erilaista syntaksia).

Asenna Keepalived molemmille TM-palvelimille. Käytimme rpmfind.net-sivustoa jakelulähteenä:

[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

Säilytysasetuksissa määritämme yhden palvelimista isäntäpalvelimeksi, toisen varmuuskopioksi. Sitten asetamme VIP-palvelut ja palvelut kuormituksen tasapainottamiseen. Asetustiedosto sijaitsee yleensä täällä: /etc/keepalived/keepalived.conf.

TM1-palvelimen asetukset

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-palvelimen asetukset

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

Asennamme LVS:n masteriin, joka tasapainottaa liikennettä. Ei ole mitään järkeä asentaa tasapainotinta toiselle palvelimelle, koska meillä on vain kaksi palvelinta kokoonpanossa.

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

Tasapainotinta hallinnoi keepalived, jonka olemme jo konfiguroineet.

Viimeistele kuva lisäämällä Keepalived automaattiseen käynnistykseen molemmilla palvelimilla:

[root@tm6_1 ~]#chkconfig keepalived on

Johtopäätös

Tulosten tarkistaminen

Jatketaan molemmilla palvelimilla:

service keepalived start

VRRP-virtuaaliosoitteen saatavuuden tarkistaminen

Varmistetaan, että VIP on masterissa:

Ja varmuuskopiossa ei ole VIP:tä:

Ping-komennolla tarkistamme VIP:n saatavuuden:

Nyt voit sammuttaa masterin ja suorittaa komennon uudelleen ping.

Tuloksen pitäisi pysyä samana, ja varmuuskopiossa näemme VIP:

Palvelutasapainon tarkistus

Otetaan esimerkiksi SMTP. Avataan kaksi yhteyttä 10.20.20.105:een samanaikaisesti:

telnet 10.20.20.105 25

Isännässä meidän pitäisi nähdä, että molemmat yhteydet ovat aktiivisia ja yhdistetty eri palvelimiin:

[root@tm6_1 ~]#watch ipvsadm –Ln

Näin ollen olemme toteuttaneet TM-palveluiden vikasietoisen konfiguraation asentamalla tasapainottimen yhteen TM-palvelimista. Järjestelmämme osalta tämä puolitti TM:n kuormituksen, mikä mahdollisti vaakasuuntaisen skaalausongelman ratkaisemisen järjestelmän avulla.

Useimmissa tapauksissa tämä ratkaisu toteutetaan nopeasti ja ilman lisäkustannuksia, mutta joskus konfiguroinnissa on useita rajoituksia ja vaikeuksia esimerkiksi UDP-liikenteen tasapainottamisessa.

Lähde: will.com