Users Guide

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.
ii. En el chasis principal nuevo, elimine el chasis principal anterior del grupo para eliminar las referencias a él.
iii. En el chasis principal anterior, consiga acceso físico al chasis principal fallado tan pronto como sea posible y sáquelo de
la pila del grupo. Si había alguna plantilla con asignaciones de grupos de identidades que se implementan en cualquier
procesamiento del chasis principal anterior, recupere esas asignaciones desde los procesamientos. Se requiere la recuperación
de las asignaciones de grupos de identidades para evitar cualquier colisión de la identidad de la red cuando el chasis antiguo se
vuelve a poner en producción.
iv. No elimine los fabrics del chasis principal antiguo, ya que la eliminación de las fabrics puede provocar la pérdida de la red una
vez que el chasis principal antiguo se vuelva a agregar a la red.
v. En el chasis principal anterior, fuerce un "restablecimiento de configuración" mediante la siguiente carga útil de la API REST:
URI: /api/ApplicationService/Actions/ApplicationService.ResetApplication
Método: POST
Carga útil: {"ResetType": "RESET_ALL", "ForceReset": true}
d. Reubique los componentes en funcionamiento del chasis principal anterior en otros chasis del grupo:
i. Reubique los switch de red del chasis principal anterior en el nuevo chasis principal o en uno que sea miembro del grupo para
restaurar el estado de las redes fabric.
ii. Reubique los procesamientos del chasis principal anterior en el nuevo chasis principal o en uno que sea miembro del grupo. Las
nuevas plantillas o identidades se deben implementar en los procesamientos antes de reanudar las cargas de trabajo que se
estaban ejecutando en el chasis principal anterior.
Identifier
GUID-189CDE37-8AC2-4443-9F3B-B4991CE3D6ED
Version 3
Status Translation approved
Retiro del chasis principal
La opción de "retiro" permite que un chasis de respaldo pase a ser el chasis principal de un grupo de chasis, cuando el chasis principal ha
estado funcionando durante un tiempo prolongado y debe extraerse del entorno de producción de forma temporal o permanente. El chasis
principal puede desconectarse correctamente del grupo. La opción de "retiro" también facilita quitar la función principal de un chasis y que
permanezca como un miembro del grupo.
1. Ejecute la tarea de "retiro" desde el chasis principal:
a. Se crea un trabajo cuando se inicia la tarea de "retiro". El trabajo puede completarse entre 10 y 45 minutos, en función de la
cantidad de chasis que haya en el grupo y de la cantidad de configuración que se restaurará.
b. Si el chasis principal está configurado para reenviar alertas a destinos externos (correo electrónico, captura, registro del sistema),
todas las alertas que generan los componentes del grupo solo están disponibles en sus respectivos registros de hardware. Además,
se registra una alerta cuando la tarea de retiro y el chasis de respaldo, que pasa a ser el chasis principal, están en curso. Una vez
finalizada la tarea de "retiro" y antes de promover el chasis respaldo, se produce una interrupción en la administración de grupos. La
interrupción incluye el reenvío de alertas a los destinos externos que estén configurados.
2. Comportamiento esperado del chasis de respaldo tras finalizar la tarea de "retiro":
a. El chasis de respaldo se convierte en el nuevo chasis principal y se puede acceder a todos los chasis miembros de igual manera que
en el chasis principal que se retiró. El nuevo chasis principal redescubre todos los miembros en el grupo y, si no se puede acceder
a ningún chasis miembro, estos aparecerán de igual modo en la página de inicio del chasis principal con una conexión dañada y las
opciones de reparación disponibles. Utilice la opción de reparación para volver a agregar o eliminar un chasis miembro 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 que se retiró.
3. Comportamiento esperado del chasis principal antiguo tras finalizar la tarea de "retiro":
150
Situaciones de uso