¿Qué debo hacer si la potencia de un servidor no es suficiente para procesar todas las solicitudes y el fabricante del software no proporciona el equilibrio de carga? Hay muchas opciones, desde comprar un equilibrador de carga hasta limitar la cantidad de solicitudes. Cuál es correcto, debe mirar la situación, teniendo en cuenta las condiciones existentes. En este artículo le diremos qué se puede hacer si el presupuesto es limitado y hay un servidor gratuito disponible.

Como un sistema para el que era necesario reducir la carga en uno de los servidores, elegimos InfoWatch DLP (Sistema de prevención de fugas de información). Una característica de la implementación fue la colocación de la función equilibradora en uno de los servidores de "combate".

Uno de los problemas que encontramos es la incapacidad de usar Source NAT (SNAT). Para lo que se necesitaba y cómo se resolvió el problema, lo describiremos más adelante.

Entonces, el diagrama lógico inicial del sistema existente era el siguiente:

El tráfico ICAP, SMTP, los eventos de las computadoras de los usuarios se procesaron en el servidor Traffic Monitor (TM). Al mismo tiempo, el servidor de la base de datos hizo frente fácilmente a la carga después de procesar eventos en la TM, pero la carga en la TM en sí era grande. Esto fue evidente por la aparición de la cola de mensajes en el servidor Device Monitor (DM), así como por la carga del procesador y la memoria en el TM.

A primera vista, si agregamos otro servidor TM a este esquema, ICAP o DM podrían cambiarse a él, pero decidimos no usar este método, ya que se redujo la tolerancia a fallas.

Descripción de la solución

En el proceso de encontrar la solución correcta, nos decidimos por el software freeware keepalived junto con LVS . Dado que keepalived resuelve el problema de crear un clúster de conmutación por error, también puede administrar el equilibrador LVS.

A lo que queríamos llegar (reducir la carga en TM y mantener el nivel actual de tolerancia a fallas) debería funcionar de acuerdo con el siguiente esquema:

Al verificar el rendimiento, resultó que el ensamblaje RedHat personalizado instalado en los servidores no es compatible con SNAT. En nuestro caso, planeamos usar SNAT para que los paquetes entrantes y las respuestas a ellos se envíen desde la misma dirección IP, de lo contrario obtendríamos la siguiente imagen:

Esto es inaceptable. Por ejemplo, un servidor proxy, que envía paquetes a una dirección IP virtual (VIP), esperará una respuesta de VIP, pero en este caso vendrá de IP2 para las sesiones enviadas a la copia de seguridad. Se encontró la solución: era necesario crear otra tabla de enrutamiento en la copia de seguridad y conectar los dos servidores TM con una red separada, como se muestra a continuación:

Configuraciones

Implementamos un esquema de dos servidores con servicios ICAP, SMTP, TCP 9100 y un equilibrador de carga instalado en uno de ellos.

Tenemos dos servidores RHEL6, de los cuales se han eliminado los repositorios estándar y parte de los paquetes.

Servicios que necesitamos para equilibrar:

• ICAP - tcp 1344;

• SMTP - tcp 25.

Servicio de tráfico DM - tcp 9100.

Primero tenemos que planificar la red.

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.

Luego habilite el reenvío de IP en los dos servidores TM. Aquí se describe cómo hacerlo en RedHat.

Decidimos cuál de los servidores tendremos el principal y cuál, la copia de seguridad. Deje que el maestro sea TM6_1, el respaldo sea TM6_2.

En la copia de seguridad, cree una nueva tabla de enrutamiento equilibrador y reglas de enrutamiento:

[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 

Los comandos anteriores funcionan hasta que el sistema se reinicia. Para mantener las rutas después de reiniciar, puede ingresarlas en /etc/rc.d/rc.local , pero mejor a través del archivo de configuración / etc / sysconfig / network-scripts / route-eth1 (nota: esto usa una sintaxis diferente).

Instale keepalived en ambos servidores TM. Como fuente de distribución, utilizamos 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 

En la configuración de keepalived, asignamos uno de los servidores maestros, el otro, backup. Luego configuramos VIP y servicios para el equilibrio de carga. El archivo de configuración generalmente se encuentra aquí: /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 } } 

Instalar en LVS maestro, que equilibrará el tráfico. Para el segundo servidor, no tiene sentido instalar un equilibrador, porque en la configuración solo tenemos dos 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 

El balanceador será administrado por el keepalived que ya hemos configurado.

Para completar la imagen, agregue keepalived para la ejecución automática en ambos servidores:

 [root@tm6_1 ~]#chkconfig keepalived on 

Conclusión

Comprobación de resultados

Ejecute keepalived en ambos servidores:

 service keepalived start 

Verifique la disponibilidad de la dirección virtual VRRP

Asegúrese de que el VIP esté en master:

Y no hay VIP en la copia de seguridad:

Usando el comando ping, verifique la disponibilidad de VIP:

Ahora puede apagar el maestro y ejecutar el comando ping nuevamente.

El resultado debe seguir siendo el mismo, y en la copia de seguridad veremos VIP:

Verificar el equilibrio del servicio

Tome SMTP, por ejemplo. Ejecute dos conexiones a 10.20.20.105 al mismo tiempo:

 telnet 10.20.20.105 25 

En master, deberíamos ver que ambas conexiones están activas y conectadas a diferentes servidores:

 [root@tm6_1 ~]#watch ipvsadm –Ln 

Por lo tanto, implementamos una configuración a prueba de fallas de los servicios TM con la instalación de un equilibrador en uno de los servidores TM. Para nuestro sistema, esto redujo la carga en TM a la mitad, lo que nos permitió resolver el problema de la falta de escala horizontal por medio del sistema.

En la mayoría de los casos, esta solución se implementa rápidamente y sin costos adicionales, pero a veces hay una serie de limitaciones y dificultades en la configuración, por ejemplo, al equilibrar el tráfico UDP.