Considérations générales concernant la mise à niveau

Avant d'effectuer une mise à niveau de vSRX, vous devez prendre en compte les considérations suivantes :

Vous pourriez rencontrer des perturbations du réseau lors de la mise à jour de votre version d' vSRX. Pour éviter les interruptions, effectuez la mise à niveau au cours d'une fenêtre de maintenance prenant en charge les temps d'indisponibilité potentiels du réseau. La reprise en ligne n'est pas disponible tant que la mise à niveau n'est pas terminée et peut nécessiter plusieurs heures. Concernant les environnements à haute disponibilité, vos paramètres de configuration de vSRX sont migrés. Toutefois, il est recommandé d'exporter vos paramètres avant la mise à niveau.
Dans le cas d'un environnement autonome, la configuration précédente n'est pas restaurée. Vous devez donc exporter et importer votre configuration. Pour plus d'informations, voir Importation et exportation d'une configuration vSRX.
Pour un rechargement réussi sur une passerelle vSRX à haute disponibilité, le mot de passe root de la passerelle vSRX mise à disposition doit correspondre au mot de passe root défini dans le portail vSRX. En outre, vous devez activer la connexion SSH root à l'adresse IP privée de vSRX.

Vous avez défini le mot de passe dans le portail lorsque vous avez mis à disposition votre passerelle. Il peut ne pas correspondre au mot de passe actuel de la passerelle. Si le mot de passe a été modifié après la mise à disposition, connectez-vous via SSH à la passerelle vSRX et modifiez le mot de passe root pour qu'il corresponde. La vérification de l'état de préparation échoue en cas de non-concordance du mot de passe.
Ne modifiez pas la configuration vSRX lors d'un rechargement de système d'exploitation. Dès le début, le processus de mise à niveau capture un instantané de la configuration actuelle du cluster vSRX. Par conséquent, la modification de la configuration vSRX au cours du processus de mise à niveau peut entraîner une défaillance ou des résultats imprévisibles. Par exemple, les agents logiciels automatisés peuvent tenter de modifier un nœud ou les deux nœuds vSRX. Les modifications de configurations peuvent endommager le rechargement du système d'exploitation. En outre, ces modifications ne sont pas conservées si une restauration est lancée.

Avant d'effectuer une mise à niveau du rechargement du système d'exploitation sur un cluster à haute disponibilité, exécutez la commande show chassis cluster status. Les nœuds doivent être regroupés en cluster, l'un étant désigné comme principal et l'autre comme secondaire. Vérifiez qu'il n'y a pas d'erreurs de type monitor failures. Si le cluster n'est pas opérationnel avant la mise à niveau, celle-ci risque d'échouer, ce qui entraînerait une interruption prolongée du trafic.

Exemple de cluster sain :

 root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
 Monitor Failure codes:
   CS  Cold Sync monitoring        FL  Fabric Connection monitoring
   GR  GRES monitoring             HW  Hardware monitoring
   IF  Interface monitoring        IP  IP monitoring
   LB  Loopback monitoring         MB  Mbuf monitoring
   NH  Nexthop monitoring          NP  NPC monitoring
   SP  SPU monitoring              SM  Schedule monitoring
   CF  Config Sync monitoring      RE  Relinquish monitoring
   IS  IRQ storm

 Cluster ID: 2
 Node   Priority Status               Preempt Manual   Monitor-failures

 Redundancy group: 0 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 Redundancy group: 1 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 {primary:node0}

Exemple de cluster non sain avec des défaillances de surveillance :

  root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
  Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring
    SP  SPU monitoring              SM  Schedule monitoring
    CF  Config Sync monitoring
  Cluster ID: 3
  Node   Priority Status         Preempt Manual   Monitor-failures

  Redundancy group: 0 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  1        primary        no      no       None

  Redundancy group: 1 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  0        primary        no      no       CS

  {primary:node1}

Si votre compte IBM Cloud comporte plusieurs instances de passerelle vSRX dans le même pod, assurez-vous qu'une seule passerelle est mise à niveau à la fois. La mise à niveau simultanée de plusieurs vSRX peut entraîner des collisions d'IP, interrompre le processus de mise à niveau et éventuellement provoquer des incidents.
Si vous configurez votre cluster HA pour qu'il utilise des politiques de détection d'intrusion (IDP) et une base de données de signatures, il est recommandé de mettre à jour cette base de données une fois la mise à niveau terminée. Cela est dû au fait que la base de données est peut-être obsolète. Pour plus d'informations sur les mises à jour des bases de données en ligne et hors ligne, consultez la section « Détection et prévention des intrusions » sur IBM Cloud
Le processus de mise à niveau ne sauvegarde ni ne restaure les certificats d' vSRX s stockés localement sur la machine virtuelle ( VM ) faisant l'objet de la mise à niveau. Le processus de mise à niveau supprime le répertoire VM existant et en crée un nouveau, qui remplace le système de fichiers JunOS. Par exemple, un certificat local tel que IKE_POLICY_CERT doit être sauvegardé avant la mise à niveau et restauré manuellement une fois la mise à niveau terminée.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

Ubuntu Éléments à prendre en compte lors de la mise à niveau d'un hyperviseur

L' vSRX e s'exécute en tant qu' VM e sur un hyperviseur Ubuntu. En règle générale, ce système d'exploitation hyperviseur est réinstallé dans le cadre d'une mise à jour d' vSRX. Il arrive toutefois que seule la maintenance de l'hyperviseur Ubuntu soit nécessaire, par exemple pour appliquer des mises à jour du noyau, des correctifs de sécurité ou des correctifs de vulnérabilité, sans pour autant mettre à niveau la machine virtuelle vSRX elle-même.

Dans ces cas-là, la commande standard apt update suffit généralement, mais il y a quelques points importants à garder à l'esprit. La mise à niveau de l'hyperviseur d' Ubuntu s est généralement considérée comme une opération de maintenance sans risque et peut généralement être effectuée avec un impact minimal sur les machines virtuelles d' vSRX en cours d'exécution. La plupart des mises à jour de paquets, y compris celles des bibliothèques et utilitaires standard de l'espace utilisateur, ne nécessitent pas d'interrompre le fonctionnement de l' VM s invitées.

Toutefois, les administrateurs doivent examiner attentivement les paquets inclus dans une mise à niveau avant de poursuivre. Certaines mises à jour peuvent affecter la stabilité ou la connectivité des machines virtuelles en cours d'exécution jusqu'à ce que l'hyperviseur soit redémarré.

Les types de mises à jour suivants nécessitent une attention particulière :

Paquets du noyau
systemd et les mises à jour d' udev
libvirt packages
Les paquets liés à la mise en réseau, tels que l' nftables, les ponts ou d'autres composants de virtualisation réseau
qemu et les mises à jour du paquet kvm

Dans certains cas, la mise à niveau de paquets liés à la virtualisation ou au réseau alors que les machines virtuelles sont encore actives peut entraîner une dégradation de l' VM, le blocage des interfaces ou un état d' libvirt incohérent jusqu'au redémarrage du nœud de l'hyperviseur. En général, un redémarrage de l'hyperviseur d' Ubuntu s permet de rétablir un fonctionnement normal.

Lorsque vous effectuez une mise à jour de l'hyperviseur ( apt upgrade ), tenez compte des recommandations suivantes :

Vérifiez les paquets en attente avant d'appliquer les mises à jour.
Prévoyez une fenêtre de maintenance si le noyau, l' libvirt ou des composants réseau font l'objet d'une mise à niveau.
Prévoyez un redémarrage de l'hyperviseur si nécessaire.
Dans la mesure du possible, évitez d'effectuer des opérations de maintenance simultanées sur plusieurs nœuds HA.

Exemple :

apt update
apt list --upgradable
apt upgrade