Gestión de cortes de energía y aislamiento de red en un clúster HA

¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster?

Una única red

Cuando hay un aislamiento de red, el comportamiento predeterminado es:

• a medida que se pierden heartbeats de cada nodo, cada nodo pasa a ALONE y ejecuta la aplicación con su dirección IP virtual (doble ejecución de la aplicación que modifica sus datos locales),
• Cuando se repara el aislamiento, un nodo ALONE se ve obligado a detenerse y a resincronizar sus datos desde el otro nodo
• Al final, el clúster es PRIM-SECOND (o SECOND-PRIM, según la detección de direcciones IP virtuales duplicadas realizada por Windows).

Dos redes con una red de replicación dedicada

Cuando hay un aislamiento de red, el comportamiento con una red de replicación dedicada es el siguiente:

• se implementa una red de replicación dedicada en una red privada,
• se pierden heartbeats en la red de producción (red aislada),
• Heartbeats en la red de replicación funcionan (no en una red aislada),
• El clúster permanece en el estado PRIM/SECOND.

Una única red y un checker split-brain

Cuando hay un aislamiento de red, el comportamiento con un checker split-brain es:

• se ha configurado un checker split-brain con la dirección IP de un testigo (normalmente un enrutador),
• el checker split-brain funciona cuando un servidor pasa de PRIM a ALONE o de SECOND a ALONE,
• En caso de aislamiento de la red, antes de pasar a ALONE, ambos nodos prueban la dirección IP
• el nodo que puede acceder a la dirección IP pasa a ALONE, el otro pasa a WAIT,
• Cuando se repara el aislamiento, el nodo WAIT resincroniza sus datos y se convierte en SECOND.

Nota: Si el testigo está inactivo o desconectado, ambos nodos pasan a WAIT y la aplicación deja de ejecutarse. Por eso debe elegir un testigo robusto como un enrutador.

¿Cuáles son los diferentes escenarios en caso de un corte de energía en un clúster?

Apagón del nodo principal

Cuando un corte de energía detiene solo el nodo principal:

• Hay una conmutación por error automática en el nodo secundario, que se convierte en ALONE y reinicia la aplicación,
• Cuando se reinicia el nodo 1, se convierte en SEDOND después de la resincronización de los datos replicados.
• Los roles de principal y secundario pueden ser intercambiados por un administrador si es necesario.

Apagón del nodo secundario

Cuando un corte de energía detiene solo el nodo secundario:

• No hay conmutación por error, el nodo principal se convierte en SOLO y la aplicación continúa su ejecución en el nodo 1.
• Cuando se reinicia el nodo 2, se convierte en SEDOND después de la resincronización de los datos replicados.

Apagón general - caso 1

Cuando un corte de energía detiene ambos nodos, el comportamiento predeterminado es:

• ambos nodos van a STOP,
• Cuando se reinicia el nodo 1, no entra en estado SOLO y no reinicia la aplicación porque no sabe si tiene los datos actualizados. Por lo tanto, pasa al estado ESPERA esperando el reinicio del otro nodo.
• Cuando se reinicia el nodo 2, ambos nodos vuelven a sus estados PRIM/SEGUNDO anteriores.

Apagón general - caso 2

Cuando un corte de energía detiene ambos nodos, el comportamiento con syncdelta es:

• syncdelta se establece, por ejemplo, en 10 minutos en la configuración, lo que significa que se acepta el inicio de un nodo incluso si sus datos están 10 minutos atrasados con respecto a la última sincronización.
• Cuando se reinicia el nodo 1, pasa a ALONE y reinicia la aplicación suponiendo que el reinicio se realiza dentro de los 10 minutos posteriores al fallo de alimentación,
• cuando se reinicia el nodo 2, se convierte en SEGUNDO después de la resincronización de los datos replicados,
• Nota: si el nodo 2 se reinicia primero, entonces se convierte en SOLO y el nodo 1 se convertirá en SEGUNDO al iniciarse.

🔍 Explora SafeKit

Encuentre información sobre las características, arquitecturas, vídeos, documentación y la prueba gratuita de SafeKit.