F5 : préparer un upgrade en haute disponibilité

Commencez par version actuelle, version cible, matériel ou VE, modules et contraintes de service. Le chemin supporté et les release notes déterminent si des étapes intermédiaires ou des adaptations sont requises.

Une procédure écrite pour un ancien hotfix ne décrit pas forcément une migration majeure actuelle. F5 fournit un guide d’update et d’upgrade, avec des procédures selon le type de déploiement. Utilisez la branche qui correspond à votre environnement.

Relevez licence et entitlement applicables, espace disponible, archives de sauvegarde, configuration sauvegardée et volumes de démarrage. Conservez les différences locales entre les deux appareils, pas uniquement une archive du nœud actif.

Avant toute bascule, vérifiez que le standby peut porter les traffic groups, joindre les backends et supporter la charge. Sans cette capacité, un ordre « standby d’abord » ne garantit pas la disponibilité.

BIG-IP distingue image importée, installation dans un emplacement de boot et volume actif. Un statut complete sur un volume inactif ne signifie pas que l’équipement exécute cette version.

La gestion de la copie de configuration et du démarrage doit suivre la procédure de la version. Ne synchronisez pas aveuglément des appareils qui exécutent temporairement des versions différentes pendant l’intervention.

Dans une paire compatible avec la procédure choisie, on prépare et met à jour l’appareil qui ne porte pas le trafic, on valide sa configuration et ses applications, puis on lui transfère le service de façon contrôlée avant de traiter l’autre appareil.

Cette séquence est un principe de planification, pas une garantie de zéro coupure. Les connexions longues, le mirroring, les profils et la durée de convergence réseau interviennent. En actif/actif ou N+1, relevez tous les propriétaires de traffic groups et leur capacité de reprise avant de définir l’ordre.

Le rollback doit préciser le volume précédent, la configuration associée, le placement des services et les éventuelles modifications incompatibles. Redémarrer sur un ancien volume ne garantit pas qu’une configuration modifiée sur la nouvelle version y soit utilisable.

Fixez des critères : échec de chargement, panne de service, erreurs TLS ou régression mesurée. Prévoyez aussi l’heure limite de décision, les personnes qui vérifient les applications et les informations à conserver.

Validez version et volume actif sur chaque appareil, état DSC, moniteurs, trafic, certificats, alertes et disponibilité des sauvegardes. Observez également le retour éventuel vers l’appareil préféré : l’auto-failback peut créer une nouvelle transition.

Dans le workflow TMOS à boot volumes, importer l’ISO, installer l’image sur un volume inactif, copier ou préparer la configuration puis y démarrer sont des étapes distinctes. Vérifiez l’image, sa checksum, le chemin supporté, l’espace et l’entitlement avant de commencer. Une installation propre et une mise à niveau qui reprend la configuration n’ont pas le même objectif.

La syntaxe ci-dessous illustre les étapes de changement. Le nom d’image et les volumes doivent être remplacés par ceux relevés sur la plateforme. N’utilisez pas l’option de reboot automatique si vous devez encore valider ou copier la configuration avant le démarrage. Le comportement de copie par défaut et la procédure de clean install doivent être confirmés dans le guide de votre version.

cpcfg copie la configuration d’une boot location source vers une cible dans le scénario documenté. Ce n’est pas une commande de synchronisation DSC. Gardez le volume précédent et sa configuration récupérable ; une copie depuis une version plus récente vers une ancienne n’est pas un rollback universel. Sur VIPRION, la procédure concerne les blades et la commande de reboot peut affecter le chassis.