Migration de datacenter : le défi technique de Vizient pour basculer vers le cloud

Une migration complète de datacenter, de Chicago vers Dallas, exécutée en six à sept mois, avec un budget minimal et sans matériel de réserve suffisant pour absorber un arrêt prolongé d'un site: c'est le scénario qu'a dû orchestrer Dave Bradley, ingénieur cloud senior chez Vizient. Comme le relate The Register à partir d'un témoignage délivré à la conférence VMware Explore, le projet est né dans un bar, après une soirée d'équipe, pour aboutir à un basculement découpé en trois nuits, fondé sur la consolidation de charges et la réplication entre baies Pure Storage (devenues Everpure).

La contrainte initiale: pas de marge, pas de temps

Le périmètre était sans ambiguïté. Deux sites reliés par des liens 10 Gbps, des schémas d'adressage IP distincts, et un inventaire matériel incapable de porter l'ensemble des workloads pendant la durée d'une migration physique classique. La question initiale posée par la direction – « Could we shut down the Chicago datacenter in two weeks and get everything moved down to Dallas? » – illustre l'écart classique entre la perception exécutive et la réalité d'un plan de bascule.

Bradley et son équipe ont immédiatement recalé l'objectif vers un délai plus réaliste de six à sept mois, imposé par les cycles de provisioning, les fenêtres de test et la capacité à réémettre les VLANs dans le nouveau site. Le budget, lui, n'a pas bougé. La dette existante – en l'occurrence des licences VMware Site Recovery Manager (SRM) déjà acquises lors d'un précédent poste de l'ingénieur – est devenue le principal levier technique et financier du projet.

La méthode: consolider, répliquer, remapper

Le goulot d'étranglement n'était pas la bande passante, mais la densité matérielle. La solution retenue: consolider les workloads sur un sous-ensemble de serveurs et de baies Chicago, libérer du matériel, l'expédier physiquement vers Dallas pour qu'il soit prêt à réceptionner les charges au moment de la bascule. La réplication entre baies a assuré le transfert de données; SRM a absorbé le remappage d'adresses IP entre les deux schémas distincts.

Le basculement a été découpé en trois nuits successives, chacune consacrée à un périmètre distinct de l'infrastructure. La première nuit a porté sur l'environnement de développement – environ 70 VM et trois VLANs – avec des orchestrations qui arrêtaient les charges côté Chicago, puis activaient les VLANs côté Dallas. Comme l'a résumé Bradley, des points de contrôle étaient intégrés pour vérifier l'état à chaque étape avant de relancer.

Ce qu'il faut verrouiller avant une bascule contrainte

Pour les équipes confrontées à un scénario de migration sous contrainte budgétaire et matérielle, la séquence observée chez Vizient hiérarchise les priorités:

• Cartographier la dette logicielle existante: des licences déjà payées peuvent absorber la complexité technique sans ligne de coût additionnelle.
• Tester la capacité de consolidation avant de planifier le transport: la libération de matériel physique conditionne toute la suite du planning.
• Découper le périmètre en nuits étanches, avec vérification à chaque palier, plutôt que viser une bascule globale risquée.
• Anticiper le transport physique comme un risque à part entière: le logisticien comme goulot d'étranglement mérite un plan B documenté.
• Documenter les schémas d'adressage et les dépendances VLAN avant le gel du code, pas pendant l'exécution.

Le cas rappelle qu'une migration de datacenter ne se gagne pas dans la phase d'exécution, mais dans la capacité à transformer des contraintes budgétaires et matérielles en leviers techniques. La valeur ne résidait pas dans l'outil, mais dans l'inventaire préalable et l'orchestration des points de contrôle.