Ejemplo: Error de nodo y sitio
En este tema se describe cómo GLVM para PowerHA® SystemMirror® Enterprise Edition gestiona los fallos y qué ocurre en el clúster para garantizar que los datos reflejados geográficamente sigan estando disponibles para la aplicación.
La figura siguiente con dos nodos en cada sitio se utiliza en estos escenarios. En esta configuración, el nodo 2 es el nodo de inicio o el propietario primario del grupo de recursos. Tiene el cliente RPV configurado y reside en el sitio local. El nodo 1 es el segundo nodo de prioridad para el grupo de recursos:
Anomalía de nodo en el sitio local
Si el nodo 2 falla, el grupo de recursos con la aplicación pasa al nodo 1.
A alto nivel, en el Nodo 1, GLVM para PowerHA SystemMirror Enterprise Edition detecta que el Nodo 2, propietario primario del grupo de recursos, ha fallado y mueve el grupo de recursos al Nodo 1. También activa el grupo de volúmenes reflejados geográficamente en Node1 y asegura que el cliente RPV en el Nodo 1 está disponible para la comunicación con el servidor RPV en el Nodo 3.
La aplicación se mantiene altamente disponible y los datos se siguen duplicando geográficamente. La aplicación continúa enviando solicitudes de E/S al RPV, y la función GLVM garantiza que el cliente RPV y el servidor RPV sigan comunicándose.
Si el Nodo 2 se reincorpora al clúster, basándose en la política del grupo de recursos PowerHA SystemMirror realiza el fallback del grupo de recursos. El grupo de recursos vuelve al nodo 2 (en función de la política de reserva del grupo de recursos) y el cliente RPV pasa a estar disponible en el nodo 2. Esto permite restablecer la comunicación entre el cliente y el servidor RPV. El grupo de recursos reanuda la duplicación de datos a través del RPV.
Error de nodo en el sitio remoto
Si el Nodo 3, que tiene configurado el servidor RPV, falla, GLVM para PowerHA SystemMirror Enterprise Edition mueve la instancia de respaldo del grupo de recursos al Nodo 4 en el sitio remoto. PowerHA SystemMirror también garantiza que el servidor RPV ya está disponible en Node4.
La aplicación se mantiene altamente disponible y los datos se siguen duplicando geográficamente. La aplicación continúa enviando solicitudes de E/S al RPV, y la función GLVM garantiza que el cliente RPV y el servidor RPV sigan comunicándose.
Cuando el nodo en el sitio remoto se reincorpora al clúster, basándose en la política del grupo de recursos PowerHA SystemMirror realiza el fallback del grupo de recursos.
Error de sitio local
Si, como resultado de una anomalía, no hay ningún nodo disponible en el sitio local para alojar un grupo de recursos con el grupo de volúmenes duplicado geográficamente y la aplicación, el grupo de recursos pasa a uno de los nodos del sitio remoto.
Por ejemplo, el grupo de recursos pasa del nodo 2 del sitio local al nodo 3 del sitio remoto. En este caso, GLVM para PowerHA SystemMirror Enterprise Edition activa forzosamente (si está configurado para ello) el grupo de volúmenes local con la copia espejo de los datos en el Nodo 3, y el Nodo 3 adquiere el grupo de recursos. La aplicación del grupo de recursos accede a esos datos directamente y no utiliza un RPV.
Si el Nodo 2 se reincorpora al cluster, PowerHA SystemMirror realiza el fallback del grupo de recursos (dependiendo de la política de fallback del grupo de recursos). El grupo de recursos vuelve al Nodo 2 y el cliente RPV pasa a estar disponible en el Nodo 2. Se restablece la comunicación entre el cliente RPV y el servidor. GLVM para PowerHA SystemMirror Enterprise Edition sincroniza las copias espejo y restablece la duplicación de datos. El grupo de recursos reanuda la duplicación de datos a través del RPV.
Error de sitio remoto
Si, como resultado de un fallo, no hay ningún nodo disponible en el sitio remoto para alojar el servidor RPV para el grupo de recursos con el grupo de volúmenes replicados geográficamente, PowerHA SystemMirror impide que el cliente RPV intente comunicarse con el servidor RPV.
Si un nodo que albergaba el servidor RPV en el sitio remoto vuelve a unirse al clúster, GLVM para PowerHA SystemMirror Enterprise Edition reanuda el servidor RPV en ese nodo y restablece la comunicación entre el cliente RPV y el servidor. La duplicación también se restablece y las copias de duplicación se sincronizan. El grupo de recursos permanece en el Nodo 2 y el cliente RPV empieza a comunicarse con el servidor RPV en el Nodo 3. El grupo de recursos reanuda la duplicación de datos a través del RPV.
Cómo evitar el particionamiento de clúster
Para evitar el particionamiento de clúster, configure una red para el latido entre los sitios, además de varias (hasta cuatro) redes basadas en IP a través de las cuales se transfieren los datos de duplicación. Si todas las conexiones de red de duplicación entre el cliente RPV y el servidor (y entre los sitios) fallan, la red de pulsaciones impide el particionamiento de clúster y la divergencia de datos resultante.
La figura siguiente ilustra el error de la red de duplicación de datos en el clúster con dos sitios (los nodos en cada sitio no se muestran):
