O que fazer se a potência 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 a compra de um balanceador de carga até a limitação do número de solicitações. Qual deles está correto deve ser determinado pela situação, levando em consideração as condições existentes. Neste artigo diremos o que você pode fazer se seu orçamento for limitado e você tiver um servidor gratuito.
Por ser um sistema para o qual era necessário reduzir a carga de um dos servidores, optamos pelo DLP (sistema de prevenção de vazamento de informações) do InfoWatch. Uma característica da implementação foi a colocação da função balanceadora em um dos servidores de “combate”.
Um dos problemas que encontramos foi a incapacidade de usar o Source NAT (SNAT). Por que isso foi necessário e como o problema foi resolvido, descreveremos mais adiante.
Então, inicialmente o diagrama lógico do sistema existente era assim:
O tráfego ICAP, SMTP e eventos dos computadores dos usuários foram processados no servidor Traffic Monitor (TM). Ao mesmo tempo, o servidor de banco de dados lidou facilmente com a carga após processar eventos na TM, mas a carga na própria TM era pesada. Isso ficou evidente pela aparência de uma fila de mensagens no servidor Device Monitor (DM), bem como pela carga de CPU e memória no TM.
À primeira vista, se adicionarmos outro servidor TM a este esquema, então tanto o ICAP quanto o DM poderão ser alternados para ele, mas decidimos não usar este método, pois a tolerância a falhas foi reduzida.
Descrição da solução
No processo de busca por uma solução adequada, optamos por software distribuído gratuitamente com . Porque keepalived resolve o problema de criação de um cluster de failover e também pode gerenciar o balanceador LVS.
O que queríamos alcançar (reduzir a carga no TM e manter o atual nível de tolerância a falhas) deveria ter funcionado de acordo com o seguinte esquema:
Ao verificar a funcionalidade, descobriu-se que o assembly RedHat personalizado instalado nos servidores não suporta SNAT. No nosso caso, planejamos usar SNAT para garantir que os pacotes recebidos e as respostas a eles sejam enviados do mesmo endereço IP, caso contrário, teríamos a seguinte imagem:
Isso é inaceitável. Por exemplo, um servidor proxy, tendo enviado pacotes para um endereço IP Virtual (VIP), esperará uma resposta do VIP, mas neste caso virá do IP2 para sessões enviadas para backup. Foi encontrada uma solução: foi necessário criar outra tabela de roteamento no backup e conectar dois servidores TM com uma rede separada, conforme mostrado abaixo:
configurações
Implementaremos 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 alguns pacotes foram removidos.
Serviços que precisamos equilibrar:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Serviço de transmissão de tráfego do 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.
Em seguida, habilitamos o encaminhamento de IP em dois servidores TM. Como fazer isso está descrito no RedHat .
Decidimos qual dos servidores que teremos é o principal e qual será o de backup. Deixe master ser TM6_1, backup ser TM6_2.
No backup, criamos 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 balancerOs comandos acima funcionam até que o sistema seja reinicializado. Para garantir que as rotas sejam preservadas após uma reinicialização, você pode inseri-las em /etc/rc.d/rc.local, mas melhor através do arquivo de configurações /etc/sysconfig/network-scripts/route-eth1 (nota: sintaxe diferente é usada aqui).
Instale o keepalived em ambos os servidores TM. Usamos rpmfind.net como fonte de distribuição:
[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.rpmNas configurações de keepalived, atribuímos um dos servidores como mestre e o outro como backup. Em seguida, configuramos VIP e serviços para balanceamento de carga. O arquivo de configurações geralmente está localizado aqui: /etc/keepalived/keepalived.conf.
Configurações para o 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
}
}
}Configurações para o 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
}
}Instalamos o LVS no master, que irá equilibrar o tráfego. Não faz sentido instalar um balanceador para o segundo servidor, pois temos apenas dois servidores na configuração.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmO balanceador será gerenciado pelo keepalived, que já configuramos.
Para completar o quadro, vamos adicionar keepalived para inicialização automática em ambos os servidores:
[root@tm6_1 ~]#chkconfig keepalived onConclusão
Verificando os resultados
Vamos executar o keepalived em ambos os servidores:
service keepalived startVerificando a disponibilidade de um endereço virtual VRRP
Vamos ter certeza de que o VIP está no master:
E não há VIP no backup:
Usando o comando ping, verificaremos a disponibilidade do VIP:
Agora você pode desligar o master e executar o comando novamente ping.
O resultado deve permanecer o mesmo, e no backup veremos VIP:
Verificando o balanceamento de serviço
Vejamos o SMTP, por exemplo. Vamos lançar duas conexões para 10.20.20.105 simultaneamente:
telnet 10.20.20.105 25No master devemos ver que ambas as conexões estão ativas e conectadas a servidores diferentes:
[root@tm6_1 ~]#watch ipvsadm –Ln
Assim, implementamos uma configuração tolerante a falhas dos serviços TM instalando um balanceador em um dos servidores TM. Para o nosso sistema, isso reduziu pela metade a carga do TM, o que possibilitou solucionar o problema de falta de escalonamento horizontal utilizando o sistema.
Na maioria dos casos, esta solução é implementada de forma rápida e sem custos adicionais, mas por vezes existem uma série de limitações e dificuldades na configuração, por exemplo, no balanceamento do tráfego UDP.
Fonte: habr.com