Descripción de la actualización de software sin interrupciones en un chasis virtual y un chasis virtual mixto

Beneficios de NSSU

• Sin interrupciones en el plano de control: NSSU utiliza un cambio normal del motor de enrutamiento (GRES) (y el enrutamiento activo sin paradas (NSR) en las plataformas aplicables) para garantizar que no se produzca ninguna interrupción en el plano de control. Durante el proceso de actualización, el chasis virtual conserva la información de la interfaz, el kernel y el protocolo de enrutamiento.

• Interrupción mínima del tráfico de red: NSSU minimiza la interrupción del tráfico de red mediante la actualización de los conmutadores miembro de uno en uno, lo que permite que los miembros principal y el respaldo mantengan sus roles principal y respaldo (aunque el rol principal cambiará) sin interrumpir el tráfico y permite que el tráfico siga fluyendo a través de los miembros en el rol de tarjeta de línea que no se están actualizando.

Requisitos para realizar una NSSU

Los requisitos para realizar NSSU para un chasis virtual incluyen:

• Todos los miembros del chasis virtual y todos los motores de enrutamiento deben ejecutar la misma versión de Junos OS.

• Debe habilitar el cambio del motor de enrutamiento elegante (GRES).

• Debe habilitar el enrutamiento activo sin paradas (NSR) para las plataformas aplicables.

  Aunque no se requiere un puente sin interrupción (NSB) para realizar una NSSU, también recomendamos habilitar NSB antes de realizar una NSSU en las plataformas aplicables. NSB garantiza que todos los protocolos de capa 2 compatibles con NSB funcionen sin problemas cuando el motor de enrutamiento cambia durante NSSU. Consulte Configuración de puentes sin interrupción en conmutadores (procedimiento de la CLI).

• Para minimizar la interrupción del tráfico, debe configurar los grupos de agregación de vínculos (LAG) de manera que los vínculos de miembro de cada LAG residan en diferentes miembros del chasis virtual y configurar el Protocolo de control de agregación de vínculos (LACP) para supervisar los estados de los vínculos de miembro del LAG. Cuando un vínculo miembro de un LAG está inactivo, los vínculos restantes están activos y el tráfico sigue fluyendo a través del LAG. Para obtener más información acerca de cómo configurar LAG y LACP, consulte Configurar la agregación de vínculos y Configurar LACP de Ethernet agregada (procedimiento de la CLI).

  Nota:

  Durante una operación NSSU, si intenta ver el estado de la interfaz LAG en el miembro del motor de enrutamiento principal mediante el comando de la show interfaces ae-ae-interface-number CLI, es posible que vea recuentos de tráfico incorrectos o nulos. Para solucionar este problema, ejecute el comando en el miembro del motor de enrutamiento de respaldo si ese miembro ya está cargado y en ejecución.

Requisitos para el chasis virtual o los miembros mixtos del chasis virtual que se actualizan mediante NSSU:

• Los conmutadores miembro deben estar conectados en una topología de anillo para que ningún miembro quede aislado como resultado del reinicio de otro miembro. Esta topología impide que el chasis virtual se divida durante una NSSU.

• Los conmutadores miembro principal y de respaldo deben ser adyacentes entre sí en la topología de anillo. La colocación adyacente garantiza que el principal y el respaldo estén siempre sincronizados mientras se reinician los conmutadores miembro en los roles de tarjeta de línea.

• El chasis virtual está preaprovisionado y asignó explícitamente la función de tarjeta de línea a los conmutadores miembro que actúan en una función de tarjeta de línea. Los conmutadores miembro principal y de respaldo de chasis virtual cambian de función principal mientras se actualiza uno u otro durante la NSSU, pero deben mantener sus funciones de motor de enrutamiento principal y de respaldo, y los conmutadores restantes deben mantener sus funciones de tarjeta de línea.

• Un chasis virtual de dos miembros debe haberse no-split-detection configurado de manera que el chasis virtual no se divida cuando una NSSU actualice a un miembro. Consulte Descripción de la división y fusión en un chasis virtual.

Cómo funciona una NSSU en un chasis virtual y un chasis virtual mixto

Cuando solicite una NSSU en un chasis virtual o un chasis virtual mixto:

1. El principal del chasis virtual verifica que:

   • La copia de seguridad está en línea y ejecuta la misma versión de software.

   • Habilitó el cambio del motor de enrutamiento elegante (GRES) y, si corresponde, el enrutamiento activo sin detención (NSR).

   • Utilizó una configuración preaprovisionada para configurar el chasis virtual.

2. El principal copia la imagen de software nueva en la copia de seguridad y en los miembros restantes de la función de tarjeta de línea en secuencia utilizando rcp.

   Para optimizar el tiempo necesario para completar una operación NSSU para un chasis virtual, el principal utiliza sesiones paralelas rcp para copiar el nuevo software a varios miembros a la vez (en lugar de esperar a que se complete la operación de copia en cada miembro antes de comenzar a copiar la imagen de software al siguiente miembro). El principal utiliza un algoritmo predeterminado para determinar el número de operaciones de copia paralelas en función del número de miembros del chasis virtual, o bien puede configurar un número específico mediante la rcp-count instrucción configuration. Consulte rcp-count para obtener más detalles.

   Nota:

   Si se produce un error al copiar el software nuevo en cualquier miembro, NSSU finaliza el proceso de actualización para todo el chasis virtual sin reiniciar ningún miembro y registra la condición de error.

3. El principal reinicia el conmutador miembro de respaldo con el nuevo software y el respaldo se resincroniza con el principal.

4. El principal carga y reinicia los conmutadores miembro que están en el rol de tarjeta de línea, uno a la vez. El principal espera a que cada miembro se conecte y esté activo ejecutando el nuevo software antes de reiniciar al siguiente miembro.

   • Si configuró grupos de actualización, los miembros del chasis virtual del primer grupo de actualización cargan la imagen nueva y reinician. Cuando los miembros de ese grupo de actualización vuelvan a estar en línea, los miembros del siguiente grupo de actualización cargarán la imagen nueva y reiniciarán. (NSSU actualiza los grupos en el orden en que aparecen en la configuración).

   • El tráfico sigue fluyendo a través de los otros miembros durante este proceso.

5. El reinicio continúa hasta que todos los miembros activos se hayan reiniciado con el nuevo software.

   Nota:

   Si algún miembro del rol de tarjeta de línea no se reinicia correctamente, NSSU finaliza el proceso de actualización y registra la condición de error. En este caso, para evitar la inestabilidad del chasis virtual, debe revertir la actualización parcial restaurando el software antiguo y reiniciando los miembros que ya se reiniciaron con el software nuevo, o intentar reiniciar manualmente todos los miembros con el software nuevo que se les copió, de modo que todos los miembros vuelvan a conectarse con la misma versión del software.

6. Después de que el principal haya actualizado todos los miembros en el rol de tarjeta de línea, realiza un cambio correcto del motor de enrutamiento y el conmutador de miembro de respaldo actualizado se convierte en el nuevo principal.

7. La nueva base principal actualiza el software en la base de datos principal original y lo reinicia automáticamente. Cuando el principal original se haya vuelto a unir al chasis virtual, puede revertir opcionalmente el rol principal a ese conmutador solicitando explícitamente otro cambio correcto del motor de enrutamiento.

Limitaciones de NSSU

No puede usar NSSU para degradar el software, es decir, para instalar una versión anterior del software que la que se ejecuta actualmente en el conmutador. Para instalar una versión de software anterior, use el request system software add comando.

No puede revertir a la versión de software anterior después de realizar una actualización con NSSU. Si necesita revertir a la versión de software anterior, puede reiniciar desde la partición raíz alternativa si aún no ha copiado la nueva versión de software en la partición raíz alternativa.

Soporte de versiones de NSSU y Junos OS

NSSU solo funciona en algunos chasis virtuales con versiones particulares desde y hacia Junos OS. Comuníquese con el centro de asistencia técnica de Juniper Networks (JTAC) para confirmar las versiones compatibles desde y hasta si está considerando actualizar su chasis virtual con NSSU.

Si su chasis virtual está ejecutando una versión de software que no admite NSSU o no admite la combinación de las versiones from y to con NSSU, utilice el request system software add comando para actualizar los conmutadores miembro en el chasis virtual de forma individual.

También puede consultar este ejemplo de configuración de red sobre cómo actualizar manualmente un chasis virtual de la serie QFX de dos miembros con un impacto mínimo en el flujo de tráfico cuando no se admite NSSU:

• Procedimiento de actualización del chasis virtual de la serie QFX de dos miembros

Descripción general de la configuración y operación de NSSU

Para que NSSU tenga éxito, el conmutador de chasis virtual y miembro debe cumplir los requisitos de Requisitos para realizar una NSSU. NSSU solo requiere esos pasos de configuración.

Si su chasis virtual cumple con los requisitos de NSSU, simplemente ingrese el comando para iniciar NSSU request system software nonstop-upgrade . Consulte Actualización de software en un chasis virtual y un chasis virtual mixto mediante una actualización de software sin interrupciones para obtener más información.