Le live patch ESX a séparé les correctifs applicables en mémoire de ceux qui exigent un reboot. Cet article traite la seconde pile. Sur vSAN, « rolling » ne veut pas dire automatique ni sans risque : cela veut dire un hôte à la fois, avec une redondance, une capacité et un placement de données à protéger à chaque étape.
Le fil rouge reste Nordwind Logistics. CHG-2026-0742 traverse trois clusters ESA : un edge de quatre hôtes, une production de huit hôtes répartis sur quatre fault domains, puis un cluster étiré Paris–Lille avec témoin.
Contrat de sincérité
La documentation chargée ne décrit pas un rolling ESA différent d’un rolling OSA. Elle documente la procédure vSAN et, séparément, l’architecture ESA. Aucun lab n’a mesuré de durée ni observé le comportement du témoin. Cela ne bloque pas le runbook : les points dépendants de la plateforme sont signalés et doivent être vérifiés sur un environnement de test avant exécution.
TL;DR
- vLCM remédie un cluster vSAN séquentiellement, avec un seul hôte en maintenance mode ; les fault domains puis les sites imposent l’ordre de progression.
Ensure accessibilitymaintient l’accès mais réduit la redondance ;Full data migrationmaintient la conformité des objets au prix d’une évacuation complète et peut échouer faute de marge.- L’action du lundi matin consiste à exécuter le Data Migration Pre-check par hôte et par mode, puis à écrire un critère d’arrêt entre deux hôtes avant d’ouvrir la fenêtre.
Un rolling dépend de trois couches
Le workflow n’échoue pas toujours dans la couche que l’on surveille. Trois contraintes indépendantes s’empilent.
- vSphere Lifecycle Manager impose une remédiation séquentielle sur vSAN. Avec des fault domains, il traite tous les hôtes d’un domaine avant le suivant. Sur un cluster étiré, il traite le site préféré puis le site secondaire.
- vSAN choisit ce qui arrive aux composants de données quand l’hôte entre en maintenance mode.
- Le placement réel décide si l’évacuation est possible : politique FTT, RAID effectif, fault domains disponibles et capacité libre.
La procédure d’upgrade vSAN ajoute une contrainte chronologique forte : vCenter d’abord, les hôtes ESX ensuite, puis le format disque en dernier. La documentation avertit qu’un ordre différent expose à la perte de données et à l’échec du cluster. Si vCenter n’est pas à la cible, le rolling ne commence pas.
change: CHG-2026-0742
window: MW-2026-Q3-01
instance: vcf-par-01
target_version: collect_from_release_plan
current_esx_build: collect_from_cluster
target_esx_build: collect_from_release_plan
scope:
- cl-fret-edge-01
- cl-fret-prod-01
- cl-fret-dr-01RECONSTITUTION — ESA n'a pas un runbook séparé
La mécanique publiée ne distingue pas ESA et OSA. ESA utilise un storage pool par hôte, mais aucune source chargée ne promet une évacuation plus rapide ni un comportement de rolling particulier. Les gains de temps doivent être mesurés sur le parc, pas déduits de l’architecture.
Choisir le mode d’évacuation en connaissance de cause
Les trois modes vSAN répondent à des objectifs différents.
| Mode | Comportement documenté | Dette créée |
|---|---|---|
| Ensure accessibility | déplace juste assez de données pour garder chaque objet accessible | redondance réduite pendant le traitement de l’hôte |
| Full data migration | évacue toutes les données et maintient l’état de conformité des objets | trafic complet, besoin de capacité, échec possible |
| No data migration | ne déplace aucune donnée | des VM peuvent devenir inaccessibles ; hors parcours production |
La remédiation vLCM utilise par défaut Ensure accessibility. Le mot est précis : les objets restent accessibles, mais une panne concomitante peut les rendre indisponibles jusqu’au retour d’un hôte. « Disponible » ne signifie donc pas « protégé ».
Full data migration conserve la conformité à la politique, mais déclenche une resynchronisation. Si vSAN ne peut pas replacer tous les composants sans violer les politiques, l’entrée en maintenance mode échoue avec un manque de nœuds ou de disques. Changer de mode pour faire passer la fenêtre revient à changer le risque accepté ; cette décision doit être écrite.
| Cluster | Mode à qualifier | Risque principal | Décision |
|---|---|---|---|
cl-fret-edge-01, 4 hôtes |
Ensure accessibility |
faible marge pendant l’absence d’un hôte | à trancher en revue de changement |
cl-fret-prod-01, 8 hôtes, 4 FD |
Full data migration |
évacuation impossible si capacité ou placement insuffisants | à trancher en revue de changement |
cl-fret-dr-01, stretched |
à trancher | réserve automatique non supportée, témoin non qualifié | à trancher en revue de changement |
À_VALIDER_EN_LAB — RAID et topologie
VCF 9.1 annonce RAID-6 comme défaut ESA, tandis que la documentation exige au moins six fault domains pour RAID-6. cl-fret-prod-01 n’en déclare que quatre. La politique effective doit être relevée avant la fenêtre ; elle ne peut pas être déduite du défaut produit.
Refuser la fenêtre avant de la planifier
Un rolling sans marge échoue au premier hôte ou, plus dangereusement, laisse un hôte qui ne ressort pas de maintenance mode. Trois contrôles en lecture seule précèdent tout calendrier.
- Capacité libre réelle. Lire la capacité physiquement consommée, l’espace libre et les réserves, pas seulement la taille logique du datastore.
- Resynchronisation résiduelle. Un operations usage non nul signifie que le cluster ouvre la fenêtre avec une dette déjà active.
- Santé et compatibilité. Le remediation pre-check vSAN inclut un contrôle de santé et une vérification de compatibilité matérielle.
HYPOTHÈSE_DE_DESIGN
Si un seul de ces contrôles n’est pas au vert, Nordwind annule la fenêtre au lieu d’en réduire le périmètre. Cette règle est une décision d’exploitation, pas une prescription Broadcom.
Le Data Migration Pre-check répond ensuite à la question exacte : quel serait l’impact de chaque mode pour l’hôte candidat ? Il expose les objets qui auraient un problème, l’effet avant/après sur la capacité et les contrôles de santé susceptibles de changer. La recherche n’a trouvé ni export de masse ni procédure 9.1 scriptée ; le parcours conservateur reste donc hôte par hôte.
before_window:
capacity_margin: collect_before_window
operations_usage: collect_before_window
resyncing_objects: collect_before_window
vsan_health: collect_before_window
hardware_compatibility: collect_before_window
data_migration_precheck:
host: evaluate_each_host
mode: evaluate_each_mode
objects_at_risk: collect_from_precheckDérouler un hôte, puis décider du suivant
Quick Boot peut raccourcir le reboot en sautant l’initialisation BIOS ou UEFI. Il ne supprime ni le maintenance mode ni l’évacuation. Suspend-to-memory est réservé au patch et ne s’applique pas à un upgrade de version ; plusieurs VM d’infrastructure, dont les témoins vSAN, en sont exclues.
À_VALIDER_EN_LAB — témoin stretched
Les sources décrivent la progression du site préféré vers le site secondaire, mais pas le traitement de wit-fret-01 pendant ce cycle. Le témoin ne doit recevoir aucune procédure inventée. Son comportement est à relever sur l’environnement cible.
Entre l’hôte N et l’hôte N+1, Nordwind utilise une porte plus stricte que celle documentée par l’orchestrateur :
gate_between_hosts:
- condition: "hôte N conforme à son image"
evidence: DOCUMENTÉ
- condition: "bytes left to resync = 0"
evidence: HYPOTHÈSE_DE_DESIGN
- condition: "aucune nouvelle alerte de santé vSAN"
evidence: HYPOTHÈSE_DE_DESIGNLa conformité à l’image dit que le logiciel est aligné. Elle ne dit pas que les objets respectent leur politique. Inversement, une resynchronisation terminée ne prouve pas que l’hôte a atteint l’image cible. Les deux preuves sont nécessaires.
RÉSULTAT_ATTENDU : Bytes left to resync décroît entre deux hôtes et revient à zéro avant la reprise. Un plateau durable est un signal d’arrêt. Aucune source Broadcom ne rend ce seuil obligatoire : c’est une règle d’exploitation à valider sur le lab.
Finir par le format disque
Le format disque ferme la chaîne, après vCenter et tous les hôtes. Ses prérequis sont explicites : disques sains, aucune reconstruction en cours et aucun hôte en maintenance mode. Le Pre-check Upgrade vérifie les hôtes, les disques, le réseau et les objets.
L’opération est optionnelle mais recommandée pour bénéficier du format courant. Elle peut générer une resynchronisation temporaire et consommer de l’espace supplémentaire. C’est donc une seconde opération de données, pas la dernière case anodine d’un workflow réussi.
Pièges à éviter
Ne pas utiliser No data migration pour sauver le planning. Ne pas appeler Ensure accessibility conforme ou redondant. Ne pas cumuler rolling hôte et upgrade de format disque sans refaire les contrôles de capacité. Ne pas annoncer de durée avant une mesure sur les données réelles.
Incidents et preuves
| Symptôme | Première couche à contrôler | Décision |
|---|---|---|
| l’hôte n’entre pas en maintenance mode | Data Migration Pre-check, objets et capacité | rétablir la marge ou réarbitrer le mode |
| l’hôte ne se vide pas | DRS et chemin d’évacuation des VM | vMotion manuelle ou arrêt planifié |
| l’hôte ne ressort pas | santé, politiques et composants vSAN | arrêter avant l’hôte suivant |
| la resynchronisation plafonne | réseau, capacité, reconstruction concurrente | suspendre la progression |
| l’hôte est Incompatible | image et compatibilité matérielle | sortir l’hôte du lot |
La preuve finale doit couvrir quatre plans : précheck de migration sans objet à risque, un seul hôte en maintenance mode, hôte revenu Compliant, puis objets conformes avec resynchronisation terminée. Après un arrêt de fenêtre, aucun hôte ne doit rester en maintenance mode et la liste des cibles non traitées doit alimenter le runbook de reprise LCM.
Conclusion
Un hôte à la fois
Le séquencement vSAN n’est pas un réglage de performance. C’est la limite de sécurité du rolling.
Le mode porte le risque
Accessibilité et conformité ne sont pas synonymes ; l’arbitrage doit figurer dans le changement.
Deux conformités
L’image prouve le logiciel, les objets prouvent le placement. Une seule vue ne ferme pas la fenêtre.
Le rolling est terminé ou explicitement interrompu. Dans les deux cas, l’étape suivante consiste à lire l’état réel du parc avant toute relance : VCF LCM, workflows bout-en-bout et reprise sur incident.
Sources principales : spécificités de remédiation des clusters vSAN, Data Migration Pre-check, modes de maintenance vSAN, suivi des resynchronisations et upgrade du format disque.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
