Opération « Migration » : comment passer vers le cloud DataLine

Il y a environ 7 ans, les tout premiers projets ont migré vers notre cloud de manière simple et sans prétention. Les images de machines virtuelles étaient téléchargées sur un serveur FTP ou livrées sur des disques durs. Ensuite, via un serveur d’importation spécial, les machines virtuelles ont été téléchargées sur le cloud.

S'il n'y a aucun problème pour le client d'éteindre la machine virtuelle pendant un jour ou deux (ou s'il n'y a pas d'autres options), cela peut être fait. Mais si le temps d'arrêt doit être d'une heure maximum, cette méthode ne fonctionnera pas. Aujourd'hui, je vais vous expliquer quels outils vous aideront à migrer vers le cloud avec un temps d'arrêt minimal et comment fonctionne notre processus de migration lui-même.

Migration avec Veeam Backup et Replication

Tout le monde connaît Veeam Backup and Replication comme un outil permettant de créer des sauvegardes et des réplicas. Nous l'utilisons pour la migration entre nos sites et pour transporter les clients de la virtualisation privée vers notre cloud. Les machines virtuelles du client sont répliquées sur notre vCenter, après quoi l'ingénieur les ajoute à vCloud Director.

La réplication principale se produit sur une machine virtuelle sous tension. A l'heure convenue, la machine côté client est éteinte. La réplication s'exécute à nouveau pour reporter les modifications survenues depuis la première réplication. Après cela, la machine virtuelle démarre dans notre cloud.

En règle générale, à partir du moment où la machine est éteinte sur l'infrastructure du client jusqu'au moment où elle est allumée dans notre cloud, il ne s'écoule pas plus d'une demi-heure, mais plutôt 15 à 20 minutes.

Dans ce cas, la machine virtuelle d'origine reste sur le site client. Si soudainement quelque chose ne va pas, vous pouvez toujours revenir en arrière et l'activer. Cette méthode est également pratique pour le client dans la mesure où elle ne nécessite pas qu'il dispose de Veeam.

Cas 1
Le client disposait de sa propre infrastructure virtuelle basée sur VMware - 40 VM d'une capacité de 30 To. L'équipement sur lequel le cluster était déployé était déjà obsolète et le client a décidé de ne pas se donner la peine d'en acheter de nouveaux et est passé au cloud public. Le temps d’arrêt requis pour les systèmes critiques n’était pas supérieur à une heure. Veeam Replication a été choisi comme outil. Un autre avantage était que le fournisseur Internet du client était présent dans notre data center, ce qui a permis d'organiser un bon canal. La migration a duré environ un mois, les temps d'arrêt lors de la commutation pouvant atteindre 30 minutes par groupe de machines virtuelles.

Migrez avec Veeam Cloud Connect

Veeam Cloud Connect est un outil qui vous aide à configurer la réplication de machines virtuelles et à lancer des réplicas dans le cloud du fournisseur de services. Après la mise à jour vers 2019 Année après année, il est devenu possible de répliquer des machines virtuelles directement sur vCloud Director. La seule condition est que côté client, Veeam Backup and Replication soit déployé au minimum en version 9. En bref (version détaillée ici), alors l'ensemble du processus ressemble à ceci.

Dans vCloud Director, une organisation est créée avec les ressources et les réseaux nécessaires. Dans Veeam Cloud Connect, nous créons un compte, le client s'y connecte depuis son Veeam B&R, sélectionne un fournisseur DataLine et une organisation, et configure les tâches de réplication. Outre le fait que lors d'une telle migration, le temps d'arrêt sera de 15 à 20 minutes, le client ne dépend en aucun cas du support technique du fournisseur et gère l'ensemble du processus de manière indépendante : crée des tâches de réplication, la réplication elle-même, s'éteint les machines et les démarre sur le nouveau site.

Cas 2
L’infrastructure du client, à partir de laquelle la migration était prévue, était située en Biélorussie. Il a fallu transporter 90 VM pour un volume total de 27 To, malgré un canal Internet de 100 Mbit/s. Si vous effectuez une sauvegarde et la téléchargez immédiatement sur notre cloud, cela prendra plusieurs jours pour certaines machines virtuelles. Pendant ce temps, un delta important aurait augmenté sur la VM, ce qui aurait pu avoir un impact négatif sur les performances des machines ou, pire encore, l'espace sur la banque de données aurait été épuisé. Nous avons procédé comme suit : dans un premier temps, le client a effectué une sauvegarde complète locale et en a transféré une copie sur notre cloud via Veeam Cloud Connect. Ensuite, j'ai créé et transféré l'incrément vers le cloud. La machine virtuelle d'origine a continué à fonctionner. Après avoir arrêté la VM, le client a effectué un autre incrément et l'a également transféré vers le cloud. De notre côté, nous avons déployé une machine virtuelle à partir d’une sauvegarde complète, puis y avons ajouté deux incréments. Ce schéma a finalement permis de minimiser les temps d'arrêt à 2 heures lors du passage sur notre site.

Migration avec la disponibilité de VMware vCloud

En mars de cette année, VMware a publié vCloud Availability 3.0, qui vous permet de migrer des machines virtuelles entre différents cloud (vCloud Director - vCloud Director) et depuis des supports de virtualisation de clients privés vers le cloud (vCenter - vCloud Director). La principale commodité est l'intégration avec l'interface de vCloud Director. Cela simplifie grandement le processus de gestion de la réplication et minimise les temps d'arrêt lors des basculements.

À l'aide de cet outil, nous avons migré l'un des clients de notre cloud de Moscou vers notre cloud de Saint-Pétersbourg. Il a fallu transporter 18 machines virtuelles d'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, à partir de l'interface de vCloud Director, le client a accédé aux paramètres de disponibilité de vCloud, a créé des tâches de réplication et est passé au site de Saint-Pétersbourg à un moment qui lui convient. Le temps d'arrêt pendant la commutation était de 12 minutes.

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

vCloud Availability dispose d'un mécanisme pour migrer les machines virtuelles du site du client vers notre cloud. Pour ce faire, une application spéciale vCloud Availability est déployée dans le vCenter du client. Après une configuration simple, vous vous connectez au cloud et configurez les tâches de migration. Le client gère également l’ensemble du processus de manière indépendante et le temps de migration est réduit au minimum.

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

VMware vCloud Availability présente de nombreux autres cas d'utilisation ; nous en parlerons bientôt dans un article séparé.

Se préparer à la migration

Pour choisir un outil et réellement démarrer la migration, vous devez trancher sur les points suivants :

D’où migre-t-on ? Si vous migrez depuis une solution privée, vous disposez alors d’une totale liberté dans le choix des outils. Si vous quittez votre prestataire, c’est plus compliqué. Très probablement, relier les infrastructures de deux fournisseurs et simplement glisser-déposer une VM ne fonctionnera pas pour des raisons de sécurité. Parfois, le prestataire que le client est sur le point de refuser commence à se montrer espiègle et à gagner du temps. Vous pouvez vous éloigner du fournisseur à l'ancienne : en téléchargeant des machines virtuelles sur des disques et sur FTP, ou en migrant au niveau de l'application. Le nom de ce dernier est conditionnel, et il ressemble à ceci.

Cas 3
Il était nécessaire de migrer le système SAP du client depuis un fournisseur européen : 34 VM d'une capacité de 54 To. Le client s'est vu attribuer des ressources dans notre cloud. La 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 et les configurations nécessaires reconduites. De grandes bases de données ont été migrées en téléchargeant des sauvegardes sur notre cloud. Ensuite, la réplication a été configurée entre les bases de données de notre site et celles d'origine. À l'heure convenue, nous sommes passés aux bases de données dans notre cloud.

Volume de données et canal Internet. Nous demandons généralement au client de fournir un téléchargement par système avec les paramètres de mémoire, de CPU et de disque. Nous évaluons si le canal est suffisant 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, machines virtuelles, cela peut être différent en fonction de leur criticité pour l'entreprise. Habituellement, le client présente des exigences toutes faites en matière de temps d'arrêt pendant la migration, et sur cette base, nous sélectionnons l'outil et le plan de migration appropriés. Nous essayons de planifier le basculement final la nuit ou le week-end afin que même un temps d'arrêt mineur ne soit pas perceptible pour les utilisateurs finaux du client.

Sur la base de ces données, vous pouvez sélectionner un outil et commencer 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. Les machines virtuelles seront copiées sur ce réseau. Si Veeam Backup and Replication est utilisé, il s'agit alors d'un canal dédié, moins souvent d'un canal VPN. S'il s'agit de Veeam Cloud Connect, alors tout se passe via Internet ou le même canal dédié.

   Ensuite, le réseau est configuré pour la VM dans le cloud. Les voitures circulent généralement en groupe et pendant plus d'une journée. Une fois que les VM nous sont apportées et lancées, elles doivent communiquer avec les machines qui restent encore sur le site d'origine.

2. Calendrier des migrations. Lorsqu'il y a beaucoup de voitures, il est judicieux de les diviser en groupes et de les transporter par lots. En collaboration avec le client, nous convenons d'un plan dans lequel nous précisons quand et quelles machines seront déplacées et quand la réplication finale et le basculement vers le nouveau site seront effectués.
3. Tester la migration. Nous migrons la machine virtuelle de test et vérifions si tout est correctement configuré : connectivité réseau entre les sites, disponibilité de la machine virtuelle sur les machines du site source, droits du compte, etc. Ce test permet d'éviter les accrocs lors de la phase de migration de combat.

C'est tout pour moi. Dans les commentaires, posez des questions et parlez-nous de votre expérience de migration.

Source: habr.com