disponibilité d’une architecture virtualisee vmware esx esxi

Upload: waylead

Post on 08-Jul-2015

434 views

Category:

Documents


0 download

TRANSCRIPT

Disponibilit dune architecture virtualise avec VMware ESX-ESXiTravail de diplmeSession 2009

Professeur : LITZISTORF Grald tudiant : SANDMEIER Loc Filire Tlcommunications Laboratoire de transmission de donnes

Mise en uvre des fonctions volues vMotion

2

Table des matiresI Introduction .......................................................................................................................................... 6 II Remerciements .................................................................................................................................... 6 III Convention dcriture ......................................................................................................................... 7 1 tude du matriel et des logiciels utiliss ............................................................................................ 8 1.1 Composants du rseau.................................................................................................................. 8 1.2 SAN ................................................................................................................................................ 9 1.3 LUN.............................................................................................................................................. 10 1.4 VMFS ........................................................................................................................................... 11 1.5 iSCSI ............................................................................................................................................. 12 1.5.1 Introduction ......................................................................................................................... 12 1.5.2 Adressage ............................................................................................................................. 14 1.5.3 Oprations sur un disque iSCSI ............................................................................................ 16 1.5.3.1 Connexion au disque iSCSI ............................................................................................ 17 1.5.3.2 Liste des LUNs disponible.............................................................................................. 18 1.5.3.3 Infos globales propos du disque ................................................................................ 19 1.5.3.4 Lecture de la capacit du LUN cible .............................................................................. 20 1.5.3.5 Lecture de donnes....................................................................................................... 21 1.5.3.6 criture de donnes ...................................................................................................... 22 1.5.3.7 Rservation du LUN suivi dune criture ...................................................................... 23 1.5.3.8 Logout ........................................................................................................................... 23 2 vMotion .............................................................................................................................................. 24 2.1 Introduction ................................................................................................................................ 24 2.2 Fonctionnement.......................................................................................................................... 25 2.3 Paramtres .................................................................................................................................. 27 2.4 Scnario 1 : vMotion entre serveurs ESXi sur un rseau 100Mbps ......................................... 28 2.4.1 Schmas et plan du rseau .................................................................................................. 28 2.4.2 Mthodologie....................................................................................................................... 28 2.4.3 Mesures................................................................................................................................ 29 2.4.3.1 changes entre lhte source et lhte de destination ................................................. 31 2.4.3.2 changes entre le disque iSCSI et les htes ESXi .......................................................... 32 2.4.3.3 changes comprenant le VI Serveur / Client................................................................. 32 2.5 Scnario 2 : vMotion entre serveurs ESXi sur un rseau 1Gbps .............................................. 33 2.5.1 Schmas et plan du rseau .................................................................................................. 33

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

3

2.5.2 Mthodologie....................................................................................................................... 33 2.5.3 Mesures................................................................................................................................ 34 2.6 Scnario 3 : vMotion entre serveurs ESX sur un rseau 100Mbps .......................................... 35 2.6.1 Schmas et plan du rseau .................................................................................................. 35 2.6.2 Mthodologie....................................................................................................................... 35 2.6.3 Mesures................................................................................................................................ 36 2.7 Scnario 4 : vMotion entre ESX sur un rseau 1Gbps .............................................................. 41 2.7.1 Schmas et plan du rseau .................................................................................................. 41 2.7.2 Mthodologie....................................................................................................................... 41 2.7.3 Mesures................................................................................................................................ 42 2.8 Conclusion ................................................................................................................................... 42 3 Distributed Resource Scheduler ........................................................................................................ 43 3.1 Introduction ................................................................................................................................ 43 3.2 Cluster ......................................................................................................................................... 44 3.3 Fonctionnement.......................................................................................................................... 45 3.3.1 Rservations ......................................................................................................................... 45 3.4 Paramtres .................................................................................................................................. 46 3.5 Topologie et plans du rseau ...................................................................................................... 47 3.6 Scnario 5 : dplacement manuel .............................................................................................. 48 3.6.1 Configuration teste et mthodologie ................................................................................ 48 3.6.2 Mise en uvre de la configuration de DRS ......................................................................... 49 3.6.3 Observations et mesures ..................................................................................................... 50 3.7 Scnario 6 : dplacement automatique, sensibilit maximum .................................................. 53 3.7.1 Configuration teste et mthodologie ................................................................................ 53 3.7.2 Mise en uvre de la configuration de DRS ......................................................................... 53 3.7.3 Observations et mesures ..................................................................................................... 54 3.8 Scnario 7 : dplacement automatique, changement du rglage de la sensibilit .................... 55 3.8.1 Configuration teste et mthodologie ................................................................................ 55 3.8.2 Mise en uvre de la configuration de DRS ......................................................................... 55 3.8.3 Observations et mesures ..................................................................................................... 56 3.9 Scnario 8 : 2 VMs doivent rester ensemble .............................................................................. 57 3.9.1 Configuration teste et mthodologie ................................................................................ 57 3.9.2 Mise en uvre de la configuration de DRS ......................................................................... 57 3.9.3 Observations et mesures ..................................................................................................... 59

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

4

3.10 Scnario 9 : 2 VMs ne doivent pas tre sur le mme serveur ESX............................................ 60 3.10.1 Configuration teste et mthodologie .............................................................................. 60 3.10.2 Mise en uvre de la configuration de DRS ....................................................................... 61 3.10.3 Observations et mesures ................................................................................................... 61 3.11 Conclusion ................................................................................................................................. 61 4 Conclusions ........................................................................................................................................ 62 A Annexes ............................................................................................................................................. 63 A.1 Versions des logiciels utiliss ...................................................................................................... 63 A.2 Matriel ...................................................................................................................................... 63 A.3 Installation dOpenfiler ............................................................................................................... 63 A.4 Installation et configuration de ESX/ESXi ................................................................................... 64 A.4.1 ESXi ...................................................................................................................................... 64 A.4.2 ESX ....................................................................................................................................... 64 A.5 Virtual Infrastructure Server (VI Server) ..................................................................................... 65 A.6 Virtual Infrastructure Client (VI Client) ....................................................................................... 68 A.6.1 Installation ........................................................................................................................... 68 A.6.2 Ajout/cration dun Datacenter .......................................................................................... 68 A.6.3 Ajout dun host .................................................................................................................... 69 A.6.4 Ajout dun VMkernel............................................................................................................ 72 A.6.5 Ajout dun disque iSCSI ........................................................................................................ 76 A.6.6 Activation de vMotion ......................................................................................................... 83 A.6.7 Dplacer une VM laide de vMotion ................................................................................. 85 A.6.8 Cration dun cluster DRS .................................................................................................... 87 A.7 Tests du switch NETGEAR ........................................................................................................... 92 A.7.1 Schmas et plans du rseau ................................................................................................ 92 A.7.2 Mthodologie ...................................................................................................................... 92 A.7.3 Mesures ............................................................................................................................... 92 A.8 Script ........................................................................................................................................... 93 A.9 Problmes rencontrs et bugs .................................................................................................... 94 A.9.1 Bug de dconnection alatoire ............................................................................................ 94 A.9.2.1 Symptmes ................................................................................................................... 94 A.9.2.2 Cause............................................................................................................................. 94 A.9.2.3 Solution ......................................................................................................................... 94 A.9.2 Problme deffacement des VMs ........................................................................................ 94

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

5

A.9.2.1 Symptmes ................................................................................................................... 94 A.9.2.3 Solutions ....................................................................................................................... 94 A.9.3 Problme lors dusage simultan de plusieurs VMs ............................................................ 95 A.9.3.1 Symptmes ................................................................................................................... 95 A.9.3.2 Solutions et causes ....................................................................................................... 95 A.9.4 Erreur lors daccs certaines pages de linterface web dOpenfiler ................................. 95 A.9.4.1 Symptmes ................................................................................................................... 95 A.9.4.2 Cause et solution .......................................................................................................... 96

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

6

I IntroductionActuellement, les solutions de virtualisation sont de plus en plus utilises, et encore plus particulirement celles proposes par VMware. Il y a plusieurs raisons cela, dont la principale est lconomie que reprsentent de telles solutions. En effet, l ou il tait ncessaire davoir de nombreux serveurs physiquement indpendants, seuls 2 ou 3 serveurs hbergeant des machines virtuelles suffisent (ces serveurs sont plus puissant que les serveurs traditionnels, mais cette puissance est mieux exploite). Il est galement trs ais de crer de nouvelles machines virtuelles, ce qui savre trs pratique en environnement de test. Cependant, plusieurs serveurs virtuels sur un mme matriel impliquent que si ce matriel est dfectueux, ou quun serveur virtuel mobilise trop de ressources, il peut en rsulter une indisponibilit dune partie ou de la totalit des machines virtuelles. Cest l quinterviennent les fonctionnalits proposes par VMware pour ses serveurs ESX et ESXi, testes lors de ce projet. Mon choix sest port sur ce projet, car la virtualisation mintresse particulirement pour plusieurs raisons, la principale tant la curiosit. Je connaissais dj les machines virtuelles, mais le cours dispens par M. Litzistorf ma permis de me rendre compte de ltendue des possibilits offertes par les serveurs ESX et ESXi, que je ne connaissais pas. Mon travail sest droul en 4 parties, durant une priode de 8 semaines : 1. Installation et configuration des produits VMware, et correction des problmes et bugs de fonctionnement. Cette premire partie, rpartie tout au long du projet, a dur environ trois semaines. 2. Comprendre et expliquer le fonctionnement des logiciels et du matriel utilis. Cette partie explique principalement le fonctionnement des disques iSCSI utilis pour stocker les machines virtuelles. Cette premire partie sest droule sur une priode dune semaine et demi. 3. Tester et comprendre le fonctionnement de vMotion, une fonctionnalit qui permet de dplacer une machine virtuelle dun serveur physique un autre alors quelle est en tat de fonctionnement. VMware annonce que lors de ce type de dplacement, aucune interruption de service na lieu, lobjectif principal est donc de vrifier cette affirmation. Cette partie fut llment central de mon travail, elle sest droule sur une priode de 4 semaines. 4. Tester plusieurs configurations de DRS, une fonctionnalit qui pour but dquilibrer la charge CPU et RAM des serveurs ESX et ESXi faisant partie dun mme groupe. DRS utilise vMotion pour rquilibrer la charge, cest pourquoi cette partie nest tudie quaprs vMotion. 4 jours ont t consacrs ltude de cette fonctionnalit.

II RemerciementsJe tiens remercier M. Grald LITZISTORF pour mavoir propos ce projet et galement pour ses conseils et recommandations. Je remercie aussi M. Jos TAVARES pour son aide.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

7

III Convention dcritureLe texte crit en gras est important, celui crit en italique est une citation ou, dans les annexes, le texte sur un bouton cliquer. Le texte entre guillemets est une copie dune partie du texte dune boite de dialogue. Le texte blanc sur fond noir correspond aux lignes de commandes. Labrviation VM signifie Virtual Machine ou Machine Virtuelle en franais, et VI signifie Virtual Infrastructure.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

8

1 tude du matriel et des logiciels utiliss1.1 Composants du rseauVM 1 Serveur ESX/ ESXi Switch 1 Rseau de gestion Switch 2 Rseau de stockage

VI Server et VI Client

Disque iSCSI Fichiers VM 1 Fichiers VM 2

VM 2 Serveur ESX/ ESXi

Figure 1.1 : plan regroupant les principaux composants rseau

Les composants du rseau sont : Le VI Serveur (rseau de gestion) Le VI Client (rseau de gestion) Le disque iSCSI (rseau de stockage) Les serveurs ESX/ESXi (rseau de gestion et rseau de stockage) Le VI Serveur est un service Windows qui supervise/contrle un ou plusieurs serveurs ESX/ESXi qui lui ont t attribus. vMotion et DRS exigent sa prsence. Le VI Client est linterface utilisateur qui se connecte soit directement sur un serveur ESX/ESXi, soit sur le VI Serveur, permettant de contrler plusieurs serveurs dans une seule fentre et dexploiter les fonctionnalits du VI Serveur. Le VI Client peut tre install sur plusieurs machines, dont celle qui hberge dj le service du VI Serveur (configuration utilise lors de mon travail). Le disque iSCSI contient les fichiers des VMs dun ou plusieurs serveurs ESX/ESXi. Ces fichiers correspondent : au disque dur virtuel, dont la taille varie selon la quantit de donnes contenues la partition swap, de taille galement variable, et uniquement prsente lorsque la VM est en fonction la description des caractristiques matrielles de la VM (CPU, RAM, disque dur virtuel, ...), de taille plus petite que 3kB aux logs de la VM, de taille maximum quivalente 30kB Comme plusieurs serveurs peuvent y accder, son utilisation rend possible des fonctions comme vMotion en rduisant la quantit de donnes dplacer lors dune migration. Nayant pas de disque iSCSI physique, un disque a du tre mul. Pour cette mulation, le premier choix a t dutiliser FreeNAS (une distribution BSD base sur FreeBSD), hlas, ce dernier supportait mal les accs multiples, rendant lensemble de linfrastructure inutilisable (voir annexe A.9.3). Cest pourquoi le

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

9

choix sest port sur Openfiler (une distribution GNU/Linux) qui gre correctement ces accs multiples, mais qui ne permet pas de profiter pleinement des capacits dun rseau gigabit (plus de 12 minutes pour transfrer 3 GB, soit 3.9 MBps, voir annexe A.7). Les serveurs ESX/ESXi ont pour rle de faire fonctionner les VMs en leur attribuant les ressources ncessaires. Il sagit la base dun OS GNU/Linux RedHat modifi et allg le plus possible par VMware. ESXi est la version gratuite et allge de ESX. Les deux types ont t utilis pour comparer les diffrences entre un produit payant et un autre gratuit, tant au niveau des performances que des fonctionnalits. Les VI Client et Serveur ainsi que les serveurs ESX sont en version 3.5, avec des licences dvaluations. Cette version tait la plus rcente au moment ou mon travail de diplme a dbut, si bien que nous avons convenu de ne pas utiliser la version 4, vSphere, sortie le 21 avril 2009.

1.2 SANSelon Wikipedia, http://fr.wikipedia.org/wiki/R%C3%A9seau_de_stockage_SAN, un SAN, Storage Area Network ou rseau de stockage, se diffrencie des autres systmes de stockage tel que le NAS (Network attached storage) par un accs bas niveau aux disques. Pour simplifier, le trafic sur un SAN est trs similaire aux principes utiliss pour l'utilisation des disques Internes (ATA, SCSI). C'est une mutualisation des ressources de stockage. Dans le cas du SAN, les baies de stockage n'apparaissent pas comme des volumes partags sur le rseau. Elles sont directement accessibles en mode bloc par le systme de fichiers des serveurs. En clair, chaque serveur voit l'espace disque d'une baie SAN auquel il a accs comme son propre disque dur. L'administrateur doit donc dfinir trs prcisment les LUNs (units logiques), le masking et le zoning, pour qu'un serveur Unix n'accde pas aux mmes ressources qu'un serveur Windows utilisant un systme de fichiers diffrent. Lutilisation dun SAN est ncessaire pour utiliser des fonctionnalits comme vMotion. Le SAN utilis durant ce projet contient le disque iSCSI mul par Openfiler ainsi que les serveurs ESX et ESXi. Une fois le disque li aux serveurs ESX/ESXi, ces derniers y accdent comme si le disque tait une database interne. Il est recommand dans les bests parctices (http://www.vmware.com/pdf/vc_technical_best.pdf p.12) dutiliser un rseau ddi pour le stockage, bien que ce ne soit pas toujours possible, comme je lexplique au dbut du scnario 1 (chapitre 2.4).

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

10

1.3 LUNSelon Wikipedia, http://fr.wikipedia.org/wiki/LUN, un LUN (Logical Unit Number) est, en informatique, un "identifiant d'unit logique", c'est--dire un pointeur vers un espace de stockage. Un LUN est caractris par sa taille (en Giga octets en gnral). Un contrleur iSCSI peut grer jusqu 8 units logiques, le LUN est donc cod sur 3 bits. Le seul moment o lon voit les LUNs dans lutilisation des produits VMware, cest au moment de lajout dun disque iSCSI un serveur ESX/ESXi. Si ce dernier nest pas format en VMFS, il ne sera pas dtect automatiquement, il faut donc le configurer la main. Durant cet ajout, tout les LUNs vu par le serveur sont propos, et il faut choisir lequel sera format. Pour plus dinfo, voir le chapitre A.6.5.

Figure 1.2 : choix du LUN formater

Lappareil est galement identifi par une chaine de la forme vmhba32 :0 :0. Selon le document http://publib.boulder.ibm.com/infocenter/dsichelp/ds6000ic/index.jsp?topic=/com.ibm.storage.smr ic.help.doc/f2c_vmesxlunprobe_1m5c8p.html, cet identifiant peut tre dcompos en trois parties : La premire partie, vmhba32, dfinit le contrleur iSCSI utilis. Le chiffre 32 peut varier dune machine lautre, mais vmhba est fixe. Le premier 0 identifie le disque iSCSI (la cible) sur lequel se trouve lunit logique. Le second zro correspond au LUN.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

11

1.4 VMFSLe VMFS, ou Virtual Machine File System, est le systme de fichiers pour les units de stockage dvelopp par VMware. La principale raison de la cration de ce systme de fichiers est la ncessit de garantir laccs concurrent en lecture et criture aux mmes fichiers plusieurs clients (dans ce cas, les serveurs ESX/ESXi). Cet accs concurrent est vital pour des fonctionnalits telles que vMotion, hors les systmes de fichiers utiliss, par exemple, par les disques iSCSI ne permettent pas ce genre dopration. Par le biais du VI Client, il est possible de formater des units logiques sur des disques (i)SCSI en VMFS. Le LUN devient ainsi un volume VMFS. Comme il permet laccs multiple, le VMFS doit galement garantir que laccs en criture nest possible que depuis un client la fois. Un systme de verrous est ainsi utilis pour garantir quune seule criture la fois est ralise sur un fichier donn. Lutilisation du VMFS est transparente pour lutilisateur, qui indique les oprations effectuer depuis le VI Client, mais na pas besoin dintervenir lors du droulement de ces dernires. Voici un lien vers la fiche du produit (en anglais) : http://www.vmware.com/pdf/vmfs_datasheet.pdf

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

12

1.5 iSCSICe chapitre sappuie principalement sur le document http://docs.hp.com/en/T1452-90011/T145290011.pdf 1.5.1 Introduction Le SCSI est un protocole qui permet de communiquer avec des units (disque dur, lecteur CD, imprimante) lintrieur dun SAN. Le protocole iSCSI transporte le primitives SCSI au travers dun rseau IP. De ce fait, pour comprendre le fonctionnement du iSCSI, il est ncessaire de comprendre celui du SCSI. Lors dun change SCSI, on a dun ct linitiateur (le client) et de lautre, la cible (le serveur). Le disque dur (ou autre priphrique) SCSI se situe sur la cible, qui est composes dune ou plusieurs units logiques. Chaque unit logique est indpendante, et peut donc recevoir des commandes de la part de linitiateur. Pour savoir quelle unit est destine une commande, chaque unit se voit attribuer un LUN (voir 1.5.1). Ce LUN est joint chaque requte. Le protocole SCSI est prvu pour tre utilis sur des rseaux de donnes ddis haute vitesse (souvent fiber channel). Seulement, ces solutions sont extrmement couteuses, et par consquent, les entreprises de petite et moyenne tailles ne peuvent pas se permettre ce type dinvestissement. Cest pour cette raison quest n le iSCSI. Le protocole iSCSI, qui est une surcouche du TCP, encapsule les requtes (les primitives) SCSI afin de les faire transiter sur un rseau IP.

Figure 1.3 : empilement protocolaire du iSCSI

Pour plus de dtails, voici un lien qui explique bien et de faon simple le fonctionnement de iSCSI : http://www.supinfo-projects.com/fr/2006/stockres_fr/4/.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

13

Les messages changs entre un initiateur et une cible sont appel PDU (iSCSI Protocol Data Unit). Cest les messages PDU qui contiennent les requtes ainsi que les rponses SCSI. Ces messages ne sont pas limits la taille disponible dans un paquet TCP, ils peuvent tre segment et envoy dans plusieurs paquets TCP. Ils sont de la forme suivante :

Figure 1.4 : message PDU

Seule la partie entte est obligatoire, les commandes ne ncessitant pas toujours un transfert de donnes. Par exemple, voici lentte et les donnes dune rponse une demande de lecture (pour plus de dtails, voir chapitre 1.5.3.5) :

Figure 1.5 : entte dune rponse une requte de lecture

Figure 1.6 : donnes dune rponse une requte de lecture

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

14

1.5.2 Adressage Ladressage utilis par Openfiler est de type iqn (iSCSI Qualified Name). Il existe un deuxime type dadresse (eui ou IEEE EUI-64 format), qui ne sera pas dtaill dans ce document. Selon http://www.cuddletech.com/articles/iscsi/ar01s02.html, un iqn est de la forme suivante :

iqn.2006-01.com.openfiler:tsn.9ed4ca97e298iqn est fixe, il permet didentifier le type dadressage utilis. 2006-01 correspond au premier mois entier ou le nom de domaine dauthentification a t en fonction. com.openfiler est le nom du domaine dauthentification invers (openfiler.com). Cest ce domaine qui attribue ladresse iqn. Ce qui suit les deux points est une chaine de caractres dtermine par le domaine dauthentification ne suivant aucune rgle particulire. Chaque domaine est libre de choisir ses propres rgles ou de gnrer alatoirement cette suite de caractres. Pour obtenir cette adresse en mode dynamic discovery, il faut tablir une session avec le disque iSCSI voulu en se servant de son adresse IP. Cette session ne restera ouverte que le temps dobtenir ladresse iqn du disque cible. Voici les changes qui permettent daboutir son obtention : Login Request (annonce du type de session dsir, mthode dauthentification) Login Response (connexion accepte) Login Request (indication des mthodes connues pour signer lchange, proposition de configuration pour divers paramtre) Login Response (mthodes acceptes, indication des valeurs retenue pour les paramtres) Command (demande de lenvoi de ladresse des cibles utilisant cette adresse IP) Response (adresse des cibles) Logout Request (demande de dconnection) Logout Response (validation de la demande)

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

15

Voici un exemple pratique dobtention dadresse iqn :

Figure 1.7 : annonce du type de session voulu

Figure 1.8 : session accept

Figure 1.9 : annonce des mthodes de hash connues et proposition de valeurs pour divers paramtres

Figure 1.10 : indications des mthodes de hash choisie et valeurs retenues pour les paramtres

Figure 1.11 : demande de lenvoi des adresses iqn des cibles

Figure 1.12 : envoi de la liste

Le logout ne comportant pas de paramtres particuliers, les captures dcrans ne sont pas ncessaires.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

16

1.5.3 Oprations sur un disque iSCSI Pour illustrer les oprations quil est possible deffectu sur un disque iSCSI, le scnario pdagogique suivant va tre employ : On effectuera en premier lieu une connexion sur le disque iSCSI (p.15) On demandera ensuite au disque de nous fournir une liste des LUNs quil contient (p.16) On lui demandera galement des informations plus globales (p.17) On cherchera connatre la capacit du LUN cible (p.18) On procdera une lecture sur un LUN (p.19) Suivra une criture sur le mme LUN (p.20) Une rservation du disque sera effectue, durant laquelle une criture aura lieu (p.21) Pour finir, il faudra se dconnecter du disque (p.21) On part du principe que lors de ces changes, lidentifiant iqn de la cible est connu par linitiateur. Ces oprations ncessitent une ou plusieurs commandes SCSI. Pour toutes commandes, il faut prciser le disque de destination ainsi que le LUN (voir chapitre 1.3), au cas o le disque hbergerait plusieurs LUNs. La version des commandes SCSI utilise est SPC-2, cette information est communiqu au travers du premier Inquiry (voir p.17) de chaque LUN :

Figure 1.13 : version des commandes iSCSI utilises

Les points suivants sappuient sur la page Wikipedia suivante http://en.wikipedia.org/wiki/SCSI_command ainsi que les pages qui y sont relies. Les autres sources seront indiques au cas par cas. Les captures Wireshark do sont extraites les captures dcran utilises pour illustrer ce scnario sont disponibles sur le DVD : iSCSI/iSCSI_rescan.pcap et iSCSI/ech_xp.pcap en utilisant le filtre ip.addr==10.1.1.54 (et 10.1.2.155 pour la 2me capture). La premire capture est obtenue grce la commande esxcfg-swiscsi s, qui lance une dcouverte des LUNs sur les disques iSCSI qui lui sont lis. La commande est effectue depuis un serveur ESX, et est issue du document http://www.rtfmed.co.uk/docs/vmwdocs/ESX3.x-VC2.x-ServiceConsole-Guide.pdf. La deuxime capture est issue dun change de fichiers entre le disque iSCSI et un poste sous Windows XP, et contient galement la dtection du disque iSCSI au poste XP. Comme le scnario est pdagogique, il ne suit pas lordre des captures Wireshark, les paquets ont t choisit afin dillustrer le scnario dcrit plus haut.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

17

1.5.3.1 Connexion au disque iSCSI Durant la phase de connexion (ou login), le but est didentifi, avec ou sans mot de passe, les participants (la cible et linitiateur) des futurs changes. Pour simplifier, aucun mot de passe ne sera utilis dans cet exemple. Les changes suivants ont lieu durant cette tape (linitiateur est gauche, il en sera de mme pour tout les changes suivants) : Login Request (annonce du type de session dsir, annonce de la mthode dauthentification) Login Response (connexion accepte) Login Request (indication des mthodes connues pour signer lchange, proposition de configuration pour divers paramtre) Login Response (mthodes acceptes, indication des valeurs retenue pour les paramtres)

Figure 1.14 : annonce du type de session voulu et annone de la cible voulue

Figure 1.15 : session accept

Figure 1.16 : annonce des mthodes de hash connues et proposition de valeurs pour divers paramtres

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

18

Figure 1.17 : indications des mthodes de hash choisie et valeurs retenues pour les paramtres

1.5.3.2 Liste des LUNs disponible Cette phase permet dobtenir une liste des LUNs disponibles sur le disque. Les changes suivants ont lieu durant cette tape : Report LUNs Report LUNs Response (Liste des LUNs)

Figure 1.18 : liste des LUNs obtenue suite lchange

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

19

1.5.3.3 Infos globales propos du disque Il sagit ici dobtenir des informations propos du disque allant du constructeur jusqu la mthode daccs aux LUNs. Les changes suivants ont lieu pour chaque LUN durant cette tape : Inquiry (LUN, type dinfos attendu en retour) Inquiry Response (infos demandes) Inquiry (LUN, type dinfos attendu en retour) Inquiry Response (infos demandes) Inquiry (LUN, type dinfos attendu en retour) Inquiry Response (infos demandes) Inquiry (LUN, type dinfos attendu en retour) Inquiry Response (infos demandes) Le premier change est le plus complet, et celui qui contient les informations principales, je parlerai donc uniquement de celui-ci, et non des 3 suivants. Les informations obtenues sont : 1. 2. 3. 4. 5.6.

Laccs au priphrique est direct ou indirect Le type de cible (lecteur CD, imprimante, disque dur, ) La cible est-elle retirable chaud (un CD peut-tre retir du lecteur CD) La cible supporte-t-elle les vnements asynchrones (p.ex : interruptions asynchrones) La version des commandes iSCSI supportes par le LUN La cible supporte-t-elle ladressage relatif (par rapport au LUN et non au disque entier)

Figure 1.19 : dtail de la rponse contenant les informations principales

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

20

1.5.3.4 Lecture de la capacit du LUN cible Pour connatre la capacit dun LUN, il faut utiliser la commande Read Capacity, qui se droule de la manire suivante : Read Capacity (LUN cible) Read Capacity Response (Capacit du LUN, taille des blocs du systme de fichier)

Figure 1.20 : commande Read Capacity

Le 10 entre parenthses indique que le disque utilise un bus de 32 bits.

Figure 1.21 : rponse un Read Capacity

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

21

1.5.3.5 Lecture de donnes La lecture de donnes introduit des changes particuliers : selon la quantit de donnes lire, la rponse ne tient pas dans un seul paquet TCP, cest pourquoi il sera galement chang de paquets contenant des segments PDU en plus des habituelles commandes et rponses. Les changes se droulent comme suit : Read (LUN, adresse et taille des donnes lire) Read Response(validation de la requte, donnes) PDU segment + TCP ACK (donnes) PDU segment + TCP ACK (donnes) TCP ACK Les trois derniers changes tant facultatifs, et se droulant autant de fois que ncessaire pour transmettre la totalit des donnes. La longueur des paquets contenant les segments PDU est de 1514 Bytes, exception faite du paquet contenant le dernier segment PDU du transfert. Voici le dtail de la requte :

Figure 1.22 : commande de lecture

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

22

1.5.3.6 criture de donnes Pour crire les donnes, la dmarche est un peu plus complexe, car il faut commencer par prvenir le disque que lon compte faire une criture, puis attendre son autorisation pour pouvoir commencer crire. Les changes suivants ont lieu : Write (bloc ou commencera lcriture, taille des donnes crire) Ready To Transfert (rappel de la taille) Write Request Data (donnes) Write Response (indique si lcriture sest bien droule) Voici le dtail de la demande dcriture :

Figure 23 : commande Write

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

23

1.5.3.7 Rservation du LUN suivi dune criture Ce passage sappuie galement du la page suivante : http://support.microsoft.com/kb/309186/fr Dans le cas de certaines critures, linitiateur rserve en premier lieu le LUN. Cette opration est ncessaire si la zone du disque ou doit avoir lieu lcriture est galement utilise par un autre initiateur. Dans le cas de vMotion, deux serveurs ESX/ESXi sont amen grer conjointement une mme VM, et par consquent, les fichiers qui sy rapportent sur le disque. Cest pourquoi au moment ou le serveur de destination prend la main sur une partie des donnes correspondant la VM, elle rserve le disque afin de modifier en premier lieu un byte qui sert indiquer au serveur de dpart quil na plus accs en criture ces donnes. Cette opration implique que seul linitiateur qui a rserv le disque peut y accder, les autres requtes seront ignores. Dans cet exemple, linitiateur effectuera une criture une fois la rservation effective. Il va de soi que dautres commandes sont galement ralisables, comme une lecture, bien que ces dernires ne ncessitent gnralement pas de rservation. Les tapes se drouleront de la faon suivante : Reserve (LUN rserver) Reserve Response (LUN, validation de la rservation) Write (LUN, bloc ou commencera lcriture, taille des donnes crire) Ready To Transfert (LUN, rappel de la taille) Write Request Data (LUN, donnes) Write Response (LUN, indique si lcriture sest bien droule) Release (LUN) Release Response (LUN, confirmation du release) Lopration dcriture se droule comme la prcdente, et les oprations spcifiques la rservation ne demandant aucun paramtre particulier, il nest pas ncessaire de montrer des captures de ces paquets. 1.5.3.8 Logout Le logout seffectue en une seule commande et rponse : Logout Request (demande de dconnection) Logout Response (validation de la demande) Comme aucun paramtre particulier nest requis, une capture dcran serait inutile.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

24

2 vMotion2.1 IntroductionSelon VMware http://www.vmware.com/files/fr/pdf/vmotion_datasheet_fr.pdf, vMotion est une fonctionnalit des serveurs ESX et ESXi servant transfrer une VM dun hte un autre sans teindre cette dernire.

Figure 2.1 : principe de vMotion

VMware VMotion permet de dplacer en temps rel des VMs en fonctionnement depuis un serveur physique vers un autre sans interruption de service, tout en garantissant une disponibilit continue et une totale intgrit des transactions. VMotion est une technologie cl dans le cadre de la mise en place dun datacenter dynamique, automatis et optimis. Grce VMotion, les utilisateurs peuvent : Optimiser et allouer automatiquement des pools entiers de ressources pour amliorer le taux dutilisation, la flexibilit et la disponibilit des ressources matrielles. Effectuer la maintenance des ressources matrielles sans planifier dinterruption de service. Migrer proactivement les VMs des serveurs dfaillants ou insuffisamment performants.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

25

2.2 FonctionnementCe paragraphe est bas sur ltude de larticle http://www.vmware.com/pdf/usenix_vmotion.pdf. La structure dun systme ESX ou ESXi est la suivante : 1. La couche matrielle (CPU, RAM, interfaces rseau, disque dur interne et rseau, pour plus de dtails, voir lannexe A.2) 2. Le VMkernel, qui gre les connections sur le rseau virtuel et les VMM. Cette fonction est dsactive par dfaut sur ESX, mais ncessaire pour utiliser vMotion 3. Une couche intermdiaire, VMM (Virtual Machine Monitor), qui gre, entre autre, le matriel virtuel 4. LOS invit , qui doit avoir limpression de tourner sur du vrai matriel

4

OS invit VMM, virtualisation du matriel

OS invit VMM, virtualisation du matriel

3

}

Machines Virtuelles

2

VM kernel, virtualisation du rseau et gestion des VMM Couche matrielle physique

1

Figure 2.2 : les diffrentes couches dun serveur ESX/ESXi

Une VM est compose en ralit de fichiers qui reprsentent ses composants et sa configuration : un fichier qui dfinit les caractristiques (taille de la RAM, frquence du processeur, ), un autre qui contient le disque dur virtuel, etc Afin de rendre les VMs encore moins dpendantes du serveur ESX/ESXi qui lui fournit les ressources ncessaires son fonctionnement, les fichiers composant une VM seront stocks dans un SAN sur un disque iSCSI. Il en va de mme pour toutes les VMs fonctionnant sur les serveurs dun mme groupe. Les principaux fichiers composant une VM sont les .vmdk et le .vmx. Les .vmdk contiennent le disque dur de la VM, et le .vmx la configuration matrielle (taille de la RAM et du disque dur, nombre de processeur, famille de lOS, etc.). Lors d'une sauvegarde manuelle dune VM, ce sont les fichiers quil faut copier.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

26

De par cette configuration, pour une VM donne en fonctionnement, la RAM et le processeur seront sur un serveur ESX/ESXi (A sur la figure 2.3), alors que le disque dur virtuel et les priphriques virtuels (lecteur de disquette/CD, ) seront sur le disque de stockage iSCSI (B sur la figure 2.3).

A

VM 1 Serveur ESX/ ESXi

VM 2 Serveur ESX/ ESXi

switch

Disque iSCSI B Fichiers VM 1 Fichiers VM 2

Figure 2.3 : stockage de VMs

Il y a 2 types de donnes transfrer lors dune migration par vMotion : Ltat du matriel comme le processeur, la carte mre, les cartes rseau, les adaptateurs de stockages, les lecteurs de disquettes, la carte graphique, les lecteurs cd, etc. La RAM de la VM

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

27

Le but tant de transfrer ces donnes de la faon la plus transparente possible, en minimisant le temps dindisponibilit des machines transfres. La mthode de migration actuelle est compose de 3 tapes : A. Oprations : initialisation de la migration en choisissant la VM migrer et lhte de destination B. Oprations : Pr-copie de la mmoire vive (RAM) de la VM sur lhte de destination, la VM continuant de fonctionner. Cest la partie o le plus de donnes sont changes. C. Oprations : Mise en pause (quiesed state) de la VM puis envoi des donnes dtat nonRAM, transfert du contrle de la VM lhte de destination, envoi des donnes mmoire modifies et annulation des dpendances sur lhte source et remise en marche de la VM. Cest la seule tape o la VM est teinte, pour une dure dpendant des paramtres indiqus dans le point suivant. Les serveurs ESX et ESXi sont contrls distance par le Virtual Infrastructure (VI) Serveur. Ce dernier est lui-mme contrl distance ou en local par un ou plusieurs VI Client. Lutilisateur interagit donc avec les serveurs ESX/ESXi et les VMs (VMs) par le biais du VI Client. noter quune interface web peut-tre utilise la place du VI Client, mais certaines fonctionnalits nont pas t portes sur cette interface.VM 1 Serveur ESX/ESXi

VI Server et VI Client

Switch 1

Switch 2

Disque iSCSI Fichiers VM 1 Fichiers VM 2

VM 2 Serveur ESX/ESXiFigure 2.4 : stockage et gestion des VMs

2.3 ParamtresEn connaissant le droulement du transfert dune VM dun hte un autre, nous pouvons dduire que les paramtres suivants influencent la dure dindisponibilit : La vitesse du rseau sur lequel on effectue le transfert (le minimum recommand est de 1Gbps pour le rseau de stockage et 100Mbps pour le rseau de management) La taille de la RAM occupe ainsi que lactivit de la machine durant le transfert (RAM modifie durant la pr-copie) La frquence du processeur et la taille de sa mmoire cache Lactivit de la VM est trs importante, car elle dfinit la quantit de donnes contenues dans la RAM retransmettre car modifie depuis la pr-copie. Si la VM ne fait rien, la quantit de donnes retransmettre sera quasiment nulle, et donc le temps ncessaire sera trs court. En revanche, si la VM tait trs active, la quantit de donnes transmettre sera importante, le temps de transfert sera donc bien plus consquent.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

28

2.4 Scnario 1 : vMotion entre serveurs ESXi sur un rseau 100Mbps2.4.1 Schmas et plan du rseau8 iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux) IP = 10.1.7.1 Serveur ESXi n1 Dplacement par vMotion 4 VM Ubuntu + script 2 Wireshark 1 pour le rseau de gestion et stockage IP = 10.1.2.155 XP SP2 1 rseau de gestion et stockage 1 SPAN port pour le monitoring Switch 1 VLAN 1 5 IP = 10.1.7.2 Serveur ESXi n2Avant vMotion Aprs vMotion

3 rseau applicatif Switch 1 VLAN 2 7

VM Ubuntu Server

6 Wireshark 2 pour le rseau applicatif VM XP IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX

VI Serveur et Client IP = 10.1.2.150 XP SP2

Figure 2.5 : schma rseau du scnario 1, vMotion sur ESXi 100Mbps

2.4.2 Mthodologie Pour ce scnario, le rseau 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 faon, lanalyse effectue 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 sparer le rseau de gestion (ESXi et VI Serveur/Client) du rseau de stockage (ESXi et disques de stockage), utilis par vMotion. Cependant, sur les serveurs ESXi, il nest pas possible dajouter une deuxime console de management, alors quil serait ncessaire den avoir une pour le rseau de management et une autre pour le rseau de stockage. Cest pourquoi ces deux rseaux sont runis en un pour ce scnario. 2. Lobservation des changes ct ESXi est effectue 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 possde 24 ports, de marque Cisco modle Catalyst 2950. 3. Les VM sont connectes au mme switch physique que les serveurs ESXi, mais dans un autre VLAN 4. Un client Ubuntu est dplac via vMotion entre les deux serveurs ESXi. Durant ces transferts, il excute un script tlchargeant en boucle une page sur un serveur web (voir annexe A.8). La mmoire RAM de cette machine est de 256MB, dont 247MB sont occups 5. Le serveur est une autre VM Ubuntu, tournant sur un serveur ESX qui nest pas impliqu dans lchange vMotion. 6. Sur ce mme hte ESX, une VM Windows XP (Wireshark 2) monitore les changes de donnes entre les deux autres VMs.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

29

7. Le vSwitch auquel sont connects le serveur web Ubuntu et la VM Wireshark 2 est configur en hub, de sorte rendre la capture des paquets changs possible. Grce Wireshark 2, il est possible de voir quand et durant combien de temps la machine dplace par vMotion est indisponible. 8. Toutes les VMs sont stockes sur le disque iSCSI. Jai choisi de virtualiser le serveur Ubuntu et le pc dobservation XP par besoin dutiliser un hub pour la capture des changes entre les VMs. Dans ce scnario, jaurais pu configurer un autre port de monitoring et utiliser des machines physiques, mais pour le scnario suivant, le switch ne sera pas configurable. Ce choix unifie ainsi la manire de prendre les mesures. Une comparaison du nombre de paquets capturs via Wireshark avec les compteurs de paquets du switch sera galement effectue afin dtre sr quaucun paquet na t perdu par Wireshark. Une autre capture comprenant les rseaux applicatif, de gestion et de stockage sera galement effectue afin de voir de faon plus prcise les concordances temporelles entre les captures faites prcdemment. Pour ce faire, le switch sera configur de sorte ce que le PC physique dobservation puisse monitorer les ports des VMs en plus des ports dj monitors pour les premires captures. Pour plus de prcisions, une dizaine de migrations par vMotion sera effectue. 2.4.3 Mesures La quantit de paquets capturs par Wireshark 1 et 2 correspond celle que le switch indique avoir fait transiter par les ports de connexion des dites machines. Les chiffres indiqus sont des moyennes des valeurs obtenues dans les captures scnario 1/physique_X, scnario 1/virtuel/virtuel_X et scnario 1/global.pcap disponible sur le DVD. Pour plus dinformation, reportez-vous au fichier READ ME du dossier scnario 1. Lors des mesures, le temps de transfert moyen indiqu par le VI Client est de 70 secondes, cependant, les relevs effectus avec Wireshark montrent que la quasi-totalit des changes ont lieu dans un intervalle denviron 32 secondes (A, B, C et D sur la figure de la page suivante). Je pense que cette diffrence constate entre les temps indiqus vient du fait que les transferts ne commencent pas tout de suite, il faut dabord que lordre soit donn et que les htes concerns librent les ressources ncessaires un transfert rapide. De mme, la fin du transfert, le VI Client attend que la VM soit de nouveau compltement oprationnelle pour considrer le transfert termin. Or comme on peut le voir sur la figure 2.6, le trafic rseau ne reprend pas instantanment la fin des changes sur le rseau de gestion et stockage. Le temps dinactivit 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.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

30

Figure 2.6 : les diffrentes tapes dun transfert par vMotion

La figure ci-dessus est obtenue partir du fichier scnario 1/global.pcap disponible sur le DVD. Concernant les filtres appliquer, reportez-vous au fichier READ ME.txt disponible dans le mme dossier. A. Cette partie des changes a lieu entre le disque iSCSI et les serveurs ESXi. Le volume de donnes transfr est de 3.3MB sur une priode de 1.5 2 secondes. B. Cest l que sont transfrs plus de 90% des donnes de lchange par vMotion. Durant cette tape, une pr-copie de la RAM est effectue entre les 2 serveurs ESXi, alors que la VM est encore en fonction. La dure de ces changes est de 25 secondes pour une quantit de donnes changes valant 290.4MB (taille comprenant galement le dbut de la partie C : envoi des changements de la RAM). Cette taille correspond la RAM occupe sur la VM plus environ 7% de la valeur de la RAM rpartit entre le r-envoi de la RAM (dbut C), les enttes des paquets et les paquets servant la gestion de lchanges. Si des critures devaient avoir lieux dans une zone de la RAM dj pr-copie, elles seraient inscrites dans un fichier bmp qui sera envoy au dbut de la partie C. C. Durant cette partie de lchange, la VM est mise en pause. On peut dcomposer cette partie en deux sous partie : lenvoi 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. lenvoi des donnes 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 dplace.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

31

D. Durant cette tape, la VM est remise en fonctionnement. Ds quelle est rsume, elle envoie une requte ARP contenant sa propre MAC address en broadcast afin de faire connatre son nouvel emplacement sur le rseau. On peut constater que cette requte est mise environ 1 seconde avant que les changes entre la VM et le serveur de test ne reprennent. Je pense donc que cette requte est envoye pendant que la machine se remet en fonction, mais avant dtre nouveau totalement fonctionnelle. On peut galement voir 2 pics de donnes qui ont lieu entre lESXi sur lequel tournait la VM au dbut de lchange et le disque iSCSI, qui servent surement librer dfinitivement les ressources sur le serveur ESXi en question. Cependant, je nai 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 dure du transfert, ils reprsentent un volume de 5.3MB. Ces changes ont lieu uniquement avec les htes ESXi. Il est intressant dobserver que la totalit des changes a lieu en TCP, lUDP noffrant, de par sa conception, pas la scurit requise pour le dplacement dune VM.iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux) = 13.8 MB = 4.4% et = 0.9 MB = 0.3%Aprs vMotion

IP = 10.1.7.1 Serveur ESXi n1 = 0.2 MB = 0.1% et = 0.4MB = 0.1%

Dplacement par vMotion = 280.1 MB = 90.1% et = 10.3 MB = 3.3%

VM Ubuntu + script IP = 10.1.7.2 Serveur ESXi n2

Avant vMotion

rseau de gestion et stockage 1 SPAN port pour le monitoring Switch 1 VLAN 1 Wireshark pour le rseau de gestion et stockage IP = 10.1.2.155 XP SP2

rseau applicatif Switch 1 VLAN 2

= 0.1 MB = 0.05% et = 0.6 MB = 0.2%

= 0.1 MB = 0.05% et = 4.3 MB = 1.4%

VM Ubuntu Server

VI Serveur et Client IP = 10.1.2.150 XP SP2

Wireshark pour le rseau applicatif VM XP IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX

Figure 2.7 : plan du rseau indiquant les flux entre les machines

2.4.3.1 changes entre lhte source et lhte de destination Ces changes se droulent durant la partie B et le dbut de la partie C de la figure 2.6. Ils consistent en 2 sessions TCP simples (pas de surcouches protocolaires entre lapplication et le TCP) entre les serveurs ESXi. Pour rappel, ces changes se produisent durant 25 secondes, pour un volume de donnes de 290.4MB. La session 1 reprsente 99.99% des paquets changs. Cest le serveur ESXi qui possde la VM au dbut de lchange qui linitialise, avec un port de dpart compris entre 2050 et 5000, destination du port 8000 de lautre serveur ESXi. Le port 8000 permet laccs la console de service qui permet de contrler le serveur ESXi cible. Je pense donc que le serveur possdant la VM pilote ainsi celle qui doit en prendre le contrle pour lui dire ce quelle doit tlcharger et quand. On peut constater que

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

32

la moiti des paquets a une taille comprise entre 40 et 159 Bytes, alors que lautre moiti se situe entre 640 et 1514 Bytes par paquet. Cela indique quil y a autant de paquets servant au contrle de lchange qu lchange proprement parler. La session 2 est la mme, mais dans le sens inverse. Je pense quelle permet au serveur de destination dorienter le serveur ESXi de dpart dans les diffrentes tapes en le tenant inform de ltat de charge dans lequel il se trouve. Je ne me suis cependant pas trop attard sur cette session, vu le faible pourcentage des transferts quelle reprsente. 2.4.3.2 changes entre le disque iSCSI et les htes ESXi Ces changes sont prsents 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 dplacer 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 mme structure. Le iSCSI est un protocole qui permet de faire des changes de donnes/envoi de commande SCSI au travers dun rseau IP. iSCSI se prsente comme une surcouche au protocole TCP. Jai pu remarquer 3 types doprations lors des transferts (voir les fichiers Wireshark physique_X et global indiqu au dbut du point 2.4) : Lecture de la capacit du disque Lecture de donnes criture de donnes Pour plus dinformations, veuillez vous rfrer 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 hberge la VM au dbut de lchange. Jai pu constater quune fois la pr-copie termine, ils deviennent insignifiants. Comme la console distante tait ouverte sur le PC qui hberge le VI Serveur, je prsume que la plupart de ces derniers servent rafraichir laffichage de la console distante. Le reste des changes sert la transmission dinformations comme lavancement du vMotion, les logs, etc... Les protocoles utiliss sont TCP simple hauteur de 93.6% et SSL version 3 hauteur de 6.65% des paquets changs.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

33

2.5 Scnario 2 : vMotion entre serveurs ESXi sur un rseau 1Gbps2.5.1 Schmas et plan du rseauiSCSI Datastore IP = 10.1.1.54 Openfiler (Linux) IP = 10.1.7.1 Serveur ESXi n1 Dplacement par vMotion VM Ubuntu + script IP = 10.1.7.2 Serveur ESXi n2Avant vMotion Aprs vMotion

rseau de gestion et stockage Switch netgear 1

rseau applicatif Switch netgear 2

VM Ubuntu Server VI Serveur et Client IP = 10.1.2.150 XP SP2

Wireshark 2 pour le rseau applicatif VM XP IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX

Figure 2.8 : schma rseau du scnario 2, vMotion sur ESXi 1Gbps

2.5.2 Mthodologie Ltape prcdente a permis dobserver en dtail tous les changes ayant lieu durant un transfert vMotion, autant du ct de la VM dplace, que du ct des htes. Cependant, la vitesse du rseau tait infrieure au minimum recommand, cest pourquoi ce scnario a t mis en place. Les switch gigabit utiliss ntant pas configurables, un monitoring du ct des serveurs ESXi est exclu, mais reste possible du ct de la VM. En effet, la machine faisant tourner Wireshark 2 pour le rseau applicatif tant virtuelle et sur le mme vSwitch que le serveur recevant les requtes de la machine dplace, une fois ce vSwitch configur en hub, elle peut monitorer les paquets changs entre ces deux autres VMs. Ces captures permettront dtablir le temps dindisponibilit, comme ltape prcdente. La mthodologie sera donc la mme que lors du scnario 1, mais sans la partie monitoring du rseau de gestion et stockage. Le but de ce scnario est donc limit la mesure du temps dindisponibilit de la VM. Pour ces captures, la charge moyenne de la RAM de la VM dplace est de 245MB sur les 256MB disponibles.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

34

2.5.3 Mesures Comme on peut le voir sur la figure 2.9, les temps dindisponibilit sont bien au dessus des 1 2 secondes annonces par VMware. Ce temps sexplique par les performances mdiocres du serveur Openfiler sur un rseau gigabit (plus de 12 minutes pour un fichier de 3GB, voir annexe A.7 : tests du switch NETGEAR), et par le bridage des performances de vMotion sur les serveurs ESXi (voir scnario 3, qui donne de meilleurs rsultats en tant sur un rseau 100Mbps). Test n 1 2 3 4 5 6 7 8 9 10 moyenne Temps total [s] 37 43 36 67 35 66 35 66 37 67 48.9 Temps d'indisponibilit [s] 6.157 9.456 6.338 9.173 6.265 6.239 9.171 6.042 9.459 9.307 7.7607Figure 2.9 : temps de transfert et dindisponibilit

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

35

2.6 Scnario 3 : vMotion entre serveurs ESX sur un rseau 100Mbps2.6.1 Schmas et plan du rseauAprs vMotion

iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux) 8 Dplacement par vMotion

IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX n1

rseau de stockage Switch 1 VLAN 3 2 Wireshark 1 pour le rseau de gestion et stockage IP = 10.1.2.155 XP SP2 1 rseau de gestion 1 SPAN port pour le monitoring des VLAN 1 et 3 Switch 1 VLAN 1 VM Ubuntu + script

4Avant vMotion

3 rseau applicatif Switch 1 VLAN 2

8

IP = 10.1.2.152 Vmkernel IP = 10.1.2.154 Serveur ESX n2

7 5 VI Serveur et Client IP = 10.1.2.150 XP SP2 VM Ubuntu Server 6

Wireshark 2 pour le rseau applicatif VM XP

IP = 10.1.7.2 Serveur ESX

Figure 2.10 : schma rseau du scnario 3, vMotion sur ESX 100Mbps

2.6.2 Mthodologie La mthodologie de ce scnario sera trs similaire celle du scnario 1, car le but principal est de voir si les changes se droulent de la mme faon entre des serveurs ESX quentre des serveurs ESXi. 1. Les Best Practices recommandent de sparer le rseau de gestion (ESX et VI Serveur/Client) du rseau de stockage (ESX et disques de stockage), utilis par vMotion. Contrairement aux serveurs ESXi, les serveurs ESX permettent la cration dune seconde console de service, et donc la sparation de ces deux rseaux. Ces rseau seront sur le mme switch, mais dans un VLAN diffrent. 2. Lobservation des changes ct ESX est effectue par une machine physique, Wireshark 1, dont le port de connexion sur le switch est configur pour le monitoring. Cette machine effectuera lobservation aussi bien des rseaux de gestion et de stockage. 3. Les VM sont connectes au mme switch physique que les serveurs ESX, mais dans un autre VLAN. 4. Un client Ubuntu stock sur le disque iSCSI (Openfiler) est dplac via vMotion entre les deux serveurs ESX. Durant ces transferts, il excute un script (voir annexes) tlchargeant en boucle une page sur un serveur web. La mmoire RAM de cette machine est de 256MB, dont 245MB sont occup. 5. Le serveur est une autre VM Ubuntu, tournant sur un serveur ESXi qui nest pas impliqu dans lchange vMotion et stock en local. 6. Sur ce mme hte ESXi, une VM Windows XP (Wireshark 2) monitore les changes de donnes entre les deux autre VMs.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

36

7. Le vSwitch auquel son connects le serveur web Ubuntu et la VM Wireshark 2 est configur en hub, de sorte rendre la capture des paquets changs possible. Grace Wireshark 2, il est possible de voir quand et durant combien de temps la machine dplace par vMotion est indisponible. 8. Contrairement au serveur ESXi, les serveurs ESX offrent la possibilit daccder des logs plus nombreux et plus complets. Parmi ces logs, 1 contient des informations temporelles intressantes propos de vMotion : /var/log/vmkernel. Je me servirai donc de ces logs pour les comparer aux relevs de Wireshark 1. Une comparaison du nombre de paquets capturs via Wireshark avec les compteurs de paquets du switch sera galement effectue afin dtre sr quaucun paquet na t perdu par Wireshark. Une autre capture comprenant tous les rseaux sera nouveau effectue afin de voir de faon plus prcise les concordances temporelles entre les captures faites prcdemment. Pour ce faire, le switch sera configur de sorte ce que le PC physique dobservation puisse monitorer les ports des VMs en plus des ports dj monitors pour les premires captures. 2.6.3 Mesures La quantit de paquets capturs par Wireshark 1 et 2 correspond celle que le switch indique avoir fait transiter par les ports de connexion des dites machines. Les chiffres indiqus sont des moyennes des valeurs obtenues dans les captures scnario 3/physique_X et scnario 3/virtuel/virtuel_X disponibles sur le DVD. Pour plus dinformation, reportez-vous au fichier READ ME du dossier scnario 3. Lors des mesures, le temps de transfert moyen indiqu par le VI Client est de 53 secondes, cependant, les relevs effectus avec Wireshark montrent que la quasi-totalit des changes ont lieu dans un intervalle denviron 27 secondes. Le temps dinactivit moyen est de 3.3 secondes, soit environ 6% du temps de transfert annonc par le VI Client.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

37

partir des logs (disponible sur le DVD : scnario 3/log/vmkernel 15X.txt) on peut calculer 28.548 secondes entre la premire et la dernire entre (log des 2 serveurs confondu). Le temps dinterruption est de 1.744 secondes, soit environ la moiti du temps observ laide de Wireshark. Cette diffrence est due au fait que les logs indiquent la fin de la pr-copie et la remise en marche de la VM, ce qui ne comprend pas le temps de remise en fonction des connections rseau. Voici les logs pour un transfert :

Figure 2.11 : extrait des logs du VMkernel

Comme on peut le voir, les rfrences de temps du VI Client ne sont pas assez prcises pour tre intressantes, ce qui nest pas le cas des rfrences temporelles des serveurs ESX. Malheureusement, ces temps ne sont pas synchroniss. Le dcalage de temps peut-tre calcul partir de lentre qui indique les paramtres de migration, et apparaissant dans les 2 logs au mme moment. Les entres les plus intressantes sont : Celle qui indique la fin de la pr-copie Celle qui indique la remise en marche de la VM

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

38

Ces lignes donnent une indication sur le temps dindisponibilit de la VM indiqu plus haut. La ligne indiquant la fin de la pr-copie donne galement le nombre de pages de RAM modifies et donc retransmettre. Si on connait la taille des pages, cette information nous permet de calculer le volume de donnes retransmettre.

Figure 2.12 : transfert par vMotion

La figure ci-dessus est obtenue partir du fichier scnario 3/global.pcap disponible sur le DVD. Concernant les filtres appliquer, reportez-vous au fichier READ ME.txt disponible dans le mme dossier. A. Cette partie des changes a lieu entre le disque iSCSI et les serveurs ESXi. Le volume de donnes transfr est de 1.8MB sur une priode de 1.5 2 secondes. B. La pr-copie dure 24 secondes pour une quantit de donnes changes valant 426.5MB (taille comprenant galement le dbut de la partie C : envoi des changements de la RAM). C. Durant cette partie de lchange, la VM est mise en pause. On peut dcomposer cette partie en deux sous partie : lenvoi 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. lenvoi des donnes non RAM, qui dure environ 1 seconde pour un envoi de 6.8MB entre le disque iSCSI et le serveur ESXi sur lequel la VM est dplace. Les changes impliquant le VI Client / Serveur reprsentent un volume de 6.5MB.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

39

Aucun changement concernant la nature des flux par rapport au scnario 1. En revanche, le volume des flux bien chang, pour une raison inconnue.iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux) = 0.3 MB = 0.05% et = 0.4MB = 0.1% = 6.1 MB = 1.4% et = 1.8 MB = 0.4%Aprs vMotion

Dplacement par vMotion = 370.4 MB = 83.9% et = 56.1 MB = 12.7%

IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX n1

rseau de stockage Switch 1 VLAN 3 Wireshark 1 pour le rseau de gestion et stockage IP = 10.1.2.155 XP SP2 rseau de gestion 1 SPAN port pour le monitoring des VLAN 1 et 3 Switch 1 VLAN 1 VM Ubuntu + script IP = 10.1.2.152 Vmkernel IP = 10.1.2.154 Serveur ESX n2Avant vMotion

rseau applicatif Switch 1 VLAN 2

= 0.4 MB = 0.1% et = 3.1 MB = 0.7% = 0.2 MB = 0.05% et = 2.8 MB = 0.6%

7

VI Serveur et Client IP = 10.1.2.150 XP SP2

VM Ubuntu Server

Wireshark 2 pour le rseau applicatif VM XP

IP = 10.1.7.2 Serveur ESX

Figure 2.13 : flux de transfert

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

40

Le dplacement seffectue un dbit bien plus lev entre les serveurs ESX quentre les serveurs ESXi (scnario 1). La figure ci-dessous montre les 2 types de transferts sur une mme chelle de temps, mais avec des Bytes au lieu des paquets sur laxe vertical :

Figure 2.14 : comparaison de lvolution temporelle dun vMotion entre ESX ou ESXi

La trace noire est extraite de la figure 2.12 (trace verte plus trace rouge) ce qui correspond un change entre serveur ESX et la trace rouge est extraite de la figure 2.6 (trace rouge), ce qui correspond un change entre serveur ESXi. Bien que le dbit soit plus lev entre les ESX, le seul moment o lon voit clairement un gain de temps correspond au point C et D de la figure 2.12. Les 2 captures ayant t effectues sur un rseau fonctionnant 100Mbps, jen conclus que les performances de la fonction vMotion sont brides en dbit sur les serveurs ESXi. Cependant, la diffrence de donnes changes durant la pr-copie est trs importante (426MB sur les ESX et 290MB sur les ESXi). Aucune raison ne semble justifier une telle diffrence.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

41

2.7 Scnario 4 : vMotion entre ESX sur un rseau 1Gbps2.7.1 Schmas et plan du rseauAprs vMotion

iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux)

Rseau de stockage Switch NETGEAR

IP = 10.1.2.151 Vmkernel IP = 10.1.2.153 Serveur ESX n1 Dplacement par vMotion

rseau de gestion Switch 1 VLAN 1

VM Ubuntu + script IP = 10.1.2.152 Vmkernel IP = 10.1.2.154 Serveur ESX n2

Avant vMotion

rseau applicatif Switch 1 VLAN 2

VI Serveur et Client IP = 10.1.2.150 XP SP2

VM Ubuntu Server

Wireshark 2 pour le rseau applicatif VM XP

IP = 10.1.7.2 Serveur ESX

Figure 2.15 : schma rseau du scnario 1, vMotion sur ESX 1Gbps

2.7.2 Mthodologie Ltape prcdente a permis dobserver en dtail tous les changes ayant lieu durant un transfert vMotion, autant du ct de la VM dplace, que du ct des htes. Cependant, la vitesse du rseau tait infrieure au minimum recommand, cest pourquoi ce scnario a t mis en place. Le switch gigabit utilis ntant pas configurable, un monitoring du ct des serveurs ESXi est exclu, mais reste possible du ct de la VM. En effet, la machine faisant tourner Wireshark 2 pour le rseau applicatif tant virtuelle et sur le mme vSwitch que le serveur recevant les requtes de la machine dplace, une fois ce vSwitch configur en hub, elle peut monitorer les paquets changs entre ces deux autres VMs. Ces captures permettront dtablir le temps dindisponibilit, comme ltape prcdente. La mthodologie sera donc la mme que lors du scnario 1, mais sans la partie monitoring du rseau de gestion et stockage. Le but de ce scnario est donc limit la mesure du temps dindisponibilit de la VM. Pour ces captures, la charge moyenne de la RAM de la VM dplace est de 245MB sur les 256MB disponibles.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

42

2.7.3 Mesures Comme lors du scnario 2, on peut constater que les temps dindisponibilit dpassent les 2 secondes indiques par VMware. Cette fois, je pense que ce dpassement est d uniquement Openfiler qui ne gre pas bien le gigabit. Test n 1 2 3 4 5 6 7 8 9 10 moyenne Temps total [s] 18 19 17 17 19 18 18 16 18 17 17.7 temps d'indisponibilit [s] 3.745 2.885 1.552 4.285 4.277 4.296 2.817 4.365 2.805 1.597 3.3524Figure 2.16 : temps de transfert et dindisponibilit

Lutilisation dun vrai disque iSCSI donnera srement des temps infrieurs 2 secondes, je nai malheureusement pas de tel quipement pour effectuer des tests.

2.8 ConclusionComme on a pu le constater, les performances annonces ne sont pas atteinte, mais ceci est plutt imputable au matriel utilis. Pour un environnement de production un SAN physique est souhaitable en lieu et place de solution comme Openfiler, qui peuvent satisfaire un environnement de test peu regardant sur les performances du disque iSCSI. Lutilisation du VI Server (qui est payante) est obligatoire pour mettre en uvre cette fonctionnalit, et celle des serveurs ESX (payant eux aussi) est souhaitable celle de serveurs ESXi (qui sont gratuits), et ce pour des raisons de dbits non brid, ce qui rduit le temps dindisponibilit. Cette fonctionnalit est prometteuse, reste savoir si VMware lamliorera dans le futur pour atteindre un temps dindisponibilit le plus petit possible, voir mme nul.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

43

3 Distributed Resource Scheduler3.1 IntroductionDistributed Resource Scheduler, ou DRS dans la suite de ce document, est une fonctionnalit permettant la gestion automatique de la rpartition de la charge entre les serveurs ESX/ESXi faisant partie dun mme cluster (groupe de serveurs ESX/ESXi mettant leurs ressources en commun, voir chapitre suivant). DRS utilise vMotion pour dplacer les VMs

Selon VMware (http://www.vmware.com/files/pdf/drs_datasheet.pdf), VMware DRS dynamically balances computing capacity across a collection of hardware resources aggregated into logical resource pools, continuously monitoring utilization across resource pools and intelligently allocating available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When a virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines among the physical servers in the resource pool. VMware DRS allows IT organizations to: Prioritize resources to the highest value applications in order to align resources with business goals Optimize hardware utilization automatically and continuously to respond to changing conditions Provide dedicated resources to business units while still profiting from higher hardware utilization through resource pooling Conduct zero-downtime server maintenance DRS est une fonctionnalit trs intressante si vous virtualisez des serveurs dont la charge est amene changer rgulirement, par exemple, un serveur de VOIP (pique de charge entre 10h et 11h le matin) ou un site web trs sollicit certaines heures (p.ex : en fin de journe) et peu ou pas du tout dautres (p.ex : la nuit).

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

44

3.2 ClusterUn cluster est un groupe de serveurs physiquement distincts qui mettent leurs ressources en commun. Un cluster sera peru comme tant une seule entit physique ayant les capacits de tous les serveurs la composant. Le principal avantage est quen cas de panne dun serveur, le cluster continue fonctionner. La charge processeur et RAM est rpartie de faon quitable entre les serveurs. Dans le cas de VMware, un cluster est compos dun groupe de serveurs ESX et/ou ESXi ainsi que dun groupe de VMs. Les VMs sont hberges par un serveur quelconque du cluster et non par un serveur spcifique. Le but est de rpartir la charge gnre par les VMs le plus quitablement possible entre les diffrents serveurs ESX/ESXi laide de DRS. Il est recommand (http://www.kingston.com/branded/pdf_files/HAnDRSCapacity_WP.pdf) que ces serveurs aient une configuration matrielle identique afin dviter qu charge gale un serveur soit 90% de ses capacit et un autre 50%.

Figure 3.1 : cluster de serveurs ESX vu depuis le VI Client

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

45

3.3 FonctionnementComme indiqu dans lintroduction, lutilisation de DRS ncessite la mise en place de cluster (voir annexe A.6.8). La suite de ce chapitre sera base sur le document http://www.kingston.com/branded/pdf_files/HAnDRSCapacity_WP.pdf. Le VI Server vrifie en continu la charge CPU et RAM de chaque serveur faisant partie dun cluster utilisant DRS. Selon les paramtres dfinis (voir chapitre suivant), si un serveur se retrouve avec une charge trop importante (un trop grand nombre de VMs ou une VMs qui consomme trop de ressources), DRS dplacera automatiquement ou suggrera de dplacer manuellement des VMs vers un autre serveur moins charg en utilisant vMotion. Il est recommand dutiliser du matriel le plus homogne possible, voire mme identique. 3.3.1 Rservations La partie 2 du cours VMware de M. Litzistorf (http://www.tdeig.ch/vmware/Plaquette.pdf) explique la possibilit de rserver des ressources CPU et RAM pour une VM, ainsi que celle de limiter laccs ces mmes ressources. Par dfaut, les ressources sont partages entre les VMs selon leurs besoins respectifs. Si ces ressources ne sont pas suffisamment nombreuses, chaque VM aura le droit une part gale. Cette situation nest pas acceptable pour certaines VMs, cest pourquoi il est possible de leur attribuer manuellement une part des ressources. De mme, une VM utilisant un systme dattente active consommera bien plus de temps processeur que celui consomm par les besoins rels de la mme VM. Il est donc utile de limiter les ressources disponibles pour cette VM de sorte les conserver pour dautres VMs qui en auraient vraiment lutilit. Selon le document cit au dbut du chapitre 3.3, il est galement possible de rserver des ressources pour un groupe de VMs, par exemple, celles qui sont contenues dans un mme cluster DRS. Il faut savoir quun serveur ESX/ESXi peut faire partie dun cluster et galement avoir dautre VMs/groupes de VMs qui ne sont pas inclues dans le cluster. Cette fonctionnalit ne sera pas exploite dans la suite de ce document, car les serveurs ESX ont t entirement intgrs au cluster, mais il peut savrer utile, selon votre configuration, de savoir que cette possibilit existe.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

46

3.4 ParamtresComme DRS utilise vMotion, les paramtres dterminant le temps dindisponibilit dune VM lors dun dplacement sont identiques ceux indiqus dans le paragraphe 2.3. La configuration de DRS permet de rgler diffrents paramtres tels que : Le mode de dplacement (manuel, semi-automatique ou automatique) global (pour toutes les VMs) et individuel (pour une VM spcifique, attribuer un mode de dplacement diffrent de celui dfini globalement) La sensibilit : rquilibrage rapide de la charge entre les serveurs ou attendre un dlai Des rgles sur la disposition des VM, afin que les VMs dsires soient toujours sur le mme serveur ESX/ESXi, ou au contraire, toujours sur un serveur diffrent Les options avances, pour lesquels je nai malheureusement trouv aucune documentation Une partie de ces paramtres a pu tre rgle la cration du cluster, mais selon les scnarios qui suivront, nous verrons comment modifier ces rgles. Remarque : Il est indiqu dans la page 46 dans le document https://140.110.8.180/king/modules/userupload/upload/ets2007/vmware.13.pdf que DRS fonctionne mieux avec des petites VMs (faible consommation RAM et CPU) quavec des grosses VM. En effet, un dplacement dune VM gnrant une grosse charge CPU et RAM aura dune part un temps dindisponibilit plus long, mais laissera galement derrire lui une quantit importante de ressources libres, ce qui pourrait crer un nouveau dsquilibre de charge avec un autre serveur ESX/ESXi non impliqu dans le premier dplacement. Le dplacement en lui-mme provoque galement une consommation supplmentaire de ressources, rduisant ainsi les ressources disponibles pour les VMs ne se dplaant pas, ce qui gne le fonctionnement gnral. En opposition, une petite VM aura un dplacement rapide, perturbant ainsi moins longtemps le fonctionnement gnral, et produira une diffrence de charge bien moins importante sur les serveurs ESX/ESXi suite son dplacement, rduisant ainsi la probabilit de devoir nouveau dplacer une VM.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

47

3.5 Topologie et plans du rseauContrairement aux scnarios de test de vMotion qui ncessitaient des changements de topologie du rseau, les scnarios de test de DRS seront tous effectus avec la mme topologie rseau. Pour des raisons de performances, jai choisi dutiliser un rseau de stockage 1Gbps ne comprenant que des serveurs ESX. La topologie sera donc trs proche de celle employe lors du scnario 4.5

iSCSI Datastore IP = 10.1.1.54 Openfiler (Linux)1

4

VMs IP = 10.1.2.151 Vmkernel2

rseau de stockage Switch 2 NETGEAR

IP = 10.1.2.153 Serveur ESX n1

Dplacements par vMotion grs par DRS

1

rseau de gestion 1 SPAN port pour le monitoring des VLAN 1 et 3 Switch 1 VLAN 1

3 4

VMs IP = 10.1.2.152 Vmkernel

rseau applicatif Switch 1 VLAN 2

6

VI Serveur et Client IP = 10.1.2.150 XP SP2

2

IP = 10.1.2.154 Serveur ESX n2

Figure 3.2 : plan du rseau utilis pour les tests de DRS

1. Conformment aux best practices (http://www.vmware.com/pdf/vc_technical_best.pdf), les rseaux de stockage et de gestion sont spars. Le rseau de stockage est sur un switch NETGEAR 1Gbps et le rseau de gestion est sur le VLAN 1 du switch Cisco (switch 1). 2. Comme indiqu plus haut, seuls les serveurs ESX seront utiliss. 3. Les VMs possdent leur rseau spar qui se trouve sur le VLAN 2 du switch Cisco. 4. Les VMs seront rparties laide de DRS entre les 2 serveurs ESX. Plus de dtails seront donns concernant la disposition des VMs dans chaque scnario. 5. Comme pour le scnario 1, toutes les VMs sont stockes sur le disque iSCSI mul par le serveur Openfiler. 6. Le tout tant toujours gr par le VI Serveur/Client.

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

48

3.6 Scnario 5 : dplacement manuel3.6.1 Configuration teste et mthodologie Pour commencer, afin de pouvoir mieux voir quel moment ont lieu les dplacements, le mode utilis sera manuel. Aucune autre rgle ne sera mise en place pour ce scnario. 3 VMs Windows XP seront utilises (la VM Wireshark 2, des scnarios prcdant et 2 clones de cette dernire). Mon choix sest port sur ces VMs car Windows XP a une charge CPU et RAM suffisamment importante pour dclencher un dplacement mme au repos (contrairement aux VMs Ubuntu utilises prcdemment, qui ont une charge au repos presque nulle car moins de services sont activs au dmarrage), tout en restant considrable comme des petites VMs. Les tapes suivantes seront effectues : action mise en route de la 1e VM dialogue de demande du serveur de destination, aucune prfrence indique choix effectu mise en route de la 2e VM dialogue de demande du serveur de destination, prfrence indique pour le serveur 2 choix effectu en suivant les recommandations mise en route de la 3e VM dialogue de demande du serveur de destination, aucune prfrence indique choix effectu arrt de la 2e VM proposition de dplacement de la 3e VM dplacement accept Serveur ESX 1 Serveur ESX 2 figure

3.7 VM1 VM1 VM1 VM1 VM1 VM1 VM1 + VM3 VM1 + VM3 VM1 + VM3 VM1 VM2 VM2 VM2 VM2 3.9 3.10 et 3.11 3.13 3.14 3.8

VM3

Figure 3.3 : tableau des oprations effectu lors du scnario 5

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

49

3.6.2 Mise en uvre de la configuration de DRS Cette configuration ntant pas celle par dfaut (configure dans lannexe A.6.8), il va falloir diter les paramtres. Pour ce faire, faites un clic droit sur le cluster dans le panneau de gauche du VI Client, puis cliquez sur Edit Settings

Figure 3.4 : ouverture de la fentre ddition des paramtres du cluster DRS

Dans le menu gauche de la fentre qui vient de souvrir, cliquez sur VMware DRS.

Figure 3.5 : cran principal de la fentre ddition des paramtres

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

50

Sur ce nouvel cran, slectionnez Manual . Cliquez sur OK, les changements de configuration vont seffectuer.

Figure 3.6 : choix du mode de fonctionnement et de la sensibilit de DRS

3.6.3 Observations et mesures Lors du lancement des VMs, le choix du serveur ESX a bien t laiss lutilisateur. Un systme dtoiles (de 1 5 toiles) indique lutilisateur quel serveur est le plus optimal pour hberger la VM (plus il y a dtoiles, plus le serveur est recommand). Au lancement de la premire VM, aucun serveur nest occup, tous ont donc le mme nombre dtoiles, savoir 1. Mon choix sest port sur le serveur n2 (10.1.2.154), slectionn par dfaut. Remarque : Observateur2 est le nom de la VM Wireshark 2 dans le VI Client.

Figure 3.7 : lancement de la premire VM, choix du serveur ESX

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

51

Au lancement de la seconde VM, comme le serveur 2 hberge dj une VM, le nombre dtoiles nest plus le mme entre les 2 serveurs : 3 toiles pour le serveur 2, alors que le serveur 1 (10.1.2.153) en a 5. Mon choix se porte donc sur le serveur 1, qui est recommand et slectionn par dfaut.

Figure 3.8 : lancement de la seconde VM, choix du serveur ESX

Au lancement de la troisime VM, comme les 2 serveurs ESX ont une charge gale, chacun se voit attribuer une toile, le choix du serveur a donc peu dimportance, je laisse donc le serveur 1 comme propos par dfaut.

Figure 3.9 : lancement de la troisime VM, choix du serveur ESX

Une fois que les 3 VMs ont dmarr, il est possible en allant dans longlet Virtual Machines de chaque serveur ESX dobserver quelles sont les VMs en fonctionnement sur ce serveur ainsi que leur occupation du processeur et de la RAM.

Figure 3.10 : vue sur les VMs du serveur 2

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

52

Figure 3.11 : vue sur les VMs du serveur 2

En allant sur longlet DRS Recommandations du cluster, on peut voir les dplacements suggrs. Comme on vient de dmarrer les 3 VMs, leur charge est gale, aucun dplacement nest propos.

Figure 3.12 : dplacements suggrs par DRS

On teint la VM qui est seule sur le serveur ESX n2. Aprs un instant (ou un clic sur le bouton Generate Recommandations ), il nous est recommand avec 2 toiles de dplacer une des VMs restante sur lautre serveur ESX. Ce dplacement est accept en cliquant sur Apply Recommandations.

Figure 3.13 : proposition de dplacement dune VM par DRS

Comme on la vu lors des scnarios prcdents, il est ensuite possible de suivre la progression du dplacement par vMotion sur la partie basse de la fentre du VI Client :

Figure 3.14 : dplacement de la VM par vMotion

Sandmeier Loc

Session 2008-2009

Modifi le : 26/06/2009

Mise en uvre des fonctions volues vMotion

53

3.7 Scnario 6 : dplacement automatique, sensibilit maximum3.7.1 Configuration teste et mthodologie Cette fois, il sagit dautomatiser les migrations. Le mode sera donc