Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comprendre les mises à niveau logicielles ininterrompues sur un Virtual Chassis et un Virtual Chassis mixte

La mise à niveau logicielle non-stop (NSSU) vous permet de mettre à niveau le logiciel exécuté sur tous les commutateurs membres d’un Virtual Chassis avec un minimum d’interruption du trafic réseau pendant la mise à niveau. Cette rubrique décrit NSSU sur les Virtual Chassis EX Series et QFX Series qui prennent en charge cette fonctionnalité.

Remarque :

Étant donné que NSSU met à niveau le logiciel de chaque membre de Virtual Chassis un par un, la mise à niveau à l’aide de NSSU peut prendre plus de temps qu’une mise à niveau à l’aide de la request system software add commande.

Vous pouvez réduire la durée d’une mise à niveau en configurant des groupes de mise à niveau de carte de ligne sur des Virtual Chassis plus grands qui prennent en charge cette fonctionnalité. Le Virtual Chassis met à niveau simultanément les commutateurs membres d’un groupe de mise à niveau, ce qui réduit le temps nécessaire à la mise à niveau. Reportez-vous à la section Configuration des groupes de mise à niveau des cartes de ligne pour une mise à niveau logicielle ininterrompue.

Avantages de la NSSU

  • Pas de perturbation du plan de contrôle : NSSU utilise le basculement GRES (Graceful moteur de routage switchover ) (et le routage actif ininterrompu (NSR) sur les plates-formes applicables) pour s’assurer qu’aucune perturbation ne se produit dans le plan de contrôle. Au cours du processus de mise à niveau, le Virtual Chassis conserve les informations relatives à l’interface, au noyau et au protocole de routage.

  • Perturbation minimale du trafic réseau : NSSU minimise les perturbations du trafic réseau en mettant à niveau les commutateurs membres un par un, ce qui permet aux membres principaux et secondaires de conserver leurs rôles principal et secondaire (bien que le rôle principal change) sans perturber le trafic, et permettant au trafic de continuer à circuler à travers les membres du rôle de carte de ligne qui ne sont pas mis à niveau.

Exigences relatives à l’exécution d’une NSSU

Les exigences requises pour effectuer NSSU pour un Virtual Chassis sont les suivantes :

  • Tous les membres de Virtual Chassis et tous les moteurs de routage doivent exécuter la même version de Junos OS.

  • Vous devez activer le basculement GRES (Graceful moteur de routage switchover).

  • Vous devez activer le routage actif ininterrompu (NSR) pour les plates-formes applicables.

    Bien que le pontage sans interruption (NSB) ne soit pas obligatoire pour effectuer un NSSU, nous vous recommandons également d’activer NSB avant d’effectuer un NSSU sur les plates-formes applicables. NSB garantit que tous les protocoles de couche 2 pris en charge par NSB fonctionnent de manière transparente lorsque le moteur de routage bascule pendant NSSU. Reportez-vous à la section Configuration du pontage ininterrompu sur les commutateurs (procédure CLI).

  • Pour minimiser les interruptions du trafic, vous devez configurer les groupes d’agrégation de liens (LAG) de sorte que les liens membres de chaque LAG résident sur différents membres du Virtual Chassis, et configurer le protocole LACP (Link Aggregation Control Protocol) pour surveiller l’état des liens membres du LAG. Lorsqu’une liaison membre d’un LAG est en panne, les liaisons restantes sont actives et le trafic continue à circuler dans le LAG. Pour plus d’informations sur la configuration des LAG et LACP, consultez Configuration de l’agrégation de liens et Configuration de LACP Ethernet agrégé (procédure CLI).

    Remarque :

    Lors d’une opération NSSU, si vous essayez d’afficher l’état de l’interface LAG sur le membre principal du moteur de routage à l’aide de la show interfaces ae-ae-interface-number commande CLI, vous pouvez voir des nombres de trafic incorrects ou nuls. Pour contourner ce problème, exécutez la commande sur le membre du moteur de routage de sauvegarde si ce membre est déjà chargé et en cours d’exécution.

Configuration requise pour les membres Virtual Chassis ou Virtual Chassis mixtes mis à niveau à l’aide de NSSU :

  • Les commutateurs membres doivent être connectés dans une topologie en anneau afin qu’aucun membre ne soit isolé à la suite du redémarrage d’un autre membre. Cette topologie empêche le fractionnement du Virtual Chassis lors d’un NSSU.

  • Les commutateurs principaux et secondaires doivent être adjacents dans la topologie en anneau. L’emplacement adjacent garantit que le serveur principal et le commutateur de secours sont toujours synchronisés pendant le redémarrage des commutateurs membres dans les rôles de carte de ligne.

  • Le Virtual Chassis est préprovisionné et vous avez explicitement attribué le rôle de carte de ligne aux commutateurs membres agissant dans un rôle de carte de ligne. Les commutateurs principaux et secondaires de Virtual Chassis changent de rôle principal pendant la mise à niveau de l’un ou l’autre pendant NSSU, mais ils doivent conserver leurs rôles de moteur de routage principal et de secours, et les autres commutateurs doivent conserver leurs rôles de carte de ligne.

  • Un Virtual Chassis à deux membres doit avoir no-split-detection été configuré de manière à ce que le Virtual Chassis ne se divise pas lorsqu’un NSSU met à niveau un membre. Voir Présentation de la division et de la fusion dans un Virtual Chassis.

Fonctionnement d’un NSSU sur un Virtual Chassis et un Virtual Chassis mixte

Lorsque vous demandez un NSSU sur un Virtual Chassis ou un Virtual Chassis mixte :

  1. L’instance principale de Virtual Chassis vérifie que :

    • La sauvegarde est en ligne et exécute la même version logicielle.

    • Vous avez activé le basculement GRES (Graceful moteur de routage switchover) et, le cas échéant, le routage actif ininterrompu (NSR).

    • Vous avez utilisé une configuration préprovisionnée pour configurer Virtual Chassis.

  2. Le principal copie la nouvelle image logicielle dans la sauvegarde et les membres restants du rôle de carte de ligne dans l’ordre à l’aide de rcp.

    Pour optimiser le temps nécessaire à l’exécution d’une opération NSSU pour un Virtual Chassis, le serveur principal utilise des sessions parallèles rcp pour copier le nouveau logiciel sur plusieurs membres à la fois (plutôt que d’attendre que l’opération de copie se termine pour chaque membre avant de commencer à copier l’image logicielle sur le membre suivant). Le principal utilise un algorithme par défaut pour déterminer le nombre d’opérations de copie parallèle en fonction du nombre de membres dans le Virtual Chassis, ou vous pouvez configurer un nombre spécifique à l’aide de l’instruction rcp-count de configuration. Voir rcp-count pour plus de détails.

    Remarque :

    En cas d’échec de la copie du nouveau logiciel sur un membre, NSSU met fin au processus de mise à niveau pour l’ensemble du Virtual Chassis sans redémarrer les membres et consigne la condition d’erreur.

  3. Le serveur principal redémarre le commutateur membre de sauvegarde avec le nouveau logiciel, et la sauvegarde se resynchronise avec le commutateur principal.

  4. Le principal charge et redémarre les commutateurs membres qui jouent le rôle de carte de ligne, un par un. Le principal attend que chaque membre soit en ligne et actif en exécutant le nouveau logiciel avant de redémarrer le membre suivant.

    • Si vous avez configuré des groupes de mise à niveau, les membres Virtual Chassis du premier groupe de mise à niveau chargent la nouvelle image et redémarrent. Lorsque les membres de ce groupe de mise à niveau sont à nouveau en ligne, les membres du groupe de mise à niveau suivant chargent la nouvelle image et redémarrent. (NSSU met à niveau les groupes dans l’ordre dans lequel ils apparaissent dans la configuration.)

    • Le trafic continue de circuler à travers les autres membres pendant ce processus.

  5. Le redémarrage se poursuit jusqu’à ce que tous les membres actifs aient redémarré avec le nouveau logiciel.

    Remarque :

    Si un membre du rôle de carte de ligne ne parvient pas à redémarrer correctement, NSSU met fin au processus de mise à niveau et consigne la condition d’erreur. Dans ce cas, pour éviter l’instabilité de Virtual Chassis, vous devez soit annuler la mise à niveau partielle en restaurant l’ancien logiciel et en redémarrant les membres qui ont déjà été redémarrés avec le nouveau logiciel, soit essayer de redémarrer manuellement tous les membres avec le nouveau logiciel qui leur a été copié, afin que tous les membres se reconnectent en exécutant la même version du logiciel.

  6. Une fois que le composant principal a mis à niveau tous les membres du rôle de carte de ligne, il effectue un basculement de moteur de routage fluide et le commutateur de membre de secours mis à niveau devient le nouveau commutateur principal.

  7. Le nouveau principal met à niveau le logiciel du principal d’origine et le redémarre automatiquement. Une fois que le principal d’origine a rejoint le Virtual Chassis, vous pouvez éventuellement rétablir le rôle principal sur ce commutateur en demandant explicitement un autre basculement de moteur de routage élégant.

Limites de la NSSU

Vous ne pouvez pas utiliser NSSU pour rétrograder le logiciel, c’est-à-dire pour installer une version antérieure du logiciel à celle qui est actuellement exécutée sur le commutateur. Pour installer une version antérieure du logiciel, utilisez la request system software add commande.

Vous ne pouvez pas revenir à la version précédente du logiciel après avoir effectué une mise à niveau à l’aide de NSSU. Si vous devez revenir à la version précédente du logiciel, vous pouvez redémarrer à partir de la partition racine secondaire si vous n’avez pas déjà copié la nouvelle version du logiciel dans la partition racine secondaire.

Prise en charge des versions NSSU et Junos OS

NSSU ne fonctionne que sur certains Virtual Chassis avec notamment les versions de et vers Junos OS. Contactez le Centre d’assistance technique de Juniper Networks (JTAC) pour confirmer la prise en charge des versions à partir et à destination si vous envisagez de mettre à niveau votre Virtual Chassis à l’aide de NSSU.

Si votre Virtual Chassis exécute une version logicielle qui ne prend pas en charge NSSU ou ne prend pas en charge la combinaison des versions from et to avec NSSU, utilisez la request system software add commande pour mettre à niveau individuellement les commutateurs membres du Virtual Chassis.

Vous pouvez également vous référer à cet exemple de configuration réseau pour savoir comment mettre à niveau manuellement un Virtual Chassis QFX Series à deux membres avec un impact minimal sur le flux de trafic lorsque NSSU n’est pas pris en charge :

Présentation de la configuration et du fonctionnement de NSSU

Pour que NSSU réussisse, le Virtual Chassis et les commutateurs membres doivent répondre aux exigences de la section Exigences relatives à l’exécution d’un NSSU. NSSU n’a besoin que de ces étapes de configuration.

Si votre Virtual Chassis répond aux exigences NSSU, entrez simplement la request system software nonstop-upgrade commande pour démarrer NSSU. Voir Mise à niveau de Logiciels sur un Virtual Chassis et Virtual Chassis mixtes à l’aide d’une mise à niveau Logiciels nonstop pour plus de détails.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
14,1 X 53 À D40
(Pour Virtual Chassis QFX5100 uniquement) À partir de la version 14.1X53-D40 de Junos OS, pour optimiser le temps nécessaire à l’exécution d’une opération NSSU pour un Virtual Chassis, le serveur principal utilise des sessions parallèles rcp pour copier le nouveau logiciel sur plusieurs membres à la fois (plutôt que d’attendre la fin de l’opération de copie pour chaque membre avant de commencer à copier l’image logicielle sur le membre suivant).
14,1 X 53 À D40
À partir de la version 14.1X53-D40 de Junos OS, si une opération de copie NSSU sur un membre échoue, le serveur principal exécute une mesure supplémentaire de récupération d’erreur pour supprimer le nouveau logiciel des membres vers lesquels il a déjà été transféré.
14,1 X 53 À D40
À partir de la version 14.1X53-D40 de Junos OS, NSSU appelle automatiquement des mesures de récupération si le redémarrage échoue sur un membre du rôle de la carte de ligne, arrêtant le processus de redémarrage séquentiel et arrêtant et redémarrant l’ensemble du Virtual Chassis.