Opération « Migration » : comment se passe le déménagement vers le cloud DataLine

Il y a environ 7 ans, les premiers projets ont migré vers notre cloud de manière simple et sans complications. Les images des machines virtuelles étaient chargées sur un serveur FTP ou étaient transportées sur des disques durs. Ensuite, via un serveur d'importation spécial, les VM étaient chargées dans le cloud.

Si pour le client il n'est pas problématique d'éteindre la machine virtuelle pendant un jour ou deux (ou s'il n'y a pas d'autres options), cela peut fonctionner ainsi. Mais si l'arrêt doit être d'une heure maximum, cette méthode ne convient pas. Aujourd'hui, je vais vous parler des outils qui aideront à migrer vers le cloud avec un minimum d'arrêt et du processus même de migration chez nous.

Migration avec Veeam Backup and Replication

Tout le monde connaît Veeam Backup and Replication comme un outil de création de sauvegardes et de réplicas. Nous l'utilisons pour migrer entre nos plateformes et pour transférer des clients de la virtualisation privée vers notre cloud. Les machines virtuelles des clients sont répliquées sur notre vCenter, après quoi les ingénieurs les ajoutent au vCloud Director.

La réplication initiale est effectuée sur la machine virtuelle allumée. À un moment convenu, la machine côté client est éteinte. La réplication est relancée pour transférer les modifications qui se sont produites depuis la première réplication. Après cela, la machine virtuelle démarre déjà dans notre cloud.

En général, depuis l'arrêt de la machine sur l'infrastructure du client jusqu'à sa mise sous tension dans notre cloud, cela ne prend pas plus de trente minutes, plutôt 15 à 20 minutes.

Au même moment, la machine virtuelle d'origine reste sur le site du client. Si quelque chose ne va pas, il est toujours possible de revenir en arrière et de la rallumer. Pour le client, cette méthode est également pratique car elle ne nécessite pas la possession de Veeam.

Cas 1
Le client avait sa propre infrastructure virtuelle basée sur VMware – 40 VM d'une capacité de 30 To. Le matériel sur lequel le cluster avait été déployé était déjà obsolète, et le client a décidé de ne pas s'engager dans l'achat de nouveau matériel et de migrer vers le cloud public. L'exigence d'arrêt des systèmes critiques était de ne pas dépasser une heure. Nous avons choisi Veeam Replication comme outil. Un avantage supplémentaire était que le fournisseur d'accès Internet du client se trouvait dans notre centre de données, ce qui a permis d'organiser un bon canal. La migration a pris environ un mois, avec un arrêt de jusqu'à 30 minutes lors du basculement pour un groupe de machines virtuelles.

Migration avec Veeam Cloud Connect

Veeam Cloud Connect – un outil qui permet de configurer la réplication des machines virtuelles et de lancer des répliques dans le cloud de l fournisseur de services. Après la mise à jour en 2019 année, il est devenu possible de répliquer les machines virtuelles directement vers vCloud Director. La seule condition est qu'un Veeam Backup and Replication de version 9 ou supérieure doit être déployé du côté du client. En résumé (version détaillée ici), le processus se déroule comme suit.

Une organisation avec les ressources et réseaux nécessaires est créée dans vCloud Director. Dans Veeam Cloud Connect, nous créons un compte, le client s'y connecte depuis son Veeam B&R, choisit le fournisseur DataLine et l'organisation, et configure les tâches de réplication. En plus du fait que la migration sera simple, durant environ 15 à 20 minutes, le client n'est pas dépendant du support technique du fournisseur et gère tout le processus de manière autonome : il crée des tâches de réplication, réalise la réplication elle-même, éteint les machines et les relance sur le nouveau site.

Cas 2
L'infrastructure du client, d'où la migration était prévue, était située en Biélorussie. Il fallait transférer 90 VM avec un volume total de 27 To, alors que la bande passante Internet était de 100 Mbit/s. Si une sauvegarde était réalisée et immédiatement envoyée vers notre cloud, cela aurait pris plusieurs jours pour certaines VM. Pendant ce temps, une grande delta aurait eu lieu sur les VM, ce qui aurait pu nuire aux performances des machines ou, pire encore, entraîner un manque d'espace sur le datastore. Nous avons agi comme suit : d'abord, le client a effectué une sauvegarde complète locale et a transféré sa copie vers notre cloud via Veeam Cloud Connect. Ensuite, il a créé et transféré un incrément dans le cloud. La machine virtuelle d'origine continuait de fonctionner. Après avoir éteint la VM, le client a également fait un autre incrément et l'a transféré dans le cloud. De notre côté, nous avons déployé la machine virtuelle à partir de la sauvegarde complète, puis intégrons les deux incréments. Ce schéma a permis de minimiser le temps d'arrêt à 2 heures lors du passage à notre site.

Migration via VMware vCloud Availability

En mars de cette année, VMware a lancé vCloud Availability 3.0, qui permet de migrer des machines virtuelles entre différents clouds (vCloud Director – vCloud Director) et depuis des environnements de virtualisation privés vers le cloud (vCenter – vCloud Director). L'un des principaux avantages est l'intégration avec l'interface de vCloud Director. Cela simplifie considérablement le processus de gestion de la réplication et minimise les temps d'arrêt lors des basculements.

Avec cet outil, nous avons migré l'un de nos clients de notre cloud de Moscou vers notre cloud à Saint-Pétersbourg. Il fallait transférer 18 machines virtuelles avec une capacité totale de 14 To. Une organisation a été créée pour le client dans le cloud de Saint-Pétersbourg et les réseaux nécessaires ont été organisés. Ensuite, depuis l'interface de vCloud Director, le client est passé aux paramètres de vCloud Availability, a créé des tâches de réplication et a basculé vers le site de Saint-Pétersbourg à un moment qui lui convenait. Le temps d'arrêt lors du basculement était de 12 minutes.

Schéma de migration entre les clouds DataLine à Saint-Pétersbourg et à Moscou.

vCloud Availability dispose d'un mécanisme de migration des VM depuis l'environnement du client vers notre cloud. Pour cela, un appliance spécifique de vCloud Availability est déployé dans le vCenter du client. Après des réglages simples, une connexion au cloud est établie et les tâches de migration sont configurées. Le client gère également tout le processus de manière autonome, et le temps de migration est réduit au minimum.

Schéma de migration des machines virtuelles d'une installation privée vers le cloud.

VMware vCloud Availability offre de nombreux autres scénarios d'utilisation, que nous aborderons bientôt dans un article séparé.

Préparation à la migration

Pour choisir l'outil et commencer réellement la migration, il faut se décider sur les points suivants :

D'où migrons-nous. Si vous migrez depuis une solution privée, vous avez toute liberté dans le choix des outils. Si vous quittez un fournisseur, cela devient plus compliqué. Il est fort probable que relier les infrastructures de deux fournisseurs et simplement déplacer les VM ne soit pas possible pour des raisons de sécurité. Parfois, le fournisseur d'où le client envisage de partir peut même commencer à faire des difficultés et à retarder le processus. Il est possible de quitter un fournisseur de manière traditionnelle : en exportant les VM sur des disques et via FTP ou en migrant au niveau de l'application. Le nom de cette dernière est conditionnel, et cela se présente généralement comme suit.

Cas 3
Il était nécessaire de migrer le système SAP d'un client depuis un fournisseur européen : 34 VMs d'une capacité de 54 To. Des ressources ont été allouées au client dans notre cloud. Une connectivité réseau a été organisée entre nous et l'infrastructure du fournisseur européen. Les serveurs d'applications ont été redéployés, avec les configurations nécessaires appliquées. Les grandes bases de données ont été migrées en chargeant des sauvegardes dans notre cloud. Par la suite, une réplication entre les bases de données sur nos sites et le site d'origine a été configurée. Au moment convenu, nous avons basculé vers les bases de données de notre cloud.

Volume de données et bande passante Internet. Nous demandons généralement au client de fournir un export des systèmes avec les paramètres de mémoire, CPU et de disque. Nous évaluons si la bande est suffisante pour envoyer directement des répliques ou des sauvegardes de machines virtuelles.

Temps d'arrêt acceptable. Pour différents systèmes et, par conséquent, différentes machines virtuelles, cela peut varier en fonction de leur criticité pour l'entreprise. En général, le client vient avec des exigences précises concernant le temps d'arrêt lors de la migration, et sur cette base, nous choisissons l'outil et le plan de migration adaptés. Nous essayons de programmer le basculement final la nuit ou pendant le week-end, afin que même un temps d'arrêt minime ne soit pas perceptible pour les utilisateurs finaux du client.

À partir de ces données, il est possible de choisir l'outil et de procéder à la migration elle-même. Voici ce qui se passe ensuite.

1. Configuration de la connectivité réseau. Nous organisons la connectivité réseau entre notre cloud et l'infrastructure du client. C'est par ce réseau que les machines virtuelles seront copiées. Si Veeam Backup and Replication est utilisé, il s'agit d'un canal dédié, rarement d'un canal VPN. Si Veeam Cloud Connect est utilisé, tout passe par Internet ou par le même canal dédié.

   Ensuite, le réseau pour les VMs dans le cloud est configuré. Les machines déménagent généralement par groupes et cela peut durer plusieurs jours. Une fois que les VMs sont déplacées chez nous et démarrées, elles doivent interagir avec les machines qui restent encore sur le site d'origine.

2. Planification de la migration. Quand il y a beaucoup de machines, il est raisonnable de les diviser en groupes et de les transporter par vagues. En collaboration avec le client, nous convenons d'un plan qui précise quand et quelles machines déménagent, et quand la réplication finale et le basculement sur le nouveau site seront réalisés.
3. Migration de test. Nous migrons une machine virtuelle de test et vérifions si tout est correctement configuré : connectivité réseau entre les sites, accessibilité de la machine virtuelle pour les machines sur le site d'origine, droits du compte et autres. Ce type de test aide à éviter les ralentissements lors de la migration en production.

C'est tout pour moi. N'hésitez pas à poser des questions dans les commentaires et à partager votre expérience de migration.

Source : habr.com