Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Contrôler la résilience des chemins et la haute disponibilité dans une structure de châssis virtuelle

Cette section traite de la résilience des chemins de contrôle et de la haute disponibilité dans un VCF, et comprend les sections suivantes :

Résilience des chemins de contrôle

VCF utilise un fond de panier virtuel intrabande pour transporter le trafic de contrôle de la structure. Le logiciel du plan de contrôle utilise la résilience de chemin intégrée pour obtenir la résilience du plan de contrôle. Les topologies VCF peuvent ajouter plusieurs chemins entre deux nœuds quelconques de la structure en ajoutant des périphériques spine. par exemple, un chemin du nœud feuille 1 au nœud feuille 2 a deux chemins lorsqu’un VCF utilise deux périphériques de colonne vertébrale et quatre chemins lorsqu’un VCF utilise quatre épines. Les topologies VCF doivent être créées en tenant compte du fait que l’ajout d’équipements spine améliore les performances en fournissant plusieurs chemins pour le trafic et la résilience, car des chemins supplémentaires restent disponibles en cas de défaillance d’un périphérique spine.

Note:

Vous ne devez pas configurer plus de 64 VCP sur un seul périphérique de colonne vertébrale.

Basculement GRES (Graceful Routing Engine Switchover)

VCF est une architecture de moteur de routage double qui prend en charge le basculement GRES (Graceful Routing Engine Switchover). GRES permet au moteur de routage de secours d’assumer le rôle de moteur de routage principal sans interrompre le transfert de paquets en cas de défaillance du moteur de routage principal.

GRES préserve les informations de l’interface et du noyau afin que le trafic ne soit pas interrompu pendant un basculement. Toutefois, GRES seul ne préserve pas le plan de contrôle en cas de défaillance du moteur de routage principal. D’autres événements, tels que l’expiration des temporisateurs de protocole ou la perte des relations de voisinage, peuvent se produire lors d’un basculement de moteur de routage. Ces comportements sont atténués à l’aide de la sortie active non-stop (NSR) et du pontage non-stop (NSB), qui sont prises en charge pour VCF.

Reportez-vous à Configuration du basculement Graceful Routing Engine pour plus d’informations sur GRES dans un VCF.

Mise à niveau logicielle ininterrompue (NSSU)

La mise à niveau logicielle non-stop (NSSU) fournit un mécanisme permettant de mettre à niveau Junos OS sur les commutateurs Ethernet EX et QFX Series de Juniper Networks dans un VCF à l’aide d’une seule commande d’interface de ligne de commande (CLI) avec un minimum de perturbation du trafic. Pour les VCF qui prennent en charge NSSU, la fonctionnalité nécessite des moteurs de routage redondants actifs pour mettre à niveau correctement le VCF, et le VCF doit être préprovisionné.

NSSU exploite les fonctionnalités de haute disponibilité sous-jacentes telles que GRES, NSR et NSB pour permettre la mise à niveau de la version de Junos OS exécutée sur un commutateur ou dans une configuration VCF sans perturbation du plan de contrôle ni interruption mineure du plan de données en moins d’une seconde. NSSU met à niveau les commutateurs membres individuellement, ce qui permet au trafic de continuer à circuler à travers les commutateurs de carte de ligne qui ne sont pas mis à niveau. En configurant les groupes d’agrégation de liens (LAG) de telle sorte que les liens membres résident sur différents commutateurs membres, il est possible d’obtenir peu ou pas de perturbation du trafic en moins d’une seconde sur votre VCF lors de l’exécution d’une NSSU.

Reportez-vous à la section Understanding Nonstop Software Upgrade on a Virtual Chassis Fabric pour plus d’informations sur la NSSU dans un VCF.