Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Ano ang gagawin kung ang kapangyarihan ng isang server ay hindi sapat upang iproseso ang lahat ng mga kahilingan, at ang tagagawa ng software ay hindi nagbibigay ng pagbalanse ng pagkarga? Maraming opsyon, mula sa pagbili ng load balancer hanggang sa paglilimita sa bilang ng mga kahilingan. Alin ang tama ay dapat matukoy ng sitwasyon, isinasaalang-alang ang mga umiiral na kondisyon. Sa artikulong ito sasabihin namin sa iyo kung ano ang maaari mong gawin kung limitado ang iyong badyet at mayroon kang libreng server.

Bilang isang sistema kung saan kinakailangan upang bawasan ang pagkarga sa isa sa mga server, pinili namin ang DLP (sistema ng pag-iwas sa pagtagas ng impormasyon) mula sa InfoWatch. Ang isang tampok ng pagpapatupad ay ang paglalagay ng function ng balancer sa isa sa mga "combat" server.

Одна из проблем, с которой мы столкнулись, – невозможность использования Source NAT (SNAT). Для чего это было нужно и как проблема была решена, мы расскажем далее.

Kaya, sa una ang lohikal na diagram ng umiiral na sistema ay ganito ang hitsura:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Ang trapiko ng ICAP, SMTP, mga kaganapan mula sa mga computer ng gumagamit ay naproseso sa server ng Traffic Monitor (TM). Kasabay nito, ang database server ay madaling nakayanan ang pag-load pagkatapos ng pagproseso ng mga kaganapan sa TM, ngunit ang pagkarga sa TM mismo ay mabigat. Ito ay maliwanag mula sa paglitaw ng isang queue ng mensahe sa server ng Device Monitor (DM), gayundin mula sa CPU at memory load sa TM.

Sa unang tingin, kung magdaragdag kami ng isa pang TM server sa scheme na ito, maaaring ilipat dito ang alinman sa ICAP o DM, ngunit nagpasya kaming huwag gamitin ang pamamaraang ito, dahil nabawasan ang fault tolerance.

Paglalarawan ng solusyon

Sa proseso ng paghahanap para sa isang angkop na solusyon, kami ay nanirahan sa malayang ipinamamahaging software keepalived kasama nina LVS. Поскольку keepalived решает задачу создания отказоустойчивого кластера, а также может управлять балансировщиком LVS.

Ang gusto naming makamit (bawasan ang load sa TM at panatilihin ang kasalukuyang antas ng fault tolerance) ay dapat na gumana ayon sa sumusunod na pamamaraan:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Kapag sinusuri ang pag-andar, lumabas na ang pasadyang pagpupulong ng RedHat na naka-install sa mga server ay hindi sumusuporta sa SNAT. Sa aming kaso, binalak naming gamitin ang SNAT upang matiyak na ang mga papasok na packet at mga tugon sa kanila ay ipapadala mula sa parehong IP address, kung hindi, makukuha namin ang sumusunod na larawan:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Ito ay hindi katanggap-tanggap. Halimbawa, ang isang proxy server, na nagpadala ng mga packet sa isang Virtual IP (VIP) address, ay aasahan ang isang tugon mula sa VIP, ngunit sa kasong ito manggagaling ito sa IP2 para sa mga session na ipinadala sa backup. May nakitang solusyon: kinailangan na gumawa ng isa pang routing table sa backup at ikonekta ang dalawang TM server na may hiwalay na network, tulad ng ipinapakita sa ibaba:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Mga Setting

Magpapatupad kami ng scheme ng dalawang server na may mga serbisyong ICAP, SMTP, TCP 9100 at isang load balancer na naka-install sa isa sa mga ito.

Mayroon kaming dalawang RHEL6 server, kung saan inalis ang mga karaniwang repositoryo at ilang pakete.

Mga serbisyo na kailangan nating balansehin:

• ICAP – tcp 1344;

• SMTP – tcp 25.

Serbisyo sa paghahatid ng trapiko mula sa DM – tcp 9100.

Una, kailangan nating planuhin ang network.

Virtual IP address (VIP):

• IP: 10.20.20.105.

Server TM6_1:

• Panlabas na IP: 10.20.20.101;

• Panloob na IP: 192.168.1.101.

Server TM6_2:

• Panlabas na IP: 10.20.20.102;

• Panloob na IP: 192.168.1.102.

Pagkatapos ay pinagana namin ang pagpapasa ng IP sa dalawang TM server. Paano ito gagawin ay inilarawan sa RedHat dito.

Kami ang magpapasya kung alin sa mga server ang mayroon kami ang pangunahing isa at kung alin ang magiging backup. Hayaan ang master ay TM6_1, backup ay TM6_2.

Sa backup, lumikha kami ng bagong balancer routing table at mga panuntunan sa pagruruta:

[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

Gumagana ang mga utos sa itaas hanggang sa ma-reboot ang system. Upang matiyak na ang mga ruta ay napanatili pagkatapos ng pag-reboot, maaari mong ipasok ang mga ito /etc/rc.d/rc.local, но лучше через файл настроек /etc/sysconfig/network-scripts/route-eth1 (tandaan: ibang syntax ang ginagamit dito).

I-install ang keepalived sa parehong TM server. Ginamit namin ang rpmfind.net bilang pinagmumulan ng pamamahagi:

[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

В настройках keepalived назначаем один из серверов master, другой – backup. Затем задаем VIP и сервисы для балансировки нагрузки. Файл настроек обычно расположен тут: /etc/keepalived/keepalived.conf.

Настройки для сервера 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
        }
    }
}

Настройки для сервера 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 
        } 
}

Nag-install kami ng LVS sa master, na magbabalanse sa trapiko. Walang saysay na mag-install ng balancer para sa pangalawang server, dahil dalawa lang ang server namin sa configuration.

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

Ang balancer ay pamamahalaan ng keepalived, na na-configure na namin.

Upang makumpleto ang larawan, idagdag natin ang keepalived sa autostart sa parehong mga server:

[root@tm6_1 ~]#chkconfig keepalived on

Konklusyon

Sinusuri ang mga resulta

Запустим keepalived на обоих серверах:

service keepalived start

Проверка доступности виртуального адреса VRRP

Siguraduhin natin na ang VIP ay nasa master:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

At walang VIP sa backup:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Gamit ang ping command, susuriin namin ang pagkakaroon ng VIP:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Ngayon ay maaari mong isara ang master at patakbuhin muli ang command ping.

Ang resulta ay dapat manatiling pareho, at sa backup makikita natin ang VIP:

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Sinusuri ang pagbabalanse ng serbisyo

Kunin natin ang SMTP bilang halimbawa. Maglunsad tayo ng dalawang koneksyon sa 10.20.20.105 nang sabay-sabay:

telnet 10.20.20.105 25

Sa master dapat nating makita na ang parehong mga koneksyon ay aktibo at konektado sa iba't ibang mga server:

[root@tm6_1 ~]#watch ipvsadm –Ln

Pagse-set up ng load balancing sa InfoWatch Traffic Monitor

Kaya, nagpatupad kami ng fault-tolerant na configuration ng mga serbisyo ng TM sa pamamagitan ng pag-install ng balancer sa isa sa mga TM server. Para sa aming system, binawasan nito ng kalahati ang load sa TM, na naging posible upang malutas ang problema ng kakulangan ng horizontal scaling gamit ang system.

Sa karamihan ng mga kaso, ang solusyon na ito ay ipinatupad nang mabilis at walang karagdagang mga gastos, ngunit kung minsan ay may ilang mga limitasyon at kahirapan sa pagsasaayos, halimbawa, kapag binabalanse ang trapiko ng UDP.

Pinagmulan: www.habr.com

Magdagdag ng komento