Avec l'arrivée de la 10.02, une nouvelle fonction liée au mécanisme VSX est également apparu : "vsx software-update"
Cette fonction permet de mettre à jour un cluster VSX en initiant l'operation uniquement à partir du switch primaire, ce dernier orchestrant l'ensemble de l'opération, de manière à réaliser une mise globale avec le minimum d'impact possible.
Le principe est le suivant :
L'administrateur passe une commande très simple sur le VSX Primary, permettant de télécharger le nouveau code a partir d'un serveur distant, et d'initier le process de mise à jour du cluster:
Switch(config)#vsx software-update <remote_server>/<version_firmware_cible> vrf <votre_vrf>
A partir de ce moment, le process de mise à jour du cluster est lancé :
Le primaire demande si vous souhaitez sauvegarder la configuration. Si vous repondez "Yes", un "write memory" est effectué sur les 2 peers du cluster.
Ensuite, l'image est téléchargée par les 2 équipements :
Ce n'est pas le primaire qui télécharge et fait une copie sur le secondaire. Ce sont bien les 2 équipements qui téléchargent le code de manière simultanée.
La nouvelle image est toujours installée dans l'image alternative a celle utilisée. Par exemple, si vous avez booté en Primary, alors l'image sera installée sur la Secondary.
Une fois le code téléchargé sur les 2 équipements, le primaire envoie l'instruction au secondaire de redémarrer :
Le statut de l'ISL passe donc à "Down", et si on regarde de plus près les évènements :
- Redemarrage du secondaire, vu du Primaire :
- Redemarrage du secondaire, vu du Secondaire :
- ISL status passant a "Down"
Dans l'hypothèse où la mise à jour du secondaire venait à mal se passer, alors tout le process de mise à jour du cluster serait interrompu.
Une fois la mise à jour sur le secondaire réalisée, que son statut est opérationnel et que VSX est correctement remonté, une synchronisation VSX est réalisée, de manière à garantir que le secondaire, lorsqu'il va reprendre son rôle, est bien à jour en termes de configuration, mais également de tables (ARP, MAC, etc...), permettant alors de garantir le niveau de résilience attendue d'un cluster VSX.
Lorsque cette synchronisation est terminée, alors le primaire redémarre à son tour - Tant que le secondaire n'a pas retrouvé un état "forwarding", alors le primaire ne redémarre pas.
Cette copie d'écran montre le dernier état avant le redémarrage du primaire lorsque l'on est connecté via SSH.
Si on est connecté en console, on trouve un autre type d'information :
Si on regarde de plus près les évènements :
Nous voyons bien ici le statut du primaire à : "Reboot started"
Le secondaire reprend donc la main pour l'ensemble des rôles, et traite l'ensemble du trafic, en attendant que le primaire ait fini de redémarrer et soit à jour.
Une fois le primaire redémarré, le process de mise à jour est terminé et le cluster VSX reformé et opérationnel.
Voici un schema recapitulatif de l'ensemble de phases :
(Merci à Vincent Giles)
Nous avons donc maintenant une procédure de mise à jour d'un cluster VSX extrêmement simple à utiliser, permettant au switch primaire d'orchestrer l'ensemble du process, et sans impact majeur sur l'environnement réseau, puisque ce mécanisme permet d'attendre les bascules avant de redémarrer un des équipements, garantissant ainsi une mise à jour encore plus transparente, et le tout en conservant toujours cette très haute résilience liée aux 2 plans de contrôle distincts d'un cluster VSX.