\u00ab\u00a0On va migrer le week-end, comme \u00e7a personne ne s’en rendra compte.\u00a0\u00bb C’est souvent la premi\u00e8re id\u00e9e qui vient. Et souvent la mauvaise, si tout le reste n’a pas \u00e9t\u00e9 pr\u00e9par\u00e9 en amont. Une migration sans interruption ne tient pas au timing, elle tient \u00e0 la m\u00e9thode.<\/p>\n\n
Avant de d\u00e9placer une seule machine virtuelle, il faut savoir exactement ce qui existe\u00a0: d\u00e9pendances entre serveurs, fen\u00eatres de maintenance acceptables, applications critiques qui ne tol\u00e8rent aucune coupure. C’est l’\u00e9tape la plus n\u00e9glig\u00e9e, et celle qui \u00e9vite le plus de mauvaises surprises.<\/p>\n\n
Une architecture cible claire, un planning d\u00e9taill\u00e9, et surtout une proc\u00e9dure de retour arri\u00e8re test\u00e9e \u2014 pas improvis\u00e9e le jour J si \u00e7a tourne mal. Sur une migration de 250 machines virtuelles, le plan de rollback compte autant que le plan de migration lui-m\u00eame.<\/p>\n\n
Basculer tout d’un coup maximise le risque. Migrer par lots \u2014 en commen\u00e7ant par les services les moins critiques \u2014 permet de valider la m\u00e9thode sur des enjeux faibles avant de s’attaquer aux syst\u00e8mes sensibles. Les outils de migration \u00e0 chaud (vMotion, Storage vMotion et \u00e9quivalents) permettent souvent de d\u00e9placer une charge de travail sans m\u00eame interrompre le service.<\/p>\n\n
Les premiers jours apr\u00e8s bascule sont ceux o\u00f9 les probl\u00e8mes de performance ou de configuration remontent. Une p\u00e9riode de surveillance renforc\u00e9e, avant de passer la main aux \u00e9quipes internes, \u00e9vite de d\u00e9couvrir un souci trois semaines plus tard.<\/p>\n\n
C’est cette m\u00e9thode qui m’a permis de faire migrer 250 machines virtuelles d’une plateforme VxRail\/vSphere vers une solution Huawei DCS pour un grand groupe international, sans interruption de service. Le principe reste le m\u00eame, que vous ayez 250 VMs ou 12.<\/p>\n\n