EN ESTA PÁGINA
Actualización de un clúster de chasis mediante la actualización de software en servicio
La actualización de software en servicio (ISSU) permite una actualización de software de una versión de Junos OS a una versión posterior de Junos OS con un tiempo de inactividad mínimo. Para obtener más información, consulte los temas siguientes:
Descripción de ISSU para un clúster de chasis
La actualización de software en servicio (ISSU) permite una actualización de software de una versión de Junos OS a una versión posterior de Junos OS con poco o ningún tiempo de inactividad. ISSU se realiza cuando los dispositivos funcionan solo en modo de clúster de chasis.
La función ISSU del clúster de chasis permite que ambos dispositivos de un clúster se actualicen desde las versiones compatibles de Junos OS con una interrupción mínima del tráfico y sin interrupciones en el servicio.
A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.
A partir de Junos OS versión 15.1X49-D70, SRX1500 dispositivos admiten ISSU.
A partir de Junos OS versión 23.4R1, los dispositivos SRX1600 y SRX2300 admiten ISSU.
A partir de Junos OS versión 24.2R1, SRX4300 dispositivos admiten ISSU.
-
En dispositivos SRX1500, SRX4100 y SRX4200, ISSU no se admite para actualizar a versiones 17.4 desde versiones anteriores de Junos OS. ISSU se admite para actualizar de Junos OS 17.4 a versiones 17.4 sucesivas.
-
En dispositivos SRX5400, SRX5600 y SRX5800, ISSU no se admite para actualizar a versiones 17.3 y posteriores de versiones anteriores de Junos OS. ISSU se admite para actualizar de Junos OS 17.3 a versiones 17.3 sucesivas.
-
Los dispositivos de la serie SRX300 ni el firewall virtual vSRX no admiten ISSU.
ISSU ofrece los siguientes beneficios:
-
Elimina el tiempo de inactividad de la red durante las actualizaciones de imágenes de software
-
Reduce los costos operativos, a la vez que ofrece niveles de servicio más altos
-
Permite una rápida implementación de nuevas características
ISSU tiene las siguientes limitaciones:
-
ISSU solo está disponible para Junos OS versión 10.4R4 o posterior.
-
ISSU no admite degradaciones de software.
-
Si actualiza desde una versión de Junos OS que solo admite IPv4 a una versión que admite IPv4 e IPv6, el tráfico IPv4 seguirá funcionando durante el proceso de actualización. Si actualiza desde una versión de Junos OS que admite IPv4 e IPv6 a una versión que admite IPv4 e IPv6, tanto el tráfico IPv4 como IPv6 seguirán funcionando durante el proceso de actualización. Junos OS versión 10.2 y versiones posteriores admiten el procesamiento basado en flujo para el tráfico IPv6.
-
Durante una ISSU, no puede poner en línea ninguna PIC. No puede realizar operaciones como confirmar, reiniciar o detener.
-
Durante una ISSU, se suspenden operaciones como la supervisión de estructuras, la recuperación de vínculos de control y la preferencia de RGX.
-
Durante una ISSU, no se puede confirmar ninguna configuración.
Para obtener más información sobre el estado de compatibilidad de ISSU, consulte el artículo KB17946 de Knowledge Base.
El siguiente proceso se produce durante una ISSU para dispositivos en un clúster de chasis. Las secuencias dadas a continuación son aplicables cuando RG-0 es el nodo 0 (nodo primario). Tenga en cuenta que debe iniciar una ISSU desde RG-0 principal. Si inicia la actualización en el nodo 1 (secundario RG-0), se muestra un mensaje de error.
-
Al principio de una ISSU de clúster de chasis, el sistema conmuta automáticamente por error todos los grupos de redundancia RG-1+ que no son primarios en el nodo desde el que se inicia la ISSU. Esta acción garantiza que todos los grupos de redundancia estén activos solo en el nodo primario RG-0.
La conmutación por error automática de todos los grupos de redundancia RG-1+ está disponible a partir de la versión 12.1 o posterior de Junos OS. Si utiliza Junos OS versión 11.4 o anterior, antes de iniciar la ISSU, asegúrese de que todos los grupos de redundancia estén activos solo en el nodo principal RG-0.
Después de que el sistema conmuta por error todos los grupos de redundancia RG-1+, establece el bit de conmutación por error manual y cambia todas las prioridades del nodo principal de RG-1+ a 255, independientemente de si el grupo de redundancia conmutó por error al nodo primario RG-0.
-
El nodo principal (nodo 0) valida la configuración del dispositivo para garantizar que se pueda confirmar con la nueva versión del software. Se comprueba la disponibilidad de espacio en disco para el sistema de archivos /var en ambos nodos, las configuraciones no compatibles y las tarjetas de interfaz física (PIC) no compatibles.
Si el espacio en disco disponible en cualquiera de los motores de enrutamiento es insuficiente, se produce un error en el proceso ISSU y devuelve un mensaje de error. Sin embargo, las PIC no compatibles no impiden la ISSU. El software emite una advertencia para indicar que estas PIC se reiniciarán durante la actualización. Del mismo modo, una configuración de protocolo no compatible no impide la ISSU. Sin embargo, el software emite una advertencia de que puede producirse una pérdida de paquetes para el protocolo durante la actualización.
-
Cuando la validación se realiza correctamente, el demonio de sincronización de estado del kernel (ksyncd) sincroniza el kernel en el nodo secundario (nodo 1) con el nodo 0.
-
El nodo 1 se actualiza con la nueva imagen de software. Antes de actualizarse, el nodo 1 obtiene el archivo de configuración del nodo 0 y valida la configuración para garantizar que se puede confirmar mediante la nueva versión de software. Después de actualizarse, se vuelve a sincronizar con el nodo 0.
-
El proceso de clúster de chasis (chassisd) en el nodo 0 prepara otros procesos de software para la lSSU. Cuando todos los procesos están listos, el chasis envía un mensaje a las PIC instaladas en el dispositivo.
-
El motor de reenvío de paquetes en cada concentrador PIC flexible (FPC) guarda su estado y descarga la nueva imagen de software del nodo 1. A continuación, cada motor de reenvío de paquetes envía un mensaje (unificado-listo para ISSU) al chasisd.
-
Después de recibir el mensaje (unificado y listo para ISSU) de un motor de reenvío de paquetes, el chasis envía un mensaje de reinicio a la FPC en la que reside el motor de reenvío de paquetes. El FPC se reinicia con la nueva imagen de software. Después de reiniciar la FPC, el motor de reenvío de paquetes restaura el estado de la FPC y se establece un vínculo interno de alta velocidad con el nodo 1 ejecutando el nuevo software. El chasis también se restablece con el nodo 0.
-
Después de que todos los motores de reenvío de paquetes hayan enviado un mensaje listo utilizando el chasis en el nodo 0, se preparan otros procesos de software para un cambio de nodo. El sistema está listo para un cambio en este punto.
-
Se produce el cambio de nodo y el nodo 1 se convierte en el nuevo nodo primario (hasta ahora nodo secundario 1).
-
El nuevo nodo secundario (hasta ahora nodo primario 0) ahora se actualiza a la nueva imagen de software.
Cuando ambos nodos se actualizan correctamente, la ISSU se completa.
Al actualizar un clúster de versiones que no admite el cifrado a una versión que admita cifrado, actualice el primer nodo a la nueva versión. Sin el cifrado configurado y habilitado, dos nodos con diferentes versiones aún pueden comunicarse entre sí y el servicio no se interrumpe. Después de actualizar el primer nodo, actualice el segundo nodo a la nueva versión. Los usuarios pueden decidir si activar la función de cifrado después de completar la actualización. El cifrado debe desactivarse antes de cambiar a una versión que no admita el cifrado. Esto garantiza que la comunicación entre un nodo de versión habilitado para cifrado y un nodo degradado no se interrumpa, ya que ambos ya no están cifrados.
Las directivas del motor de enrutamiento y del motor de reenvío de paquetes deben estar sincronizadas para que se confirme la configuración. Cuando se modifican las configuraciones de directivas y éstas no están sincronizadas, el sistema muestra un mensaje de error.
Como solución alternativa, debe usar el comando request security policies resync para sincronizar la configuración de las políticas de seguridad en el motor de enrutamiento y el motor de reenvío de paquetes, en caso de que observe que las directivas de seguridad no están sincronizadas después de una actualización.
Requisitos del sistema de ISSU
Puede utilizar ISSU para actualizar desde una versión de software compatible con ISSU a una versión posterior.
Para realizar una ISSU, el dispositivo debe ejecutar una versión de Junos OS que admita ISSU para la plataforma específica. Consulte la Tabla 1 para obtener información sobre la compatibilidad con la plataforma.
Dispositivo |
Versión de Junos OS |
|---|---|
| SRX5800 |
10.4R4 o posterior |
| SRX5600 |
10.4R4 o posterior |
| SRX5400 |
12.1X46-D20 o posterior |
| SRX1500 |
15.1X49-D70 o posterior |
| SRX1600 |
23.4R1 o posterior |
| SRX2300 |
23.4R1 o posterior |
| SRX4100 |
15.1X49-D80 o posterior |
| SRX4200 |
15.1X49-D80 o posterior |
| SRX4300 |
24.2R1 o posterior |
| SRX4600 |
17.4R1 o posterior |
Para obtener más información sobre la compatibilidad y las limitaciones de ISSU, consulte Limitaciones de actualización de ISSU/ICU en dispositivos de la serie SRX.
Tenga en cuenta las siguientes limitaciones relacionadas con una ISSU:
El proceso de ISSU finaliza si la versión de Junos OS especificada para la instalación es anterior a la que se ejecuta actualmente en el dispositivo.
El proceso de ISSU finaliza si la actualización especificada entra en conflicto con la configuración actual, los componentes compatibles, etc.
ISSU no admite los paquetes de aplicación de extensión desarrollados con Junos OS SDK.
ISSU no admite la degradación de versiones en todos los firewalls de la serie SRX compatibles.
ISSU falla ocasionalmente bajo una carga pesada de CPU.
Para cambiar de una versión compatible con ISSU a una versión anterior (compatible con ISSU o no), utilice el request system software add comando. A diferencia de una actualización mediante el proceso ISSU, una degradación mediante el comando puede provocar interrupciones en la request system software add red y pérdida de datos.
Le recomendamos encarecidamente que realice ISSU en las siguientes condiciones:
Cuando los ganglios primarios y secundarios están en buen estado
Durante el período de mantenimiento del sistema
Durante el período de tráfico más bajo posible
Cuando el uso de CPU del motor de enrutamiento es inferior al 40 por ciento
En los casos en que ISSU no sea compatible o recomendado, mientras se deba minimizar el tiempo de inactividad durante la actualización del sistema, se puede utilizar el procedimiento de tiempo de inactividad mínimo, consulte el artículoKB17947 de la base de conocimientos.
Actualización de ambos dispositivos en un clúster de chasis mediante ISSU
Antes de comenzar la ISSU para actualizar ambos dispositivos, tenga en cuenta las siguientes directrices:
Asegúrese de que se cumplen los siguientes requisitos de comprobación previa de ISSU:
La prioridad de todos los grupos de redundancia es mayor que 0
Todos los grupos de redundancia son primarios o secundarios en el estado
Existe suficiente espacio (el doble del tamaño de la imagen) disponible en / var/tmp
El uso de la CPU es inferior al 80% en un período de 5 segundos
Si no se cumplen los requisitos de verificación previa, ISSU terminará al principio.
Haga una copia de seguridad del software mediante el
request system snapshotcomando de cada motor de enrutamiento para realizar una copia de seguridad del software del sistema en el disco duro del dispositivo. Elrequest system snapshotcomando no se admite en plataformas SRX1500, SRX1600, SRX2300, SRX4100, SRX4200, SRX4300 y SRX4600.Si utiliza Junos OS versión 11.4 o anterior, antes de iniciar la ISSU, establezca la conmutación por error para todos los grupos de redundancia de modo que todos estén activos en un solo nodo (principal). Consulte Inicio de una conmutación por error del grupo de redundancia manual de un clúster de chasis.
Si utiliza Junos OS versión 12.1 o posterior, Junos OS conmuta automáticamente por error todos los RG al RG0 primario.
Se recomienda habilitar el reinicio correcto para los protocolos de enrutamiento antes de iniciar una ISSU.
En todos los firewalls de la serie SRX compatibles, el primer ISSU recomendado a partir de la versión es Junos OS versión 10.4R4.
La función ISSU del clúster de chasis permite que ambos dispositivos de un clúster se actualicen desde las versiones compatibles de Junos OS con un impacto en el tráfico similar al de las conmutaciones por error del grupo de redundancia.
A partir de Junos OS versión 15.1X49-D70, SRX1500 dispositivos admiten ISSU.
A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.
A partir de Junos OS versión 17.4R1, SRX4600 dispositivos admiten ISSU.
Para realizar una ISSU desde la CLI en el motor de enrutamiento2:
Si desea que los grupos de redundancia vuelvan automáticamente al nodo 0 como principal después de una actualización de software en servicio (ISSU), debe establecer la prioridad del grupo de redundancia de modo que el nodo 0 sea principal y habilitar la preempt opción. Tenga en cuenta que este método funciona para todos los grupos de redundancia, excepto el grupo de redundancia 0. Debe establecer manualmente la conmutación por error para el grupo de redundancia 0.
Para establecer la prioridad del grupo de redundancia y habilitar la preempt opción, consulte Ejemplo: Configuración de grupos de redundancia de clúster de chasis.
Para establecer manualmente la conmutación por error para un grupo de redundancia, consulte Inicio de una conmutación por error de grupo de redundancia manual de clúster de chasis.
Durante la actualización, ambos dispositivos pueden experimentar conmutaciones por error de grupo de redundancia, pero el tráfico no se interrumpe. Cada dispositivo valida el paquete y comprueba la compatibilidad de la versión antes de comenzar la actualización. Si el sistema descubre que la nueva versión del paquete no es compatible con la versión instalada actualmente, el dispositivo rechaza la actualización o le solicita que tome medidas correctivas. A veces, una sola característica no es compatible, en cuyo caso, el software de actualización le pedirá que finalice la actualización o que desactive la característica antes de comenzar la actualización.
Si desea volver a utilizar el firewall de la serie SRX como un dispositivo independiente o quitar un nodo de un clúster de chasis, asegúrese de haber finalizado el procedimiento de ISSU en ambos nodos (en caso de que se inicie el procedimiento de ISSU).
Para iniciar el proceso de ISSU en dispositivos SRX5K con motor de enrutamiento3 y en dispositivos SRX1600, SRX2300 y SRX4300:
Ejecute el comando siguiente para iniciar ISSU:
user@host> request vmhost software in-service-upgrade image-name-with-full-path
Ver también
Revertir dispositivos en un clúster de chasis después de un ISSU
Si una ISSU no se completa y solo se actualiza un dispositivo del clúster, puede revertir a la configuración anterior solo en el dispositivo actualizado emitiendo uno de los siguientes comandos en el dispositivo actualizado:
request chassis cluster in-service-upgrade abortrequest system software rollback node node-id rebootrequest system reboot
Habilitación de una conmutación por recuperación automática de nodos de clúster de chasis después de un ISSU
Si desea que los grupos de redundancia vuelvan automáticamente al nodo 0 como principal después de una actualización de software en servicio (ISSU), debe establecer la prioridad del grupo de redundancia de modo que el nodo 0 sea principal y habilitar la preempt opción. Tenga en cuenta que este método funciona para todos los grupos de redundancia, excepto el grupo de redundancia 0. Debe establecer manualmente la conmutación por error para un grupo de redundancia 0. Para establecer la prioridad del grupo de redundancia y habilitar la preempt opción, consulte Ejemplo: Configuración de grupos de redundancia de clúster de chasis. Para establecer manualmente la conmutación por error para un grupo de redundancia, consulte Inicio de una conmutación por error de grupo de redundancia manual de clúster de chasis.
Para actualizar el nodo 0 y que esté disponible en el clúster de chasis, reinicie manualmente el nodo 0. El nodo 0 no se reinicia automáticamente.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.