Actualización del chasis virtual de dos miembros de la serie QFX
Acerca de este ejemplo de configuración de red
En este ejemplo de configuración de red (NCE), se muestra cómo actualizar una Chasis virtual de serie QFX de dos miembros cuando el proceso de actualización de software sin interrupciones (NSSU) no está disponible o no es deseable. Este proceso minimiza la interrupción del servicio y tiene un impacto mínimo en las cargas de trabajo del centro de datos. La función NSSU para la serie QFX se admite entre versiones específicas que se pueden encontrar en la sección de la serie QFX de las notas de la versión de Junos.
Ver también
Descripción general del caso de uso
Las capacidades del chasis virtual son aspectos importantes de la cartera de la serie QFX. Un caso de uso común del chasis virtual en los centros de datos es agregar múltiples conmutadores en la parte superior del rack en una sola entidad lógica para simplificar la administración y las operaciones de los pares de alta disponibilidad. En este caso de uso, los bastidores de servidores tienen multiconexión en dos conmutadores de la serie QFX en la parte superior del bastidor. Los conmutadores se configuran en un par de chasis virtual y proporcionan resistencia a la ruta de red si falla uno de los dispositivos de la serie QFX.
Cuando estos dispositivos necesiten actualizaciones de software, generalmente usará las capacidades NSSU del chasis virtual para actualizar los dispositivos. La actualización de NSSU actualiza selectivamente los dispositivos miembro del chasis virtual en un orden inteligente para minimizar la interrupción del servicio a los servidores conectados.
Sin embargo, hay ciertos escenarios de actualización en los que la versión "desde" y la versión "hasta" no admiten el proceso de actualización de NSSU. Al actualizar en estos escenarios, podemos lograr un resultado similar a través de una serie de operaciones manuales. Este caso de uso cubre la ruta de actualización que no es de NSSU entre dos versiones.
Descripción técnica
El proceso para actualizar manualmente un chasis virtual de dos miembros imita fielmente los pasos dados por el proceso automatizado de NSSU. La secuencia aprovecha el diseño de alta disponibilidad para eliminar sistemáticamente un dispositivo del servicio para realizar la actualización y el reinicio. Cuando los nodos del servidor tienen doble conexión con cada uno de los dispositivos, la red puede soportar la eliminación de uno de los miembros del chasis virtual durante la ventana de actualización. Hay una reducción del ancho de banda general de la red durante el proceso, pero la red permanece disponible.
La función Chasis virtual utiliza un concepto principal/de respaldo para mantener el estado del dispositivo sincronizado entre los miembros del chasis virtual. Mientras un dispositivo maneja el tráfico, desconectamos el otro dispositivo y lo actualizamos. Para actualizar ambos dispositivos, seguimos los siguientes pasos:
Primero, desplazamos todo el tráfico al dispositivo principal.
Una vez que el dispositivo de copia de seguridad ya no maneja el tráfico del servidor, separamos el chasis virtual.
Con el dispositivo de copia de seguridad completamente aislado, actualizamos el software en el dispositivo de copia de seguridad y lo reiniciamos. El dispositivo de copia de seguridad conservará una copia de la configuración de red original.
Una vez que la copia de seguridad actualizada se conecta, cambiamos el tráfico del servidor del dispositivo principal al dispositivo de copia de seguridad. Una vez que la copia de seguridad maneja la carga de red, actualizamos y reiniciamos el dispositivo principal.
Después de que el dispositivo principal se conecta, cambiamos el tráfico de nuevo al dispositivo principal.
Finalmente, volvemos a habilitar los vínculos de chasis virtual entre los dos dispositivos para volver a crear el par de chasis virtual que ejecuta la nueva versión de software.
ejemplo de configuración
En este ejemplo de configuración, se muestra cómo actualizar una Chasis virtual de dos miembros de Junos OS versión 14.1X53-D49.1 a Junos OS versión 18.1R2.6. Da la casualidad de que esta no es una combinación compatible con la función NSSU, por lo que usaremos el proceso manual que se describe a continuación.
En este ejemplo, se utiliza una configuración básica de chasis virtual, pero el proceso aquí se puede adaptar a varios casos de uso diferentes.
Requisitos
Utilice este procedimiento para actualizar ambos miembros de un conmutador Chasis virtual de dos miembros compuesto por conmutadores QFX5100, QFX5110, QFX5220 o QFX5200 a la misma versión de versión de Junos OS. Recomendamos encarecidamente que ambos miembros del chasis virtual estén en la misma plataforma, como en este ejemplo.
Antes de empezar:
-
Asegúrese de que el chasis virtual esté compuesto por dos miembros, donde uno está configurado como miembro principal y el otro como miembro de respaldo.
-
Configure el chasis virtual en el modo Chasis virtual (es decir, no en el modo de estructura del chasis virtual)
-
Asegúrese de que el chasis virtual solo esté realizando funciones de capa 2 (es decir, sin IRB ni protocolos de enrutamiento)
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Dos dispositivos QFX5100-48S-6Q con Junos OS versión 14.1X53-D49.1
-
Junos OS versión 18.1R2.6
-
Servidor de prueba que ejecuta Ubuntu Linux 16.04
Descripción general
La actualización entre versiones requiere una secuencia específica de pasos coordinados entre los elementos de red para garantizar un tiempo de inactividad mínimo durante la transición. Como se indica en el diagrama, el procedimiento general aprovechará las características de alta disponibilidad de los servidores modernos con conexiones redundantes al chasis virtual durante la transición.
Al comienzo de la actualización, comenzamos con un chasis virtual funcional de dos miembros. Nuestro objetivo es actualizar a una nueva versión de Junos OS con las mínimas interrupciones del tráfico. Para lograr esto, dividiremos el chasis virtual y actualizaremos los dispositivos miembro como unidades independientes. Una vez que se hayan actualizado los dispositivos, los volveremos a conectar y restableceremos el chasis virtual.
Topología
Configuración
Procedimiento
Procedimiento paso a paso
Para actualizar los dispositivos:
-
Verifique el estado del Chasis virtual. Compruebe los parámetros del chasis virtual y compruebe que está trabajando con un chasis virtual de dos miembros que esté operativo.
{master:0} user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Cargue el software nuevo en los miembros del chasis virtual. Copie el software nuevo en /var/tmp en los dispositivos principal y de respaldo del chasis virtual. Este paso prepara el software de ambos conmutadores para el procedimiento de actualización. La operación de copia tardará algún tiempo en completarse mientras transfiere las imágenes de Junos OS.
file copy http://server.example.com/volume/download/software/junos/18.1R2.6/jinstall-host-qfx-5-18.1R2.6-signed.tgz /var/tmp/
-
Recomendamos deshabilitar la detección de divisiones siempre que forme un chasis virtual con solo dos miembros. Si no deshabilita la detección dividida, el dispositivo principal puede asumir un rol de tarjeta de línea y detener los planos de control y datos cuando deshabilite el motor de enrutamiento de respaldo más adelante en este ejemplo.
Dado que comenzó este NCE con un Chasis virtual completamente configurado, esta opción ya debería estar configurada. Si no es por algún motivo, configúrelo ahora.
user@qfx5100-a# set virtual-chassis no-split-detection
-
Desactive los puertos orientados al servidor en el motor de enrutamiento de respaldo para minimizar las interrupciones durante el cambio.
user@qfx5100-b# wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Desactive los puertos VCP hacia el motor de enrutamiento de respaldo. Esto rompe el chasis virtual.
user@qfx5100-b> request virtual-chassis vc-port delete pic-slot 0 port 48 member 1 request virtual-chassis vc-port delete pic-slot 0 port 48 member 0
Actualice el motor de enrutamiento de respaldo. Cuando actualice a una versión de Junos 18.2 o más reciente, debe incluir la
force-hostopción. Esto garantiza que tanto el sistema operativo host como los binarios de Junos se actualicen y sigan siendo coincidentes.{master:1} user@qfx5100-b> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Intercambie los puertos orientados al servidor desactivando los puertos orientados al servidor en el dispositivo principal y volviendo a habilitar los puertos orientados al servidor en la copia de seguridad simultáneamente. Implemente la misma configuración en los dispositivos de respaldo y principales para modificar cualquier configuración sobrante de cuando los dos dispositivos formaban parte del chasis virtual.
En el QFX de respaldo, desactive primero los puertos orientados al servidor en el dispositivo principal. No confirme la configuración:
user@qfx5100-b# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable
A continuación, vuelva a habilitar los puertos orientados al servidor en la copia de seguridad eliminando la configuración anterior. Confirme la configuración:
wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Repita la configuración en el QFX principal:
user@qfx5100-a# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
-
Actualice el motor de enrutamiento principal. Cuando actualice a una versión de Junos 18.2 o más reciente, debe incluir la
force-hostopción. Esto garantiza que tanto el sistema operativo host como los binarios de Junos se actualicen y sigan siendo coincidentes.{master:0} user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Vuelva a cambiar los puertos orientados al servidor con el dispositivo principal. Vuelva a habilitar los puertos orientados al servidor en el dispositivo principal para acelerar la convergencia de LACP cuando vuelva el chasis virtual. Implemente la misma configuración en los dispositivos de respaldo y principales para modificar cualquier configuración sobrante de cuando los dos dispositivos formaban parte del chasis virtual.
En el QFX de respaldo, primero vuelva a habilitar los puertos orientados al servidor en el dispositivo principal eliminando la configuración anterior. No confirme la configuración:
user@qfx5100-b# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable
A continuación, deshabilite los puertos orientados al servidor en la copia de seguridad y confirme la configuración:
wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
Repita la configuración en el QFX principal:
user@qfx5100-a# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Vuelva a habilitar los puertos VCP en ambos dispositivos para restablecer el chasis virtual.
user@qfx5100-a> request virtual-chassis vc-port set pic-slot 0 port 48 member 0 request virtual-chassis vc-port set pic-slot 0 port 48 member 1
-
Compruebe que ha restablecido el chasis virtual.
user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Active los puertos de acceso en ambos miembros. Ahora que se restableció el chasis virtual, debemos restablecer los puertos de acceso para poder usar la dirección em0 del motor de enrutamiento principal para comunicarnos con el chasis virtual recién actualizado.
En el QFX principal:
user@qfx5100-a# wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Nota:Si desea agregar más dispositivos a su chasis virtual de dos miembros, vuelva a activar la detección de divisiones.
Actualizó su chasis virtual de dos miembros.
Conclusión
El chasis virtual es un diseño de arquitectura importante para la alta disponibilidad del centro de datos. Ahora sabe cómo actualizar manualmente un chasis virtual de la serie QFX de dos miembros con un impacto mínimo en las cargas de trabajo de su centro de datos. Utilice el procedimiento descrito en este documento para actualizar cualquier chasis virtual con una topología similar cuando NSSU no esté disponible o no se desee.