Users Guide

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
implementación funcione, el administrador debe desconectar la plantilla de la ranura, volver a conectarla a la ranura y eliminar o
volver a insertar el sled existente. O bien, insertar un sled nuevo.
iv. Todos los catálogos de firmware que se crean con el catálogo de actualización automática programado se restauran como
actualizaciones manuales. Edite el catálogo y proporcione el método de actualización automática con la frecuencia de
actualización.
v. Las políticas de alerta, con elementos obsoletos o sin referencias, para los dispositivos del chasis principal antiguo no se
restauran en el chasis principal nuevo.
c. Pasos necesarios para restaurar el chasis principal fallido antes de colocarlo en producción:
i. En el chasis principal nuevo, apague el chasis de forma remota antes de realizar la tarea "promover" en el chasis de respaldo. Si
el chasis no está apagado, es posible que el chasis principal fallido parcialmente se esté en línea y cause una situación de varios
chasis principales. El soporte para la detección y recuperación automáticas de esta situación es limitado. Si el chasis principal
anterior está en línea y la recuperación automática puede realizarse, el chasis principal anterior se ve forzado a unirse al grupo
como un miembro.
138
Situaciones de uso