O que devo fazer se a capacidade de um servidor não for suficiente para processar todas as solicitações e o fabricante do software não fornecer balanceamento de carga? Existem muitas opções - desde comprar um balanceador de carga até limitar o número de solicitações. Qual deles está correto, é preciso analisar a situação, levando em consideração as condições existentes. Neste artigo, informaremos o que pode ser feito se o orçamento for limitado e houver um servidor gratuito disponível.

Como um sistema para o qual era necessário reduzir a carga em um dos servidores, escolhemos o InfoWatch DLP (Sistema de prevenção de vazamento de informações). Um recurso da implementação foi o posicionamento da função de balanceador em um dos servidores de "combate".

Um dos problemas que encontramos é a incapacidade de usar o NAT NAT (SNAT). Para o que era necessário e como o problema foi resolvido, descreveremos mais adiante.

Portanto, o diagrama lógico inicial do sistema existente era o seguinte:

O tráfego ICAP, SMTP, eventos dos computadores dos usuários foram processados ​​no servidor Traffic Monitor (TM). Ao mesmo tempo, o servidor de banco de dados lidava facilmente com a carga após o processamento de eventos na TM, mas a carga na própria TM era grande. Isso ficou evidente pela ocorrência da fila de mensagens no servidor Device Monitor (DM), bem como pelo carregamento do processador e da memória na TM.

À primeira vista, se adicionarmos outro servidor de TM a esse esquema, o ICAP ou o DM poderão ser alternados, mas decidimos não usar esse método, pois a tolerância a falhas foi reduzida.

Descrição da solução

No processo de encontrar a solução certa, optamos pelo software de manutenção gratuita de freeware junto com o LVS . Como keepalived resolve o problema de criar um cluster de failover, ele também pode gerenciar o balanceador LVS.

O que queríamos chegar (reduzir a carga na TM e manter o nível atual de tolerância a falhas) deve funcionar de acordo com o seguinte esquema:

Ao verificar o desempenho, verificou-se que o conjunto RedHat personalizado instalado nos servidores não suporta SNAT. No nosso caso, planejávamos usar o SNAT para que os pacotes e as respostas recebidas fossem enviados do mesmo endereço IP, caso contrário, obteríamos a seguinte imagem:

Isso é inaceitável. Por exemplo, um servidor proxy, enviando pacotes para um endereço IP (VIP) virtual, aguardará uma resposta do VIP, mas, nesse caso, será do IP2 para as sessões enviadas para backup. A solução foi encontrada: era necessário criar outra tabela de roteamento no backup e conectar os dois servidores da TM a uma rede separada, conforme mostrado abaixo:

Configurações

Implementamos um esquema de dois servidores com serviços ICAP, SMTP, TCP 9100 e um balanceador de carga instalado em um deles.

Temos dois servidores RHEL6, dos quais os repositórios padrão e parte dos pacotes foram removidos.

Serviços que precisamos equilibrar:

• ICAP - tcp 1344;

• SMTP - tcp 25.

Serviço de tráfego DM - tcp 9100.

Primeiro, precisamos planejar a rede.

Endereço IP Virtual (VIP):

• IP: 10.20.20.105.

Servidor TM6_1:

• IP externo: 10.20.20.101;

• IP interno: 192.168.1.101.

Servidor TM6_2:

• IP externo: 10.20.20.102;

• IP interno: 192.168.1.102.

Ative o encaminhamento de IP nos dois servidores da TM. Como fazer isso no RedHat é descrito aqui .

Decidimos quais dos servidores teremos o principal e quais - o backup. Deixe o mestre ser TM6_1, o backup seja TM6_2.

No backup, crie uma nova tabela de roteamento do balanceador e regras de roteamento:

[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 

Os comandos acima funcionam até o sistema reiniciar. Para manter as rotas após a reinicialização, você pode digitá-las em /etc/rc.d/rc.local , mas melhor no arquivo de configurações / etc / sysconfig / network-scripts / route-eth1 (nota: isso usa uma sintaxe diferente).

Instale keepalived nos dois servidores da TM. Como fonte de distribuição, usamos o 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 

Nas configurações mantidas, atribuímos um dos servidores principais, o outro - backup. Em seguida, definimos VIP e serviços para balanceamento de carga. O arquivo de configurações geralmente está localizado aqui: /etc/keepalived/keepalived.conf .

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

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

Instale no LVS principal, que equilibrará o tráfego. Para o segundo servidor, não faz sentido instalar um balanceador, porque na configuração temos apenas dois servidores.

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

O balanceador será gerenciado pelo keepalived que já configuramos.

Para concluir a imagem, adicione keepalived à execução automática nos dois servidores:

 [root@tm6_1 ~]#chkconfig keepalived on 

Conclusão

Verificando resultados

Execute keepalived nos dois servidores:

 service keepalived start 

Verifique a disponibilidade do endereço virtual VRRP

Verifique se o VIP está no master:

E não há VIP no backup:

Usando o comando ping, verifique a disponibilidade do VIP:

Agora você pode desativar o master e executar o comando ping novamente.

O resultado deve permanecer o mesmo e, no backup, veremos o VIP:

Verificar balanceamento de serviço

Veja o SMTP, por exemplo. Execute duas conexões para 10.20.20.105 ao mesmo tempo:

 telnet 10.20.20.105 25 

No master, devemos ver que as duas conexões estão ativas e conectadas a servidores diferentes:

 [root@tm6_1 ~]#watch ipvsadm –Ln 

Assim, implementamos uma configuração à prova de falhas dos serviços de TM com a instalação de um balanceador em um dos servidores de TM. Para o nosso sistema, isso reduziu a carga na MT pela metade, o que nos permitiu resolver o problema da falta de escala horizontal por meio do sistema.

Na maioria dos casos, essa solução é implementada rapidamente e sem custos adicionais, mas às vezes existem várias limitações e dificuldades na configuração, por exemplo, ao equilibrar o tráfego UDP.