Descripción de escenarios de conmutación por error de alta disponibilidad
En las siguientes secciones se describen posibles escenarios de fallas de alta disponibilidad: cómo se detecta una falla, qué acción de recuperación tomar y, si corresponde, el impacto en el sistema causado por la falla.
Bloqueos de nodos VIP activos
Detección
El servicio de latidos que se ejecuta en un nodo VIP en espera detecta un fallo en 10 segundos de no recibir ningún mensaje de latidos de su par. El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en otros nodos detectar que el servidor JBoss en el nodo fallido no responde, en unos 52 segundos.
Recuperación
El nodo en espera se hace cargo inmediatamente de la dirección VIP.
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo que tarda el proceso en completarse depende de la cantidad de conexiones de dispositivos que se migrarán, la carga en los nodos restantes, etc. Por lo general, el proceso se completa en unos minutos.
Después de que el nodo de espera tome el control de la dirección VIP, se inicia un servicio de monitoreo de red en el nodo de espera. El servicio de monitoreo de red tarda entre tres y cinco minutos en completar su inicialización. Puede llevar más tiempo dependiendo del tamaño de los datos de FM y PM que se mantienen.
Impacto
La dirección VIP deja de estar disponible durante unos 10 segundos hasta que el nodo de espera la toma. El acceso de cliente de GUI o API durante este período encuentra errores transitorios. Además, se pierden las capturas SNMP enviadas por los dispositivos a la dirección VIP durante este intervalo.
La conectividad del dispositivo se ha inactivo durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss en el nodo fallido.
Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
Los usuarios experimentan una interrupción de la funcionalidad de monitoreo de red durante unos tres a cinco minutos, mientras que el servicio de monitoreo de red se inicia en el nodo de espera.
A partir de la plataforma de administración de red Junos Space 21.1R1, para realizar un error manual en lugar de reiniciar, ejecute los siguientes comandos en la CLI del nodo VIP:
systemctl restart corosyncsystemctl restart pacemaker
Nodo VIP en espera se bloquea
Detección
El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en los otros nodos detectar que el servidor JBoss en el nodo fallido no responde en unos 52 segundos.
Recuperación
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo de finalización del proceso depende del número de conexiones de dispositivo que se migrarán, de la carga en los nodos restantes, etc. Por lo general, este proceso se completa en unos minutos.
Impacto
La conectividad del dispositivo se ha inactivo durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss en el nodo fallido.
Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
eth0 en el nodo VIP activo cae
Detección
El servicio de latidos que se ejecuta en el nodo VIP de espera detecta el fallo en 10 segundos de no recibir ningún mensaje de latidos de su par. El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en los otros nodos detectar que el servidor JBoss en el nodo fallido no responde, en unos 52 segundos.
Recuperación
El nodo en espera se hace cargo inmediatamente de la dirección VIP.
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo que tarda el proceso en completarse depende de la cantidad de conexiones de dispositivos que se migrarán, la carga en los nodos restantes, etc. Por lo general, el proceso se completa en unos minutos.
Después de que el nodo de espera tome el control de la dirección VIP, se inicia un servicio de monitoreo de red en el nodo de espera. El servicio de monitoreo de red tarda entre tres y cinco minutos en completar su inicialización. Puede llevar más tiempo dependiendo del tamaño de los datos de FM y PM que se mantienen.
Impacto
La dirección VIP deja de estar disponible durante unos 10 segundos hasta que el nodo de espera la toma. El acceso de cliente de GUI o API durante este período encuentra errores transitorios. Además, se pierden las capturas SNMP enviadas por los dispositivos a la dirección VIP durante este intervalo.
La conectividad del dispositivo no funciona durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss en el nodo fallido.
Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
Los usuarios experimentan una interrupción de la funcionalidad de monitoreo de red durante unos tres a cinco minutos, mientras que el servicio de monitoreo de red se inicia en el nodo de espera.
eth0 en el nodo VIP en espera cae
Detección
El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en los otros nodos detectar que el servidor JBoss en el nodo fallido no responde en unos 52 segundos.
Recuperación
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo de finalización del proceso depende del número de conexiones de dispositivo que se migrarán, de la carga en los nodos restantes, etc. Por lo general, este proceso se completa en unos minutos.
Impacto
La conectividad del dispositivo no funciona durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss en el nodo fallido.
Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
Un nodo no vip se bloquea
Detección
El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en los otros nodos detectar que el servidor JBoss en el nodo fallido no responde en unos 52 segundos.
Recuperación
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo que tarda el proceso en completarse depende de la cantidad de conexiones de dispositivos que se migrarán, la carga en los nodos restantes, etc. Por lo general, este proceso se completa en unos minutos.
Impacto
La conectividad del dispositivo está desactivada durante unos minutos para los dispositivos cuyas conexiones fueron atendidas por el servidor JBoss en el nodo fallido. Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
eth0 en un nodo no vip cae
Detección
El mecanismo de agrupación en clústeres JBoss permite a los servidores JBoss en los otros nodos detectar que el servidor JBoss en el nodo fallido no responde en unos 52 segundos.
Recuperación
Las conexiones de dispositivo atendidas por el nodo fallido se migran a los nodos restantes del clúster. Este proceso comienza en aproximadamente 11 minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo de finalización del proceso depende del número de conexiones de dispositivo que se migrarán, de la carga en los nodos restantes, etc. Por lo general, este proceso se completa en unos minutos.
Impacto
La conectividad del dispositivo no funciona durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss en el nodo fallido.
Todos los trabajos que estaban en curso en el nodo fallido se marcan como fallidos y se indica el motivo.
eth3 en un nodo no vip cae
Detección
El monitor de control de dispositivos detecta que todas las conexiones de dispositivos atendidas por este nodo están caídas en 15 minutos y marca el estado de conexión de estos dispositivos como Inactivo.
Recuperación
En el caso de las conexiones iniciadas por Junos Space, Junos Space intenta volver a conectarse con estos dispositivos. Cada intento se realiza desde el nodo del clúster que se determina que es el menos cargado en términos de la cantidad de dispositivos que administra. Si otros nodos del clúster están significativamente menos cargados que este nodo, de acuerdo con esta comprobación de equilibrio de carga, se realizan intentos de reconexión desde esos nodos y tienen éxito. En este caso, la conectividad de estos dispositivos vuelve a activarse en unos minutos. Si este nodo es el que menos carga tiene, todos los intentos de reconexión se realizan desde este nodo y estos intentos siguen fallando mientras eth3 permanezca inactivo.
En el caso de conexiones iniciadas por dispositivo, el dispositivo detecta una falla de conexión en unos 15 minutos y, luego, se vuelve a conectar con otro nodo del clúster en los próximos segundos.
Impacto
La conectividad del dispositivo está desactivada para los dispositivos cuyas conexiones estaban siendo atendidas por este nodo. La conectividad puede estar inactivo durante 15 minutos (mejor de los casos) o hasta que se vuelva a activar eth3 (en el peor de los casos). Además, el tiempo de interrupción puede variar de un dispositivo a otro según el nodo elegido para intentar una reconexión para ese dispositivo. En el caso de conexiones iniciadas por dispositivos, la interrupción dura un poco más de 15 minutos.
eth3 en el nodo VIP activo cae
Detección
El monitor de control de dispositivos detecta que todas las conexiones de dispositivos atendidas por este nodo están caídas en 15 minutos y marca el estado de conexión de estos dispositivos como Inactivo.
Recuperación
En el caso de las conexiones J iniciadas por Junos Space, Junos Space intenta volver a conectarse con estos dispositivos. Cada intento se realiza desde el nodo del clúster que se determina que es el menos cargado en términos de la cantidad de dispositivos que administra. Si otros nodos del clúster están significativamente menos cargados que este nodo, de acuerdo con esta comprobación de equilibrio de carga, se realizan intentos de reconexión desde esos nodos y tienen éxito. En este caso, la conectividad de estos dispositivos vuelve a activarse en unos minutos. Si este nodo es el que menos carga tiene, todos los intentos de reconexión se realizan desde este nodo y estos intentos siguen fallando mientras eth3 permanezca inactivo.
En el caso de conexiones iniciadas por dispositivo, el dispositivo detecta una falla de conexión en unos 15 minutos y, luego, se vuelve a conectar con otro nodo del clúster en los próximos segundos.
Impacto
La conectividad del dispositivo está desactivada para los dispositivos cuyas conexiones estaban siendo atendidas por este nodo. La conectividad puede estar inactivo durante 15 minutos (mejor de los casos) o hasta que se vuelva a activar eth3 (en el peor de los casos). Además, el tiempo de interrupción puede variar de un dispositivo a otro según el nodo elegido para intentar una reconexión para ese dispositivo. En el caso de conexiones iniciadas por dispositivos, la interrupción dura un poco más de 15 minutos.
El servicio de monitoreo de red también se ve afectado porque se ejecuta solo en el nodo VIP. El servicio no recibe capturas SNMP de ningún dispositivo administrado, ya que todos los dispositivos están configurados con la dirección IP eth3 del nodo VIP como destino de captura. Además, todo el rendimiento y la supervisión de fallas de todos los dispositivos administrados fallan hasta que se vuelve a incorporar eth3.
El servidor JBoss en un nodo cae
Detección
Cuando el servidor JBoss en un nodo cae, otros nodos del clúster de JBoss detectan la falla en unos dos segundos) porque sus conexiones TCP con el servidor JBoss fallido se cierran por el sistema operativo.
Recuperación
Las conexiones de dispositivo atendidas por el servidor JBoss fallido se migran a los otros nodos del clúster. Este proceso comienza en aproximadamente un minuto después de que los miembros del clúster JBoss detecten que el servidor JBoss en el nodo fallido está inactivo. El tiempo que tarda el proceso en completarse depende de la cantidad de conexiones de dispositivos que se migrarán, la carga en los nodos restantes, etc. Por lo general, el proceso se completa en unos minutos.
El servicio de vigilancia (jmp-watchdog) que se ejecuta en el nodo detecta que el servidor JBoss está inactivo y lo reinicia automáticamente. Cuando el servidor JBoss vuelve a subir, otros miembros del clúster lo descubren automáticamente y se agregan al clúster. Luego, sincronice su caché desde los otros nodos del clúster. El tiempo de reinicio típico para JBoss es de dos a cinco minutos. Sin embargo, puede llevar más tiempo dependiendo de la cantidad de aplicaciones instaladas, la cantidad de dispositivos que se administran, la cantidad de versiones de esquema DMI instaladas, etc.
Impacto
La conectividad de los dispositivos se desconecte durante unos minutos para los dispositivos cuyas conexiones estaban siendo atendidas por el servidor JBoss que se quedó inactivo.
Todos los trabajos que estaban en curso en el servidor JBoss colapsado se marcan como fallidos y se indica el motivo.
MySQL Server en el nodo VIP activo cae
Detección
Si el servidor MySQL en un nodo falla, el servicio de vigilancia detecta el servidor MySQL caído en ese nodo activo en unos uno a dos segundos.
Recuperación
El servicio de control reinicia inmediatamente el servidor MySQL en el nodo. Cuando se reinicia, el servidor MySQL aparece en unos 20 a 60 segundos.
Impacto
El servidor MySQL en el nodo VIP es la base de datos activa que atiende todas las solicitudes de todos los servidores JBoss del clúster. Esto significa efectivamente que JBoss podría experimentar una breve interrupción de la base de datos en todos los nodos durante esta duración (de 20 a 60 segundos). Durante este período, se fallan las solicitudes que requieren acceso a la base de datos. Esto da lugar a errores encontrados por los clientes de GUI o API en sus solicitudes, que internamente requieren acceso a la base de datos durante este período. Esto también da lugar a errores en los trabajos que requieren acceso a la base de datos durante este período.
MySQL Server en el nodo VIP en espera cae
Detección
Si el servidor MySQL en un nodo falla, el servicio de vigilancia detecta el servidor MySQL caído en ese nodo de espera en unos uno a dos segundos.
Recuperación
El servicio de control reinicia inmediatamente el servidor MySQL en el nodo. Cuando se reinicia, el servidor MySQL tarda entre 20 y 60 segundos. Después de realizar una copia de seguridad, este servidor se resincroniza con el servidor principal en segundo plano y el tiempo de resincronización depende de la cantidad de cambios que se produjeron durante la interrupción.
Impacto
Dado que JBoss no accede al servidor MySQL en el nodo VIP de espera, su tiempo de inactividad no causa ningún impacto adverso que sea notado por el resto del sistema o los usuarios del sistema.
Nodo de base de datos principal se bloquea
Detección
El servicio de latidos que se ejecuta en el nodo secundario de la base de datos detecta el bloqueo dentro de los 10 segundos de no recibir ningún mensaje de latidos del nodo principal de la base de datos.
Recuperación
La dirección VIP de la base de datos se transfiere al nodo secundario de la base de datos en un plazo de 10 a 20 segundos. Los servidores JBoss en otros nodos pueden acceder a la base de datos después de que la dirección VIP de la base de datos sea tomada por el nodo secundario de la base de datos.
Impacto
La dirección VIP de la base de datos deja de estar disponible durante unos 10 a 20 segundos hasta que el nodo secundario de la base de datos la toma. El servidor MySQL en el nodo de base de datos principal es la base de datos activa que atiende todas las solicitudes de todos los servidores JBoss del clúster. Esto significa efectivamente que JBoss podría experimentar una breve interrupción de la base de datos en todos los nodos durante esta duración (de 20 a 60 segundos). Durante este período, se fallan las solicitudes que requieren acceso a la base de datos. Esto da como resultado errores encontrados por los clientes de GUI y API en sus solicitudes que internamente requieren acceso a la base de datos durante este período. Esto también da lugar a errores en los trabajos que requieren acceso a la base de datos durante este período.
Nodo de base de datos secundario se bloquea
Detección
El servicio de latidos que se ejecuta en el nodo principal de la base de datos detecta el bloqueo en 10 segundos de no recibir ningún mensaje de latidos desde el nodo secundario de la base de datos.
Recuperación
El nodo se puede eliminar y un nuevo nodo se puede agregar al clúster de Junos Space como un nodo secundario de base de datos para mantener la alta disponibilidad de la base de datos.
Impacto
Dado que JBoss no accede al servidor MySQL en el nodo secundario de la base de datos, su tiempo de inactividad no causa ningún impacto adverso que sea notado por el resto del sistema o los usuarios del sistema.
MySQL Server en el nodo de base de datos principal cae
Detección
Si el servidor MySQL en un nodo falla, el servicio de vigilancia detecta el servidor MySQL caído en ese nodo activo en unos uno a dos segundos.
Recuperación
El servicio de control reinicia inmediatamente el servidor MySQL en el nodo. Cuando se reinicia, el servidor MySQL aparece en unos 20 a 60 segundos.
Impacto
El servidor MySQL en el nodo de base de datos principal es la base de datos activa que atiende todas las solicitudes de todos los servidores JBoss del clúster. Esto significa efectivamente que JBoss podría experimentar una breve interrupción de la base de datos en todos los nodos durante esta duración (de 20 a 60 segundos). Durante este período, se fallan las solicitudes que requieren acceso a la base de datos. Esto da como resultado errores encontrados por los clientes de GUI y API en sus solicitudes que internamente requieren acceso a la base de datos durante este período. Esto también da lugar a errores en los trabajos que requieren acceso a la base de datos durante este período.
El servidor MySQL en el nodo secundario de la base de datos cae
Detección
Si el servidor MySQL en un nodo falla, el servicio de vigilancia detecta el servidor MySQL caído en ese nodo de espera en unos uno a dos segundos.
Recuperación
El servicio de control reinicia inmediatamente el servidor MySQL en el nodo. Cuando se reinicia, el servidor MySQL tarda entre 20 y 60 segundos. Después de hacer una copia de seguridad, este servidor se vuelve a sincronizar con el nodo de base de datos principal en segundo plano. El tiempo de resincronización depende de la cantidad de cambios que se produzcan durante la interrupción.
Impacto
Dado que JBoss no accede al servidor MySQL en el nodo secundario de la base de datos, su tiempo de inactividad no causa ningún impacto adverso que sea notado por el resto del sistema o los usuarios del sistema.
El servidor Apache HTTP en el nodo VIP activo cae
Detección
Si el servidor Apache HTTP en un nodo cae, el servicio de vigilancia detecta el servidor HTTP caído en ese nodo en aproximadamente uno a dos segundos.
Recuperación
El servicio de control reinicia de inmediato el servidor Apache HTTP en el nodo y se prepara para el servicio en un segundo.
Impacto
Los clientes de GUI y NBI podrían experimentar una breve interrupción del servicio hasta que se reinicie el servidor Apache HTTP. Sin embargo, esta interrupción es solo por unos segundos (normalmente, dos segundos) y los clientes apenas la notan.
El servidor APACHE HTTP en el nodo VIP en espera cae
Detección
Si el servidor Apache HTTP en un nodo cae, el servicio de vigilancia detecta el servidor HTTP caído en ese nodo en aproximadamente uno a dos segundos.
Recuperación
El servicio de control reinicia de inmediato el servidor APACHE HTTP en el nodo y se prepara para el servicio en un segundo.
Impacto
Sin impactos.
Bloqueos de nodos dedicados de Cassandra
Detección
Si el nodo de Cassandra falla, el servicio de vigilancia detecta que el servicio de Cassandra está inactivo en ese nodo en aproximadamente uno a dos segundos.
Recuperación
El nodo cassandra que está caído debe eliminarse de la estructura.
Impacto
Los archivos no se pueden cargar o eliminar de la base de datos de Cassandra hasta que el nodo que está caído se elimina de la estructura.
El servicio de Cassandra en un nodo JBoss cae
Detección
Si el servicio de Cassandra en un nodo JBoss falla, el servicio de control detecta que el servicio de Cassandra está inactivo en ese nodo en unos uno o dos segundos.
Recuperación
El servicio de Cassandra en el nodo debe estar deshabilitado.
Impacto
Los archivos no se pueden cargar o eliminar de la base de datos de Cassandra hasta que el servicio cassandra esté deshabilitado en el nodo.