Mise à niveau logicielle en haute disponibilité multinœud
Aperçu
Les pare-feu SRX Series déployés dans une configuration MNHA peuvent être mis à niveau avec un minimum d’interruptions grâce à la mise à niveau séquentielle de chaque appareil. En fonction de l’architecture de votre équipement, utilisez l’une des commandes CLI suivantes pour lancer la mise à niveau request system software add Junos ou request vmhost software add .
| De la version de Junos OS | à la version de Junos OS Utiliser | la méthode de mise à niveau logicielle |
|---|---|---|
| 20.4 | Toute version postérieure à la version 20.4 | Non |
| 22.3 | Prochaine version 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. Utilisez la procédure de mise à niveau des noeuds isolésdans de tels cas.
-
La mise à niveau de la version 22.3 vers la version suivante peut entraîner une brève interruption du trafic.
-
Vous pouvez le voir
Peer Hardware Incompatible: SPU SLOT MISMATCHlors des mises à jour à partir de la version 21.4R1. -
Les sessions NAT ne sont pas synchronisées pendant les étapes de mise à niveau intermédiaires dans les versions antérieures à la version 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 des mises à niveau et des rétrogradations des versions de Junos OS, consultez Politique de prise en charge des mises à niveau et des rétrogradations pour les versions de Junos OS et les versions en fin de vie prolongée dans les notes de mise à jour.
Lorsque vous mettez à niveau des pare-feu SRX Series en haute disponibilité multinœud vers Junos OS version 22.4R1 ou 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 équipement SRX Series en configuration MNHA), il est recommandé de rediriger le trafic loin de l’équipement de manière contrôlée. Cela peut être fait à l’aide de l’une des méthodes suivantes :
-
Basculement manuel : déclenche un basculement manuel pour transférer le trafic vers l’appareil homologue.
-
Mode de mise à niveau logicielle : configurez temporairement l’équipement à l’aide de la commande suivante :
user@host# set chassis high-availability software-upgrade
Cette commande introduit une défaillance de périphérique avec le code d’échec SU (Software Upgrade). Par conséquent, les groupes de redondance de services (SRG) 1 et les versions ultérieures passent à l’état Non éligible (au lieu d’Actif ou de sauvegarde) sur l’appareil en cours de mise à niveau. Ainsi, le trafic associé bascule automatiquement vers l’autre membre du cluster MNHA.
Note: Si votre cluster MNHA est configuré uniquement avec SRG0 et inclut l’optioninstall-on-failure-route, vous pouvez toujours rediriger le trafic à l’aide de laset chassis high-availability software-upgradeconfiguration pour déplacer le trafic hors de l’appareil correctement.
Mise à jour logicielle
Liste de contrôle pour la préparation
Tenez compte des bonnes pratiques suivantes lorsque vous planifiez votre mise à niveau logicielle :
- Assurez-vous que les deux nœuds sont en ligne et qu’ils 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érifier la disponibilité du stockage :
show system storage - Vérifier 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.
- Sauvegardez la configuration et les clés de licence.
- Téléchargez l’image Junos OS dans /var/tmp sur les deux équipements.
- Assurez-vous que votre configuration de haute disponibilité est saine, fonctionnelle et que la liaison interchâssis (ICL) est active.
show chassis high-availability information - Préparez vos pare-feu SRX Series pour une mise à niveau à l’aide de la liste de contrôle disponible dans .
Pour plus d’informations sur la préparation de votre équipement pour une mise à niveau, reportez-vous à la section Préparation de l’installation et de la mise à niveau du logiciel (Junos OS).
Télécharger le logiciel
Téléchargez l’image Junos OS à partir de la page d’assistance de Juniper Networks sur les deux pare-feu SRX Series et enregistrez-la dans 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 équipements SRX Series configurés dans une configuration MNHA (Multinode High Availability). Dans cet exemple, le cluster se compose de deux périphériques : srx-01 (actuellement actif) et srx-02 (actuellement de secours). Le processus de mise à niveau commence par le nœud de secours (srx-02), suivi du nœud actif (srx-01), afin de minimiser les interruptions de service.
Assurez-vous que votre configuration de haute disponibilité multinœud est saine, fonctionnelle et que la liaison interchâssis (ICL) est opérationnelle.
Sur l’appareil SRX-01
user@srx-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 l’équipement SRX-02
user@srx-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 (srx-02) et validez la configuration
user@srx-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, ce qui permet au nœud homologue de prendre ou de conserver le rôle actif
- Vérifiez l’état de la haute disponibilité multinœud. La sortie affiche Node Status : OFFLINE [ SU ], ce qui indique que le noeud est prêt pour la mise à niveau logicielle. Vous pouvez voir que le statut de la SRG1 est passé à INÉLIGIBLE.
user@srx-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 (srx-01) joue un rôle actif et fonctionne normalement.
user@srx-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 le périphérique SRX-02.
user@srx-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
request system rebootcommande une fois l’installation réussie. - Vérifiez la version de Junos OS après le redémarrage.
user@srx-02> show versionHostname: srx-02 Model: vSRX Junos: 22.3R1.3La sortie confirme que l’équipement a été mis à niveau vers la version correcte de Junos OS.
- Vérifiez l’état de la haute disponibilité multinœud sur l’appareil.
user@srx-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 noeud en tant que et l’état SRG1 en tant que
OFFLINE [ SU ]INELIGIBLE. - Supprimez l’instruction
software-upgradeet validez la configuration.user@srx-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 à l’état INÉLIGIBLE. Ainsi, le nœud ne peut plus gérer le trafic pendant la mise à niveau, tant que l’homologue reste sain. -
Vérifiez à nouveau l’état de haute disponibilité multinœud 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: ONLINEl’état SRG1 en tant queBACKUP, ce qui indique que le nœud est de nouveau en ligne et fonctionne normalement en tant que rôle de secours. -
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 (SRX-01) en suivant 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 du logiciel précédemment installée.
Mise à niveau du logiciel à 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 l’install-on-failure-route. Cette route peut être référencée dans les stratégies de route pour annoncer les chemins moins privilégiés lors de scénarios de mise à niveau logicielle ou de défaillance de nœud. Dans cette méthode, vous pouvez rediriger 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é à l’itinéraire utilisé pour rediriger le trafic lors de 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 stratégie 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-existsfichier .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 faire référence à la condition en tant que 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 du logiciel 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 fonctionnalité est déconseillée (plutôt que supprimée immédiatement) afin d’assurer la shutdown-on-failure rétrocompatibilité et la possibilité 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-redundancy-group 0 shutdown-on-failure interface-name] est obsolète.
Auparavant, le trafic devait être dévié manuellement en arrêtant les interfaces. Vous pouvez désormais utiliser la commande software-upgrade pour garder le noeud hors ligne et tous les SRG à l’état INELIGIBLE pendant toute la durée de la mise à niveau. Cela permet d’isoler 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 rediriger le trafic pendant la mise à niveau.