2.4.1 Schémas et plan du réseau
IP = 10.1.2.153
Figure 2.5 : schéma réseau du scénario 1, vMotion sur ESXi à 100Mbps
2.4.2 Méthodologie
Pour ce scénario, le réseau utilisé fonctionne à 100Mbps, ce choix permettant de garantir que les PC Wireshark 1 et 2 puissent capturer tous les paquets sans saturation du buffer. De cette façon, l’analyse effectuée sera plus pertinente, et les diverses étapes seront plus distincte sur un diagramme temporel.
1. Les Best Practices (http://www.vmware.com/pdf/vc_technical_best.pdf p.12) recommandent de séparer le réseau de gestion (ESXi et VI Serveur/Client) du réseau de stockage (ESXi et disques de stockage), utilisé par vMotion. Cependant, sur les serveurs ESXi, il n’est pas possible d’ajouter une deuxième console de management, alors qu’il serait nécessaire d’en avoir une pour le réseau de management et une autre pour le réseau de stockage. C’est pourquoi ces deux réseaux sont réunis en un pour ce scénario.
2. L’observation des échanges côté ESXi est effectuée par une machine physique, Wireshark 1, dont le port de connexion sur le switch est configuré pour le monitoring. Ce choix permet de faire des captures globales des échanges en utilisant un port de monitoring. Le switch possède 24 ports, de marque Cisco modèle Catalyst 2950.
3. Les VM sont connectées au même switch physique que les serveurs ESXi, mais dans un autre VLAN
4. Un client Ubuntu est déplacé via vMotion entre les deux serveurs ESXi. Durant ces transferts, il exécute un script téléchargeant en boucle une page sur un serveur web (voir annexe A.8). La mémoire RAM de cette machine est de 256MB, dont 247MB sont occupés 5. Le serveur est une autre VM Ubuntu, tournant sur un serveur ESX qui n’est pas impliqué
dans l’échange vMotion.
6. Sur ce même hôte ESX, une VM Windows XP (Wireshark 2) monitore les échanges de données entre les deux autres VMs.
7. Le vSwitch auquel sont connectés le serveur web Ubuntu et la VM Wireshark 2 est configuré en hub, de sorte à rendre la capture des paquets échangés possible. Grâce à Wireshark 2, il est possible de voir quand et durant combien de temps la machine déplacée par vMotion est indisponible.
8. Toutes les VMs sont stockées sur le disque iSCSI.
J’ai choisi de virtualiser le serveur Ubuntu et le pc d’observation XP par besoin d’utiliser un hub pour la capture des échanges entre les VMs. Dans ce scénario, j’aurais pu configurer un autre port de monitoring et utiliser des machines physiques, mais pour le scénario suivant, le switch ne sera pas configurable. Ce choix unifie ainsi la manière de prendre les mesures.
Une comparaison du nombre de paquets capturés via Wireshark avec les compteurs de paquets du switch sera également effectuée afin d’être sûr qu’aucun paquet n’a été perdu par Wireshark. Une autre capture comprenant les réseaux applicatif, de gestion et de stockage sera également effectuée afin de voir de façon plus précise les concordances temporelles entre les captures faites précédemment. Pour ce faire, le switch sera configuré de sorte à ce que le PC physique d’observation puisse monitorer les ports des VMs en plus des ports déjà monitorés pour les premières captures.
Pour plus de précisions, une dizaine de migrations par vMotion sera effectuée.
2.4.3 Mesures
La quantité de paquets capturés par Wireshark 1 et 2 correspond à celle que le switch indique avoir fait transiter par les ports de connexion des dites machines. Les chiffres indiqués sont des moyennes des valeurs obtenues dans les captures scénario 1/physique_X, scénario 1/virtuel/virtuel_X et scénario 1/global.pcap disponible sur le DVD. Pour plus d’information, reportez-vous au fichier READ ME du dossier scénario 1.
Lors des mesures, le temps de transfert moyen indiqué par le VI Client est de 70 secondes, cependant, les relevés effectués avec Wireshark montrent que la quasi-totalité des échanges ont lieu dans un intervalle d’environ 32 secondes (A, B, C et D sur la figure de la page suivante). Je pense que cette différence constatée entre les temps indiqués vient du fait que les transferts ne commencent pas tout de suite, il faut d’abord que l’ordre soit donné et que les hôtes concernés libèrent les ressources nécessaires à un transfert rapide. De même, à la fin du transfert, le VI Client attend que la VM soit de nouveau complètement opérationnelle pour considérer le transfert terminé. Or comme on peut le voir sur la figure 2.6, le trafic réseau ne reprend pas instantanément à la fin des échanges sur le réseau de gestion et stockage.
Le temps d’inactivité moyen est de 8.8 secondes (C et D sur la figure de la page suivante), soit environ 12.5% du temps de transfert annoncé par le VI Client.
Figure 2.6 : les différentes étapes d’un transfert par vMotion
La figure ci-dessus est obtenue à partir du fichier scénario 1/global.pcap disponible sur le DVD.
Concernant les filtres à appliquer, reportez-vous au fichier READ ME.txt disponible dans le même dossier.
A. Cette partie des échanges a lieu entre le disque iSCSI et les serveurs ESXi. Le volume de données transféré est de 3.3MB sur une période de 1.5 à 2 secondes.
B. C’est là que sont transférés plus de 90% des données de l’échange par vMotion. Durant cette étape, une pré-copie de la RAM est effectuée entre les 2 serveurs ESXi, alors que la VM est encore en fonction. La durée de ces échanges est de 25 secondes pour une quantité de données échangées valant 290.4MB (taille comprenant également le début de la partie C : envoi des changements de la RAM). Cette taille correspond à la RAM occupée sur la VM plus environ 7% de la valeur de la RAM répartit entre le ré-envoi de la RAM (début C), les en-têtes des paquets et les paquets servant à la gestion de l’échanges.
Si des écritures devaient avoir lieux dans une zone de la RAM déjà pré-copiée, elles seraient inscrites dans un fichier bmp qui sera envoyé au début de la partie C.
C. Durant cette partie de l’échange, la VM est mise en pause. On peut décomposer cette partie en deux sous partie :
l’envoi des changements de la RAM, durant 0.5 à 1 secondes qui est similaire à la partie B, tant en vitesse de transmission que dans le type de paquets transmis.
l’envoi des données non RAM, qui dure environ 6 secondes pour un envoi de 12.1MB entre le disque iSCSI et le serveur ESXi sur lequel la VM est déplacée.
D. Durant cette étape, la VM est remise en fonctionnement. Dès qu’elle est résumée, elle envoie une requête ARP contenant sa propre MAC address en broadcast afin de faire connaître son nouvel emplacement sur le réseau. On peut constater que cette requête est émise environ 1 seconde avant que les échanges entre la VM et le serveur de test ne reprennent. Je pense donc que cette requête est envoyée pendant que la machine se remet en fonction, mais avant d’être à nouveau totalement fonctionnelle.
On peut également voir 2 pics de données qui ont lieu entre l’ESXi sur lequel tournait la VM au début de l’échange et le disque iSCSI, qui servent surement à libérer définitivement les ressources sur le serveur ESXi en question. Cependant, je n’ai aucune certitude à ce sujet.
Les échanges impliquant le VI Client / Serveur sont peu importants en volume par pics, mais comme ils ont lieu sur toute la durée du transfert, ils représentent un volume de 5.3MB. Ces échanges ont lieu uniquement avec les hôtes ESXi.
Il est intéressant d’observer que la totalité des échanges a lieu en TCP, l’UDP n’offrant, de par sa conception, pas la sécurité requise pour le déplacement d’une VM.
VI Serveur et Client
Figure 2.7 : plan du réseau indiquant les flux entre les machines
2.4.3.1 Échanges entre l’hôte source et l’hôte de destination
Ces échanges se déroulent durant la partie B et le début de la partie C de la figure 2.6. Ils consistent en 2 sessions TCP simples (pas de surcouches protocolaires entre l’application et le TCP) entre les serveurs ESXi. Pour rappel, ces échanges se produisent durant 25 secondes, pour un volume de données de 290.4MB.
La session 1 représente 99.99% des paquets échangés. C’est le serveur ESXi qui possède la VM au début de l’échange qui l’initialise, avec un port de départ compris entre 2050 et 5000, à destination du port 8000 de l’autre serveur ESXi. Le port 8000 permet l’accès à la console de service qui permet de contrôler le serveur ESXi cible. Je pense donc que le serveur possédant la VM pilote ainsi celle qui doit en prendre le contrôle pour lui dire ce qu’elle doit télécharger et quand. On peut constater que
la moitié des paquets a une taille comprise entre 40 et 159 Bytes, alors que l’autre moitié se situe entre 640 et 1514 Bytes par paquet. Cela indique qu’il y a autant de paquets servant au contrôle de l’échange qu’à l’échange à proprement parler.
La session 2 est la même, mais dans le sens inverse. Je pense qu’elle permet au serveur de destination d’orienter le serveur ESXi de départ dans les différentes étapes en le tenant informé de l’état de charge dans lequel il se trouve. Je ne me suis cependant pas trop attardé sur cette session, vu le faible pourcentage des transferts qu’elle représente.
2.4.3.2 Échanges entre le disque iSCSI et les hôtes ESXi
Ces échanges sont présents dans les parties A et C de la figure 2.6, soit un volume total de 15.3 MB.
On constate deux paires de partenaires pour ces échanges :
Le serveur ESXi sur lequel on veut déplacer la VM et le disque iSCSI (92.6% des échanges du iSCSI)
Le serveur ESXi sur lequel est la VM et le disque iSCSI (7.4% des échanges du iSCSI)
Dans les deux cas, les échanges utilisent la même structure. Le iSCSI est un protocole qui permet de faire des échanges de données/envoi de commande SCSI au travers d’un réseau IP. iSCSI se présente comme une surcouche au protocole TCP.
J’ai pu remarquer 3 types d’opérations lors des transferts (voir les fichiers Wireshark physique_X et global indiqué au début du point 2.4) :
Lecture de la capacité du disque Lecture de données
Écriture de données
Pour plus d’informations, veuillez vous référer au chapitre 1.4.
2.4.3.3 Échanges comprenant le VI Serveur / Client
Ces échanges ont lieu tout le long de la transmission de la VM par vMotion et leur volume est de 5.3MB. Ils ont uniquement lieu avec les serveurs ESXi, principalement avec celui qui héberge la VM au début de l’échange. J’ai pu constater qu’une fois la pré-copie terminée, ils deviennent insignifiants. Comme la console distante était ouverte sur le PC qui héberge le VI Serveur, je présume que la plupart de ces derniers servent à rafraichir l’affichage de la console distante. Le reste des échanges sert à la transmission d’informations comme l’avancement du vMotion, les logs, etc...
Les protocoles utilisés sont TCP simple à hauteur de 93.6% et SSL version 3 à hauteur de 6.65% des paquets échangés.