361.3 - Clusters de Failover

Introducción

Un cluster de failover garantiza la continuidad del servicio trasladando automáticamente los recursos de un nodo fallido a otro nodo funcional. Pacemaker/Corosync es la solución estándar en Linux.

Configuración de Corosync

corosync.conf

# /etc/corosync/corosync.conf
totem {
    version: 2
    cluster_name: mi_cluster
    transport: knet              # knet (predeterminado), udp, udpu
    crypto_cipher: aes256        # Cifrado de comunicaciones
    crypto_hash: sha256
 
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 239.255.1.1   # Solo para udp
        mcastport: 5405
    }
}
 
logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
}
 
quorum {
    provider: corosync_votequorum
    expected_votes: 3
    two_node: 0                  # 1 para clusters de 2 nodos
    wait_for_all: 1
}
 
nodelist {
    node {
        ring0_addr: nodo1
        nodeid: 1
    }
    node {
        ring0_addr: nodo2
        nodeid: 2
    }
    node {
        ring0_addr: nodo3
        nodeid: 3
    }
}

Para el examen: Los parámetros clave de totem son transport, crypto_cipher y crypto_hash. En clusters de 2 nodos, two_node: 1 debe estar habilitado.

Inicialización del Cluster con pcs

# Autenticar nodos (ejecutar en cada nodo primero)
pcs host auth nodo1 nodo2 nodo3 -u hacluster -p password
 
# Configurar cluster
pcs cluster setup mi_cluster nodo1 nodo2 nodo3
 
# Iniciar cluster en todos los nodos
pcs cluster start --all
 
# Habilitar inicio automático
pcs cluster enable --all
 
# Ver estado
pcs cluster status
pcs status

Tipos de Recursos

Primitive (Recurso Primitivo)

Un recurso individual que se ejecuta en un solo nodo:

# Crear IP virtual
pcs resource create VIP ocf:heartbeat:IPaddr2 \
    ip=10.0.0.100 cidr_netmask=24 \
    op monitor interval=30s
 
# Crear recurso de servicio web
pcs resource create WebServer ocf:heartbeat:apache \
    configfile=/etc/httpd/conf/httpd.conf \
    statusurl="http://localhost/server-status" \
    op monitor interval=60s timeout=30s \
    op start timeout=60s \
    op stop timeout=60s

Group (Grupo)

Varios recursos que se ejecutan juntos en el mismo nodo, en orden:

# Crear grupo (los recursos se inician en orden y se detienen en orden inverso)
pcs resource group add WebGroup VIP WebFS WebServer
 
# El grupo se migra como unidad: si un recurso falla, todo el grupo se mueve

Clone

Recurso que se ejecuta en múltiples nodos simultáneamente:

# Crear un clone (se ejecuta en todos los nodos)
pcs resource create dlm ocf:pacemaker:controld \
    op monitor interval=30s
 
pcs resource clone dlm clone-max=3 clone-node-max=1
 
# Alternativa con pcs
pcs resource create dlm ocf:pacemaker:controld \
    op monitor interval=30s clone

Promotable (Multi-State / Master-Slave)

Recurso clone que puede estar en modo Master (promoted) o Slave (unpromoted):

# Recurso promotable (ej: DRBD)
pcs resource create drbd_data ocf:linbit:drbd \
    drbd_resource=data \
    op monitor interval=20s role=Unpromoted \
    op monitor interval=10s role=Promoted \
    promotable promoted-max=1 promoted-node-max=1
 
# Con pcs antiguo (crm):
# ms ms_drbd_data drbd_data master-max="1" master-node-max="1"

Para el examen: Conoce los cuatro tipos: primitive, group, clone y promotable (antes master/slave). Un promotable es un clone especial donde una instancia puede ser “promovida”.

Restricciones (Constraints)

Location Constraints (Ubicación)

Controlan dónde puede ejecutarse un recurso:

# Preferir un nodo
pcs constraint location VIP prefers nodo1=100
 
# Evitar un nodo
pcs constraint location VIP avoids nodo2=INFINITY
 
# Regla basada en atributo
pcs constraint location VIP rule score=100 \
    '#uname' eq nodo1
 
# Mover recurso temporalmente (crea location constraint)
pcs resource move VIP nodo2
# IMPORTANTE: eliminar después
pcs resource clear VIP

Colocation Constraints (Colocación)

Controlan qué recursos deben ejecutarse juntos (o separados):

# WebServer debe estar en el mismo nodo que VIP
pcs constraint colocation add WebServer with VIP INFINITY
 
# Recurso A NO debe estar con recurso B
pcs constraint colocation add RecursoA with RecursoB -INFINITY

Order Constraints (Orden)

Controlan el orden de inicio/parada de recursos:

# VIP debe iniciarse antes que WebServer
pcs constraint order VIP then WebServer
 
# Con tipo de acción específico
pcs constraint order start VIP then start WebServer
 
# Orden para promotable
pcs constraint order promote drbd_data-clone then start WebFS
 
# Orden opcional (no obligatoria)
pcs constraint order VIP then WebServer kind=Optional

Para el examen: Las tres restricciones son location, colocation y order. INFINITY significa obligatorio, valores menores son preferencias.

Resource Agents

Clases de Agentes

Clase	Formato	Ejemplo
OCF	`ocf:proveedor:agente`	`ocf:heartbeat:IPaddr2`
systemd	`systemd:servicio`	`systemd:httpd`
LSB	`lsb:script`	`lsb:httpd`
service	`service:nombre`	`service:httpd`
stonith	`stonith:agente`	`stonith:fence_ipmilan`

Operaciones de Recursos

# Definir operaciones en la creación
pcs resource create WebServer ocf:heartbeat:apache \
    op start timeout=60s \
    op stop timeout=60s \
    op monitor interval=30s timeout=20s
 
# Listar agentes disponibles
pcs resource agents
pcs resource agents ocf:heartbeat
 
# Describir un agente
pcs resource describe ocf:heartbeat:IPaddr2

Agentes OCF Importantes

Agente	Función
`ocf:heartbeat:IPaddr2`	Gestión de IP virtual
`ocf:heartbeat:apache`	Servidor web Apache
`ocf:heartbeat:Filesystem`	Montaje de sistema de archivos
`ocf:heartbeat:mysql`	Base de datos MySQL
`ocf:linbit:drbd`	Replicación DRBD
`ocf:pacemaker:controld`	DLM (Distributed Lock Manager)
`ocf:heartbeat:Delay`	Introduce retardo (testing)

Dispositivos STONITH

Configuración de STONITH

# Habilitar STONITH (obligatorio en producción)
pcs property set stonith-enabled=true
 
# IPMI LAN
pcs stonith create ipmi_fence fence_ipmilan \
    ipaddr=192.168.1.200 \
    login=admin passwd=password \
    lanplus=1 pcmk_host_list=nodo1
 
# Máquinas virtuales (libvirt)
pcs stonith create vm_fence fence_xvm \
    key_file=/etc/cluster/fence_xvm.key \
    pcmk_host_map="nodo1:vm-nodo1;nodo2:vm-nodo2"
 
# SBD (STONITH Block Device) - para entornos sin IPMI
pcs stonith create sbd_fence fence_sbd \
    devices=/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB12345
 
# Verificar configuración
pcs stonith status
pcs stonith show

SBD (STONITH Block Device)

# Crear dispositivo SBD en disco compartido
sbd -d /dev/sda create
 
# Listar información SBD
sbd -d /dev/sda list
 
# Configurar watchdog
sbd -d /dev/sda watch
 
# Archivo de configuración
# /etc/sysconfig/sbd
SBD_DEVICE="/dev/disk/by-id/scsi-..."
SBD_WATCHDOG_DEV="/dev/watchdog"
SBD_WATCHDOG_TIMEOUT=5

Para el examen: Los dispositivos STONITH más comunes son fence_ipmilan (servidores físicos con IPMI), fence_xvm (VMs libvirt) y sbd (disco compartido). STONITH debe estar siempre habilitado en producción.

Configuración de Quorum

# Ver estado del quorum
pcs quorum status
 
# Configurar quorum device (QDevice)
pcs quorum device add model net \
    host=qdevice-host algorithm=ffsplit
 
# Políticas de no-quorum
pcs property set no-quorum-policy=stop    # Predeterminado
pcs property set no-quorum-policy=freeze
pcs property set no-quorum-policy=ignore  # Solo testing

Administración con pcs

Comandos de Estado

pcs status                    # Estado completo
pcs status nodes              # Estado de nodos
pcs status resources          # Estado de recursos
pcs cluster status            # Estado del cluster

Gestión de Recursos

pcs resource show             # Listar recursos
pcs resource show VIP         # Detalle de un recurso
pcs resource enable VIP       # Habilitar recurso
pcs resource disable VIP      # Deshabilitar recurso
pcs resource restart VIP      # Reiniciar recurso
pcs resource cleanup VIP      # Limpiar errores
pcs resource move VIP nodo2   # Mover a nodo específico
pcs resource ban VIP nodo1    # Prohibir en un nodo
pcs resource clear VIP        # Eliminar restricciones temporales
pcs resource delete VIP       # Eliminar recurso
pcs resource update VIP ip=10.0.0.200  # Modificar parámetro

Gestión de Propiedades

pcs property set stonith-enabled=true
pcs property set no-quorum-policy=stop
pcs property set default-resource-stickiness=100
pcs property set migration-threshold=3

Administración con cibadmin y crm

cibadmin

# Exportar CIB completa
cibadmin --query > cib_backup.xml
 
# Importar CIB
cibadmin --replace --xml-file cib_backup.xml
 
# Borrar CIB (peligroso)
cibadmin --erase --force

crm (shell alternativo)

crm status
crm configure show
crm resource start VIP
crm resource stop VIP
crm resource move VIP nodo2

Para el examen: pcs resource move crea una restricción temporal de location. Siempre ejecuta pcs resource clear después para eliminarla, o el recurso nunca volverá al nodo original.

Manejo de Split-Brain

Estrategias de Prevención

Múltiples rutas de comunicación (anillos redundantes en Corosync)
Fencing obligatorio (STONITH habilitado)
Quorum correctamente configurado
Watchdog timers como respaldo de fencing

Propiedades Relacionadas

# Stickiness: evita movimientos innecesarios
pcs property set default-resource-stickiness=100
 
# Threshold de migración: fallos antes de mover
pcs property set migration-threshold=3
 
# Tiempo de fallo: ventana de conteo de fallos
pcs resource meta VIP failure-timeout=60s

Ejemplo Completo: Cluster Apache HA

# 1. Configurar cluster
pcs cluster setup mi_cluster nodo1 nodo2
pcs cluster start --all
 
# 2. Configurar STONITH
pcs stonith create fence_nodo1 fence_ipmilan \
    ipaddr=10.0.0.201 login=admin passwd=secret lanplus=1 \
    pcmk_host_list=nodo1
pcs stonith create fence_nodo2 fence_ipmilan \
    ipaddr=10.0.0.202 login=admin passwd=secret lanplus=1 \
    pcmk_host_list=nodo2
 
# 3. Crear recursos
pcs resource create VIP ocf:heartbeat:IPaddr2 \
    ip=10.0.0.100 cidr_netmask=24 op monitor interval=30s
pcs resource create WebServer ocf:heartbeat:apache \
    configfile=/etc/httpd/conf/httpd.conf \
    op monitor interval=60s
 
# 4. Agrupar recursos
pcs resource group add WebGroup VIP WebServer
 
# 5. Configurar preferencia
pcs constraint location WebGroup prefers nodo1=50
pcs property set default-resource-stickiness=100
 
# 6. Verificar
pcs status

Trampas del examen

Errores comunes y distinciones criticas que LPI suele evaluar en este subtema:

pcs resource move crea una restriccion permanente — despues de pcs resource move VIP nodo2, se crea un constraint de location con score -INFINITY contra el nodo original. Si no ejecutas pcs resource clear VIP despues, el recurso NUNCA volvera al nodo original. Es la trampa mas clasica del examen
Promotable no es lo mismo que clone — un clone ejecuta la misma instancia en todos los nodos; un promotable (antes master/slave) tiene una instancia Promoted y las demas Unpromoted. DRBD usa promotable: solo el Promoted monta el filesystem
INFINITY vs valores numericos en constraints — INFINITY en colocation/location significa obligatorio (el recurso NO puede funcionar sin cumplirlo). Un valor numerico (ej: 100) es una preferencia que puede ignorarse. Confundirlos causa que recursos no arranquen
Orden de restricciones: location, colocation, order — location controla DONDE, colocation controla CON QUIEN, order controla CUANDO. El examen pregunta cual constraint usar para un escenario: si necesitas que VIP y Apache esten juntos es colocation, no location
stonith-enabled=false rompe la integridad — desactivar STONITH permite que el cluster funcione sin fencing, pero en split-brain no se puede garantizar la integridad de datos. El examen puede presentar un cluster que funciona pero pierde datos: la causa es STONITH deshabilitado
no-quorum-policy=ignore es solo para testing — con ignore, el cluster sigue funcionando sin quorum, lo que permite split-brain. En produccion debe ser stop (predeterminado) o freeze. El examen puede preguntar la politica correcta para produccion
resource cleanup vs resource restart — cleanup limpia el contador de fallos y re-evalua el estado; restart detiene y reinicia el recurso. Si un recurso esta en estado fallido y ha superado el migration-threshold, necesitas cleanup antes de que pueda reiniciarse en ese nodo
SBD requiere watchdog Y disco compartido — SBD (STONITH Block Device) no funciona solo con disco compartido; necesita un watchdog timer configurado. Sin watchdog, un nodo que debe hacer self-fencing no puede garantizar su propia muerte
Los grupos inician en orden y paran en orden inverso — si el grupo es VIP, WebFS, WebServer, inician en ese orden pero se detienen WebServer, WebFS, VIP. Si un recurso del grupo falla, todo el grupo se mueve al otro nodo
cibadmin —erase destruye toda la configuracion — cibadmin --erase --force borra la CIB completa. cibadmin --replace reemplaza con un XML. El examen puede preguntar como restaurar la configuracion: cibadmin --replace --xml-file backup.xml

LPIC & Hacking Vault

Navegacion

Notas Recientes

101.1 - Comandos Clave

101.1 - Configuracion de Hardware

361.3 - Clusters de Failover

361.3 - Clusters de Failover

Introducción

Configuración de Corosync

corosync.conf

Inicialización del Cluster con pcs

Tipos de Recursos

Primitive (Recurso Primitivo)

Group (Grupo)

Clone

Promotable (Multi-State / Master-Slave)

Restricciones (Constraints)

Location Constraints (Ubicación)

Colocation Constraints (Colocación)

Order Constraints (Orden)

Resource Agents

Clases de Agentes

Operaciones de Recursos

Agentes OCF Importantes

Dispositivos STONITH

Configuración de STONITH

SBD (STONITH Block Device)

Configuración de Quorum

Administración con pcs

Comandos de Estado

Gestión de Recursos

Gestión de Propiedades

Administración con cibadmin y crm

cibadmin

crm (shell alternativo)

Manejo de Split-Brain

Estrategias de Prevención

Propiedades Relacionadas

Ejemplo Completo: Cluster Apache HA

Trampas del examen

Graph View