Il y a environ sept ans, les tout premiers projets ont migré vers notre cloud de manière simple et rapide. Les images des machines virtuelles étaient téléchargées sur un serveur FTP ou stockées sur des disques durs. Ensuite, via un serveur d'importation dédié, les machines virtuelles étaient téléchargées vers le cloud.
Si le client peut facilement éteindre la machine virtuelle pendant un jour ou deux (ou s'il n'y a pas d'autre solution), cette méthode est envisageable. En revanche, si l'indisponibilité ne doit pas dépasser une heure, cette méthode ne fonctionnera pas. Aujourd'hui, je vais vous présenter les outils permettant de migrer vers le cloud avec un temps d'indisponibilité minimal et comment le processus de migration est organisé chez nous.
Migration avec Veeam Backup and Replication
Veeam Backup and Replication est un outil de création de sauvegardes et de réplications bien connu. Nous l'utilisons pour la migration entre nos sites et pour transférer nos clients de leur virtualisation privée vers notre cloud. Les machines virtuelles des clients sont répliquées sur notre vCenter, puis ajoutées à vCloud Director par nos ingénieurs.
La réplication initiale est effectuée sur une machine virtuelle en cours d'exécution. À l'heure convenue, la machine côté client est arrêtée. La réplication est redémarrée pour transférer les modifications intervenues depuis la première réplication. La machine virtuelle redémarre ensuite dans notre cloud.
En règle générale, à partir du moment où une machine est éteinte sur l'infrastructure du client jusqu'à ce qu'elle soit allumée dans notre cloud, cela ne prend pas plus d'une demi-heure, ou plutôt 15 à 20 minutes.
Dans ce cas, la machine virtuelle d'origine reste sur le site du client. En cas de problème, vous pouvez toujours la restaurer et la réactiver. Cette méthode est également pratique pour le client, car elle ne nécessite pas 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. Le client a donc décidé de migrer vers un cloud public, sans se soucier d'en acquérir de nouveaux. L'indisponibilité des systèmes critiques ne devait pas dépasser une heure. Veeam Replication a été choisi comme outil. Autre avantage : la présence du fournisseur d'accès Internet du client dans notre centre de données, ce qui nous a permis d'organiser un canal efficace. La migration a duré environ un mois, avec un temps d'indisponibilité pouvant atteindre 30 minutes par groupe de machines virtuelles lors du basculement.
Migration avec Veeam Cloud Connect
Veeam Cloud Connect est un outil qui vous aide à configurer la réplication des machines virtuelles et à lancer des réplicas dans le cloud du fournisseur de services. Après la mise à jour vers Depuis un an, il est possible de répliquer des machines virtuelles directement vers vCloud Director. La seule condition est que le client dispose de sa propre solution Veeam Backup and Replication, version 9 ou supérieure, déployée. En bref (version détaillée) ), alors tout le processus ressemble à ceci.
Dans vCloud Director, une organisation disposant des ressources et des réseaux nécessaires est créée. Dans Veeam Cloud Connect, nous créons un compte, le client s'y connecte depuis son Veeam B&R, sélectionne le fournisseur et l'organisation DataLine, et configure les tâches de réplication. Outre le fait qu'avec une telle migration, le temps d'arrêt est de 15 à 20 minutes, le client ne dépend pas du support technique du fournisseur et gère l'ensemble du processus de manière autonome : création des tâches de réplication, réplication elle-même, arrêt des machines et démarrage sur le nouveau site.
Cas 2
L'infrastructure du client, d'où la migration était prévue, était située en Biélorussie. Il était nécessaire de migrer 90 machines virtuelles d'un volume total de 27 To, compte tenu d'un débit Internet de 100 Mbit/s. Si une sauvegarde était immédiatement téléchargée sur notre cloud, cela prendrait plusieurs jours pour certaines machines virtuelles. Pendant ce temps, un important delta se formerait sur la machine virtuelle, ce qui pourrait nuire aux performances des machines, voire, pire encore, entraîner un manque d'espace sur le datastore. Nous avons procédé comme suit : le client a d'abord effectué une sauvegarde complète locale et en a transféré une copie sur notre cloud via Veeam Cloud Connect. Il a ensuite effectué et transféré un incrément vers le cloud. La machine virtuelle d'origine a continué de fonctionner. Après avoir éteint la machine virtuelle, 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 déployé deux incréments. Ce schéma nous a finalement permis de réduire le temps d'arrêt à deux heures lors de la migration vers notre site.
Migration avec VMware vCloud Availability
En mars dernier, VMware a lancé vCloud Availability 3.0, qui permet la migration des machines virtuelles entre différents clouds (vCloud Director – vCloud Director) et des postes de virtualisation client privés vers le cloud (vCenter – vCloud Director). Son principal avantage réside dans l'intégration avec l'interface vCloud Director. Cela simplifie considérablement la gestion de la réplication et minimise les temps d'arrêt lors des changements de cloud.
Nous avons utilisé cet outil pour migrer l'un de nos clients de notre cloud de Moscou vers celui de Saint-Pétersbourg. Nous devions migrer 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, depuis l'interface vCloud Director, le client a accédé aux paramètres de disponibilité de vCloud, créé des tâches de réplication et basculé vers le site de Saint-Pétersbourg au moment opportun. Le temps d'arrêt pendant la migration a été 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 machines virtuelles du site client vers notre cloud. Pour ce faire, une application vCloud Availability dédiée est déployée dans le vCenter du client. Après une configuration simple, une connexion au cloud est établie et les tâches de migration sont configurées. Le client gère l'ensemble du processus de manière autonome, ce qui réduit le temps de migration au minimum.
Schéma de migration de machines virtuelles d'une installation privée vers le cloud.
VMware vCloud Availability a de nombreux autres cas d'utilisation, nous en parlerons bientôt dans un article séparé.
Se préparer à la migration
Pour sélectionner un outil et démarrer réellement la migration, vous devez décider des points suivants :
D'où migre-t-on ? Si vous migrez depuis une solution privée, vous avez une totale liberté dans le choix des outils. Si vous changez de fournisseur, la situation est plus complexe. Il sera probablement impossible de connecter les infrastructures de deux fournisseurs et de simplement transférer la VM pour des raisons de sécurité. Il arrive que le fournisseur que le client s'apprête à quitter devienne agressif et fasse preuve de lenteur. Vous pouvez changer de fournisseur de manière traditionnelle : en transférant la VM sur des disques et via FTP, ou en effectuant une migration au niveau de l'application. Le nom de cette dernière option est arbitraire et ressemble à ceci.
Cas 3
Il était nécessaire de migrer le système SAP d'un client depuis un fournisseur européen : 34 VM d'une capacité de 54 To. Des ressources ont été allouées au client 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 ont été mises en œuvre. Les bases de données volumineuses ont été migrées en chargeant les sauvegardes dans notre cloud. La réplication a ensuite été configurée entre les bases de données de notre site et celles du site d'origine. À la date convenue, nous avons migré vers les bases de données de notre cloud.
Volume de données et canal Internet. Nous demandons généralement au client de fournir un fichier système avec les paramètres de mémoire, de processeur et de disques. Nous évaluons si le canal est suffisant pour envoyer directement des répliques ou des sauvegardes de machines virtuelles.
Temps d'arrêt acceptable. Selon les systèmes et, par conséquent, les machines virtuelles, la situation peut varier selon leur criticité pour l'entreprise. Généralement, le client a des exigences prédéfinies en matière d'interruption de service pendant la migration ; c'est sur cette base que nous sélectionnons l'outil et le plan de migration appropriés. Nous nous efforçons de planifier la migration finale la nuit ou le week-end, afin que même une interruption mineure ne soit pas perceptible par les utilisateurs finaux du client.
À partir de ces données, vous pouvez sélectionner un outil et procéder à la migration. Voici la suite.
- Configuration de la connectivité réseau. Nous organisons la connectivité réseau entre notre cloud et l'infrastructure du client. Les machines virtuelles sont copiées sur ce réseau. Si Veeam Backup and Replication est utilisé, il s'agit d'un canal dédié, plus rarement d'un canal VPN. Avec Veeam Cloud Connect, tout passe par Internet ou par le même canal dédié.
Ensuite, le réseau est configuré pour les machines virtuelles dans le cloud. Les machines sont généralement transférées par lots et sur une période donnée. Une fois les machines virtuelles transférées et opérationnelles, elles doivent communiquer avec les machines encore présentes sur le site d'origine.
- Calendrier de migration. Lorsque le nombre de machines est important, il est judicieux de les répartir en groupes et de les transporter par lots. En collaboration avec le client, nous convenons d'un plan précisant le moment et la nature des machines déplacées, ainsi que la date de la réplication finale et du basculement vers le nouveau site.
- 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 du site source, droits de compte, etc. Un tel test permet d'éviter les accrocs au stade de la migration de combat.
C'est tout pour l'instant. Posez vos questions et racontez-nous votre expérience de migration dans les commentaires.
Source: habr.com
