Búsqueda de sitios web

Configurar alta disponibilidad con Corosync y Pacemaker

Todas las técnicas y métodos utilizados para mejorar la disponibilidad de un sistema o un servicio y aumentar la tolerancia a fallas se denominan Alta Disponibilidad, como ejemplo de falla podemos mencionar: redundancia de hardware, clustering, replicación de datos en caliente físicamente (RAID 1 y RAID 5) o en software (Snapshots, DRBD), o escenarios de crisis (modo degradado, plan de emergencia). En una gran empresa, puede derivar en un puesto de responsabilidad a tiempo completo. Verá una imagen para implementar una faceta de este problema en este artículo: un clúster activo/pasivo que garantiza la disponibilidad de un servicio de aplicación.

Respecto a GNU/Linux, en este artículo se probaron dos software que podrían gestionar una infraestructura de cluster:

  • Heartbeat tiene sus pruebas pero es limitado: no hay cluster de más de 2 nodos, no hay gestión de recursos y reglas para pasar de un nodo a otro.
  • Corosync y Pacemaker: Es la elección de la distribución de Red Hat y que se detallará más adelante en este artículo.

Habíamos montado un modelo representativo compuesto por dos máquinas virtuales Debian Wheezy con 4 interfaces de red que ejecutan un servicio Apache al que se accede mediante una dirección IP administrada por el cluster.

La siguiente imagen representa el diagrama de red:

Las interfaces eth0 y eth1 son parte de una agregación de enlaces lógicos y ayudan al clúster a verificar el estado de los otros nodos. Constituyen una red privada con los demás nodos de la red 10.20.13.0/255.255.255.252. Las interfaces eth2 y eth3 son parte de otra agregación lógica y brindan servicio fuera de la red 192.168.1.0/24.

La agregación lógica (también llamada vinculación) proporciona una redundancia adicional. Si el adaptador de red eth0 se agota, el tráfico seguirá pasando por eth1. Se puede configurar en modo activo/pasivo o en modo de equilibrio de carga.

Aquí está la configuración de las interfaces en la máquina vm-node1 en “/etc/network/interfaces/”:

auto bond0
iface bond0 inet static
  address 10.20.13.1
  netmask 255.255.255.252
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth0 eth1
auto bond1
iface bond1 inet static
  address 192.168.1.61
  netmask 255.255.255.0
  gateway 192.168.1.1
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth2 eth3

Y la configuración del bonding en “/etc/modprobe.d/bonding”:

alias bond0 bonding 
alias bond1 bonding

La configuración de red de la máquina vm-node2 es simétrica con bond0 en 10.20.13.2 y bond1 en 192.168.1.62. Cuando la configuración de la red esté lista, podemos manejar el clúster. Primero necesitas instalar Corosync y Pacemaker en Debian, harás lo siguiente:

apt-get install corosyncpacemaker

Luego configure Corosync. Gestiona la infraestructura del clúster, es decir, el estado de los nodos y su funcionamiento en grupo. Para ello, debemos generar una clave de autenticación que será compartida por todos los nodos del clúster. La utilidad corosync-keygen para generar esta clave a partir de pulsaciones de teclas pseudoaleatorias que luego deben protegerse y copiarse a otros nodos.

generation of the key from vm-node1
corosync-keygen
mvauthkey/etc/corosync/authkey
chownroot:root/etc/corosync/authkey
chmod400/etc/corosync/authkey
 
copy of the key to vm-node2
scp/etc/corosync/[email :/etc/corosync/authkey

Corosync propone el concepto de anillos de conexión para permitir la comunicación entre nodos. Como parte del modelo, definimos dos anillos: ring0, el anillo de comunicación predeterminado que utiliza la red privada y ring1, un anillo de respaldo que pasa a través de los conmutadores con el resto del tráfico. Corosync le permite definir los anillos en términos de IP/máscara de red en lugar de definir direcciones IP. Esto es importante porque se puede implementar el mismo archivo de configuración en todos los nodos sin cambiar nada.

totem {   
    version:2    
    
    #How long before declaring a token lost(ms)   
    token:3000    

    #How many token retransmits before forming a new configuration   
    token_retransmits_before_loss_const:10    

    #How long to wait for joining messages in the membership protocol(ms)   
    join:60    

    #How long to wait for consensus to be achieved before starting a new round of membership configuration(ms)    consensus:3600    

    #Turn off the virtual synchrony filter   
    vsftype:none    

    #Number of messages that may be sent by one processor on receipt of the token   
    max_messages:20    

    #Limit generated nodeids to 31-bits(positive signed integers)   
    clear_node_high_bit:yes    

    #Disable encryption   
    secauth:off    

    #How many threads to use for encryption/decryption   
    threads:0    

    #Optionally assign a fixed nodeid(integer)   
    #nodeid:1234    

    #This specifies the mode of redundant ring,which may be none,active,or passive.   
    rrp_mode:passive    

    interface {       
        ringnumber:0       
        bindnetaddr:10.20.13.0       
        mcastaddr:226.94.1.1       
        mcastport:5405   
    }   

    interface {       
        ringnumber:1       
        bindnetaddr:192.168.1.0       
        mcastaddr:226.94.1.1       
        mcastport:5407   
     }
} 

amf {   
     mode:disabled
} 

service {   
     #Load the Pacemaker Cluster Resource Manager   
     ver:       0   
     name:     pacemaker
} 

aisexec {   
    user:  root   
    group: root
} 

logging {   
    fileline:off   
    to_stderr:yes   
    to_logfile:no   
    to_syslog:yes   
    syslog_facility:daemon   
    debug:off   
    timestamp:on   
    logger_subsys {       
          subsys:AMF       
          debug:off       
          tags:enter|leave|trace1|trace2|trace3|trace4|trace6   
    }
}

En este punto, la infraestructura del clúster está instalada pero no gestiona ningún recurso. Es el papel del marcapasos.

Tiene las siguientes limitaciones operativas:

  1. recursos (servicio Apache y la dirección IP del clúster) que se ejecutan en el servidor vm-node1 en el caso normal.
  2. El servicio Apache y la dirección IP del clúster deben ejecutarse en el mismo servidor si nuestro servicio es inaccesible.
  3. Si el servicio Apache falla en el servidor primario, cambia al servidor secundario.
  4. si el servidor primario está conectado a través de la puerta de enlace de Internet, cambia al servidor secundario.

Pacemaker proporciona cierta utilidad en modo texto para interactuar.

  • CRM para gestionar la configuración de todos los aspectos.
  • crm_mon muestra el estado del clúster.

Primero definimos la configuración global. Apagado STONITH (Dispara al otro nodo en la cabeza) y el quórum. STONITH es la capacidad de eliminar el otro nodo si ya no se encuentra con el clúster de infraestructura. Y el quórum no funciona en un grupo dentro de los 3 nudos.

property stonith-enabled=false
property no-quorum-policy=ignore

Ahora podemos definir nuestro primer recurso: la dirección IP del clúster adjunta al nodo activo.

primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.1.60 cidr_netmask=24nic="bond1"op monitor interval="10s"

Luego el recurso de Apache, el servicio crítico que queremos brindar en este modelo:

primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf"statusurl="http://localhost/server-status"op start timeout="60s"op stop timeout="60s"op monitor timeout="20s"

El inicio y la detención de Apache ahora los gestiona el clúster. Entonces, ahora tenemos que eliminar el inicio automático del servicio:

update-rc.d-fremoveapache2

Notarás que esto va más allá de la definición de recurso de Apache. El atributo STATUSURL de Pacemaker permite utilizar la página de estado de Apache para determinar un balancín. Así que no olvides configurar esta URL en Apache:

<Location/server-status>    
    SetHandler server-status    
    Order deny,allow    
    Deny from all    
    Allow from 127.0.0.1
</Location>

A medida que construimos el paso de configuración, crm_mon volvió, tal vez haya algunos errores en ciertos recursos porque no estaba operativo. Existe un contador de fallos que nos avisa en caso de aviso. Podemos restablecer este temporizador para el recurso http usando el siguiente comando:

crm resource clean up httpd

En esta etapa tenemos una dirección de clúster y un recurso HTTP, pero no necesariamente en el mismo nodo. El recurso vip cambiará si el nodo se baja. El recurso httpd cambiará si el nodo se cae o el servicio apache aumenta (monitoreo por URL/estado del servidor).

Vayamos más allá y fuercemos que ambos recursos se ejecuten en el mismo nodo:

colocation httpd-with-vip inf : httpd vip

Y nos gustaría tener esto también en el caso normal, los recursos se ejecutan en vm-node1, nuestro nodo principal:

location preferred-node vip 100 : vm-node1

Finalmente, agregamos una condición de escala. Si el nodo no llega a la puerta de enlace a través de Internet, queremos mover recursos al otro nodo. Para ello definimos un recurso del tipo ping que se ejecuta en todos los nodos (a través del concepto de recurso clonado). Luego se agrega una regla de vacaciones para cambiar si el nodo activo no ve el puente.

primitive ping-gateway ocf:pacemaker:ping params host_list="192.168.1.1"multiplier="1000"op monitor interval="10s"
clone cloned-ping-gateway ping-gateway
location vip-needs-gateway vip rule-inf:not_defined pingd or pingd lte 0

Este es nuestro modelo operativo. y esperamos poder ayudarte a hacerlo.