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.
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.
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:
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.
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.
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.