M2SI Services
VMware / Virtualization

VMware Cloud Foundation 9.0.x vers 9.1 : la checklist de préparation avant upgrade

Une méthode go/no-go pour préparer un upgrade VMware Cloud Foundation 9.0.x vers 9.1 : séquencement, DNS, certificats, NTP, sauvegardes, NSX et compatibilité matérielle.

25 août 20269 min de lectureInfrastructure

Un environnement VMware Cloud Foundation peut sembler sain et rester bloqué au moment de l’upgrade. Une séquence de composants incorrecte, une adresse IP manquante, un certificat NSX incomplet, une sauvegarde inutilisable ou un serveur non compatible suffit à interrompre le workflow.

Cette checklist propose une méthode go/no-go pour préparer un passage de VCF 9.0.x vers VCF 9.1. Elle ne remplace pas la documentation Broadcom applicable à la build et à la topologie concernées, et ne constitue pas un guide d’exécution complet en production.

Contexte et problème

VCF 9.1 fait intervenir plusieurs composants et workflows de lifecycle : VCF Operations, SDDC Manager, vCenter Server, ESXi, NSX, VCF Management Services et le License Server centralisé. Des composants optionnels, comme VCF Automation, VCF Operations for Networks, VCF Operations for Logs, Identity Broker, vSAN, VxRail ou VMware vDefend, peuvent ajouter leurs propres contrôles.

Le premier risque consiste donc à traiter l’opération comme une simple mise à jour logicielle. Le chemin supporté dépend notamment :

  • de la version et de la build source ;
  • de la version cible et du BOM VCF 9.1 applicable ;
  • de la présence de composants optionnels ;
  • de la configuration vSAN ;
  • de la plateforme matérielle, notamment VxRail ;
  • du workflow utilisé pour la lifecycle management.

Broadcom documente une séquence de mise à niveau pour VCF 9.1. Dans les environnements VCF 9.0.x gérés par SDDC Manager, VCF Operations doit être traité en premier lorsque le chemin applicable l’exige, avant les workflows lifecycle suivants [S1][S2]. Les workload domains peuvent ensuite être mis à niveau dans une phase Day-2 lorsque cela s’applique à la topologie.

L’objectif de la préparation n’est pas de cocher des cases sans contexte. Il est de produire des preuves permettant de répondre à trois questions :

  1. Le chemin source-cible est-il supporté ?
  2. Les prérequis techniques et opérationnels sont-ils satisfaits ?
  3. Existe-t-il un point d’arrêt ou une procédure de reprise validée pour chaque étape importante ?

Concept ou architecture

La préparation doit être organisée en six contrôles :

  1. Identifier la topologie de départ.
  2. Vérifier le chemin d’upgrade et le séquencement.
  3. Contrôler réseau, DNS, certificats et temps.
  4. Vérifier sauvegardes et capacité de reprise.
  5. Contrôler NSX et les composants optionnels.
  6. Valider matériel, firmware, drivers et interopérabilité.

Le résultat attendu est un dossier de décision contenant les versions, les résultats des prechecks, les preuves de compatibilité, les journaux et les limites de récupération connues.

Il faut distinguer deux types d’information :

  • les exigences ou workflows documentés par Broadcom pour un produit, une build ou un scénario donné ;
  • les recommandations d’exploitation destinées à réduire le risque, comme la conservation des identifiants de tâches ou la définition d’une fenêtre de maintenance.

Une checklist générale ne doit pas être présentée comme une procédure universelle. La Product Interoperability Matrix et le Broadcom Compatibility Guide doivent être interrogés avec les versions et le matériel réels [S18][S20][S21].

Prérequis

Avant de planifier la fenêtre d’upgrade, rassemblez au minimum :

  • la release et la build VCF actuelles ;
  • les versions et builds de VCF Operations et de SDDC Manager ;
  • les versions de vCenter Server, ESXi et NSX ;
  • la présence de VCF Automation, Networks, Logs et Identity Broker ;
  • la plateforme matérielle utilisée ;
  • le CIDR du management network ;
  • les adresses IP disponibles ;
  • les serveurs NTP configurés ;
  • la destination de sauvegarde et son espace libre ;
  • les règles de support ou les tickets Broadcom déjà ouverts.

Utilisez ensuite :

  • le VCF Upgrade Planner pour préparer le scénario applicable [S3] ;
  • la Product Interoperability Matrix pour vérifier les combinaisons de produits et le chemin source-cible [S18][S20] ;
  • le Broadcom Compatibility Guide pour les serveurs, BIOS, firmwares, drivers et périphériques d’I/O [S10][S21].

Conservez une capture ou un export des résultats obtenus. Une compatibilité constatée sur une version antérieure ne constitue pas automatiquement une preuve de compatibilité avec ESXi ou VCF 9.1.

Mise en pratique

1. Établir l’inventaire et le chemin supporté

Commencez par produire un tableau d’inventaire. Associez à chaque composant sa version, sa build, son rôle et son état de santé.

Identifiez notamment si l’environnement utilise encore un Fleet Management Appliance autonome, ou si le scénario implique les services Fleet Lifecycle et SDDC Lifecycle intégrés dans VCF Management Services. VCF 9.1 fait évoluer ce modèle de services par rapport à certains déploiements VCF 9.0 [S1].

Ne lancez pas le workflow tant que la source exacte et la cible exacte ne sont pas confirmées dans les outils Broadcom. Si un composant optionnel n’apparaît pas dans le scénario prévu, arrêtez la préparation et vérifiez sa documentation spécifique.

2. Contrôler le séquencement lifecycle

Appliquez le séquencement correspondant à la documentation de votre environnement :

  1. Relevez les versions, la topologie et l’état de santé.
  2. Validez le chemin d’upgrade dans la Product Interoperability Matrix.
  3. Vérifiez si VCF Operations doit être mis à niveau en premier.
  4. Confirmez la disponibilité des binaires et la configuration du depot.
  5. Préparez VCF Management Services et le License Server.
  6. Exécutez ensuite les workflows SDDC Manager et lifecycle applicables.
  7. Planifiez la mise à niveau des workload domains comme une phase ultérieure lorsque le scénario le prévoit.

Broadcom documente un cas dans lequel les binaires VCF 9.1 ne sont pas correctement visibles dans VCF Operations lorsque ce composant n’a pas été mis à niveau dans le bon ordre [S2]. Cette situation illustre pourquoi le séquencement doit être validé avant toute intervention.

3. Vérifier le réseau, les IP et le DNS

VCF Management Services nécessite un pool d’au moins 12 adresses IP sur le management network dans le scénario documenté par Broadcom. Prévoyez une capacité supplémentaire si une extension ultérieure des services est attendue [S1].

Effectuez les contrôles suivants :

  • Réservez au moins 12 adresses utilisables pour le pool concerné.
  • Vérifiez que le pool appartient bien au management network.
  • Contrôlez l’absence de chevauchement avec 198.18.0.0/15.
  • Réservez des noms DNS et des adresses uniques pour les services requis.
  • Vérifiez les enregistrements directs et inverses du License Server.
  • Contrôlez la résolution depuis les composants VCF concernés.
  • Vérifiez le conflit potentiel avec 172.17.0.0/16 lorsque le scénario License Server documenté l’identifie [S1].

Depuis un poste d’administration disposant de l’outil dig, utilisez des contrôles non destructifs :

dig +short <FQDN>
dig -x <IP_ADDRESS> +short

Un enregistrement A correct et un PTR correct ne suffisent pas à prouver que le workflow complet fonctionnera. Ils valident uniquement une partie de la chaîne DNS.

4. Contrôler la synchronisation NTP

La synchronisation temporelle doit être traitée comme un contrôle dépendant du composant, de la build et du workflow. Elle ne doit pas être présentée comme une règle identique pour toutes les topologies VCF 9.1.

Contrôlez les points suivants :

  • Identifiez les composants concernés par le workflow.
  • Relevez les serveurs NTP configurés.
  • Vérifiez leur accessibilité réseau.
  • Comparez l’heure observée sur SDDC Manager, vCenter et les composants pertinents.
  • Utilisez le dashboard NTP de VCF Operations Diagnostics lorsqu’il est disponible [S15].
  • Appliquez le critère de cinq minutes uniquement dans le périmètre de la procédure Broadcom qui le définit [S14].
  • Enregistrez l’écart constaté avant toute modification.

Broadcom documente un scénario VCF 9.x dans lequel un décalage temporel entre SDDC Manager et vCenter peut provoquer des erreurs de validation SAML ou empêcher l’accès normal à l’interface SDDC Manager [S16]. Ce seuil et ce scénario ne doivent toutefois pas être transformés en seuil universel d’upgrade.

5. Vérifier les certificats et l’inventaire NSX

Séparez le contrôle des certificats du contrôle d’état de l’inventaire.

Pour le certificat du NSX Manager Management Cluster VIP :

  1. Identifiez le FQDN utilisé par SDDC Manager.
  2. Inspectez le certificat présenté par le VIP.
  3. Vérifiez la présence du FQDN dans le Subject Alternative Name.
  4. Vérifiez les entrées IP requises par le scénario.
  5. Corrigez le certificat uniquement selon la procédure Broadcom applicable.
  6. Relancez le precheck après correction.

Broadcom documente un échec de la phase de planning NSX lorsque le certificat du VIP ne contient pas les entrées SAN nécessaires [S4].

Pour l’inventaire et les objets Edge :

  • Recherchez dans les logs les erreurs de chargement d’inventaire NSX.
  • Examinez l’état des Edge Transport Nodes et des clusters.
  • Conservez les identifiants de tâche et les journaux avant toute nouvelle tentative.
  • Vérifiez les dépendances réseau et les services associés.
  • N’effectuez pas de suppression d’objet Edge sur la seule base d’un état unhealthy.
  • Ouvrez un dossier de support lorsque la procédure applicable ou la limite d’intervention n’est pas claire.

La suppression d’un Edge peut affecter un service actif. La décision doit donc s’appuyer sur un export de configuration et sur une vérification indépendante des usages.

6. Valider les sauvegardes

La validation doit couvrir le mécanisme de sauvegarde réellement utilisé, et non l’existence théorique d’une destination.

Contrôlez les éléments suivants :

  • Identifiez la destination de sauvegarde.
  • Vérifiez la connectivité et l’authentification.
  • Contrôlez l’espace libre disponible.
  • Vérifiez la présence d’une sauvegarde récente et exploitable.
  • Identifiez le responsable d’une restauration.
  • Documentez le support attendu pour chaque composant.

Broadcom documente un échec d’upgrade VCF 9.1 lié à l’expiration du backup du composant VIDB. La documentation identifie également l’espace libre insuffisant sur le serveur de sauvegarde configuré comme cause possible d’un échec de validation [S8].

Cette information doit rester limitée à ce scénario. Elle ne signifie pas que toute saturation de sauvegarde interrompt systématiquement tous les workflows VCF.

Résultat attendu

Avant de passer en exécution, vous devez disposer d’un dossier contenant :

  • le chemin source-cible validé ;
  • l’inventaire complet des composants ;
  • les résultats des prechecks ;
  • les contrôles DNS directs et inverses ;
  • le pool IP et les éventuels chevauchements ;
  • l’état NTP et l’écart observé ;
  • les certificats et leurs SAN ;
  • les preuves de sauvegarde ;
  • les résultats de la Product Interoperability Matrix ;
  • les résultats du Compatibility Guide ;
  • les identifiants de tâches et les journaux importants.

Tout contrôle sans preuve observable doit être considéré comme incomplet.

Vérification

Les points de contrôle doivent être vérifiés dans les interfaces ou données appropriées :

  • consultez les workflows et prechecks dans SDDC Manager ou le composant lifecycle concerné ;
  • consultez le dashboard NTP de VCF Operations Diagnostics lorsque les composants sont accessibles [S15] ;
  • vérifiez les résultats directs avec dig et les résultats inverses avec dig -x ;
  • inspectez les certificats et leurs SAN dans l’interface de gestion appropriée ;
  • contrôlez les logs NSX et les détails des tâches lifecycle ;
  • vérifiez le résultat exact de la Product Interoperability Matrix ;
  • vérifiez le serveur, le BIOS, le firmware, les drivers et les périphériques d’I/O dans le Compatibility Guide.

Ne concluez pas à la réussite de l’opération à partir de la seule disparition d’un message d’erreur. Recherchez un état de tâche terminé, un precheck réussi ou une preuve de santé explicitement affichée par le produit.

Bonnes pratiques

  • Capturez les versions et les builds juste avant la fenêtre de maintenance.
  • Enregistrez les résultats des outils Broadcom pour les versions exactes.
  • Réexécutez un precheck uniquement après avoir corrigé sa cause.
  • Préservez les logs avant de redémarrer ou de nettoyer un workflow interrompu.
  • Définissez un responsable pour chaque décision go/no-go.
  • Distinguez les prérequis documentés des contrôles internes de votre organisation.
  • Préparez une procédure d’escalade avec les journaux, les task IDs et les résultats d’interopérabilité.
  • Vérifiez les composants optionnels séparément au lieu de supposer qu’ils suivent le même chemin.
  • Planifiez la capacité IP et la capacité de sauvegarde avant la fenêtre d’upgrade.

Sécurité

Les certificats, le DNS et le temps participent directement à la sécurité et à la disponibilité des échanges entre composants. Un SAN incomplet peut empêcher une communication légitime entre SDDC Manager et NSX [S4]. Un décalage horaire peut affecter la validation de timestamps SAML dans le scénario documenté par Broadcom [S16].

N’exposez pas publiquement SDDC Manager, NSX Manager, vCenter Server ou VCF Operations. Limitez les accès d’administration au réseau de management et appliquez le principe du moindre privilège.

Le contournement de validation Cloud Proxy documenté par Broadcom est conditionnel à un scénario précis [S6]. Il doit faire l’objet d’un change control, d’une justification, d’un accès privilégié contrôlé et d’une validation post-upgrade. Il ne doit pas être transformé en procédure standard.

N’insérez jamais de mot de passe, de clé privée ou de certificat de production dans un support de préparation ou dans un exemple partagé.

Coûts

Les prix des licences et abonnements VCF 9.1 ne sont pas détaillés ici.

L’upgrade peut néanmoins générer des coûts liés à :

  • l’ajout ou au remplacement de serveurs ;
  • la mise à niveau de BIOS, firmwares, adaptateurs ou contrôleurs ;
  • l’augmentation de la capacité de sauvegarde ;
  • des adresses ou ressources réseau supplémentaires ;
  • une intervention de support Broadcom ou OEM ;
  • la migration de workloads ;
  • la main-d’œuvre nécessaire à la fenêtre de maintenance.

Les résultats du Compatibility Guide peuvent conduire à remplacer un matériel ancien ou un périphérique déclaré Restricted ou End of Life. Pour ESXi 9.0, un périphérique EOL peut notamment entraîner une perte d’accès au stockage, au réseau ou à une configuration hôte antérieure [S17].

Limites et points de vigilance

La compatibilité d’un serveur ou d’un composant avec une version antérieure ne prouve pas sa compatibilité avec VCF 9.1. Les modèles de serveurs, versions de BIOS, firmwares, drivers, VIBs et périphériques d’I/O doivent être vérifiés individuellement [S10][S11][S12].

Les versions exactes de VCF 9.1, les résultats d’interopérabilité et les builds corrigées peuvent évoluer après la publication de cet article. Consultez donc les sources Broadcom avec les identifiants précis de votre environnement.

Les contrôles VCF Automation, les scénarios VxRail, vSAN et les intégrations optionnelles peuvent imposer des exigences supplémentaires. Aucun résultat générique ne doit être extrapolé à ces composants sans validation spécifique.

Rollback ou nettoyage

Il n’existe pas de procédure universelle de rollback vérifiée pour toutes les topologies et toutes les étapes d’un passage de VCF 9.0.x vers 9.1 [S1][S20][S21].

Avant l’exécution :

  • identifiez la méthode de récupération de chaque composant ;
  • confirmez les limites avec la documentation Broadcom ou un dossier de support ;
  • documentez les points d’arrêt sûrs ;
  • vérifiez les sauvegardes et leur restauration ;
  • ne considérez pas les snapshots comme une stratégie universelle de retour arrière.

Après un échec, conservez les logs et les identifiants de tâche avant toute relance. Ne supprimez pas un objet NSX Edge sans export ou sauvegarde de configuration et sans avoir confirmé qu’il ne fournit aucun service actif. Une suppression peut être irréversible du point de vue du service.

Références officielles

Conclusion

Un upgrade VCF 9.0.x vers 9.1 se prépare d’abord comme une opération de validation, pas comme une simple installation de binaires. Le go/no-go doit s’appuyer sur le chemin d’interopérabilité exact, le séquencement lifecycle, les contrôles DNS et NTP, les certificats NSX, les sauvegardes et la compatibilité matérielle.

Si une preuve manque, l’upgrade n’est pas encore prêt.