Clusters UltraMonkey

Existen varios proyectos dedicados a facilitar la instalación de clusters HA (High Availability, alta disponibilidad), utilizados principalmente en granjas de servidores. Uno de ellos es UltraMonkey (ultramonkey.org), un proyecto que simplifica la instalación y configuración de un cluster HA integrando las herramientas LVS, HeartBeat y Ldirectord.

Recursos

Veamos un ejemplo de un cluster HA utilizando UltraMonkey:

Cluster LVS NAT

  1. instalar el kernel LVS: uno de los componentes de LVS es el parche ip_vs (IP Virtual Server), incluido en los kernel 2.6, por lo que ya no es necesario parchear el kernel manualmente.
  2. instalar UltraMonkey: cuando instalemos UltraMonkey (paquete ultramonkey) se instalarán por dependencias ipvsadm (las herramientas de usuario de LVS, paquete ipvsadm), HeartBeat (paquete heartbeat) y Ldirectord (paquete ldirectord). Para ello editaremos /etc/apt/sources.list e incluiremos el repositorio de UltraMonkey:
    deb http://www.ultramonkey.org/download/3/ sarge main
    deb-src http://www.ultramonkey.org/download/3 sarge main

    Actualizaremos la lista de paquetes e instalaremos:

    # apt-get update
    # apt-get install ultramonkey

    Si nos pregunta:
    Do you want to automatically load IPVS rules on boot? No
    Select a daemon method: none

  3. configurar el router: el router debe redirigir las peticiones <IP_pública>:80 a <IP_virtual>:80
  4. configurar LVS
    1. Para que los directores reenvíen las peticiones a los servidores reales activaremos el bit de forwarding. Para ello editaremos el archivo /etc/sysctl.conf y descomentaremos la línea:
      # Uncomment the next line to enable packet forwarding for IPv4
      net.ipv4.conf.default.forwarding=1

      Y ejecutaremos:

      # sysctl -p

      Esto es equivalente a:

      # echo 1 > /proc/sys/net/ipv4/ip_forward
    2. El script de inicio de LVS es /etc/init.d/ipvsadm y el archivo de configuración /etc/ipvsadm.rules.
  5. configurar HeartBeat: instalaremos HeartBeat en ambos directores. Uno de los directores está activo (master) y el otro está en hot stand-by (backup) y HeartBeat controla todo el asunto: los monitoriza y activa el director backup si el master falla. También se encarga de que el director master responda en la IP virtual (VIP) 192.168.6.240 y de lanzar/detener Ldirectord en ambos directores para monitorizar los servidores reales.
    1. /etc/heartbeat/ha.cf: crearemos este archivo idéntico en ambos directores:
      logfacility     local0
      bcast   eth0
      mcast eth0 225.0.0.1 694 1 0
      auto_failback off
      respawn hacluster /usr/lib/heartbeat/ipfail
      apiauth ipfail gid=haclient uid=hacluster
      node   loadb1
      node   loadb2
    2. /etc/heartbeat/haresources: crearemos este archivo idéntico en ambos directores:
      loadb1 IPaddr2::192.168.6.240/24/eth0/192.168.0.255
        ldirectord::ldirectord.cf  LVSSyncDaemonSwap::master

      En este archivo se especifica el nombre del director master (loadb1), la IP virtual (192.168.6.240) y los demonios a monitorizar (ldirectord y LVSSyncDaemonSwap).

    3. /etc/heartbeat/authkeys: crearemos este archivo idéntico en ambos directores:
      auth 3
      3 md5 mi_password

      Aquí definimos el mecanismo de autentificación (md5) y el password para que los dos demonios heartbeat de los servidores se autentifiquen uno contra el otro (mi_password). Sólo root debe tener permisos de lectura sobre /etc/heartbeat/authkeys por lo que haremos:

      # chmod 600 /etc/heartbeat/authkeys
  6. configurar Ldirectord: monitoriza los servidores reales. Si un servidor real falla Ldirectord lo excluye del grupo. Cuando vuelva a estar en línea será reinsertado. Si todos los servidores reales fallan insertará un servidor de fallos, que suele ser el propio director, hasta que algún servidor real vuelva a estar en línea.
    1. /etc/ha.d/ldirectord.cf: crearemos este archivo idéntico en ambos directores:
      checktimeout=10
      checkinterval=2
      autoreload=no
      logfile="local0"
      quiescent=yes
       
      virtual=192.168.6.240:80
              real=192.168.6.5:80 gate
              real=192.168.6.4:80 gate
              fallback=127.0.0.1:80 gate
              service=http
              request="ldirector.html"
              receive="Test Page"
              scheduler=rr
              protocol=tcp
              checktype=negotiate
    2. borrar el script de inicio de Ldirectord: Ldirectord estará bajo el control de HeartBeat (que se encargará de lanzarlo) por lo que borraremos el script de inicio de Ldirectord en ambos directores:
      # update-rc.d -f ldirectord remove
      # /etc/init.d/ldirectord stop
  7. configurar los servidores reales:
    1. aceptar peticiones en la IP virtual: configuraremos los dos nodos Apache (webserver1 y webserver2) para que acepten peticiones en la IP virtual 192.168.6.240. Para ello editaremos el archivo /etc/sysctl.conf:
      # Enable configuration of arp_ignore option
      net.ipv4.conf.all.arp_ignore = 1
       
      # When an arp request is received on eth0, only respond if that
      # address is configured on eth0. In particular, do not respond if
      # the address is configured on lo
      net.ipv4.conf.eth0.arp_ignore = 1
       
      # Ditto for eth1, add for all ARPing interfaces
      #net.ipv4.conf.eth1.arp_ignore = 1
       
       
      # Enable configuration of arp_announce option
      net.ipv4.conf.all.arp_announce = 2
       
      # When making an ARP request sent through eth0 Always use an address
      # that is configured on eth0 as the source address of the ARP request.
      # If this is not set, and packets are being sent out eth0 for an address
      # that is on lo, and an arp request is required, then the address on lo
      # will be used. As the source IP address of arp requests is entered into
      # the ARP cache on the destination, it has the effect of announcing this
      # address. This is not desirable in this case as adresses on lo on the
      # real-servers should be announced only by the linux-director.
      net.ipv4.conf.eth0.arp_announce = 2
       
      # Ditto for eth1, add for all ARPing interfaces
      #net.ipv4.conf.eth1.arp_announce = 2

      Y ejecutaremos en ambos nodos Apache:

      # sysctl -p

      Editaremos también /etc/network/interfaces y añadiremos las líneas:

      auto lo:0
      iface lo:0 inet static
        address 192.168.6.240
        netmask 255.255.255.255
        pre-up sysctl -p > /dev/null

      Y ejecutaremos:

      # ifup lo:0
    2. /var/www/ldirector.html: crearemos en ambos nodos Apache el archivo /var/www/ldirector.html al que Ldirectord accede repetidamente para comprobar si los nodos Apache siguen funcionando, cuyo contenido es:
      Test Page
    3. gateway de los servidores reales: el gateway de los servidores reales no es el director sino el router (no es una configuración NAT sino direct routing o tunnelling). Esto evita que el director se convierta en un cuello de botella conseguiendo mejor rendimiento.
  8. Arrancar y comprobar
    1. arrancar HeartBeat: en ambos directores:
      # /etc/init.d/heartbeat start
    2. comprobar la IP virtual: en el director master veremos la IP virtual 192.168.6.240:
      # ip addr sh eth0
      2: eth0: <BROADCAST,MULTICAST,UP>mtu 1500 qdisc pfifo_fast qlen 1000
         link/ether 00:16:3e:40:18:e5 brd ff:ff:ff:ff:ff:ff
         inet 192.168.6.2/24 brd 192.168.0.255 scope global eth0
         inet 192.168.6.240/24 brd 192.168.0.255 scope global secondary eth0

      En el director backup no veremos la IP virtual:

      # ip addr sh eth0
      2: eth0: <BROADCAST,MULTICAST,UP>mtu 1500 qdisc pfifo_fast qlen 1000
         link/ether 00:16:3e:50:e3:3a brd ff:ff:ff:ff:ff:ff
         inet 192.168.6.3/24 brd 192.168.0.255 scope global eth0
    3. comprobar Ldirectord: para comprobar que Ldirectord funciona correctamente en el director master:
      # ldirectord ldirectord.cf status
      ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1455

      En el director backup:

      # ldirectord ldirectord.cf status
      ldirectord is stopped for /etc/ha.d/ldirectord.cf
    4. comprobar LVS: para comprobar el estado de LVS en el director master:
      # ipvsadm -L -n
      IP Virtual Server version 1.2.1 (size=4096)
      Prot LocalAddress:Port Scheduler Flags
        ->RemoteAddress:Port           Forward Weight ActiveConn InActConn
      TCP  192.168.6.240:80 rr
        ->192.168.6.5:80             Route   0      0          0
        ->192.168.6.4:80             Route   0      0          0
        ->127.0.0.1:80               Local   1      0          0

      En el director backup:

      # ipvsadm -L -n
      IP Virtual Server version 1.2.1 (size=4096)
      Prot LocalAddress:Port Scheduler Flags
        ->RemoteAddress:Port           Forward Weight ActiveConn InActConn
    5. comprobar la sincronización LVS: los directores están sincronizados: si falla el master el backup dispone de la información de las conexiones, de manera que puedan mantenerse activas las conexiones establecidas. De esto se encarga el demonio de sincronización. Para comprobarlo en el director master:
      # /etc/ha.d/resource.d/LVSSyncDaemonSwap master status
      master running
      (ipvs_syncmaster pid: 1591)

      En el director backup:

      # /etc/ha.d/resource.d/LVSSyncDaemonSwap master status
      master stopped
    6. simular el fallo de Apache: ahora podemos acceder al sitio web alojado en dos nodos Apache en la dirección http://192.168.6.240. Probaremos a detener Apache alternativamente en webserver1 y webserver2 y comprobaremos que seguimos accediendo a la web y que las peticiones se dirigen al nodo que funciona.
      # /etc/init.d/apache stop
    7. simular el fallo del director master: simularemos el fallo de loadb1:
      # /etc/init.d/heartbeat stop

      Esperaremos unos segundos y entraremos en http://192.168.6.240. Si podemos acceder a la web significa que loadb2 es ahora el nuevo director master.

    8. simular que el director master vuelve a estar en línea: reiniciamos HeartBeat en loadb1:
      # /etc/init.d/heartbeat start

      Esperaremos unos segundos y comprobaremos que loadb1 vuelve a ser el master.

    9. logs: HeartBeat y Ldirectord envían logs a /var/log/messages
  9. instalar MON (paquete mon): programa que monitoriza el sistema.
  10. instalar un cliente NTP (paquete ntpdate): para asegurarnos de que todos los nodos tienen la misma hora del sistema (System Time) los conectaremos al mismo servidor NTP (que puede ser local). Su sintaxis es:
    # ntpdate <server>

    Para comprobar la hora del sistema:

    # date

Artículos en la categoría "Virtualización"

  1. Centralitas telefónicas IP PBX
  2. Clusters Beowulf/PVM
  3. Clusters Beowulf/MPI
  4. Clusters OpenMosix
  5. Clusters Kerrighed
  6. Clusters HA con LVS
  7. Clusters UltraMonkey
  8. Clusters LVS + Keepalived
  9. Emulador Qemu
  10. Máquina virtual VirtualBox
  11. Máquina virtual Xen
  12. API de Windows para Linux: WINE
  13. La jaula en Linux: chroot
  14. Cómo ejecutar aplicaciones Android en Linux
  15. RAID (discos redundantes)
  16. LVM (volúmenes lógicos)
  17. AoE (ATA over Ethernet)
  18. Mirror remoto con DRBD

8 Comments:

  1. Genial el tutorial, se agradece.

    Pregunta, que tal anda ultramonkey en comparacion con Keepalived ?

  2. Hola estoy implemtantando lo del manual.
    PERO tengo un problema con la direccon virtual que no me aparece con el comando #ip addr sh eth0. y otro problema porque los nodos directores estan inactivos y ninguno de los dos es maestro. si me pueden colaborar con estas dos configuraciones

  3. Muchas gracias por esta informacion, es genial. :)

  4. hola una pregunta
    como puedo escoger el algoritmo de balanceo para lvs
    y como podria ver el codigo de todos esos algortimos
    gracias x la ayuda

  5. estoy utilizando el LVS en red hat EL 5 y me esta dando problemas el ipvsadmin

  6. el problema esta aqui ..fijenese y diganme algo que estoy haciendo un trabajo muy importante y la verdad es que no se como arreglarlo …/etc/init.d/ipvsadm: line 62 : /etc/sysconfig/ipvsadm [FALLO]

    es decir ya instale el ipvsadm pero me da problemas en este arcihvo que no lo reconoce

  7. Me podrian decir que tipo de de servicios balancea a parte de HTTP, SMTP, es posible para gestores de bases de datos etc?
    Gracias.

  8. Soy relativamente nuevo en linux
    y para poder empezar el manual, me gustaria saber si los directores son 2 maquinas distintas o que???