Ce que nous faisons · Données et web: Live migration et sorties d'hyperviseur
Des machines virtuelles en marche passent d'un hôte à l'autre sans s'arrêter, et des parcs entiers quittent VMware ou des serveurs KVM autonomes pour notre private cloud Oracle Linux Virtualization Manager (OLVM). À chaud quand il est sûr de l'être, en copie à froid vérifiée quand il ne l'est pas, et toujours avec l'original gardé intact jusqu'à ce que le nouveau côté ait fait ses preuves.
De quoi il s'agit
Trois sortes de déplacement sous une seule discipline :
- Live migration : une machine virtuelle KVM en marche, mémoire et disque, déplacée entre hôtes avec une pause mesurée en millisecondes. C'est ainsi que nous faisons la maintenance des hôtes et le remplacement du matériel sans planifier votre interruption.
- Sorties d'hyperviseur : des parcs VMware et des hôtes KVM autonomes déplacés vers OLVM, où les VM démarrent depuis un stockage all-flash d'entreprise sur des fabrics Fibre Channel redondants, avec backup et supervision dès le premier jour.
- Déplacements de site : des environnements entiers relocalisés entre nos datacenters, en gardant leurs adresses et leurs identités.
Comment nous le construisons
Une règle de décision avant qu'un seul octet ne bouge. Si la génération de CPU, la configuration réseau et la version de l'hyperviseur restent compatibles, la VM migre à chaud. Quand tout change à la fois, nous ne parions pas : la VM est arrêtée, copiée, redéfinie et démarrée à froid sur la cible, et la source reste intacte comme rollback.
La live migration faite correctement. Nous utilisons le chemin de migration directe de libvirt avec copie du stockage et auto-converge, pour que les VM très sollicitées convergent quand même. La destination est préparée d'abord : pools de stockage, bridges et interfaces VLAN, et pour les dispositions de disque inhabituelles une image pré-créée à la taille exacte de la source.
Reconstruire le sans état, répliquer l'avec état. Pour une sortie, nous préférons souvent une reconstruction propre à partir de spécifications mesurées en production. Les tiers web et applicatifs sont reconstruits à partir de la configuration ; la base de données migre par réplication, de sorte que la bascule (cutover) est une promotion avec quelques secondes de delta.
Une appliance de migration construite pour cela. Les conversions tournent sur un serveur de migration dédié au stockage all-flash NVMe et SSD, raccordé directement à notre fabric. Il convertit les invités d'autres hyperviseurs et transfère les images disque KVM directement dans des disques créés par la plateforme cible, en préservant les adresses MAC, le mode de firmware et le type de machine, pour que la VM démarre à l'arrivée.
Audité face à l'API, pas aux notes de construction. Chaque VM est contrôlée face au gestionnaire de virtualisation lui-même (topologie CPU, garanties mémoire, interfaces réseau, routes, disques, nom d'hôte) avant tout déplacement de données. Les VM sont redimensionnées au juste besoin et ne reçoivent jamais plus de vCPU qu'un socket CPU n'a de cœurs.
Windows pris en charge. Pilotes et outils invités sont mis en ordre, les outils de l'ancien hyperviseur retirés seulement une fois que le disque de démarrage tourne sur VirtIO, et Active Directory et les licences vérifiés après le déplacement.
Répétitions à blanc, horaire convenu. Chaque conversion est d'abord répétée sur une copie. Si un déplacement pouvait toucher votre trafic, nous en convenons l'horaire avec vous au préalable.
Ce dont il vous protège
- L'interruption pour la maintenance des hôtes, les travaux de firmware ou le remplacement de matériel.
- Des changements de licence dont vous n'avez aucun moyen de sortir.
- Une migration qui perd la source avant que la cible ne fonctionne.
- Un déplacement entre générations de CPU qui casse silencieusement un invité.
- Des VM qui arrivent avec la mauvaise topologie, une interface manquante ou une adresse perdue.
- Renuméroter tout votre parc juste pour changer de plateforme.
En pratique
Un load balancer, migré à chaud. La VM load balancer très sollicitée d'un éditeur de presse a été migrée à chaud entre hôtes, disque compris, en 3 minutes 5 secondes, avec une pause d'environ 300 millisecondes.
Un diffuseur national quitte VMware. Nous avons reconstruit la plateforme web d'un diffuseur national de VMware vers OLVM en VM redimensionnées au juste besoin, audité chacune face à l'API et déplacé la base de données par réplication. Un serveur de développement est passé par notre appliance de migration et était prêt à démarrer en environ sept minutes et demie. La bascule s'est achevée il y a des mois.
Un hôte KVM autonome, importé. Le serveur KVM autonome d'un client a été importé dans OLVM à environ neuf GiB par minute, chaque adresse intacte, parce que la répétition à blanc avait déjà traité le nommage des interfaces du nouveau chipset virtuel.
Un parc VDI déplacé entre pays. Un environnement de postes de travail virtuels a été déplacé d'Amsterdam à Athènes. Nous avons transporté son sous-réseau de gestion en entier sur notre extension Layer 2, de sorte que chaque pool de postes et chaque droit d'accès sont passés inchangés, et chaque contrôleur de domaine a été vérifié sain ensuite.
Pourquoi EuroVPS
- Une règle écrite pour chaud ou froid, appliquée à chaque fois.
- La source gardée comme rollback jusqu'à ce que la cible ait fait ses preuves.
- Une appliance de migration dédiée, pas un ordinateur portable et un week-end.
- L'extension Layer 2 entre nos sites, pour que vous déménagiez sans renuméroter.
- Chaque VM auditée face à l'API avant tout déplacement de données.
Questions fréquentes
- Pouvez-vous déplacer nos VM sans les reconstruire ? Oui, par conversion, avec pilotes et outils permutés dans un ordre testé. Nous gardons les originaux jusqu'à votre validation.
- Nos VM garderont-elles leurs adresses IP ? Elles le peuvent. Avec l'extension Layer 2, les serveurs gardent leurs adresses et se déplacent un par un.
- Combien de temps une live migration met-elle la VM en pause ? Typiquement une fraction de seconde au moment du basculement. Les déplacements à froid vont dans une fenêtre convenue avec vous.
- Et si quelque chose tourne mal en cours de route ? La source est inchangée. Nous revenons en arrière, cherchons pourquoi, et recommençons.
- Qu'est-ce qu'OLVM ? Oracle Linux Virtualization Manager, une gestion d'entreprise pour du KVM standard. Aucun verrouillage propriétaire.
Vous quittez VMware ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.