Concepts et pratiques recommandées pour vMotion

HCX est essentiellement un proxy bidirectionnel vMotion. Chaque instance de HCX émule un seul hôte VMware ESXi™ au sein du centre de données vSphere, en dehors de tout cluster. L'instance HCX fait elle-même "l'interface" pour le composant de flotte de la passerelle de cloud (CGW). Un hôte proxy apparaît pour chaque site HCX qui est lié au site actuellement consulté. Lorsqu'une vMotion est initiée vers un hôte distant, l'hôte ESXi local migre cette machine virtuelle vers l'hôte ESXi proxy local.

Une migration vMotion est lancée de l'hôte proxy ESXi distant vers l'hôte ESXi physique vSphere de destination, alors qu'il reçoit les données de la passerelle CGW source via le tunnel. Lorsqu'une migration vMotion est utilisée, contrairement à l'option de migration en bloc, une seule opération de migration de machine virtuelle est exécutée à la fois. Par conséquent, pour de nombreuses VM à migrer, il est recommandé de n'utiliser vMotion que lorsque l'indisponibilité n'est pas envisageable ou qu'il existe un risque de redémarrage de la VM. Cependant, comme pour la vMotion standard, la machine virtuelle peut être sous tension pendant le processus.

Un seul site vMotion atteint sa limite maximale à environ 1.7 Gbps sur le LAN et 300 - 400 Mbps sur le WAN grâce au WAN Optimizer. Cela ne signifie pas que 1,7 Gbit/s sur le réseau LAN équivaut à 400 Mbits/s sur le réseau étendu grâce à l'optimiseur de réseau étendu, mais uniquement que ces valeurs maximales ont été observées dans des environnements spécifiques. L'environnement sur lequel cela a été observé consistait en un réseau LAN vMotion de 10 Go et une liaison Internet montante de 1 Go, partagés avec le trafic Web de production.

Utilisez vMotion dans les cas suivants :

• Si la VM est difficile à arrêter ou à démarrer, ou si le temps de fonctionnement est long et qu'il est possible d'introduire des risques en arrêtant la VM.
• Pour toute application de type cluster qui nécessite des UUID de disque, comme les clusters RAC Oracle. vMotion ne modifie pas les UUID de disque sur la destination.
• Si vous voulez déplacer une seule machine virtuelle le plus rapidement possible.
• Si la migration planifiée n'est pas nécessaire.

Concepts et pratiques recommandées pour la migration en bloc

La fonction de migration en bloc de HCX utilise la réplication vSphere pour migrer les données du disque tout en recréant la machine virtuelle dans l'instance vSphere HCX de destination. Une migration d'une machine virtuelle implique les actions suivantes :

• Création d'une nouvelle machine virtuelle du côté de la destination et de ses disques virtuels correspondants.
• Réplication des données de machine virtuelle sur la nouvelle machine virtuelle. La réplication démarre dès que l'assistant est terminé, quelle que soit la planification de la commutation.
• Mise hors tension de la machine virtuelle d'origine.
• Durant la période de mise hors tension, la réplication finale de toutes les modifications de données se produit.
• Mise sous tension de la nouvelle machine virtuelle du côté de la destination.
• Changement de nom et déplacement de la machine virtuelle d'origine vers le dossier de cloud vers lequel elle a été déplacée.

Les avantages de la migration en bloc par rapport à la migration vMotion sont les suivants :

• Migration simultanée de plusieurs machines virtuelles.
• Utilisation plus cohérente de la bande passante. VMotion peut générer des fluctuations dans l'utilisation de la bande passante qui seraient visibles comme des pics et des vallées au sein des outils de surveillance du réseau ou de l'interface utilisateur d'Opt WAN.
• La migration en bloc permet d'obtenir une utilisation globale de la bande passante du réseau supérieure à celle que vous obtiendriez avec une vMotion unique.
• La migration en bloc peut être programmée pour basculer vers les machines virtuelles nouvellement migrées au cours d'une interruption de service programmée.
• Autoriser la migration des machines virtuelles qui utilisent actuellement des fonctions d'unités centrales virtuelles, qui diffèrent du côté du cloud. La migration vMotion peut échouer dans ces cas.

Les inconvénients de la migration en bloc par rapport à la migration vMotion sont les suivants :

• La migration des machines virtuelles individuelles est plus lente qu'avec la migration vMotion.
• La machine virtuelle subit un bref temps d'arrêt lorsque la nouvelle machine virtuelle clonée est affichée du côté de la destination.
• Les machines virtuelles qui dépendent de l'ordre des disques et des UUID de disque (Oracle RAC) peuvent avoir des problèmes et avoir des disques qui apparaissent différemment lorsque les UUID sont modifiées, ce qui peut modifier les chemins d'accès du système d'exploitation vers les périphériques de disque virtuel.

Clusters à disque partagé

Les clusters Oracle RAC, MS Exchange et MS-SQL sont des exemples d'applications où deux machines virtuelles ou plus participent à un cluster qui nécessite un disque partagé entre toutes les machines virtuelles ou noeuds de cluster. L'indicateur d'écriture multiple VMware® doit être activé sur tous les noeuds VM pour les disques faisant partie du cluster d'applications (disques virtuels non OS). Les machines virtuelles pour lesquelles l'indicateur d'écriture multiple est activé pour tout disque virtuel ne sont pas prises en charge.

Prenez connaissance des informations suivantes relatives à la migration d'un cluster ayant activé les disques virtuels à écriture multiple :

• vMotion est utilisée car les mappages d'origine du disque de machine virtuelle et de l'UUID sont maintenus.
• Le cluster reste à l'état dégradé (noeud unique) durant la migration.
• Le cluster subit un temps d'arrêt avant le début de la migration et après que la migration soit terminée pour réassembler la configuration d'écriture multiple entre les machines virtuelles du cluster.

Pour migrer un cluster ayant activé les disques à écriture multiple, procédez comme suit :

1. Mettez hors tension le cluster et tous les noeuds conformément aux pratiques recommandées de l'application.
2. Prenez note de l'ordre des disques, si l'application l'exige, dans chaque noeud de machine virtuelle pour les disques virtuels configurés en écriture multiple.
3. Pour Oracle et toute autre application qui utilise la fonctionnalité UUID du disque virtuel, connectez-vous à un hôte ESXi et exécutez la commande vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk. Cette commande permet d'obtenir l'UUID de chaque fichier de disque virtuel nécessitant que l'indicateur d'écriture multiple soit défini pour le cluster. Cette étape est nécessaire si la meilleure pratique aligne les ordres de disque sur la façon dont le chemin est affiché dans le système d'exploitation. VMotion peut réorganiser les disques (disk1, disk2, disk3), mais les identificateurs uniques universels restent les mêmes. Une fois la migration terminée, utilisez l'UUID noté pour mapper les informations de disque et recréer l'ordre de nommage des disques et l'ID SCSI, si nécessaire. Ces informations peuvent être utiles pour le traitement des incidents lorsqu'une instance Oracle présente de nombreux disques virtuels mappés.
4. Retirez les disques virtuels de toutes les machines virtuelles de cluster, à l'exception de celles du cluster principal.
5. Supprimez le drapeau multiwriter de la VM primaire du cluster (la seule qui possède les disques du cluster).
6. Mettez sous tension le cluster principal, si nécessaire pour réduire au minimum les temps d'arrêt.
7. Migrez tous les noeuds de cluster avec vMotion. Commencez par migrer le cluster principal. Faites migrer tous les autres noeuds après les avoir mis hors tension.
8. Lorsque le noeud propriétaire du disque principal termine la migration, mettez-le hors tension.
9. Si nécessaire, remappez l'ordre des disques avec l'UUID de disque et l'ID SCSI appropriés. Le remappage n'est pas nécessaire pour que l'application fonctionne.
10. Ré-activez l'indicateur d'écriture multiple sur le noeud principal.
11. Démarrez le nœud principal et vérifiez le fonctionnement.
12. Mappez les disques ou activez l'indicateur d'écriture multiple sur toutes les autres machines virtuelles du cluster et mettez-les sous tension.
13. Vérifiez le fonctionnement de tous les autres clusters.

Machines virtuelles générales

Une fois que la confiance s'est construite autour du fonctionnement de HCX, la migration en bloc doit être utilisée. La migration en bloc est nécessaire en cas d'applications redondantes. Par exemple, en cas de serveurs Web et lorsque plusieurs centaines ou plusieurs milliers de machines virtuelles doivent être migrées.

Machines virtuelles utilisant un serveur d'accès au réseau direct

NFS est généralement utilisé pour partager des données sur de nombreux serveurs, tels que le contenu du serveur web. ISCSI peut être utilisé sur les nœuds de machine virtuelle constitués d'un cluster d'applications tel que le courrier électronique ou le SGBDR et il est généralement plus sensible à la latence que NFS.

Dans les deux cas, si le temps d'attente peut être réduit au centre de données IBM Cloud (< ~ 7 ms pour iSCSI et quelle que soit l'application tolère pour NFS) et que l'application peut fonctionner avec une bande passante de ~ 1 Gbps ou moins, le réseau NAS peut être étendu avec HCX dans un emplacement IBM Cloud. Par la suite, les machines virtuelles peuvent être migrées ou transférées via vMotion avec HCX.

Après la migration, les volumes iSCSI peuvent être dupliqués avec le système d'exploitation vers une autre solution de stockage en cloud local et les données NFS peuvent être répliquées vers n'importe quelle solution de cloud. Prenez connaissance des remarques suivantes :

• Latence (iSCSI ou tolérance d'application pour NFS)
• Bande passante (~1 Gbit/s pour un réseau étendu)
• Bande passante sous-jacente de la liaison

Après le cycle de vie de la migration, testez les applications de développement ou de préproduction avant de tenter la migration en production. La QoS (qualité de service) peut être utilisée pour le trafic tunnel sous-jacent (UDP 500/4500) entre les dispositifs L2C de HCX qui prennent en charge des réseaux L2 étendus sensibles à la latence.