Que facer se a potencia dun servidor non é suficiente para procesar todas as solicitudes e o fabricante do software non proporciona equilibrio de carga? Hai moitas opcións, desde comprar un equilibrador de carga ata limitar o número de solicitudes. Cal é a correcta debe ser determinada pola situación, tendo en conta as condicións existentes. Neste artigo dirémosche o que podes facer se o teu orzamento é limitado e tes un servidor gratuíto.
Como sistema para o que foi necesario reducir a carga nun dos servidores, escollemos DLP (sistema de prevención de fugas de información) de InfoWatch. Unha característica da implementación foi a colocación da función de balance nun dos servidores de "combate".
Un dos problemas que atopamos foi a incapacidade de usar Source NAT (SNAT). Por que era necesario isto e como se resolveu o problema, describiremos máis adiante.
Entón, inicialmente o diagrama lóxico do sistema existente parecía o seguinte:
O tráfico ICAP, SMTP e eventos dos ordenadores dos usuarios foron procesados no servidor Traffic Monitor (TM). Ao mesmo tempo, o servidor de base de datos afrontaba facilmente a carga despois de procesar eventos na TM, pero a carga na propia TM era pesada. Isto foi evidente pola aparición dunha cola de mensaxes no servidor Device Monitor (DM), así como pola carga da CPU e da memoria na TM.
A primeira vista, se engadimos outro servidor TM a este esquema, poderíase cambiar a el ICAP ou DM, pero decidimos non usar este método, xa que reduciuse a tolerancia a fallos.
Descrición da solución
No proceso de busca dunha solución axeitada, optamos por un software de distribución libre Xunto con . Porque keepalived resolve o problema de crear un clúster de conmutación por fallo e tamén pode xestionar o equilibrador LVS.
O que queriamos conseguir (reducir a carga na TM e manter o nivel actual de tolerancia a fallos) debería funcionar segundo o seguinte esquema:
Ao comprobar a funcionalidade, resultou que o conxunto RedHat personalizado instalado nos servidores non admite SNAT. No noso caso, planeamos usar SNAT para asegurarnos de que os paquetes entrantes e as respostas a eles se envían dende o mesmo enderezo IP, se non, obteriamos a seguinte imaxe:
Isto é inaceptable. Por exemplo, un servidor proxy, que enviou paquetes a un enderezo IP virtual (VIP), esperará unha resposta de VIP, pero neste caso procederá de IP2 para as sesións enviadas a copia de seguridade. Atopouse unha solución: era necesario crear outra táboa de enrutamento na copia de seguridade e conectar dous servidores TM cunha rede separada, como se mostra a continuación:
Configuración
Implementaremos un esquema de dous servidores con servizos ICAP, SMTP, TCP 9100 e un equilibrador de carga instalado nun deles.
Temos dous servidores RHEL6, dos que se eliminaron os repositorios estándar e algúns paquetes.
Servizos que necesitamos equilibrar:
• ICAP - tcp 1344;
• SMTP – tcp 25.
Servizo de transmisión de tráfico de DM – tcp 9100.
En primeiro lugar, necesitamos planificar a rede.
Dirección IP virtual (VIP):
• IP: 10.20.20.105.
Servidor TM6_1:
• IP externa: 10.20.20.101;
• IP interna: 192.168.1.101.
Servidor TM6_2:
• IP externa: 10.20.20.102;
• IP interna: 192.168.1.102.
A continuación, activamos o reenvío de IP en dous servidores de TM. Como facelo descríbese en RedHat .
Decidimos cal dos servidores que teremos é o principal e cal será o backup. Deixa que o mestre sexa TM6_1, a copia de seguridade sexa TM6_2.
Na copia de seguridade creamos unha nova táboa de enrutamento do equilibrador e regras de enrutamento:
[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 anteriores funcionan ata que se reinicie o sistema. Para garantir que as rutas se conservan despois dun reinicio, podes ingresalas /etc/rc.d/rc.local, pero mellor a través do ficheiro de configuración /etc/sysconfig/network-scripts/route-eth1 (nota: aquí úsase unha sintaxe diferente).
Instala keepalived nos dous servidores de TM. Usamos rpmfind.net como fonte de distribución:
[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.rpmNa configuración de keepalived, asignamos un dos servidores como mestre, o outro como backup. Despois configuramos VIP e servizos para o equilibrio de carga. O ficheiro de configuración adoita estar aquí: /etc/keepalived/keepalived.conf.
Configuración para 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
}
}
}Configuración para 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 LVS no master, que equilibrará o tráfico. Non ten sentido instalar un equilibrador para o segundo servidor, xa que só temos dous servidores na configuración.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmO equilibrador será xestionado por keepalived, que xa configuramos.
Para completar a imaxe, imos engadir keepalived ao inicio automático en ambos os servidores:
[root@tm6_1 ~]#chkconfig keepalived onConclusión
Comprobando os resultados
Imos executar keepalived nos dous servidores:
service keepalived startComprobando a dispoñibilidade dun enderezo virtual VRRP
Asegurémonos de que o VIP estea no master:
E non hai VIP na copia de seguridade:
Usando o comando ping, comprobaremos a dispoñibilidade do VIP:
Agora podes apagar o master e executar o comando de novo ping.
O resultado debe seguir sendo o mesmo, e na copia de seguridade veremos VIP:
Comprobación do equilibrio do servizo
Poñamos por exemplo SMTP. Imos lanzar dúas conexións a 10.20.20.105 simultáneamente:
telnet 10.20.20.105 25No master deberiamos ver que ambas as conexións están activas e conectadas a diferentes servidores:
[root@tm6_1 ~]#watch ipvsadm –Ln
Así, implementamos unha configuración tolerante a fallos dos servizos de TM instalando un equilibrador nun dos servidores de TM. Para o noso sistema, isto reduciu a carga da TM á metade, o que permitiu resolver o problema da falta de escala horizontal utilizando o sistema.
Na maioría dos casos, esta solución implícase rapidamente e sen custos adicionais, pero ás veces hai unha serie de limitacións e dificultades na configuración, por exemplo, ao equilibrar o tráfico UDP.
Fonte: www.habr.com