Actualización de software en un chasis virtual y un chasis virtual mixto mediante una actualización de software ininterrumpida

Antes de comenzar a instalar el nuevo software con NSSU:

• Asegúrese de que el chasis virtual esté conectado y configurado correctamente para admitir el proceso NSSU. Consulte Requisitos para realizar una NSSU.

• Compruebe que los miembros ejecutan la misma versión del software:

  Si los miembros del chasis virtual o del chasis virtual mixto no ejecutan la misma versión del software, utilice el comando para actualizar el request system software add software en los miembros incoherentes.

• Asegúrese de que el cambio normal del motor de enrutamiento (GRES) esté habilitado o, en el caso de las plataformas aplicables, asegúrese de que el enrutamiento activo sin paradas (NSR) esté habilitado, el cual también habilita el cambio normal del motor de enrutamiento. Consulte Configuración del enrutamiento activo sin paradas para obtener más información.

  Para comprobar el estado de enrutamiento activo sin paradas para comprobar que tanto NSR como GRES están habilitados:

• (Opcional para plataformas aplicables) Habilite el puente sin interrupción (NSB), lo que garantiza que todos los protocolos de capa 2 compatibles con NSB funcionen sin problemas durante el cambio del motor de enrutamiento que forma parte de la NSSU. Consulte Configuración de puentes sin interrupción en conmutadores (procedimiento de la CLI) para obtener más información.

• Para un chasis virtual de dos miembros, asegúrese de haber configurado no-split-detection de manera que el chasis virtual no se divida cuando NSSU actualice uno de los miembros. Consulte Deshabilitar división y fusión en un chasis virtual.

• En un chasis virtual QFX5100 con grupos de actualización de tarjeta de línea configurados, debe habilitar la lc-reboot-delay opción para configurar un retraso para cuando los miembros adyacentes en un grupo de tarjeta de línea se reinicien. Si no se usa esta opción, cuando se reinicie el miembro siguiente, aproximadamente dos minutos después de que el miembro anterior se reinicie y se una al chasis virtual, es posible que el miembro reiniciado anterior no esté listo para transportar tráfico. Este retraso ayuda a evitar la caída del tráfico cuando hay dos miembros de tarjeta de línea adyacentes con interfaces que forman parte de un grupo de agregación de vínculos comunes (LAG).

  Recomendamos establecer un retraso de 200 segundos (el intervalo permitido es de 0 a 600 segundos). Para configurar este retraso:

• (Opcional) Realice una copia de seguridad del software del sistema (Junos OS, la configuración activa y los archivos de registro) de cada miembro en un dispositivo de almacenamiento externo como desee mediante el request system snapshot comando.

Para actualizar a todos los miembros de un chasis virtual mediante NSSU:

1. Descargue el paquete de software tal y como se describe en Instalación de paquetes de software en dispositivos de la serie QFX. Si va a actualizar un Virtual Chasis virtual mixto, descargue los paquetes de software para los distintos tipos de conmutador.

2. Copie el o los paquetes de software en el chasis virtual. Le recomendamos que copie el archivo o los archivos al /var/tmp directorio del principal.

3. Utilice la conexión de la consola o la interfaz Ethernet de administración virtual (VME) para iniciar sesión en el chasis virtual o en el chasis virtual mixto. Puede supervisar el progreso del reinicio del conmutador principal si utiliza una conexión de consola.

4. Inicie la NSSU:

   • En un chasis virtual en el que todos los miembros utilicen la misma imagen de software, escriba:

     donde package-name.tgz es el nombre del paquete de software, por ejemplo, jinstall-qfx-3-13.2X50-D15.3-domestic-signed.tgz.

   • En un chasis virtual mixto en el que los miembros puedan utilizar imágenes de software diferentes, ingrese el request system software nonstop-upgrade comando con la opción de set especificar más de un nombre de paquete de software:

     Por ejemplo, /var/tmp/package-name1.tgz y /var/tmp/package-name2.tgz podría especificar paquetes de software para diferentes tipos de conmutadores en un chasis virtual mixto.

   El conmutador muestra mensajes de estado similares a los siguientes a medida que se ejecuta la actualización:

5. Inicie sesión después de que se complete el reinicio del conmutador principal original. Para comprobar que el software está actualizado en todos los motores de enrutamiento del chasis virtual, ingrese el siguiente comando:

6. Para asegurarse de que la función de particiones resistentes de doble raíz funcione correctamente, copie la imagen nueva de Junos OS en las particiones raíz alternativas de todos los miembros:

   Con particiones resistentes de doble raíz, el conmutador puede arrancar de forma transparente desde la partición raíz alternativa si el sistema no arranca desde la partición raíz principal.