Cluster HTTP en Alta Disponibilidad Con CentOS

download Cluster HTTP en Alta Disponibilidad Con CentOS

of 5

description

Cluster HTTP en Alta Disponibilidad Con CentOS

Transcript of Cluster HTTP en Alta Disponibilidad Con CentOS

  • Cluster HTTP en alta disponibilidad con CentOS + Heartbeat

    En esta entrada vamos a montar un cluster de alta disponibilidad con dos nodos CentOS,

    Heartbeat y servidor web Apache. A partir de esta configuracin bsica el cluster puede

    aumentar su nmero de nodos segn requerimientos de forma gradual y sencilla.

    La configuracin del cluster es la siguiente:

    nodo 1:

    IP: 192.168.1.129

    HOSTNAME: cluster01

    nodo 2:

    IP: 192.168.1.130

    HOSTNAME: cluster02

    IP virtual para el cluster:

    IP: 192.168.1.131

    Imagen: hapm.sourceforge.net

    Una vez configurado en los dos nodos el hostname e IPs (la IP virtual de momento no la

    tocamos), pasamos directamente a la instalacin de Heartbeat y Apache, en ambos nodos

    deberamos instalar:

    yum install httpd

    Si prefers compilar apache en lugar de usar paquetes precompilados acudir a este post:

    compilar apache y php.

  • Nota: Tendris que configurar Apache para que escuche por la IP virtual, no lo arranquis

    todava:

    Listen 192.168.1.131:80

    Evitamos que httpd arranque automticamente, lo har HeartBeat:

    # chkconfig httpd off

    Instalamos Heartbeat mediante yum:

    # yum install heartbeat

    Una vez instalado pasamos a la configuracin de Heartbeat. Los ficheros bsicos son

    authkeys, ha.cf y haresources. La ruta en la que debemos configurarlos es /etc/ha.d/. Si

    necesitamos ejemplos o los ficheros base los podemos encontrar en

    /usr/share/doc/heartbeat-2.1.2/.

    ha.cf

    ha.cf es el fichero en el que se especifica la configuracin global del cluster. Nuestra

    configuracin base es la siguiente. En el fichero de muestra tenis informacin sobre todas

    las directivas disponibles:

    logfile /var/log/cluster.log

    logfacility local0

    warntime 5

    deadtime 30

    initdead 120

    keepalive 2

    bcast eth0

    udpport 694

    auto_failback on

    node cluster01

    node cluster02

    En primera instancia especificamos que el log donde se volcar toda la informacin ser

    /var/log/cluster.log. Las directivas de deteccin de fallo de nodos son las siguientes:

    warntime: Heartbeat avisar cuando un nodo falle tras 5 segundos. deadtime: Hearbeat confirmar que un nodo ha cado, 30 segundos. initdead: Tiempo mximo que Heartbeat esperar a que un nodo arranque, 60 segundos. keepalive: Especifica cada cuanto tiempo Heartbeat enviar paquetes para comprobar la

    disponibilidad de los nodos, 2 segundos.

    A travs de node especificamos cada uno de los nodos que componen el cluster (sus hostname), uddport es el puerto UDP utilizado para la comunicacin y bcast la interfaz

    broadcast.

    authkeys

  • Este es el fichero en el que se configura el sistema de autenticacin entre todos los nodos

    del cluster. El formato es el siguiente:

    auth num

    num algorithm secret

    Los algoritmos disponibles son crc (1) sha1 (2) y md5 (3). Se recomienda utilizar sha1 as

    que lo utilizamos para nuestro cluster. clu$ter-4uth ser la llave de autenticacin (secret):

    auth 2

    2 sha1 clu$ter-4uth

    nicamente root debe poder leer el fichero, as que asignamos los permisos correspondientes:

    # chmod 600 /etc/ha.d/authkeys

    haresources

    En este fichero se especifican los servicios que se moveran entre los distintos nodos del

    cluster cuando uno de ellos caiga. En este caso nicamente trabajaremos con httpd, en el

    propio fichero tenis toda la informacin. Le especificamos tambin la IP virtual asignada al

    servicio:

    cluster01 192.168.1.131 httpd

    Propagar cambios de configuracin entre nodos

    Una vez finalizada la configuracin inicial, podemos propagar los cambios entre todos los

    nodos mediante el comando ha_propagate. Hay que tener conectividad ssh/scp entre las

    mquinas, si no utilizis llaves os pedir la clave ssh de los nodos:

    # /usr/lib/heartbeat/ha_propagate

    Propagating HA configuration files to node cluster02.

    ha.cf

    100% 11KB 10.7KB/s 00:00

    authkeys

    100% 672 0.7KB/s 00:00

    Setting HA startup configuration on node cluster02.

    ..

    ...

    Arrancar y probar el cluster

    Una vez finalizada la configuracin ya podemos proceder a arrancar el cluster, para ello

    iniciamos HeartBeat en cada uno de los nodos:

    # /etc/init.d/heartbeat start

    El propio HeartBeat reiniciar Apache, no lo hagis manualmente:

    IPaddr[4618]: 2011/04/19_11:43:02 INFO: Resource is stopped

  • ResourceManager[4591]: 2011/04/19_11:43:02 info: Running

    /etc/ha.d/resource.d/IPaddr 192.168.1.131 start

    IPaddr[4694]: 2011/04/19_11:43:02 INFO: Using calculated nic for

    192.168.1.131: eth0

    IPaddr[4694]: 2011/04/19_11:43:02 INFO: Using calculated netmask for

    192.168.1.131: 255.255.255.0

    IPaddr[4694]: 2011/04/19_11:43:03 INFO: eval ifconfig eth0:0

    192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255

    IPaddr[4677]: 2011/04/19_11:43:03 INFO: Success

    ResourceManager[4591]: 2011/04/19_11:43:03 info: Running

    /etc/init.d/httpd start

    En este caso no estamos montando a travs de iSCSI, NFS o similar los datos que sirve

    Apache, de modo que para verificar contra qu nodo del cluster estamos conectando en cada

    momento podemos crear un index.html bsico en cada uno de los nodos, ruta

    /var/www/html/index.html en el que indiquemos el nodo en el que nos encontramos.

    En este momento, si accedermos a http://192.168.1.131 ya deberamos poder acceder va

    web al servicio, y nos indicar que es el cluster01 quien est sirviendo el contenido.

    La primera prueba que vamos a hacer para probar el cluster es tirar el nodo cluster01, para

    ello tiramos la interfaz de red, en mi caso eth0:

    # ifdown eth0

    Una vez pasado el tiempo especificado en la configuracin, en nodo cluster02 debera tomar

    el control de httpd y servir la web http://192.168.1.131, en el log veris algo similar a:

    heartbeat[2354]: 2011/04/19_11:31:24 WARN: node cluster01: is dead

    heartbeat[2354]: 2011/04/19_11:31:24 WARN: No STONITH device configured.

    heartbeat[2354]: 2011/04/19_11:31:24 WARN: Shared disks are not protected.

    heartbeat[2354]: 2011/04/19_11:31:24 info: Resources being acquired from

    cluster01.

    heartbeat[2354]: 2011/04/19_11:31:24 info: Link cluster01:eth0 dead.

    harc[2417]: 2011/04/19_11:31:25 info: Running /etc/ha.d/rc.d/status

    status

    heartbeat[2418]: 2011/04/19_11:31:25 info: No local resources

    [/usr/share/heartbeat/ResourceManager listkeys cluster02] to acquire.

    mach_down[2447]: 2011/04/19_11:31:26 info: Taking over resource group

    192.168.1.131

    ResourceManager[2473]: 2011/04/19_11:31:27 info: Acquiring resource group:

    cluster01 192.168.1.131 httpd

    IPaddr[2500]: 2011/04/19_11:31:28 INFO: Resource is stopped

    ResourceManager[2473]: 2011/04/19_11:31:28 info: Running

    /etc/ha.d/resource.d/IPaddr 192.168.1.131 start

    IPaddr[2576]: 2011/04/19_11:31:30 INFO: Using calculated nic for

    192.168.1.131: eth0

    IPaddr[2576]: 2011/04/19_11:31:30 INFO: Using calculated netmask for

    192.168.1.131: 255.255.255.0

    IPaddr[2576]: 2011/04/19_11:31:31 INFO: eval ifconfig eth0:0

    192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255

    IPaddr[2559]: 2011/04/19_11:31:32 INFO: Success

    ResourceManager[2473]: 2011/04/19_11:31:32 info: Running /etc/init.d/httpd

    start

    mach_down[2447]: 2011/04/19_11:31:33 info:

    /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired

    mach_down[2447]: 2011/04/19_11:31:33 info: mach_down takeover

    complete for node cluster01.

  • heartbeat[2354]: 2011/04/19_11:31:33 info: mach_down takeover complete.

    Y efectivamente, al entrar por navegador a http://192.168.1.131/ accedemos al cluster02.

    Esta es la configuracin ms bsica de un cluster HTTP con HeartBeat, a partir de aqu es

    cuestin de ir haciendo pruebas de failover y failback tirando nodos, levantandolos, y en

    definitiva, trastear con la configuracin, etc ya que HeartBeat permite una gran cantidad de

    configuraciones