Mise à niveau des logiciels en haute disponibilité multi nodale
Lisez cette rubrique pour savoir comment effectuer une mise à niveau logicielle sur les pare-feu dans la configuration haute disponibilité multi nœud.
Vue d’ensemble
Pour obtenir la liste des fonctionnalités prises en charge sur différentes plates-formes et versions logicielles, voir Explorateur de fonctionnalités.
Les pare-feu Junos déployés dans une configuration MNHA peuvent être mis à niveau avec un minimum d’interruptions en mettant à niveau chaque équipement séquentiellement. En fonction de l’architecture de votre appareil, utilisez l’une des commandes CLI suivantes pour lancer la mise à niveau de Junos : request system software add ou request vmhost software add .
| À partir de la version de Junos OS | Vers la version de Junos OS | Utiliser la méthode de mise à niveau des logiciels |
|---|---|---|
| 20.4 | Toute version postérieure à la version 20.4 | Non |
| 22.3 | Version suivante de Junos OS | Oui |
-
Les versions 22.4R1 et ultérieures ne sont pas compatibles avec les versions antérieures de Junos OS pour la synchronisation des sessions lors d’une mise à niveau régulière. Dans ce cas, utilisez la procédure de mise à niveau des nœuds isolés.
-
Dans les déploiements de haute disponibilité multinodale (MNHA) qui utilisent des adresses IPv6 pour le chiffrement des liaisons interchâssis (ICL) (liaison HA), la mise à niveau d’une version antérieure de Junos OS vers une version prenant en charge le chiffrement ICL basé sur IPv6 nécessite l’utilisation de la procédure de mise à niveau des nœuds isolés pour garantir une transition réussie. Il s’agit d’une exigence unique lors du passage à la première version prise en charge ; Les mises à niveau ultérieures ne nécessitent pas la procédure de mise à niveau du nœud isolé.
-
La mise à niveau de la version 22.3 vers la version suivante peut entraîner de brèves interruptions du trafic.
-
Vous pouvez le voir
Peer Hardware Incompatible: SPU SLOT MISMATCHlors des mises à niveau à partir de 21.4R1. -
Les sessions NAT ne sont pas synchronisées pendant les étapes de mise à niveau intermédiaire dans les versions antérieures à 23.4R2.
-
Mettez toujours à niveau les deux nœuds vers la même version de Junos OS.
Pour plus d’informations sur la prise en charge de la mise à niveau et de la rétrogradation pour les versions de Junos OS, reportez-vous à la section Politique de prise en charge de la mise à niveau et de la rétrogradation pour les versions de Junos OS et les versions en fin de vie étendue dans les notes de mise à jour.
Lorsque vous mettez à niveau des pare-feu dans Multinode High Availability vers Junos OS version 22.4R1 ou vers une version supérieure, à partir d’une version antérieure de Junos OS, vous pouvez utiliser la procédure de mise à niveau des nœuds isolés. Les versions 22.4R1 et ultérieures de Junos OS ne sont pas compatibles avec les versions antérieures de Junos OS pour la synchronisation des sessions lors d’une mise à niveau régulière.
Avant de commencer
Avant d’effectuer une mise à niveau sur un pare-feu dans la configuration MNHA), il est recommandé de rediriger le trafic loin de l’équipement de manière contrôlée. Cela peut être fait en utilisant l’une des méthodes suivantes :
-
Basculement manuel : déclenche un basculement manuel pour transférer le trafic vers l’appareil homologue.
-
Logiciels mode de mise à niveau : configurez temporairement l’appareil à l’aide de la commande suivante :
user@host# set chassis high-availability software-upgrade
Cette commande introduit une défaillance de l’appareil avec le code d’échec utilisateur unique (Logiciels Upgrade). Par conséquent, les groupes de redondance de services (SRG) 1 et versions ultérieures passeront à l’état Inéligible (au lieu de Actif ou Sauvegarde) sur l’équipement en cours de mise à niveau. Le trafic associé bascule alors automatiquement vers l’autre membre du cluster MNHA.
Remarque : Si votre cluster MNHA est configuré avec SRG0 uniquement et inclut l’optioninstall-on-failure-route, vous pouvez toujours rediriger le trafic en utilisant laset chassis high-availability software-upgradeconfiguration pour déplacer le trafic hors de l’appareil correctement.
Mise à niveau des logiciels
Liste de contrôle de préparation
Tenez compte des bonnes pratiques suivantes lorsque vous planifiez la mise à niveau de votre logiciel :
- Assurez-vous que les deux nœuds sont en ligne et exécutent la même version de Junos OS. Vérifiez la version actuelle du logiciel Junos OS sur votre équipement à l’aide de la commande show version.
- Vérifiez la disponibilité du stockage :
show system storage - Vérifiez l’état du matériel :
show chassis fpc pic-statusshow chassis alarms
- Assurez-vous qu’il n’y a pas de modifications non validées.
- Configuration de sauvegarde et clés de licence.
- Téléchargez l’image de Junos OS sur /var/tmp sur les deux équipements.
- Assurez-vous que votre installation haute disponibilité est saine, fonctionnelle et que la liaison interchâssis (ICL) est active.
show chassis high-availability information - Préparez vos pare-feu pour une mise à niveau à l’aide de la checklist disponible dans .
Pour plus d’informations sur la préparation de votre appareil à une mise à niveau, reportez-vous à la section Préparation de l’installation et de la mise à niveau des logiciels (Junos OS).
Télécharger des logiciels
Téléchargez l’image de Junos OS à partir de la page d’assistance de Juniper Networks sur les deux pare-feu et enregistrez-la à l’emplacement /var/tmp . Exemple :
user@host> request system software add /var/tmp/junos-install-vsrx3-x86-64-22.3R1.3.tgz no-copy
Procédure de mise à niveau
Suivez les étapes de cette procédure pour mettre à niveau les pare-feu configurés dans une configuration haute disponibilité multi nodale (MNHA). Dans cet exemple, le cluster se compose de deux appareils : Pare-feu-01 (actuellement actif) et Pare-feu-02 (actuellement de secours). Le processus de mise à niveau commence par le nœud de secours (Pare-feu-02), suivi du nœud actif (Pare-feu-01), ce qui garantit une interruption de service minimale.
Assurez-vous que votre installation haute disponibilité multinodale est saine, fonctionnelle et que la liaison interchâssis (ICL) est opérationnelle.
Sur le pare-feu-01
user@Firewall-01> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: ACTIVE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: N/A Failure Events: NONE Peer Information: Peer Id: 2 Status : BACKUP Health Status: HEALTHY Failover Readiness: READYSur le pare-feu-02
user@Firewall-02> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 2 Local-IP: 10.22.0.2 HA Peer Information: Peer Id: 1 IP address: 10.22.0.1 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 1 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: BACKUP Activeness Priority: 1 Preemption: DISABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: COMPLETE Failure Events: NONE Peer Information: Peer Id: 1 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/A- Lancez le processus de mise à niveau logicielle sur le nœud de sauvegarde (Pare-feu-02) et validez la configuration
user@Firewall-02# set chassis high-availability software-upgrade
Cette commande déclenche un basculement local pour SRG0 et marque SRG1 (le cas échéant) comme INÉLIGIBLE, permettant au nœud pair de prendre ou de conserver le rôle actif
- Vérifiez l’état de la haute disponibilité multi nodale. La sortie affiche l’état du nœud : HORS LIGNE [ utilisateur unique ], ce qui indique que le nœud est prêt pour la mise à niveau logicielle. Vous pouvez voir que le statut du SRG1 est passé à INÉLIGIBLE.
user@Firewall-02> show chassis high-availability information Node failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: OFFLINE [ SU ] Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: INELIGIBLE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: N/A System Integrity Check: IN PROGRESS Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/A Vérifiez que l’autre équipement (pare-feu-01) joue un rôle actif et fonctionne normalement.
user@Firewall-01> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 2 Local-IP: 10.22.0.2 HA Peer Information: Peer Id: 1 IP address: 10.22.0.1 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 1 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: ACTIVE Activeness Priority: 1 Preemption: DISABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: N/A Failure Events: NONE Peer Information: Peer Id: 1 Status : INELIGIBLE Health Status: UNHEALTHY Failover Readiness: NOT READYLa sortie de la commande indique que l’état de SRG1 est ACTIF.
Notez que dans la
Peer Informationsection du SRG1, l’état indiqueINELIGIBLEque l’autre nœud est dans un état inéligible.- Installez le logiciel Junos OS sur l’équipement Firewall-02.
user@Firewall-02> request system software add /var/tmp/junos-install-vsrx3-x86-64-22.3R1.3.tgz no-copy
- Redémarrez l’appareil à l’aide de la commande après une
request system rebootinstallation réussie. - Vérifiez la version de Junos OS après le redémarrage.
user@Firewall-02> show versionHostname: Firewall-02 Model: vSRX Junos: 22.3R1.3La sortie confirme que l’équipement est mis à niveau vers la version correcte de Junos OS.
- Vérifiez l’état de la haute disponibilité multinodale sur l’appareil.
user@Firewall-02> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: OFFLINE [ SU ] Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: INELIGIBLE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: N/A System Integrity Check: COMPLETE Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/ALa sortie continue d’afficher l’état du nœud en tant que
OFFLINE [ SU ]et l’état SRG1 en tant queINELIGIBLE. - Supprimez l’instruction
software-upgradeet validez la configuration.user@Firewall-02# delete chassis high-availability software-upgrade
Lorsque vous supprimez l’instruction
software-upgrade, l’état de basculement du nœud et toutes les routes installées sont effacés. Tant que cette instruction n’est pas supprimée, le nœud reste hors ligne et tous les SSR restent dans l’état INÉLIGIBLE. Cela isole efficacement le nœud de la gestion du trafic pendant la mise à niveau, tant que l’homologue reste sain. -
Vérifiez à nouveau l’état Haute disponibilité multinodale pour confirmer que l’appareil est en ligne et que l’état général est sain et fonctionnel.
user@srx02> show chassis high-availability information Node failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: BACKUP Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: IN PROGRESS Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/ALa sortie affiche
Node Status: ONLINEet l’état SRG1 commeBACKUP, ce qui indique que le nœud est de nouveau en ligne et fonctionne normalement dans un rôle de sauvegarde. -
Vérifiez les interfaces, les protocoles de routage, les routes annoncées, etc. pour confirmer que votre installation fonctionne normalement.
Vous pouvez maintenant procéder à la mise à niveau de l’autre périphérique (Pare-feu-01) en utilisant la même procédure.
(Facultatif) Si vous rencontrez des problèmes et que vous ne pouvez pas terminer la mise à niveau, vous pouvez restaurer le logiciel sur l’appareil, puis redémarrer le système. Utilisez la request system software rollback commande pour restaurer la version logicielle précédemment installée.
Mettre à niveau les logiciels à l’aide de la méthode install-on-failure-route
Pour les configurations utilisant uniquement SRG0 (sans prise en charge de l’état A/B), nous vous recommandons de configurer la route d’installation en cas d’échec. Cette route peut être référencée dans les stratégies de route pour annoncer des chemins moins préférés lors de scénarios de mise à niveau logicielle ou de défaillance de nœud. Dans cette méthode, vous pouvez détourner le trafic en modifiant l’itinéraire. Ici, le trafic peut toujours passer par le nœud et l’interface reste active.
-
Créez un routeur virtuel personnalisé dédié pour l’itinéraire utilisé pour détourner le trafic pendant la mise à niveau.
set routing-instances MNHA-signal-routes instance-type virtual-router
- Configurez l’instruction
install-on-failure-routepour SRG0. Ici, vous avez configuré la route avec l’adresse IP 10.39.1.3 comme route à installer en cas de défaillance du nœud.set routing-instances MNHA-signal-routes instance-type virtual-router set chassis high-availability services-redundancy-group 0 install-on-failure-route 10.39.1.3 routing-instance MNHA-signal-routes set chassis high-availability services-redundancy-group 1 active-signal-route 10.39.1.1 routing-instance MNHA-signal-routes set chassis high-availability services-redundancy-group 1 backup-signal-route 10.39.1.2 routing-instance MNHA-signal-routes
La table de routage installe la route mentionnée dans l’instruction en cas de défaillance du nœud.
- Configurez une politique de routage correspondante et définissez une condition de stratégie basée sur l’existence de routes. Ici, vous incluez la route 10.39.1.3 comme condition de correspondance de route pour le
if-route-exists.set policy-options condition active_route_exists if-route-exists address-family inet 10.39.1.1/32 set policy-options condition active_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0 set policy-options condition backup_route_exists if-route-exists address-family inet 10.39.1.2/32 set policy-options condition backup_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0 set policy-options condition failure_route_exists if-route-exists address-family inet 10.39.1.3/32 set policy-options condition failure_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0
Créez l’instruction de stratégie pour désigner la condition comme l’un des termes correspondants.
set policy-options policy-statement mnha-route-policy term 4 from protocol static set policy-options policy-statement mnha-route-policy term 4 from protocol direct set policy-options policy-statement mnha-route-policy term 4 from condition failure_route_exists set policy-options policy-statement mnha-route-policy term 4 then metric 100 set policy-options policy-statement mnha-route-policy term 4 then accept
- Lancez la mise à niveau logicielle comme indiqué dans les étapes précédentes (Mise à niveau du Logiciel).
Méthode obsolète (interface d’arrêt en cas d’échec)
À partir de la version 24.3R1 de Junos OS, la shutdown-on-failure fonctionnalité est déconseillée (plutôt que supprimée immédiatement) pour assurer la rétrocompatibilité et permettre de mettre votre configuration en conformité avec la nouvelle configuration. Dans le cadre de cette modification, l’instruction de configuration [set chassis high-availability services-redondance-group 0 shutdown-on-failure interface-name] est devenue obsolète.
Auparavant, le trafic devait être détourné manuellement en fermant les interfaces. Vous pouvez maintenant utiliser la commande software-upgrade pour maintenir le nœud hors ligne et tous les SRG à l’état INÉLIGIBLE pendant la durée de la mise à niveau. Cela isole efficacement le nœud de la gestion du trafic.
Si vous utilisez Junos OS 22.4 ou une version antérieure, nous vous recommandons d'utiliser les anciennes méthodes pour détourner le trafic pendant la mise à niveau.