Novell Doc: Guide de l'utilisateur de PlateSpin Migrate 9.1 - Remarques complémentaires concernant la migration de workload

4.5 Remarques complémentaires concernant la migration de workload

4.5.1 Migration de grappes Windows

Vous pouvez faire migrer des services métiers d'un cluster Microsoft Windows (vers ESX 3.0.2 et ultérieur). PlateSpin Migrate prend en charge les versions à noeud actif unique des technologies de mise en grappe suivantes :

Serveur de clusters Windows basé sur Windows 2003 Server (modèle Single-Quorum Device Cluster (Cluster de serveurs à périphérique quorum unique))
Cluster de basculement Microsoft basé sur Windows 2008 Server (modèles Nœud et disque majoritaires et Pas de majorité : disque uniquement)

Vous pouvez utiliser une tâche Déplacer pour migrer les services essentiels d'une grappe (cluster) qui se présente sous la forme d'une grappe à noeud unique fonctionnelle sur une machine virtuelle.

L'étendue de la prise en charge des migrations de grappe dans la version actuelle est soumise aux conditions suivantes :

Tous les disques partagés appartiennent au noeud actif.
Le workload source de la migration doit être le noeud actif, celui qui possède actuellement la ressource quorum de la grappe. Pour découvrir une grappe, spécifiez l'adresse IP de l'un des groupes de ressources de la grappe.
Une ressource quorum de grappe doit être colocalisée avec le groupe de ressources (services) de la grappe protégée.
Pour qu'une opération de synchronisation des serveurs ou X2P réussisse, les disques cibles doivent disposer de contrôleurs SCSI distincts pour séparer les disques partagés de la grappe de ceux qui hébergent les volumes système des différents noeuds.
Pour pouvoir fonctionner, la machine virtuelle à grappe unique migrée nécessite un accès à un contrôleur de domaine présentant les mêmes paramètres que ceux du contrôleur de domaine d'origine. Pour ce faire, laissez ce dernier en ligne ou migrez-le en même temps.

Les workflows de migration d'une grappe Windows ou d'un serveur autonome sont similaires :

Découvrez le noeud actif en spécifiant l'adresse IP et les références Admin de la grappe.
Dans la vue Serveurs, utilisez la fonction glisser-déplacer pour commencer une tâche de migration, puis configurez les paramètres de cette dernière.

REMARQUE :

Si vous sélectionnez Arrêt comme état final post-migration de la source, tous les noeuds sources de la grappe sont arrêtés.

Si un basculement de grappe intervient avant la fin du transfert des fichiers, la tâche de migration est abandonnée. Dans ce cas, rafraîchissez la source, puis réessayez la tâche de migration.

4.5.2 Migration de Linux vers une machine virtuelle paravirtualisée sous SLES avec XEN

Vous pouvez effectuer une migration vers une VM paravirtualisée sur Xen sous SLES (version 10 uniquement). Cela se fait indirectement, à travers un processus en deux étapes. La VM paravirtualisée doit d'abord être transformée en VM entièrement virtualisée, puis retransformée en VM paravirtualisée. L'utilitaire (xmps), compris dans votre image ISO de démarrage PlateSpin, permet de transformer la VM.

La procédure varie légèrement, selon que la cible est une nouvelle VM paravirtualisée ou une VM paravirtualisée existante.

Migration de Linux vers une nouvelle VM paravirtualisée

Copiez l'image ISO de démarrage PlateSpin Linux vers le serveur Xen/SLES cible.

Reportez-vous au Tableau 3-2, Images ISO de démarrage pour des machines physiques cibles.
Lancez le gestionnaire de machines virtuelles et créez une VM entièrement virtualisée :
1. Sélectionnez l'option Je dois installer un système d'exploitation.
2. Choisissez une taille d'image disque adéquate (la taille de disque doit être égale ou supérieure à celle de la machine source).
3. Sélectionnez l'image ISO de démarrage comme source d'installation.
  
  La VM démarre dans l'environnement système PlateSpin utilisé dans les paramètres X2P.
Terminez la migration.

Reportez-vous à la section Migration d'un workload vers l'hyperviseur Xen sous SLES.

À la fin du processus, la VM devrait être complètement fonctionnelle en tant que machine entièrement virtualisée.
Redémarrez la VM et assurez-vous qu'elle démarre toujours dans l'environnement système PlateSpin.
À l'invite boot:, tapez switch et appuyez sur Entrée.

Le système d'exploitation va être reconfiguré pour être démarrable en tant que machine paravirtualisée. Une fois le processus terminé, le résultat devrait se présenter comme suit :

Notez les arguments du chargeur de démarrage dans le dernier segment du résultat :
```
Please apply the following data as bootloader_args for
switching Xen fully-virt machine to Para-virt machine:
 
'-entry=xvda1:/vmlinuz-2.6.16.60-0.54.5-xen, /initrd-2.6.16.60-0.54.5-xen'
```
Ils sont utilisés par l'utilitaire xmps pour configurer l'emplacement du kernel et l'image initrd à partir d'où la machine paravirtualisée démarre.
Mettez la machine virtuelle hors tension :

[DB]$ poweroff
Connectez-vous au serveur XEN/SLES en tant que root et montez l'image ISO de démarrage PlateSpin Linux (l'exemple de commande part du principe que l'ISO a été copiée dans le répertoire /root) :
```
# mkdir /mnt/ps
# mount -o loop /root/linuxphysicaltarget.iso /mnt/ps
```
Exécutez l'utilitaire xmps pour créer une VM paravirtualisée basée sur la configuration de la VM entièrement virtualisée :
```
# /mnt/ps/tools/xmps --pv --vm_name=SLES10-FV --new_vm_name=SLES10-PV --bootloader_args="--entry=xvda1:/vmlinuz-2.6.16.60-0.54.5-xen, /initrd-2.6.16.60-0.54.5-xen"
```
L'utilitaire utilise en entrée :
- le nom de la VM entièrement virtualisée sur laquelle la configuration de la machine paravirtualisée sera basée (SLES10-FV) ;
- le nom de la machine virtuelle à créer (SLES10-PV) ;
- les arguments du chargeur de démarrage de la machine paravirtualisée "--bootloader_args" (indiqués à l'Étape 5).
REMARQUE :s'il existe déjà une VM du même nom que celui transmis nouveau_nom_vm, l'utilitaire xmps échoue.

La nouvelle VM paravirtualisée (SLES10-PV) doit maintenant être disponible dans le gestionnaire de machines virtuelles, prête à être activée. La machine entièrement virtualisée correspondante est retirée et ne peut pas démarrer. Cette VM peut être supprimée en toute sécurité (seule la configuration de VM sera supprimée).
Démontez l'image ISO de démarrage de PlateSpin Linux :
```
# umount /mnt/ps
```

Migration de Linux vers une VM paravirtualisée existante

Copiez l'image ISO de démarrage PlateSpin Linux vers le serveur Xen/SLES cible.

Reportez-vous au Tableau 3-2, Images ISO de démarrage pour des machines physiques cibles.
Connectez-vous au serveur XEN/SLES en tant que root et montez l'image ISO de démarrage PlateSpin Linux :
```
# mkdir /mnt/ps
# mount -o loop /root/linuxphysicaltarget.iso /mnt/ps
```
Exécutez l'utilitaire xmps pour créer une VM entièrement virtualisée basée sur la configuration de la VM paravirtualisée (la cible de rétablissement visée) :
```
# /mnt/ps/tools/xmps --fv --vm_name=SLES10-PV  --new_vm_name=SLES10-FV --bootiso=/root/linuxphysicaltarget.iso
```
L'utilitaire utilise en entrée :
- le nom de la machine paravirtualisée existante (SLES10-PV), qui est la cible de rétablissement visée ;
- le nom de la machine entièrement virtualisée temporaire (SLES10-FV) à créer pour l'opération de rétablissement en deux étapes ;
- le chemin d'accès complet de l'image ISO de démarrage (en partant du principe que le fichier ISO se trouve dans /root: /root/linuxphysicaltarget.iso).
REMARQUE :s'il existe déjà une VM du même nom que celui transmis nouveau_nom_vm, l'utilitaire xmps échoue.

La nouvelle machine entièrement virtualisée (SLES10-FV) doit maintenant être disponible dans le gestionnaire de machines virtuelles.
Activez la nouvelle machine entièrement virtualisée (SLES10-FV).

La VM démarre dans l'environnement système PlateSpin utilisé dans les paramètres X2P.
Terminez la migration.

Reportez-vous à la section Migration d'un workload vers l'hyperviseur Xen sous SLES.
Redémarrez la VM, exécutez switch et reconfigurez le workload comme décrit à la section Migration de Linux vers une nouvelle VM paravirtualisée (de l'Étape 4 à l'Étape 9 uniquement).