Il y a environ 7 ans, les tout premiers projets ont migré vers notre cloud simplement et sans prétention. Des images de machines virtuelles ont été téléchargées sur un serveur FTP ou importé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.
Si ce n'est pas un problème pour le client de désactiver la machine virtuelle pendant un jour ou deux (ou pas d'autres options), alors c'est possible. Mais si le temps d'arrêt doit être au maximum d'une heure, cette méthode ne fonctionnera pas. Aujourd'hui, je vais vous dire quels outils vous aideront à migrer vers le cloud avec un temps d'arrêt minimal et comment le processus de migration fonctionne avec nous.
Migration avec Veeam Backup and Replication
Tout le monde connaît Veeam Backup and Replication comme un outil pour créer des sauvegardes et des répliques. Nous l'utilisons pour la migration entre nos sites et pour le transport de clients avec virtualisation privée vers notre cloud. Les machines virtuelles clientes sont répliquées sur notre vCenter, après quoi l'ingénieur les ajoute à vCloud Director.
La réplication principale est effectuée sur une machine virtuelle activée. A l'heure convenue, la machine côté client s'éteint. La réplication redémarre 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.
Habituellement, à partir du moment où la machine est éteinte sur l'infrastructure du client et jusqu'au moment où elle est allumée, pas plus d'une demi-heure, mais plutôt 15 à 20 minutes, passent dans notre cloud.
Dans le même temps, la machine virtuelle d'origine reste sur le site du client. Si soudainement quelque chose se passe mal, vous pouvez toujours revenir en arrière et l'allumer. Pour le client, cette méthode est également pratique en ce qu'elle ne nécessite pas Veeam de sa part.
Cas 1
Le client avait sa propre infrastructure virtuelle basée sur VMware - 40 VM avec une capacité de 30 To. L'équipement sur lequel le cluster a été déployé est déjà obsolète, et le client a décidé de ne pas s'impliquer dans l'achat d'un nouveau et de passer à un cloud public. Le temps d'arrêt requis pour les systèmes critiques ne dépassait pas une heure. Veeam Replication a été choisi comme outil. Le plus était également que le fournisseur d'accès Internet du client était présent dans notre centre de données, ce qui nous a permis d'organiser un bon canal. La migration a pris environ un mois, tandis que le changement était simple, il a fallu jusqu'à 30 minutes pour un groupe de machines virtuelles.Migrez avec Veeam Cloud Connect
Veeam Cloud Connect est un outil qui vous aide à configurer la réplication des machines virtuelles et à exécuter des répliques dans le cloud du fournisseur de services. Après la mise à jour en
2019 , il est devenu possible de répliquer des machines virtuelles directement vers vCloud Director. La seule condition est que du côté client, votre sauvegarde et réplication Veeam doit être déployée au moins en version 9. En bref (une version détaillée est
ici ), l'ensemble du processus est le suivant.
VCloud Director crée une organisation avec les ressources et les réseaux nécessaires. Dans Veeam Cloud Connect, nous créons un compte, le client s'y connecte à partir de notre Veeam B&R, sélectionne le fournisseur et l'organisation DataLine et configure les tâches de réplication. Outre le fait que lors d'une telle migration, les temps d'arrêt seront compris entre 15 et 20 minutes, le client ne dépend pas du support technique du fournisseur et gère l'ensemble du processus de manière indépendante: il crée des tâches de réplication, la réplication elle-même, éteint les machines et démarre leur démarrage sur un nouveau site.
Cas 2
L'infrastructure client à partir de laquelle la migration était prévue était située au Bélarus. Il a fallu transporter 90 VM avec un volume total de 27 To, malgré le fait que le canal Internet était à 100 Mbps. 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 grand delta se développerait sur la machine virtuelle, ce qui pourrait déjà nuire aux performances des machines ou, pire encore, l'espace sur le magasin de données s'épuisait. Ils ont agi comme suit: premièrement, le client a effectué une sauvegarde complète locale et nous en a transféré une copie dans le cloud via Veeam Cloud Connect. Puis il a fait et jeté l'incrément dans le nuage. La machine virtuelle d'origine a continué de fonctionner. Après avoir arrêté 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 nous y avons ajouté deux incréments. Un tel schéma nous a permis de minimiser les temps d'arrêt à 2 heures lors du passage sur notre site.Migration avec VMware vCloud Availability
En mars de cette année, VMware a publié vCloud Availability 3.0, qui permet aux machines virtuelles de migrer entre différents clouds (vCloud Director - vCloud Director) et des stands de virtualisation de clients privés vers le cloud (vCenter - vCloud Director). La principale commodité est 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 de la commutation.
À 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. Pour le client, une organisation a été créée 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 est passé 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 opportun. Le temps d'arrêt lors du changement était de 12 minutes.
Le schéma de migration entre les nuages DataLine à Saint-Pétersbourg et Moscou.VCloud Availability dispose d'un mécanisme de migration des machines virtuelles d'un site client vers notre cloud. Pour ce faire, une application spéciale de disponibilité vCloud est déployée dans le client vCenter. Après une configuration simple, vous êtes connecté au cloud et les tâches de migration sont configurées. Le client gère également de manière indépendante l'ensemble du processus et le temps de migration est minimisé.
Un diagramme de la migration des 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é.
Préparation à la migration
Pour sélectionner un outil et poursuivre la migration, vous devez décider des points suivants:
D'où migrons-nous? Si vous migrez à partir d'une solution privée, vous avez une liberté totale dans le choix des outils. Si vous quittez le fournisseur, c'est plus difficile. Très probablement, la connexion de l'infrastructure des deux fournisseurs et le simple glissement de la machine virtuelle échoueront pour des raisons de sécurité. Parfois, le prestataire, que le client va refuser, commence complètement à être nuisible et prend du temps. Vous pouvez quitter le fournisseur à l'ancienne: en téléchargeant la machine virtuelle sur des disques et FTP ou en migrant au niveau de l'application. Le nom de ce dernier est arbitraire et ressemble à ceci.
Cas 3
Il a fallu migrer le système SAP du client depuis un fournisseur européen: 34 VM avec un volume de 54 To. Des ressources ont été allouées au client dans notre cloud. Entre nous et l'infrastructure du fournisseur européen a été organisée la connectivité réseau. Les serveurs d'applications ont été redéployés, avec le cumul des configurations nécessaires. De grandes bases de données ont migré via le téléchargement de sauvegardes sur notre cloud. Ensuite, la réplication entre les bases de données sur notre et les sites source a été configurée. À l'heure convenue, nous sommes passés aux bases de données de notre cloud.La quantité de données et le canal Internet. Nous demandons généralement au client de fournir le déchargement sur les systèmes avec des paramètres de mémoire, CPU, disques. Nous estimons si le canal est suffisant pour envoyer directement des répliques ou des sauvegardes de machines virtuelles.
Valide simple. Pour différents systèmes et, par conséquent, les machines virtuelles, il peut être différent selon leur criticité pour l'entreprise. Habituellement, un client est livré avec des exigences prédéfinies pour les temps d'arrêt pendant la migration, et sur cette base, nous choisissons le bon outil et le bon plan de migration. Nous essayons de planifier le passage final à la nuit ou au week-end, de sorte que même un léger temps d'arrêt ne soit pas perceptible pour les utilisateurs finaux du client.
Sur la base de ces données, vous pouvez choisir un outil et poursuivre la migration elle-même. Voici ce qui se passe ensuite.
- Configuration de la connectivité réseau. Nous organisons la connectivité réseau entre notre cloud et l'infrastructure client. Les machines virtuelles seront copiées sur ce réseau. Si Veeam Backup and Replication est utilisé, il s'agit d'un canal dédié, moins souvent un canal VPN. Si Veeam Cloud Connect, alors tout passe par Internet ou le même canal dédié.
Ensuite, le réseau est configuré pour la machine virtuelle dans le cloud. Les voitures se déplacent généralement en groupe et plus d'une journée. Une fois que les VM nous ont été transférées et lancées, elles devraient interagir avec les machines qui restent toujours sur le site de départ. - Calendrier de migration. Lorsqu'il y a beaucoup de voitures, il est raisonnable de les diviser en groupes et de les transporter par lots. En accord avec le client, nous convenons d'un plan dans lequel nous prescrivons quand et quelles machines se déplacer et quand la réplication finale et le passage à un nouveau site seront effectués.
- Tester la migration. Nous migrons la machine virtuelle de test et vérifions si tout est correctement configuré: connectivité réseau entre les sites, la disponibilité de la machine virtuelle pour les machines sur le site source, les droits de compte, etc. Un tel test permet d'éviter les accrocs lors de la phase de migration de combat.
C’est tout pour moi. Posez des questions dans les commentaires et parlez de votre expérience de migration.