Mostrando entradas con la etiqueta alta disponibilidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta alta disponibilidad. 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

INSTALACIÓN y CONFIGURACIÓN de HEARTBEAT en DEBIAN6 (II)

Tras ver como funciona heartbeat de modo teórico, pasamos a la parte práctica. El esquema que tendremos será el siguiente:

Para la prueba usaremos dos nodos con debian6 como sistema operativo, ambas máquinas tendrán una interfaz de red (eth0) y levantarán una virtual (eth0:0) que la mantendremos en alta disponibilidad con Heartbeat.
Datos
Nodo1(N1): 192.168.112.180
Nodo2(N2):192.168.112.181
IP Virtual:192.168.112.182


Empezamos!
 Para no complicarnos, instalaremos el paquete directamente de los repositorios en ambas máquinas, para ello ejecutamos:

 root@N1:~# apt-get install heartbeat

 Facil y sencillo, ya tenemos instalado heartbeat, podemos comprobarlo de la siguiente manera:

 root@N1:/etc/heartbeat# dpkg -l | grep heartbeat
ii  heartbeat                           1:3.0.3-2                    Subsystem for High-Availability Linux
ii  libheartbeat2                       1:3.0.3-2                    Subsystem for High-Availability Linux (libraries)

En /etc habrá aparecido una carpeta /heartbeat, donde están los ficheros de configuración. Para que Heartbeat funcione son necesario 3 ficheros.

-  ha.cf .Fichero de configuración principal.
- haresources. Fichero de configuración de recursos.
- authkeys. Información de autenticación. 

Si no encontramos estos ficheros en el directorio /etc/heartbeat, es posible encontrarlos en /usr/share/doc/heartbeat. En este caso tendriamos que copiar los ficheros en /etc/heartbeat.

 root@N1:/etc/heartbeat# cd /usr/share/doc/heartbeat/
 root@N1:/usr/share/doc/heartbeat# cp ha.cf haresources authkeys /etc/heartbeat

 authkeys

Comenzamos la configuración de los ficheros. Empezamos por el más facilito y el que menos guerra da, authkeys.Este fichero contiene información referida a como se autentican los nodos en el cluster. El contenido del fichero es el siguiente.

 auth 3
#1 crc
#2 sha1 HI!
3 md5 SecretKey


auth 3 :  método que usará para firmar los paquetes salientes ( 3 se corresponde con md5)

3 md5 SecretKey: nos dice el metodo que usa para firmar los paquetes (crc,sha1,md5), mientras que SecretKey es la clave compartida usada para firmar los paquetes. Esta clave debe ser la misma en todos los nodos. Si usamos CRC, no es necesaria clave, por ello es un método menos seguro.

Fichero configurado, sencillo. Una cosa a tener en cuenta, es que este fichero debe tener los permisos correctos, para que sea accedido solo por el propietario del mismo.

root@N1:/etc/heartbeat# chmod 600 /etc/heartbeat/authkeys

ha.cf

Este es el fichero principal de la configuración de heartbeat.

 #       keepalive: Número de segundos entre comprobación y comprobación
#
keepalive 2
#
#       deadtime: Número de segundos para declarar a un host muerto
#
deadtime 10
#
#       Que puerto UDP usar para comunicación unicast/multicast 
#
udpport 694
...
#       Sobre que interfaz se envian los hearbeats en multicast?
#
bcast   eth0            # Linux
#
mcast eth0 225.0.0.1 694 1 0
#
# IP del nodo 2
#
ucast eth0 192.168.112.181
#
# Si queremos autofailback     
#
auto_failback off
...
#
#       Que máquinas están en cluster
#       Formato: node    nodename ...  Podemos sacar el nodename con uname -n
#   
node    N1
node    N2

Con estas opciones funcionaría a la perfección, pero hay un montón más de opciones que nos permiten hacer cosas más complejas. Copiamos este fichero en el Nodo2, cambiando la IP que hemos configurado por la del Nodo1.

root@N1:/etc/heartbeat# scp /etc/heartbeat/ha.cf Nodo2:/etc/heartbeat/ha.cf

haresources

Este fichero contiene la lista de recursos que se moverán entre las máquinas de un cluster. tiene que ser IDENTICO en todos los nodos de un cluster

#       These resources in this file are either IP addresses, or the name
#       of scripts to run to "start" or "stop" the given resource.
#
#       The format is like this:
#
#node-name resource1 resource2 ... resourceN

N1 192.168.112.182

# También podemos ponerlo N1 IPaddr::192.168.112.182/24    


Heartbeat configurado!!. Este caso es muy simple, podemos encontrarnos con configuraciones un poco más complejas, pero el procedimiento sería el mismo.
Antes de arrancar el servicio, es importante dar de alta en el /etc/hosts de cada máquina el resto de nodos. Una vez hecho esto, reiniciamos y comprobamos:

root@N1:~# /etc/init.d/heartbeat restart
Stopping High-Availability services: Done.

Waiting to allow resource takeover to complete:Done.

Starting High-Availability services: IPaddr[1683]: INFO:  Resource is stopped
IPaddr[1723]: INFO:  Resource is stopped
Done.

Para comprobar podemos quitar la red, o tirar directamente el nodo que tiene el recurso, en nuestro caso N1, pasados 10 segundos, se dará el N1 como muerto y N2 levantará la interfaz.


root@N2:~# ifconfig
eth0   inet addr:192.168.112.181  Bcast:192.168.112.255  Mask:255.255.255.0
       
eth0:0   inet addr:192.168.112.182  Bcast:192.168.112.255  Mask:255.255.255.0

Todo correcto!. Hasta aquí el tutorial sobre Heartbeat. Espero que haya quedado claro el tema del heartbeat y os sea de ayuda.

Un saludo,
Víctor.
  
TOP

INSTALACIÓN y CONFIGURACIÓN de HEARTBEAT en DEBIAN6 (I)

Empiezo el blog con un tema recurrente, Heartbeat, herramienta muy usada en entornos de producción para aumentar la tolerancia a fallos de los equipos.

Heartbeat nos permite tener alta disponibilidad de determinados servicios o recursos mediante la creación y mantenimiento de un cluster compuesto por una serie de nodos. Los recursos se ejecutan y se mueven entre nodos, ya sea por motivos de fallo o por motivos de administración.

Un claro ejemplo que se nos presenta a diario es el de una página web. Cuando desde un navegador solicitamos una página web, normalmente nuestra petición va dirigida contra una IP virtual o de cluster, esta IP estará levantada en el servidor que mantiene el recurso (el recurso es la página web en nuestro caso) en ese momento.

Los nodos del cluster están constantemente en comunicación (normalmente mediante ping), en caso de caida o fallo del nodo que tiene el recurso, gracias a Heartbeat, otro nodo es capaz de levantarlo de forma totalmente transparente para el usuario y sin que se aprecie perdida de servicio


Después de una breve explicación sobre el funcionamiento de Heartbeat, pasamos a la parte práctica. 
El ejemplo será muy básico, configuraremos Heartbeat para que mantenga en alta disponibilidad una interfaz de red, que bien puede ser la interfaz a la cúal llegarán las peticiones de nuestro portal web.


Pero eso será en la siguiente entrada ;).
Saludos,
Víctor.