LVS/Keepalived y los virtual_server_group

Cuando utilizamos Keepalived ya sea para routing o balanceo de carga/alta disponibilidad es bueno hacer uso de los grupos para evitar tanto hacer más compleja la configuración como añadir carga innecesaria al sistema (chequeos duplicados entre varios servidores virtuales).

En otra entrada podemos hablar de los grupos VRRP pero en este caso quería comentar un poco como funcionan los grupos de servidores virtuales ya que la documentación es prácticamente nula en ese sentido. Los virtual_server_group nos van a permitir asociar n virtual servers a un grupo de real servers.

Por ejemplo, tenemos tres servidores web los cuales deben atender peticiones de varias IPs virtuales (Ips de balanceo, virtual servers), estas IPs además pueden escuchar desde varios puertos, no sólo el 80:

  • 192.168.0.100 puerto 80
  • 192.168.0.101 puerto 80
  • 192.168.0.102 puerto 80
  • 192.168.0.102 puerto 81

Estas son las IPs balanceadas de servicio, que atacan contra tres servidores web:

  • 10.0.0.1 puerto 80
  • 10.0.0.2 puerto 80
  • 10.0.0.3 puerto 80

Si no utilizaramos los grupos de virtual servers, crearíamos un virtual_server para cada IP de servicio de las anteriormente mencionadas, eso son 4 virtual servers cada uno contra 3 real servers. Eso son 12 chequeos web cada “n” segundos que hayamos configurado el Healthchecker.

En cambio, si utilizamos grupos de balanceo únicamente se ejecutará un chequeo para cada real server, es decir, 3 chequeos cada “n” segundos que hayamos configurado el Healthchecker.

Para crear el grupo de virtual servers lo primero que definimos es el “virtual_server_group”, que incluirá las IPs de servicio y el puerto de escucha asociado a la misma. Le damos el identificador VGS_HTTP:

virtual_server_group VSG_HTTP {
    192.168.0.100 80
    192.168.0.101 80
    192.168.0.102 80
    192.168.0.102 81
}

Después definimos los real servers asociados a ese virtual_server_group. Todas las IPs especificadas en el virtual_server_group atacarán contra estos real servers. Aquí es donde especificamos el tipo de chequeo, si es TCP o UDP, modo NAT o directo, pesos, etc. La configuración típica de un virtual_server estándar con la diferencia de que le añadimos “group VSG_HTTP” en el bloque para definirlo como grupo.

virtual_server group VSG_HTTP {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    real_server 10.0.0.1 80 {
        weight 1
        HTTP_GET {
            url { 
              path /test.php
              digest 23x205b7s0fcs6s1e291cs63f3ccf34t
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 10.0.0.2 80 {
        weight 1
        HTTP_GET {
            url { 
              path /test.php
              digest 35x20567s08cs6s17291cs63f3ccf34c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 10.0.0.3 80 {
        weight 1
        HTTP_GET {
            url { 
              path /test.php
              digest 08x2d5b7s0fcs6s14g53ss63f3ccf34a
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

Tenéis algo más de información sobre todos los parámetros disponibles en GitHub.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *