{"id":683,"date":"2022-05-19T17:05:04","date_gmt":"2022-05-19T15:05:04","guid":{"rendered":"http:\/\/loeilduse.fr\/?p=683"},"modified":"2022-05-20T11:13:21","modified_gmt":"2022-05-20T09:13:21","slug":"ca-demenage","status":"publish","type":"post","link":"https:\/\/loeilduse.fr\/?p=683&lang=fr","title":{"rendered":"Ca d\u00e9m\u00e9nage"},"content":{"rendered":"

\"\"<\/span><\/p>\n

 <\/p>\n

Le plus important dans un d\u00e9m\u00e9nagement de Data Center qu’il soit de OnPrem vers\/depuis le Cloud Public et\/ou de OnPrem vers le OnPrem, ce sont les donn\u00e9es, les applications et leur accessibilit\u00e9 par les utilisateurs internes et externes. Un des int\u00e9r\u00eats d\u2019un d\u00e9m\u00e9nagement de Data Center et d\u2019en profiter pour le rendre plus moderne, plus agile, plus v\u00e9loce afin d\u2019y h\u00e9berger les applications modernes \u00e0 base de container \u00e0 c\u00f4t\u00e9 des applications existantes.<\/span><\/p>\n

Dans cet article, je ne vais pas couvrir les applications fonctionnant directement sur des serveurs physiques, c’est un p\u00e9rim\u00e8tre que je ne couvre pas habituellement chez mes clients, et il ne repr\u00e9sente qu’un faible pourcentage d’application, environs moins de 10%. En revanche, je vais traiter celles s’ex\u00e9cutant sur des environnements virtualis\u00e9s, ce qui repr\u00e9sente environs pus de 90% des applications. La majorit\u00e9 des clients dispose d’hyperviseurs vSphere, certains peuvent encore avoir un peu d’Hyper-V ou de KVM mais c’est vraiment tr\u00e8s rare.<\/span><\/p>\n

Un des avantages apport\u00e9s par la virtualisation des serveurs et la facult\u00e9 de repr\u00e9senter une machine physique et de tout ce qu’elle contient (syst\u00e8me d’exploitation, Applications, configurations, donn\u00e9es, …) dans des machines virtuelles (VMs) qui sont stock\u00e9es dans des fichiers. Le d\u00e9m\u00e9nagement de ces VMs, consiste donc \u00e0 copier ces fichiers vers la nouvelle destination. Pour acc\u00e9der aux VMs copi\u00e9es, il faut les connect\u00e9s \u00e0 un r\u00e9seau si possible sans avoir \u00e0 modifier le plan d\u2019adressage IP initial car c\u2019est un travail fastidieux et risqu\u00e9, en effet certaines applications n’ont pas \u00e9t\u00e9 con\u00e7ues pour prendre en compte ce type de changement. Pour simplifier cela, il faut virtualiser le r\u00e9seau et ainsi \u00eatre capable de reproduire \u00e0 la destination ce qu\u2019il y avait sur le site initial permettant d\u2019\u00e9viter le changement d\u2019adressage IP de tous les serveurs et des applications. A noter qu\u2019il n\u2019est pas n\u00e9cessaire de virtualiser le r\u00e9seau \u00e0 source seule \u00e0 la destination suffit. Une autre m\u00e9thode aurait \u00e9t\u00e9 de reproduire physiquement et \u00e0 l’identique le r\u00e9seau \u00e0 la destination, m\u00eame si cela est possible dans un d\u00e9m\u00e9nagement de OnPrem vers OnPrem, c\u2019est impossible \u00e0 r\u00e9aliser dans un d\u00e9m\u00e9nagement vers le Cloud Public. Vous l’aurez compris, appliquer la virtualisation au r\u00e9seau comme cela a \u00e9t\u00e9 fait aux serveurs physiques permet d’\u00eatre compl\u00e9ment d\u00e9coupl\u00e9 de l’infrastructure physique et \u00eatre libre de choisir le fournisseurs mat\u00e9riel et\/ou h\u00e9bergeurs.<\/span><\/p>\n

La premi\u00e8re \u00e9tape du d\u00e9m\u00e9nagement consiste \u00e0 avoir un environnement de destination virtualis\u00e9 \u00e0 minima l’hyperviseur et le r\u00e9seau pour recevoir les VMs, il faut ensuite les transf\u00e9rer, nous avons vu que les VMs \u00e9taient des fichiers et qu’il suffisait de les copier sur la destination. C’est aussi simple que \u00e7a, cependant pour avoir un \u00e9tat coh\u00e9rent des donn\u00e9es, la copie devra se faire \u00e0 froid, c\u2019est-\u00e0-dire VMs \u00e9teintes, cela engendra une indisponibilit\u00e9 d’acc\u00e8s aux applications durant toute la dur\u00e9e de la copie. Une fois termin\u00e9e et les VMs associ\u00e9es aux bons r\u00e9seaux il faut les d\u00e9marrer \u00e0 la destination. Les copies vont \u00eatre longues et donc l’indisponibilit\u00e9 le sera aussi car il y aura une grosse volum\u00e9trie de donn\u00e9es. Une autre m\u00e9thode consiste \u00e0 utiliser des outils de r\u00e9plication qui vont r\u00e9pliquer les VMs pendant leur fonctionnement, et seulement une fois la r\u00e9plication termin\u00e9e\u00a0arr\u00eater les VMs \u00e0 la source, finir de r\u00e9pliquer les r\u00e9sidus puis d\u00e9marrer les VMs \u00e0 la destination. Ces deux m\u00e9thodes manuelles peuvent convenir pour des petits environnements mais pas s’il y a des centaines ou des milliers VMs, \u00e7a devient rapidement fastidieux. Pour encore simplifier ce processus, il est possible de tout orchestrer en utilisant un outil tel que VMware HCX que je vais d\u00e9crire et qui permet de r\u00e9pondre \u00e0 certaines questions importantes, comment faire un d\u00e9m\u00e9nagement si mes applications ne me permettent pas d’indisponibilit\u00e9 ? Comment je fais si je veux un d\u00e9m\u00e9nagement s\u00e9quentiel ? Ou encore comment tout pr\u00e9parer et le faire \u00e0 un moment pr\u00e9cis ?<\/span><\/p>\n

VMware HCX offre diff\u00e9rents types de migration :<\/span><\/p>\n