Quórums del servidor de catálogos

Cuando el mecanismo de quórum está habilitado, todos los servidores de catálogo del quórum deben estar disponibles para que se produzcan las operaciones de colocación en la cuadrícula de datos.

Términos importantes

Pulsaciones y detección de anomalías

Servidores de contenedor y grupos principales

El servicio de catálogo coloca servidores de contenedor en grupos principales de tamaño limitado. Un grupo principal intenta detectar la anomalía de sus miembros. Se elige un solo miembro de un grupo principal para que sea el líder del grupo principal. El líder del grupo principal indica periódicamente al servicio de catálogo que el grupo principal está activo y notifica cualquier cambio en la pertenencia al servicio de catálogo. Un cambio de pertenencia puede ser una JVM que falla o una JVM que se acaba de añadir y que se ha unido al grupo principal.

Si un socket de JVM está cerrado, se considera esa JVM como que ya no está disponible. Cada miembro de grupo principal también emite pulsaciones sobre estos sockets a una velocidad determinada por la configuración. Si una JVM no responde a estas pulsaciones en un periodo de tiempo máximo configurado, se considera que la JVM ya no está disponible, lo que desencadena una detección de anomalía.

Si el servicio de catálogo marca una JVM de contenedor como fallida y posteriormente se notifica el servidor de contenedor como disponible, se indica a la JVM de contenedor que concluya los servidores de contenedor WebSphere eXtreme Scale. Una JVM en este estado no se visualiza en las consultas del mandato del programa de utilidad xscmd. Los mensajes en los registros de la JVM de contenedor indican que esta última ha producido un error. Debe reiniciar manualmente estas JVM.

Si el líder del grupo principal no puede ponerse en contacto con ningún miembro, continúa intentando contactar con el miembro.

La anomalía completa de todos los miembros de un grupo principal también es una posibilidad. Si ha fallado todo el grupo principal, es responsabilidad del servicio de catálogo detectar esta pérdida.

Pulsación del dominio de servicio de catálogo

El dominio de servicio de catálogo tiene el aspecto de un grupo principal privado con una pertenencia estática y un mecanismo de quórum. Detecta las anomalías del mismo modo que un grupo principal normal. Sin embargo, el comportamiento se modifica para incluir la lógica del quórum. El servicio de catálogo utiliza también una configuración de pulsación menos agresiva.

Detección de errores

WebSphere eXtreme Scale detecta cuándo los procesos terminan mediante sucesos de cierre de socket anómalos. Se notifica inmediatamente al servicio de catálogo cuando un proceso termina.

Para obtener más información sobre la configuración de pulsación, consulte Ajuste del valor de intervalo de pulsación para la detección de migración tras error.

Comportamiento de quórum

Normalmente, los miembros del servicio de catálogo tienen conectividad completa. El dominio de servicio de catálogo es un conjunto estático de JVM. WebSphere eXtreme Scale espera que todos los miembros del servicio de catálogo estén en línea. Cuando todos los miembros están en línea, el servicio de catálogo tiene quórum. El servicio de catálogo responde a sucesos de contenedor solo mientras el servicio de catálogo tiene quórum.

Razones para la pérdida de quórum

WebSphere eXtreme Scale espera perder quórum para los escenarios siguientes:

  • Un miembro de la JVM del servicio de catálogo falla
  • Se produce una caída de la red
  • Se produce pérdida de un centro de datos
WebSphere eXtreme Scale no pierde quórum en el escenario siguiente:
  • Detención de una instancia de servidor de catálogo con el mandato stopOgServer o cualquier otra acción administrativa. El sistema sabe que la instancia del servidor se ha detenido, lo que es distinto a una caída de la red o una anomalía de JVM.

Si el servicio de catálogo pierde quórum, espera a que se restablezca el quórum. Mientras el servicio de catálogo no tiene quórum, ignora los sucesos de los servidores de contenedor. Los servidores de contenedor continúan intentando las solicitudes rechazadas por el servidor de catálogo durante este tiempo. La pulsación se suspende hasta que se restablece un quórum.

Pérdida de quórum debida a una anomalía de JVM

Un servidor de catálogo que falla causa que se pierda el quórum. Si falla una JVM, se debe sustituir el quórum lo antes posible. El servicio de catálogo anómalo no puede volver a unirse a la cuadrícula de datos hasta que se haya sustituido el quórum.

Pérdida de quórum debido a la caída de la red

WebSphere eXtreme Scale está diseñado para esperar la posibilidad de caídas de la red. Una caída de la red es cuando se produce una pérdida temporal de conectividad entre los centros de datos. Las caídas de la red normalmente son transitorias y desaparecen en cuestión de segundos o minutos. Mientras WebSphere eXtreme Scale intenta mantener el funcionamiento normal durante el periodo de la caída de la red, una interrupción temporal se considera un único suceso de anomalía. Se espera arreglar la anomalía y a continuación se reanuda el funcionamiento normal sin que sea necesaria ninguna acción.

Una caída de la red de larga duración se puede clasificar como un apagón sólo a través de la intervención del usuario. Es necesario sustituir el quórum en un lado de la caída de la red para que el suceso se clasifique como apagón.

Ciclos de la JVM del servicio de catálogo

Si un servidor de catálogo se detiene utilizando el mandato stopOgServer, el quórum pierde un servidor. Los demás servidores aún tienen el quórum. Si se reinicia el servidor de catálogo, se restablecerá el quórum en el número anterior.

Consecuencias de la pérdida de quórum

Si una JVM de contenedor fallara mientras se ha perdido el quórum, la recuperación no se produciría hasta que finalizara la caída de la red. En un escenario de apagón, la recuperación no se produce hasta que se ejecuta el mandato de sustitución de quórum. La pérdida de quórum y una anomalía de contenedor se consideran una anomalía doble, lo que es un suceso inusual. Debido a la anomalía doble, es posible que las aplicaciones pierdan acceso de grabación a los datos almacenados en la JVM anómala. Cuando se restaura el quórum, se produce la recuperación normal.

De forma similar, si intenta iniciar un contenedor durante un suceso de pérdida de quórum, el contenedor no se inicia.

La conectividad total de cliente está autorizada durante la pérdida de quórum. Si no se produce ninguna anomalía de contenedor, ni ningún problema de conectividad durante el suceso de pérdida de quórum, los clientes pueden seguir interactuando de forma completa con los servidores de contenedor.

Si se produce una caída de la red, es posible que algunos clientes no tengan acceso a copias primarias o de réplica de los datos hasta que se haya resuelto la caída de la red.

Se pueden iniciar nuevos clientes porque debe existir una JVM de servicio de catálogo en cada centro de datos. Por lo tanto, como mínimo un cliente puede contactar con un servidor de catálogo durante un suceso de caída de la red.

Recuperación del quórum

Si se pierde el quórum por alguna razón, cuando este se restablece se ejecuta un protocolo de recuperación. Cuando se produce un suceso de pérdida de quórum, se suspenden todas las comprobaciones de integridad y concurrencia para los grupos principales y también se ignoran los informes de anomalías. Una vez recuperado el quórum, el servicio de catálogo comprueba todos los grupos principales para determinar inmediatamente su pertenencia. Los fragmentos alojados anteriormente en las JVM de contenedor notificadas como anómalas se recuperan. Si se perdierán fragmentos primarios, las réplicas supervivientes pasarían a ser fragmentos primarios. Si se perdieran fragmentos de réplica, se crearían fragmentos de réplica adicionales en los supervivientes.

Alteración temporal del quórum

Sustituya el quórum solo cuando se haya producido una anomalía del centro de datos. La pérdida de quórum debida a una anomalía de JVM de servicio de catálogo o una caída de la red se recupera automáticamente después de que se reinicie la JVM de servicio de catálogo o finalice la caída de la red.

Los administradores son los únicos con conocimiento de una anomalía de centro de datos. WebSphere eXtreme Scale trata una caída de la red y un apagón de forma similar. Debe informar al entorno de WebSphere eXtreme Scale de este tipo de anomalías con el mandato xscmd -c overrideQuorum. Este mandato indica al servicio de catálogo que suponga que el quórum se consigue con la pertenencia actual, y que tiene lugar la recuperación completa. Al emitir un mandato de sustitución de quórum, garantiza que las JVM del centro de datos anómalo han fallado realmente y no tienen oportunidades de recuperación.

La siguiente lista considera algunos escenarios para alterar temporalmente el quórum. En este escenario, tiene tres servidores de catálogo: A, B y C.
  • Caída de la red: el servidor de catálogo C está aislado temporalmente. El servicio de catálogo pierde quórum y espera a que finalice la caída de la red. Una vez que se la solucionado la caída de la red, el servidor de catálogo C se vuelve a unir al dominio de servicio de catálogo y se restablece el quórum. La aplicación no verá ningún problema durante este momento.
  • Anomalía temporal: durante una anomalía temporal, el servidor de catálogo C falla y el servicio de catálogo pierde el quórum. Debe sustituir el quórum. Después de que se restablezca el quórum, puede reiniciar el servidor de catálogo C. El servidor de catálogo C se une de nuevo al dominio de servicio de catálogo cuando se reinicia. La aplicación no verá ningún problema durante este momento.
  • Anomalía del centro de atos: verifica que el centro de datos ha fallado y que se ha aislado en la red. A continuación, emite el mandato xscmd -c overrideQuorum. Los dos centros de datos supervivientes ejecutan una recuperación completa sustituyendo los fragmentos que estaban alojados en el centro de datos anómalo. El servicio de catálogo ahora se ejecuta con un quórum completo de los servidores de catálogo A y B. La aplicación podría ver retardos y excepciones durante el intervalo entre el inicio del apagón y la sustitución del quórum. Una vez que se ha sustituido el quórum, la cuadrícula de datos se recupera y se reanuda el funcionamiento normal.
  • Recuperación del centro de datos: los centros de datos supervivientes ya se están ejecutando con sustitución de quórum. Cuando el centro de datos que contiene el servidor de catálogo C se reinicia, todas las JVM del centro de datos se deben reiniciar. A continuación, el servidor de catálogo C se une de nuevo al dominio de servicio de catálogo existente y el valor de quórum vuelve a la situación normal sin intervención del usuario.
  • Anomalía de centro de datos y caída de la red: el centro de datos que contiene el servidor de catálogo C falla. El quórum se sustituye y se recupera en los demás centros de datos. Si se produce una caída de la red entre los servidores de catálogo A y B, se aplican las reglas de recuperación de caída de red normales. Una vez que se soluciona la caída de la red, el quórum se restablece y se produce la recuperación necesaria de la pérdida de quórum.

Comportamiento del contenedor durante la pérdida de quórum

Los contenedores alojan uno o más fragmentos. Los fragmentos son primarios o réplicas para una partición específica. El servicio de catálogo asigna fragmentos a un contenedor y el servidor de contenedor utiliza esa asignación hasta que llegan nuevas instrucciones del servicio de catálogo. Por ejemplo, un fragmento primario continúa intentando la comunicación con sus fragmentos de réplica durante caídas de la red, hasta que el servicio de catálogo proporciona instrucciones adicionales al fragmento primario.

Comportamiento de réplica síncrona

El fragmento primario puede aceptar transacciones nuevas mientras la conexión está interrumpida si el número de réplicas en línea está como mínimo en el valor de la propiedad minsync para el conjunto de correlaciones. Si se procesa alguna transacción nueva en el fragmento primario mientras el enlace a la réplica síncrona está interrumpido, la réplica se vuelve a sincronizar con el estado actual del primario cuando se restablece el enlace.

No configure la réplica síncrona entre los centros de datos o mediante un enlace de estilo WAN.

Comportamiento de réplica asíncrona

Mientras la conexión está interrumpida, el fragmento primario puede aceptar nuevas transacciones. El fragmento primario almacena en el almacenamiento intermedio los cambios hasta un límite. Si la conexión con la réplica se restablece antes de que se alcance el límite, la réplica se actualiza con los cambios del almacenamiento intermedio. Si se ha alcanzado el límite, el primario destruye la lista del almacenamiento intermedio y cuando se vuelve a conectar la réplica, se borra y se vuelve a sincronizar.

Comportamiento del cliente durante la pérdida de quórum

Los clientes siempre pueden conectarse al servidor de catálogo para realizar el programa de arranque de la cuadrícula de datos independientemente de si el dominio de servicio de catálogo tiene quórum o no. El cliente intenta conectarse a cualquier instancia de servicio de catálogo para obtener una tabla de direccionamiento y a continuación interactuar con la cuadrícula de datos. La conectividad de red puede impedir que el cliente interactúe con algunas particiones debido a la configuración de la red. El cliente podría conectarse a réplicas locales para datos remotos si se ha configurado para ello. Los clientes no pueden actualizar los datos si la partición primaria para estos datos no está disponible.