¿Qué hacer si la potencia de un servidor no es suficiente para procesar todas las solicitudes y el fabricante del software no proporciona equilibrio de carga? Hay muchas opciones, desde comprar un equilibrador de carga hasta limitar la cantidad de solicitudes. Cuál es el correcto debe ser determinado por la situación, teniendo en cuenta las condiciones existentes. En este artículo te contamos qué puedes hacer si tu presupuesto es limitado y tienes un servidor gratuito.
Como sistema para el cual era necesario reducir la carga en uno de los servidores, elegimos DLP (sistema de prevención de fuga de información) de InfoWatch. Una característica de la implementación fue la ubicación de la función de equilibrio en uno de los servidores de "combate".
Uno de los problemas que encontramos fue la imposibilidad de utilizar Source NAT (SNAT). Por qué era necesario esto y cómo se resolvió el problema, lo describiremos con más detalle.
Entonces, inicialmente el diagrama lógico del sistema existente se veía así:
El tráfico ICAP, SMTP y 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 pesada. Esto fue evidente por la aparición de una cola de mensajes en el servidor Device Monitor (DM), así como por la carga de CPU y memoria en el TM.
A primera vista, si agregamos otro servidor TM a este esquema, entonces se podría cambiar a él ICAP o DM, 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 búsqueda de una solución adecuada, nos decidimos por un software de distribución gratuita. con . Porque keepalived resuelve el problema de crear un clúster de conmutación por error y también puede administrar el equilibrador LVS.
Lo que queríamos lograr (reducir la carga en TM y mantener el nivel actual de tolerancia a fallas) debería haber funcionado de acuerdo con el siguiente esquema:
Al verificar la funcionalidad, resultó que el ensamblaje RedHat personalizado instalado en los servidores no es compatible con SNAT. En nuestro caso, planeamos usar SNAT para garantizar 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 ha enviado paquetes a una dirección IP virtual (VIP), esperará una respuesta de VIP, pero en este caso provendrá de IP2 para las sesiones enviadas a la copia de seguridad. Se encontró una solución: era necesario crear otra tabla de enrutamiento en la copia de seguridad y conectar dos servidores TM con una red separada, como se muestra a continuación:
Configuración
Implementaremos un esquema de dos servidores con servicios ICAP, SMTP, TCP 9100 y un balanceador de carga instalado en uno de ellos.
Disponemos de dos servidores RHEL6, de los cuales se han eliminado los repositorios estándar y algunos paquetes.
Servicios que necesitamos equilibrar:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Servicio de transmisión de tráfico desde DM – tcp 9100.
Primero, necesitamos 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 habilitamos el reenvío de IP en dos servidores TM. Cómo hacer esto se describe en RedHat .
Decidimos cuál de los servidores que tendremos es el principal y cuál será el de respaldo. Deje que el maestro sea TM6_1 y el respaldo sea TM6_2.
En la copia de seguridad creamos una nueva tabla de enrutamiento del 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 balancerLos comandos anteriores funcionan hasta que se reinicia el sistema. Para asegurarse de que las rutas se conserven después de un reinicio, puede ingresarlas en /etc/rc.d/rc.local, pero mejor a través del archivo de configuración /etc/sysconfig/network-scripts/ruta-eth1 (nota: aquí se utiliza una sintaxis diferente).
Instale keepalived en ambos servidores TM. Usamos rpmfind.net como fuente 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.rpmEn la configuración de keepalived, asignamos uno de los servidores como maestro y el otro como respaldo. Luego configuramos VIP y servicios para el equilibrio de carga. El archivo de configuración normalmente se encuentra aquí: /etc/keepalived/keepalived.conf.
Configuración para el servidor 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
}
}
}Configuración para el servidor 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
}
}Instalamos LVS en el maestro, que equilibrará el tráfico. No tiene sentido instalar un equilibrador para el segundo servidor, ya que solo tenemos dos servidores en la 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.rpmEl equilibrador será administrado por keepalived, que ya hemos configurado.
Para completar el cuadro, agreguemos keepalived para que se inicie automáticamente en ambos servidores:
[root@tm6_1 ~]#chkconfig keepalived onConclusión
Verificando resultados
Ejecutemos keepalived en ambos servidores:
service keepalived startComprobar la disponibilidad de una dirección virtual VRRP
Asegurémonos de que el VIP esté en maestro:
Y no hay VIP en la copia de seguridad:
Usando el comando ping comprobaremos la disponibilidad del VIP:
Ahora puedes cerrar master y ejecutar el comando nuevamente. ping.
El resultado debería seguir siendo el mismo y en la copia de seguridad veremos VIP:
Comprobando el equilibrio del servicio.
Tomemos como ejemplo SMTP. Iniciemos dos conexiones a 10.20.20.105 simultáneamente:
telnet 10.20.20.105 25En master deberíamos ver que ambas conexiones están activas y conectadas a diferentes servidores:
[root@tm6_1 ~]#watch ipvsadm –Ln
Por lo tanto, hemos implementado una configuración tolerante a fallas de los servicios de TM instalando un equilibrador en uno de los servidores de TM. Para nuestro sistema, esto redujo la carga en TM a la mitad, lo que permitió resolver el problema de la falta de escalamiento horizontal utilizando el sistema.
En la mayoría de los casos, esta solución se implementa rápidamente y sin costes adicionales, pero en ocasiones existen una serie de limitaciones y dificultades de configuración, por ejemplo, a la hora de equilibrar el tráfico UDP.
Fuente: habr.com