Users Guide

Identifier GUID-2C18F99C-1735-452C-B7C9-34358AAA85C5
Version 2
Status Translation Validated
Recuperación ante desastres del chasis principal
Las fallas catastróficas, como la pérdida de alimentación, la pérdida de la red y la falla de ambos MM, pueden hacer que el chasis principal
sea inaccesible o no esté disponible. En tales casos, puede promover el chasis respaldo para que asuma el lugar del chasis principal fallido y
mantener una administración continua de los sistemas.
NOTA: La promoción del chasis principal de respaldo como el nuevo chasis principal restaura la función de administración de grupos
para los chasis miembro que no están expuestos a las fallas. Sin embargo, existen limitaciones en el alcance de la funcionalidad que se
pueden restaurar en el chasis principal fallido. La restauración se basa en la gravedad de las fallas en el chasis principal.
Recuerde lo siguiente cuando realice la recuperación del chasis principal:
1. Antes de ejecutar la tarea "promover" en el chasis del principal de respaldo:
a. La tarea "promover" es una operación disruptiva y solo se debe utilizar cuando no hay medios para recuperar el chasis principal
que está inaccesible. Por ejemplo, en las fallas parciales del chasis principal, si solo los módulos de administración no responden,
pero los procesamientos funcionan, ejecutar la tarea promover interrumpe las cargas de trabajo que aún se están ejecutando en los
procesamientos del chasis principal. Para obtener información acerca de cómo reubicar los componentes que están funcionando,
es decir, los procesamientos y los switches de red del chasis principal fallido, consulte el elemento de lista 3.c, "Pasos necesarios
para restaurar el chasis principal fallido antes de ponerlo en producción".
b. Después de determinar que el chasis principal ha fallado y no se puede acceder a él, debe apagar la alimentación del chasis principal
de forma remota o extraer físicamente el chasis de la pila antes de ejecutar la tarea de "promover" en el chasis de respaldo. Si el
chasis principal no se apaga ni se extrae de la pila antes de la tarea de promover, el chasis principal fallido, o fallido parcialmente,
puede reactivarse después de promover el chasis respaldo y causar situaciones donde hay varios chasis principales. Cuando hay
varios chasis principales se puede crear confusión e interferencia en la administración del grupo.
2. Ejecución de la tarea "promover" en el chasis del principal de respaldo:
a. Si el chasis principal está encendido y en funcionamiento, la interfaz web del chasis de respaldo bloquea la tarea "promover".
Asegúrese de que el chasis principal ha fallado y no se puede acceder a él antes de iniciar la tarea de promover en el respaldo. El
respaldo puede bloquear erróneamente la "promoción" cuando se puede acceder al chasis principal a través de la red privada, pero
es posible que no se pueda acceder a él desde la red de administración de usuarios pública. En tales casos, se puede usar la API
RESTful de OME-Modular para ejecutar la tarea promover de manera forzada. Para obtener más información, consulte la guía de
API RESTful.
b. Un trabajo se crea después de que se inicia la operación de "promoción". El trabajo puede completarse en entre 10 y 45 minutos, en
función de la cantidad de chasis que haya en el grupo y de la cantidad de configuraciones que se restaurarán.
c. Si el chasis principal está configurado para reenviar alertas a destinos externos (correo electrónico, captura, registro del sistema),
todas las alertas que los componentes del grupo generan mientras el chasis principal está inactivo solo están disponibles en sus
respectivos registros de hardware o alerta. Durante una interrupción del chasis principal, este no se puede reenviar a los destinos
externos configurados. La interrupción es el período entre la falla del chasis principal y la promoción exitosa del chasis respaldo.
3. Comportamiento esperado después de la tarea de "promover":
a. El chasis de respaldo se convierte en el chasis principal y se puede acceder a todos los chasis miembros de igual manera que en
el chasis principal anterior. Después de la tarea "promover", las referencias al chasis principal anterior se realizan considerándolo un
miembro del mismo grupo. Las referencias se crean para evitar cualquier interrupción en los procesamientos de trabajo del chasis
principal anterior en una situación de falla de MM del chasis principal.
La tarea "promover" vuelve a descubrir todos los miembros del grupo y, si no se puede acceder a ningún chasis miembro, estos
seguirán apareciendo en la página de inicio del chasis principal con una conexión dañada y opciones de reparación disponibles.
Puede utilizar la opción reparar para volver a agregar un chasis miembro o eliminarlo del grupo.
b. Se restauran todos los catálogos o las líneas base de firmware, las políticas de alerta, las plantillas o los grupos de identidades y
la configuración de fabrics, tal como se encontraban en el chasis principal fallido. Sin embargo, a continuación se indican algunas
excepciones y limitaciones:
i. Los cambios en la configuración del chasis principal fallido realizados en los últimos 90 minutos que se deban copiar al chasis
de respaldo probablemente no se copien por completo en el respaldo y no se restauren por completo después de la tarea
"promover".
ii. Los trabajos en curso y copiados parcialmente que estén asociados con plantillas/grupos de identidades seguirán ejecutándose.
Puede llevar a cabo alguna de las siguientes tareas:
i. Detenga el trabajo en ejecución.
ii. Recupere las asignaciones de los grupos de identidades.
iii. Reinicie el trabajo para volver a implementar la plantilla.
iii. Cualquier plantilla que esté conectada a una ranura ocupada en el chasis principal antes de que el respaldo tome el control
como el nuevo chasis principal no se implementa en el sled existente cuando se elimina o se vuelve a insertar. Para que la
Situaciones de uso
149