Kion fari se la potenco de unu servilo ne sufiĉas por procesi ĉiujn petojn, kaj la softvarproduktanto ne provizas ŝarĝan ekvilibron? Estas multaj ebloj, de aĉetado de ŝarĝbalancilo ĝis limigado de la nombro da petoj. Kiu estas ĝusta, devas esti determinita de la situacio, konsiderante ekzistantajn kondiĉojn. En ĉi tiu artikolo ni diros al vi, kion vi povas fari se via buĝeto estas limigita kaj vi havas senpagan servilon.

Kiel sistemon, por kiu necesis redukti la ŝarĝon sur unu el la serviloj, ni elektis DLP (informforflua preventa sistemo) de InfoWatch. Karakterizaĵo de la efektivigo estis la lokigo de la ekvilibra funkcio sur unu el la "batalaj" serviloj.

Unu el la problemoj, kiujn ni renkontis, estis la malkapablo uzi Fontan NAT (SNAT). Kial ĉi tio estis bezonata kaj kiel la problemo estis solvita, ni priskribos plu.

Do, komence la logika diagramo de la ekzistanta sistemo aspektis jene:

ICAP-trafiko, SMTP, okazaĵoj de uzantaj komputiloj estis prilaboritaj sur la Traffic Monitor (TM) servilo. Samtempe, la datumbaza servilo facile traktis la ŝarĝon post prilaborado de eventoj sur la TM, sed la ŝarĝo sur la TM mem estis peza. Ĉi tio estis evidenta de la apero de mesaĝvico sur la Device Monitor (DM) servilo, same kiel de la CPU kaj memorŝarĝo sur la TM.

Unuavide, se ni aldonas alian TM-servilon al ĉi tiu skemo, tiam aŭ ICAP aŭ DM povus esti ŝanĝitaj al ĝi, sed ni decidis ne uzi ĉi tiun metodon, ĉar misfunkciadotoleremo estis reduktita.

Priskribo de la solvo

En la serĉado de taŭga solvo, ni decidiĝis pri libere distribuata programaro konservita kune kun LVS. Ĉar keepalived solvas la problemon de kreado de malsukcesa areto kaj ankaŭ povas administri la LVS-balancilon.

Kion ni volis atingi (redukti la ŝarĝon sur TM kaj konservi la nunan nivelon de faŭltoleremo) devus funkcii laŭ la sekva skemo:

Kontrolinte la funkciecon, montriĝis, ke la kutima RedHat-asembleo instalita sur la serviloj ne subtenas SNAT. En nia kazo, ni planis uzi SNAT por certigi, ke envenantaj pakoj kaj respondoj al ili estas senditaj de la sama IP-adreso, alie ni ricevus la sekvan bildon:

Ĉi tio estas neakceptebla. Ekzemple, prokura servilo, sendinte pakaĵojn al Virtuala IP (VIP) adreso, atendos respondon de VIP, sed ĉi-kaze ĝi venos de IP2 por sesioj senditaj al sekurkopio. Solvo estis trovita: necesis krei alian vojtablon sur la sekurkopio kaj konekti du TM-servilojn kun aparta reto, kiel montrite sube:

Agordoj

Ni efektivigos skemon de du serviloj kun servoj ICAP, SMTP, TCP 9100 kaj ŝarĝbalancilo instalita sur unu el ili.

Ni havas du servilojn RHEL6, el kiuj la normaj deponejoj kaj kelkaj pakaĵoj estis forigitaj.

Servoj kiujn ni bezonas ekvilibrigi:

• ICAP - tcp 1344;

• SMTP - tcp 25.

Trafiktransdona servo de DM - tcp 9100.

Unue, ni devas plani la reton.

Virtuala IP-adreso (VIP):

• IP: 10.20.20.105.

Servilo TM6_1:

• Ekstera IP: 10.20.20.101;

• Interna IP: 192.168.1.101.

Servilo TM6_2:

• Ekstera IP: 10.20.20.102;

• Interna IP: 192.168.1.102.

Tiam ni ebligas IP-sendon sur du TM-serviloj. Kiel fari tion estas priskribita sur RedHat tie.

Ni decidas, kiu el la serviloj, kiujn ni havos, estas la ĉefa kaj kiu estos la rezerva. Estu majstro TM6_1, sekurkopio estu TM6_2.

Dum sekurkopio ni kreas novan ekvilibran vojtablon kaj vojregulojn:

[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

La supraj komandoj funkcias ĝis la sistemo estas rekomencita. Por certigi, ke la itineroj estas konservitaj post rekomenco, vi povas enigi ilin /etc/rc.d/rc.local, sed pli bone per la agorda dosiero /etc/sysconfig/network-scripts/route-eth1 (noto: malsama sintakso estas uzata ĉi tie).

Instalu keepalived sur ambaŭ TM-serviloj. Ni uzis rpmfind.net kiel distribufonton:

[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

En la konservitaj agordoj, ni atribuas unu el la serviloj kiel majstro, la alian kiel rezerva. Tiam ni starigas VIP kaj servojn por ŝarĝoekvilibro. La agorda dosiero kutime troviĝas ĉi tie: /etc/keepalived/keepalived.conf.

Agordoj por TM1 Server

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

Agordoj por TM2 Server

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

Ni instalas LVS sur la majstro, kiu ekvilibros la trafikon. Ne havas sencon instali ekvilibron por la dua servilo, ĉar ni havas nur du servilojn en la agordo.

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

La ekvilibristo estos administrita de keepalived, kiun ni jam agordis.

Por kompletigi la bildon, ni aldonu keepalived al aŭtomata starto sur ambaŭ serviloj:

[root@tm6_1 ~]#chkconfig keepalived on

konkludo

Kontrolante la rezultojn

Ni rulu keeplivelive sur ambaŭ serviloj:

service keepalived start

Kontrolante la haveblecon de virtuala adreso VRRP

Ni certigu, ke la VIP estas sur majstro:

Kaj ne ekzistas VIP en sekurkopio:

Uzante la ping-komandon, ni kontrolos la haveblecon de la VIP:

Nun vi povas malŝalti majstron kaj ruli la komandon denove ping.

La rezulto devus resti la sama, kaj dum sekurkopio ni vidos VIP:

Kontrolante servobalancadon

Ni prenu SMTP ekzemple. Ni lanĉu du konektojn al 10.20.20.105 samtempe:

telnet 10.20.20.105 25

Sur majstro ni devus vidi, ke ambaŭ konektoj estas aktivaj kaj konektitaj al malsamaj serviloj:

[root@tm6_1 ~]#watch ipvsadm –Ln

Tiel, ni efektivigis mistoleran agordon de TM-servoj instalante balancilon sur unu el la TM-serviloj. Por nia sistemo, ĉi tio reduktis la ŝarĝon sur TM je duono, kio ebligis solvi la problemon de manko de horizontala skalo uzante la sistemon.

Plejofte, ĉi tiu solvo estas efektivigita rapide kaj sen aldonaj kostoj, sed foje ekzistas kelkaj limigoj kaj malfacilaĵoj en agordo, ekzemple, dum ekvilibro de UDP-trafiko.

fonto: www.habr.com