Mostrando entradas con la etiqueta LVS. Mostrar todas las entradas
Mostrando entradas con la etiqueta LVS. Mostrar todas las entradas
TOP

KeepAlived: Alta Disponibilidad y balanceo de carga

Keepalived nos ofrece una solución de alta disponibilidad mediante el uso del protocolo VRRP . Este protocolo, ideado para la L3 de la capa OSI, simula la presencia de un router "virtual" contra el que van dirigidas las peticiones, enrutando las peticiones sobre uno de los routers físicos que prestan servicio de manera totalmente transparente para el usuario. En caso de caida del router físico, se negocia el paso del servicio a otro router físico sin que se aprecie perdida de servicio.Keepalived también nos proporciona balanceo de carga basado en LVS.


El gran fuerte de Keepalived es posiblemente su sencillez. La configuración se basa unicamente en un fichero de configuración (keepalived.conf) donde se incluyen todas las opciones necesarias para la puesta a punto, (nada de linea de comandos, nada de interfaces gráficas), y los scripts de arranque y parada típicos. Quizá se pueda echar en falta algún método de configuración más elaborado, por ejemplo, para producir un failover controlado, cambiar el estado Master-Slave de los nodos mediante línea de comandos, ya que la única manera de hacerlo es producirlo manualmente, parando el servicio en el nodo Master.

Vamos ahora con un pequeño ejemplo de la forma que presenta el fichero de configuración. Necesitamos un fichero de configuración en cada uno de los nodos del cluster.

vrrp_sync_group VG1 {
    group {
        VI_1
        VI_2
    }
}


En Vrrp_sync_group especificamos los recursos que se van a sincronizar en caso de failover. En nuestro caso tenemos dos instancias VI_1 y VI_2 que se corresponden con dos interfaces virtuales. En caso de fallo queremos que ambas interfaces se cambien de nodo, por ello las metemos en este grupo.

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.110.115/24
    }
}

vrrp_instance VI_2 {
    state MASTER
    interface eth1
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.5/24
    }
}

El resto del fichero se compondrá de las instancias, entendiendo por instancia, los servicios que mantendremos en alta disponibilidad. La forma de estas es la que sigue.

  • state MASTER: Aqui definimos quien será el Master/Slave sobre este recurso. En uno de los nodos estará puesto en Master, en el otro/otros estará/an como Slave.
  • interface eth1: Sobre qué interfaz se levantará nuestra Ip virtual.
  • virtual_router_id 51: Identificador de "Cluster". Debe ser el mismo en ambos (o los que sean) nodos del cluster y distinto a cualquier otro Id de cluster que utilice keepalived.
  • authentication: Opciones de autenticación.
    • auth_type PASS: tipo de autenticación por Password.
    • auth_pass xxxx: password que comparten los nodos para identificarse. Debe ser el mismo en todos los nodos. va en texto claro, así que ojito con quien ve este fichero.
  • virtual_ipaddress: Ip virtual. Formato IP/mascara.

Con estos parametros en todos los nodos de nuestro cluster tendriamos configurado la alta disponibilidad de interfaces en nuestro cluster. La forma de configurar los servicios es ligeramente distinta a la forma de configurar las interfaces y no entraremos en ello aquí.

Para ver quien tiene configuradas las interfaces virtuales que hemos configurado en keepalived, no es suficiente con el comando "ifconfig" . Podemos ver las interfaces con uno de los siguientes comando.
    • ip address list
    • ip -4 addr show
Ambos comandos nos mostrarán las ips virtuales asociadas a nuestras interfaces físicas. Por último, si queremos provocar un failover manual, es suficiente con apagar el servicio keepalived en el nodo que tenga los recursos.

V.




TOP

LVS : Balanceo de carga en el Kernel de Linux

Pues bien, en las siguientes entradas mi objetivo será presentar las bases para poder montar un sistema de Firewalls basados en IPtables, con balance de carga, alta disponibilidad y QoS. Haré una pequeña introducción de las herramientas que voy a usar, para luego presentar el escenario final y resolverlo.

Empezamos pues. El primer elemento que analizaremos será el SW que usaremos para balancear carga.

LVS (Linux Virtual Server) es una herramienta que nos permite gestionar balance de carga en sistemas Linux. Es una solución de código abierto que busca desarrollar un servidor Linux de alto rendimiento que proporcione buena escalabilidad, confiabilidad y robustez usando tecnología clustering. Ofrece balance de carga en la L4 (TCP/UDP) mediante chequeos dinámicos y adaptativos que manejan el pool de carga dependiendo de la carga de sus componentes. LVS viene integrada en herramientas "HA&LB" ampliamente conocidas como UltraMonkey, KeepAlived, Piranha.



Es posible obtener LVS de los repositorios de nuestra distribución Linux (ipvsadm package), aunque en los últimos kernels suele venir ya integrada.

Vamos con un pequeño ejemplo de uso de LVS:



Los siguientes comandos configuran un servidor linux para distribuir peticiones entrantes dirigidas a 207.175.44.110:80 entre una granja de 5 servidores (192.168.10.x).

ipvsadm -A -t 207.175.44.110:80 -s rr

Con -A le indicamos a LVS que queremos añadir un servicio nuevo, con -t que ese servicio va a ser del tipo TCP, -s va a ser el modo de balanceo de carga, en este caso rr, round robin, de manera que las peticiones se distribuyan de forma igual por los servidores. Con esta instrucción hemos creado un servicio, de tal manera que todas las peticiones que lleguen a 207.175.44.110 puerto TCP 80 se balanceen de forma equitativa entre los servidores, ¿que servidores?, ese es el siguiente paso:

ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.1:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.2:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.3:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.4:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.5:80 -m



Con el parametro -a , señalamos que queremos agregar un nuevo servidor a nuestro servicio de balance carga que viene determinado por ip:puerto (207.175.44.110:80),con el parámetro -r indicamos la IP de los servidores de nuestra granja ( entre los que se balanceará el servicio) y con el parámetro -m, decimos que use como método "masquerading", osease NAT ( las peticiones que lleguen a 207.175.44.110:80 sean traducidas a alguna ip de nuestros servidores.

Voila!,tenemos configurado nuestro servicio de balance de carga. Es un ejemplo sencillo, LVS tiene multitud de opciones para hacer distintas cosas que pueden ser muy útiles y que se pueden consultar en la página del manual de ipvsadm.

En las siguientes entradas veremos el resto de herramientas para finalmente juntarlas todas bajo un mismo ejemplo.

Un saludo,
Víctor.