Mise à niveau de deux châssis virtuels QFX Series
À propos de cet exemple de configuration réseau
Cet exemple de configuration réseau (NCE) montre comment mettre à niveau un châssis virtuel QFX Series à deux membres lorsque le processus de mise à niveau logicielle ininterrompue (NSSU) n’est pas disponible ou indésirable. Ce processus minimise les interruptions de service et n’a qu’un impact minimal sur les charges de travail des centres de données. La fonctionnalité NSSU de la gamme QFX Series est prise en charge entre des versions spécifiques que l’on trouve dans la section QFX Series des notes de version Junos.
Voir aussi
Présentation du cas d’utilisation
Les fonctionnalités Virtual Chassis sont des aspects importants du portefeuille QFX Series. L’un des cas d’utilisation courants de Virtual Chassis dans les centres de données consiste à agréger plusieurs commutateurs haut de baie en une seule entité logique pour simplifier la gestion et les opérations des paires de haute disponibilité. Dans ce cas d’utilisation, les racks de serveurs sont multihébergement à deux commutateurs haut de baie QFX Series. Les commutateurs sont configurés en paire Virtual Chassis et fournissent une résilience au chemin réseau en cas de défaillance de l’un des équipements QFX Series.
Lorsque ces équipements ont besoin de mises à jour logicielles, vous utilisez généralement les fonctionnalités NSSU du Virtual Chassis pour mettre à niveau les équipements. La mise à niveau du NSSU permet de mettre à niveau les équipements membres Virtual Chassis de manière intelligente afin de minimiser les interruptions de service sur les serveurs connectés.
Toutefois, il existe certains scénarios de mise à niveau dans lesquels les versions « de » et « à » ne prennent pas en charge le processus de mise à niveau NSSU. Lors d’une mise à niveau dans ces scénarios, nous pouvons obtenir un résultat similaire grâce à une série d’opérations manuelles. Ce cas d’utilisation couvre le chemin de mise à niveau non-NSSU entre deux versions.
Présentation technique
Le processus de mise à niveau manuelle d’un Virtual Chassis à deux membres imite étroitement les étapes du processus automatisé NSSU. La séquence exploite la conception haute disponibilité pour supprimer systématiquement un équipement du service pour effectuer la mise à niveau et le redémarrage. Lorsque les nœuds du serveur sont connectés à chacun des équipements, le réseau peut résister à la suppression d’un des membres Virtual Chassis pendant la période de mise à niveau. Il y a une réduction de la bande passante globale du réseau pendant le processus, mais le réseau reste disponible.
La fonctionnalité Virtual Chassis utilise un concept principal/de sauvegarde pour maintenir la synchronisation de l’état de l’équipement entre les membres du Virtual Chassis. Alors qu’un équipement gère le trafic, nous le mettons hors ligne et le mettons à niveau. Pour mettre à niveau les deux équipements, nous prenons les mesures suivantes :
Tout d’abord, nous décalons tout le trafic vers l’équipement principal.
Une fois que l’équipement de sauvegarde ne gère plus le trafic serveur, nous dédions le Virtual Chassis.
L’équipement de sauvegarde étant complètement isolé, nous mettons à niveau le logiciel sur l’équipement de sauvegarde et le redémarreons. L’équipement de sauvegarde conserve une copie de la configuration réseau d’origine.
Une fois la sauvegarde mise à niveau mise en ligne, nous décalons le trafic du serveur de l’équipement principal vers l’équipement de secours. Une fois que la sauvegarde gère la charge du réseau, nous mettons à niveau et redémarreons l’équipement principal.
Une fois l’équipement principal connecté, nous repoussons le trafic vers l’équipement principal.
Enfin, nous rétablissons les liaisons Virtual Chassis entre les deux équipements pour recréer la paire Virtual Chassis exécutant la nouvelle version du logiciel.
Exemple de configuration
Cet exemple de configuration montre comment mettre à niveau un Virtual Chassis à deux membres de Junos OS version 14.1X53-D49.1 vers Junos OS version 18.1R2.6. Il se trouve que cette combinaison n’est pas prise en charge pour la fonctionnalité NSSU, c’est pourquoi nous utiliserons le processus manuel décrit ci-dessous.
Cet exemple utilise une configuration Virtual Chassis de base, mais le processus est adaptable à un certain nombre de cas d’utilisation différents.
Exigences
Utilisez cette procédure pour mettre à niveau les deux membres d’un Virtual Chassis à deux membres comprenant des commutateurs QFX5100, QFX5110, QFX5220 ou QFX5200 vers la même version junos OS. Nous recommandons fortement que les deux membres du Virtual Chassis soient la même plate-forme, comme dans cet exemple.
Avant de commencer :
-
Si le Virtual Chassis n’est pas préprovisionné, configurez un membre pour qu’il soit le moteur de routage principal et l’autre pour qu’il soit un moteur de routage de secours
-
Assurez-vous que le Virtual Chassis est composé de deux membres
-
Configurez Virtual Chassis en mode Virtual Chassis (c’est-à-dire, pas le mode Virtual Chassis Fabric)
-
Assurez-vous que le Virtual Chassis n’exécute que des fonctions de couche 2 (c’est-à-dire qu’aucun IRB ou protocole de routage)
Cet exemple utilise les composants matériels et logiciels suivants :
-
Deux équipements QFX5100-48S-6Q exécutant Junos OS Version 14.1X53-D49.1
-
Version Junos OS 18.1R2.6
-
Serveur de test exécutant Ubuntu Linux 16.04
Aperçu
La mise à niveau entre les versions nécessite une séquence spécifique d’étapes coordonnées entre les éléments du réseau afin d’assurer un minimum d’interruption pendant la transition. Comme indiqué dans le diagramme, la procédure générale exploitera les caractéristiques de haute disponibilité des serveurs modernes avec des connexions redondantes au Virtual Chassis pendant la transition.
Au début de la mise à niveau, nous commençons par un Virtual Chassis fonctionnel à deux membres. Notre objectif est de passer à une nouvelle version de Junos OS avec un minimum de perturbation du trafic. Pour y parvenir, nous allons séparer le Virtual Chassis et mettre à niveau les équipements membres en tant qu’unités autonomes. Une fois les équipements mis à niveau, nous les connecterons à nouveau et rétablirons le Virtual Chassis.
Topologie

Configuration
Procédure
Procédure étape par étape
Pour mettre à niveau les équipements :
-
Vérifiez l’état du Virtual Chassis. Vérifiez les paramètres du Virtual Chassis et vérifiez que vous travaillez avec un Virtual Chassis à deux membres opérationnel.
{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
-
Téléchargez le nouveau logiciel aux membres Virtual Chassis. Copiez le nouveau logiciel dans /var/tmp sur les équipements principaux et de secours Virtual Chassis. Cette étape met en place un logiciel sur les deux commutateurs pour la procédure de mise à niveau. L’opération de copie prendra un certain temps pendant qu’elle transfère les images 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/
-
Nous vous recommandons de désactiver la détection fractionnée chaque fois que vous formez un Virtual Chassis avec seulement deux membres. Si vous ne désactivez pas la détection fractionnée, l’équipement principal peut jouer un rôle de carte d’interface et arrêter les plans de contrôle et de données lorsque vous désactivez le moteur de routage de secours plus tard dans cet exemple.
Depuis que vous avez commencé ce NCE avec un Virtual Chassis entièrement configuré, cette option doit déjà être configurée. Si ce n’est pas pour une raison quelconque, configurez-le maintenant.
user@qfx5100-a# set virtual-chassis no-split-detection
-
Désactivez les ports orientés serveur sur le moteur de routage de secours pour minimiser les perturbations pendant le basculement.
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
-
Désactiver les ports VCP vers le moteur de routage de secours. Cela casse le Virtual Chassis.
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
Mettez à niveau le moteur de routage de secours. Lors de la mise à niveau vers une version 18.2 ou plus récente de Junos, vous devez inclure l’option
force-host
. Cela s’ensuit que le système d’exploitation hôte et les binaires Junos sont mis à jour et restent adaptés.{master:1} user@qfx5100-b> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Permutez les ports face au serveur en désactivant les ports face au serveur sur l’équipement principal et en réactivant simultanément les ports orientés serveur sur la sauvegarde. Implémentez la même configuration sur les équipements de secours et principaux pour modifier toute configuration laissée depuis que les deux équipements faisaient partie du Virtual Chassis.
Sur le QFX de sauvegarde, commencez par désactiver les ports orientés serveur sur l’équipement principal. Ne validez pas la configuration :
user@qfx5100-b# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable
Puis activez à nouveau les ports orientés serveur sur la sauvegarde en supprimant la configuration précédente. Validez la configuration :
wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Répétez la configuration sur le 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
-
Mettez à niveau le moteur de routage principal. Lors de la mise à niveau vers une version 18.2 ou plus récente de Junos, vous devez inclure l’option
force-host
. Cela s’ensuit que le système d’exploitation hôte et les binaires Junos sont mis à jour et restent adaptés.{master:0} user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Note:
Suivez cette étape uniquement si le châssis virtuel n’a pas pré-provisionné. Si virtual Chassis est pré-provisionné, l’élection d’adhésion est basée sur la disponibilité du système si le moteur de routage principal n’est pas préconfiguré.
-
Échangez les ports du serveur vers l’équipement principal. Activez à nouveau les ports orientés serveur sur l’équipement principal pour accélérer la convergence LACP lorsque le Virtual Chassis revient. Implémentez la même configuration sur les équipements de secours et principaux pour modifier toute configuration laissée depuis que les deux équipements faisaient partie du Virtual Chassis.
Sur le QFX de sauvegarde, activez d’abord les ports orientés serveur sur l’équipement principal en supprimant la configuration précédente. Ne validez pas la configuration :
user@qfx5100-b# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable
Puis désactiver les ports côté serveur sur la sauvegarde et valider la configuration :
wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
Répétez la configuration sur le 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
-
Activez à nouveau les ports VCP des deux boîtiers pour rétablir le Virtual Chassis.
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
-
Vérifiez que vous avez rétabli le Virtual Chassis.
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
-
Activez les ports d’accès sur les deux membres. Maintenant que le Virtual Chassis a été rétabli, nous devons rétablir les ports d’accès afin de pouvoir utiliser l’adresse em0 du moteur de routage principal pour communiquer avec le Virtual Chassis récemment mis à niveau.
Sur le 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
Note:Si vous avez l’intention d’ajouter d’autres équipements à votre Virtual Chassis à deux membres, activez la détection fractionnée.
Vous avez mis à niveau votre Virtual Chassis de deux membres.
Conclusion
Virtual Chassis est une conception d’architecture importante pour la haute disponibilité des centres de données. Vous savez maintenant comment mettre à niveau manuellement un châssis virtuel QFX Series à deux membres avec un impact minimal sur vos charges de travail de centre de données. Utilisez la procédure décrite dans ce document pour mettre à niveau n’importe quel Virtual Chassis avec une topologie similaire lorsque le NSSU n’est pas disponible ou non souhaitable.