Gestion des VM

Gestion des VM 1. virtual hardware version 7 Une machine virtuelle est composée d’un virtual hardware et d’un Guest OS. Le virtual hardware est le matériel virtuel proposé par ESX au Guest OS. ESX4 introduit la version 7 pour le virtual hardware. Il est possible de créer une VM avec 8 vSMP et 255 Go de mémoire et de rajouter à chaud des composants tels que la mémoire et le processeur. Attention, la compatibilité d’un virtual hardware est ascendante. Une VM créée à partir d’un ESX3 pourra être gérée par ESX4. Inversement une VM en virtual hardware version 7 n’est pas gérée par une version antérieure à ESX4. La version 7 du virtual hardware gère les contrôleurs suivants : ●
Les cartes réseaux virtuelles proposées par ESX : ●
●
●
●
E1000 : émulation d’une carte Intel Gigabit. Disponible à partir de Windows XP et des versions Linux supérieures à 2.4.19. Vlance : une ancienne carte réseau 10 Mbps dont les drivers sont nativement intégrés dans la plupart des OS 32 bits permettant de garantir une compatibilité avec des OS plus anciens. Vmxnet : VMware propose de sélectionner des cartes Vmxnet qui fournissent de meilleures performances qu’E1000 ou Vlance. Ces cartes n’existant qu’en environnement virtuel, les systèmes d’exploitation ne fournissent pas de drivers pour cette carte, ce sont les VMware Tools qui installent ce driver spécifique. Elle est déclinée en Vmxnet2 Enhanced (disponible depuis ESX3.5) et Vmxnet 3 10Gb E (disponible depuis ESX4). Les cartes SCSI proposées par ESX au Guest OS : Il est possible de choisir le contrôleur SCSI parmi : ●
Bus Logic Parallel ●
Lsi Parallel ●
Lsi Logic SAS ●
VMware Para virtual Le choix du contrôleur SCSI à utiliser est important pour les performances. Les contrôleurs standard sous VMware sont le Bus logic Parallel et Lsi Parallel. Le Bus Logic apporte la plus grande compatibilité avec des OS d’anciennes générations. Le LSI Parallel est plus performant mais sur certains OS il est nécessaire de rajouter un driver. Exemple : Pour installer le LSI Parallel sous Windows XP, il faut aller sur le site LSI et télécharger le driver correspondant. Deux nouveaux contrôleurs ont été rajoutés LSI Logic SAS et VMware para virtual afin d’optimiser les performances. Nous reviendrons dans le chapitre Supervision et optimisation ­ Optimisation et configurations avancées sur l’utilisation de ces drivers optimisés. 2. Clone, Snapshot, Template © ENI Editions - All rigths reserved - Guillaume DUBOIS
- 1-
Nous avons vu que la virtualisation offre une grande souplesse d’utilisation grâce à l’encapsulation des VM dans des fichiers. Il est possible de manipuler les VM très facilement. De plus, il est possible de créer des Template, des clones ou des snapshots ou faire des sauvegardes. a. Clone Un Clone se base sur une VM active déjà déployée, il représente une image de la machine virtuelle originale, clone qui pourra être 100 % identique à l’originale (en gardant les mêmes identifiants réseaux : SSID MAC Address...) ou identique d’un point de vue du contenu mais différent et unique sur le réseau. Dans ce cas, l’outil Sysprep permet de générer un identifiant unique (SSID) et une MAC Address différente de l’originale. Quand utiliser des clones ? Un clone peut être utilisé pour déployer ponctuellement et rapidement une nouvelle VM à partir des mêmes configurations, niveaux de patchs que l’originale. Cela permet de réaliser un gain de temps important car il n’y a pas à tout réinstaller. b. Template Un template est une image statique appelée Master Gold qui permet de faire un déploiement de masse de VM à partir d’une base commune. Il peut être assimilé à un Master souvent employé par les grandes entreprises afin d’industrialiser le déploiement des serveurs et d’homogénéiser le parc. Un template doit être créé une fois que la VM a été installée, configurée et optimisée et qu’elle est dans un état stable. Cela permet de faire du Provisioning instantané, c’est­à­dire la possibilité de mettre en service un nouveau serveur en quelques clics et quelques minutes. À noter qu’un template est une VM inactive qui ne peut pas être démarrée. c. Snapshots À quoi sert un snapshot ? Le snapshot permet de mettre en place une solution de retour en arrière simple lors de migration applicative ou de changement important au niveau du système. Lors du snapshot, l’état de la VM est préservé et cela fournit un moyen simple de retour à cet état stable s’il y a un dysfonctionnement par la suite. Comment cela fonctionne­t­il ? Un snapshot fait une capture de l’état de la VM à un instant t qui inclut : - 2-
●
l’état de la mémoire ; ●
les paramètres de la VM ; ●
l’état du disque. © ENI Editions - All rigths reserved - Guillaume DUBOIS
Au moment où le snapshot est créé, le fichier web.vmdk se fige et passe en mode lecture seule. Plus aucune donnée n’est écrite dans ce fichier. Toutes les modifications seront inscrites dans un nouveau fichier créé qui se nommera web0001­delta.vmdk. Ce fichier web0001­delta.vmdk ne représente donc que les différences entre l’instant où a été réalisé le snapshot et les modifications réalisées depuis le snapshot. Dans le cas où tout fonctionne correctement, il est nécessaire de supprimer le snapshot (étape 3) afin de ne travailler que sur un seul fichier web.vmdk. Dans le cas où il faut revenir à l’état antérieur au moment où le snapshot a été créé (3 bis) le fichier web.vmdk redevient actif en lecture/écriture. Attention dans ce cas précis, toutes les modifications entre le moment où a été réalisé le snapshot et le moment présent sont définitivement détruites. Les snapshots sont très utiles : ●
●
●
●
Avant de faire une migration applicative, une installation d’applications à risques. C’est le cas par exemple d’une installation d’un nouveau service packs, d’un nouveau patch. Lors d’une mise à jour de drivers, par exemple pour des serveurs d’impressions. Dans les environnements de test/développement où il est nécessaire de tester à différentes étapes de développement de l’application. Dans les environnements de formation pour le retour à plusieurs états différents. Le snapshot ne doit pas être considéré comme une sauvegarde car le principe d’une sauvegarde est d’avoir les données à deux endroits différents. Le snapshot ne duplique pas les données il travaille sur le même fichier à des instants différents. Dans un environnement de production, les snapshots ne doivent pas être présents trop longtemps. Ils doivent être utilisés pendant un laps de temps défini, un mois par exemple, afin de pouvoir le mettre en observation et revenir en arrière dans le cas où cela ne fonctionne pas. Une fois la migration validée, il faut supprimer le snapshot. VMware ne recommande pas d’avoir des VM avec des snapshots en production. Cela nécessite de gérer deux fichiers vmdk pour la même VM ce qui n’est pas conseillé. Précaution à prendre avec les snapshots Une mauvaise manipulation des snapshots peut rendre la VM inutilisable, il est donc important de prendre en considération les points suivants : © ENI Editions - All rigths reserved - Guillaume DUBOIS
- 3-
●
●
Un Revert to Current Snapshot (qui est équivalent à un "Goto" sur le snapshot parent) est destructif. Toutes les modifications réalisées entre le snapshot parent et l’instant présent sont définitivement détruites. Ce point est très important à bien comprendre afin de ne pas faire des erreurs de manipulations. Si l’on souhaite revenir à un snapshot parent sans perdre les modifications réalisées depuis alors il est nécessaire de créer un snapshot au temps présent. Ne jamais supprimer manuellement les fichiers ­delta.vmdk dans le répertoire de la VM. Il faut utiliser Snapshot Manager dans vCenter pour faire les opérations (cf. chapitre Configuration ­ Création de Template, Snapshots et Clones). Il est important de bien comprendre la mécanique et l’utilisation des snapshots. Pour cela, il est fortement conseillé de mettre en place une procédure et s’y tenir. En cas de doute, faire des sauvegardes avant toute manipulation. 3. Mode Persistent et non persistent Il est possible de configurer le mode d’accès au disque virtuel en mode : ●
●
- 4-
Independent Persistent : toutes les écritures disques émises par la VM sont effectivement écrites sur disque (dans le fichier vmdk). Ainsi, même après un reboot les modifications sont conservées. Independent Non Persistent : les modifications ne sont pas réellement effectuées sur le disque et la modification ne dure que jusqu’à l’arrêt de la VM (reboot ou shutdown). Dans ce mode d’utilisation, le reboot de la VM permet de retrouver une VM de référence. © ENI Editions - All rigths reserved - Guillaume DUBOIS