Habilitar el servicio HA (alta disponibilidad) en un clúster de virtualización Proxmox VE. Asignar reglas de HA a máquinas virtuales y realizar pruebas de parada de algún nodo para verificar que la migración de máquinas automática funciona correctamente.
- Crear grupos de HA en clúster Proxmox VE.
- Habilitar HA en máquinas virtuales del clúster Proxmox VE.
- Probar el HA deteniendo un nodo de forma controlada.
- Probar el HA apagando «de botón» un nodo para simular un error.
Crear grupos de HA en clúster Proxmox VE
Una vez creado el clúster Proxmox VE (con al menos tres nodos) y creado el almacenamiento Ceph compartido (o de cualquier otro tipo), para que las máquinas virtuales se migren de forma automática de un nodo caído a otro disponible, hay que activar el HA (alta disponibilidad).
En primer lugar crearemos grupos de nodos en el HA. Si tenemos muchos nodos y queremos que algunas máquinas se migren solo a los indicados y no a cualquiera de ellos, deberemos crear grupos de nodos. En este caso, puesto que tenemos tres nodos en el clúster y nos es indiferente en qué nodo se migra una máquina cuando se activa el HA, crearemos un grupo con todos los nodos. Para ello, desde la consola de gestión de Proxmox VE, seleccionaremos el Datacenter [1], y pulsaremos en «HA» y en «Groups» [2]. Pulsaremos en «Create» [3]:
Introduciremos un identificador del grupo, marcaremos alguna de las siguientes opciones (si lo consideremos neceario):
- restricted: las máquinas vinculadas a grupos restringidos solo podrán ejecutarse en los nodos definidos en el grupo. El recurso se colocará en el estado detenido si no hay ningún miembro del nodo del grupo en línea. Los recursos de grupos sin restricciones pueden ejecutarse en cualquier nodo del clúster si todos los miembros del grupo están sin conexión, pero volverán a migrar tan pronto como un miembro del grupo se conecte. Se puede implementar un comportamiento de nodo preferido utilizando un grupo sin restricciones con un solo miembro.
- nofailback: el CRM intentará ejecutar las máquinas virtuales al nodo con la prioridad más alta. Si un nodo con mayor prioridad se conecta, el CRM migrará nuevamente las máquinas virtuales a ese nodo. Si macamos la opción «nofailback», se evitará ese comportamiento.
Seleccionaremos los nodos que compondrán el grupo, en este caso, todos los nodos. Y, si lo estimamos oportuno, definiremos cuáles son los nodos con mayor prioridad (estableciendo un número mayor en «Priority»):
Si queremos asignar máquinas a un solo nodo o a dos, podremos crear tantos grupos como necesitemos, incluso grupos de un solo nodo.
Habilitar HA en máquinas virtuales del clúster Proxmox VE
Tras crear los grupos, iremos añadiendo cada máquina virtual al servicio HA y a un grupo. Para ello, pulsaremos en «HA» [1] y pulsaremos en «Add» [2] de «Resources»:
Elegiremos la máquina virtual a la que le habilitaremos el HA:
Elegiremos el grupo de HA al que pertenerá la máquina virtual y el resto de opciones de HA:
- max_relocate: número máximo de intentos de reubicación de la máquina virtual cuando se produce un error en el inicio.
- max_restart: número máximo de intentos para reiniciar la máquina virtual en un nodo después de que se haya producido un error en su inicio.
- Request state:
- started: el CRM intenta iniciar la máquina virtual. El estado del servicio pasa a ser started tras un inicio correcto. En caso de errores de nodo o cuando falla el inicio, intenta recuperar el recurso. Si todo falla, el servicio queda en estado de error.
- stopped: el CRM intenta mantener el recurso en estado stopped, pero intentará reubicar los recursos en caso de errores de nodo.
- disabled: el CRM intenta poner el recurso en estado stopped, pero no lo reubicará en caso de errores de nodo. El objetivo principal de este estado es la recuperación de errores, ya que es la única manera de mover un recurso fuera del estado de error.
- ignored: el recurso se elimina del estado del administrador y, por lo tanto, el CRM y el LRM no modificarán el recurso. Todas las llamadas a la API pve que afecten a este recurso se ejecutarán, omitiendo directamente la pila de alta disponibilidad. Se lanzarán comandos de CRM mientras la fuente esté en este estado. El recurso no se reubicará en errores de nodo.
Pulsaremos en «Add» para habilitar el HA en la máquina virtual/contenedor seleccionado:
Repetiremos el proceso para todas las máquinas virtuales o contenedores a las queramos aplicarles el HA (alta disponibilidad):
En cada máquina virtual o contenedor, en «Summary», podremos comprobar el HA habilitado y su política asignada:
Probar el HA deteniendo un nodo de forma controlada
En el nodo 3 del clúster Proxmox VE tenemos tres máquinas virtuales: 100, 102 y 103, sólo la máquina 100 tiene habilitado el HA.
Apagamos de forma controlada el nodo 3 para ver el comportamiento. Para ello, seleccionamos el nodo y pulsamos en «Shutdown»:
Se activará el HA de forma automática, que apagará la máquina 100 (la que tenía el HA habilitado) y la migrará a otro nodo disponible. Se detendrá unos segundos pero se iniciará automáticamente en otro nodo:
Quedando accesible:
En cambio, las máquinas 102 y 107, que no tienen habilitado el HA, quedan inaccesibles hasta que se recupere el nodo.
Por su parte, el servicio de almacenamiento compartido Ceph queda en estado de warning, con degradación de un nodo, pero disponible y con todos los datos accesibles (dado que están replicados en los discos de los otros nodos). El servicio Ceph mostrará avisos como los siguientes:
1/3 mons down, quorum proxmox, proxmox2
2 osds down
1 host (2 osds) down
Degraded data redundancy: … objects degraded…
En esta situación, dado que tenemos almacenamiento compartido en Ceph, deberemos recuperar lo antes posible en nodo porque, además de CPU y RAM, también aportaba almacenamiento con sus OSD (discos) compartidos en hiperconvergencia Ceph para uso del clúster. Si el almacenamiento estuviera en una SAN u otra unidad de almacenamiento compartido externa a los servidores, la parada de un nodo no influiría en la disponibilidad del almacenamiento.
Probar el HA apagando «de botón» un nodo para simular un error
El nodo que vamos a apagar «de botón», para simular un posible error de disco, un fallo de red, de placa base o de alimentación eléctrica (como hemos simulado en este caso), contiene las máquinas 100, 102 y 103, todas ellas con HA activado y todas ellas iniciadas:
Apagamos el equipo «de botón» para simular un error real del nodo proxmox3, en unos pocos segundos pasará a estado error y, desde el Datacenter del clúster Proxmox VE, podremos comprobar que el nodo con error ha pasado a estado «old timestamp – dead?»
Trascurridos unos segundos, puesto que el nodo no se recupera, las máquinas virtuales que tengan habilitado el HA del nodo erróneo (100, 102 y 103), se migrarán de forma automática a otros nodos del clúster y se iniciarán. El comportamiento es similar al de una parada controlada del nodo:
