Présentation (ULTRA !) rapide de VMware
Avant de commencer à réfléchir à la mise en place de notre lab, il est bon de bien comprendre le fonctionnement d’un hyperviseur, et dans notre cas des ESX.
Commençons par un peu de vocabulaire:
ESXi ou ESX ou Hôte = c’est le serveur sur lequel se trouve la couche VMware ESX et qui va permettre d’héberger les machines virtuelles.
Machine Virtuelle ou VM = c’est un serveur virtuel qui s’exécute sur l’ESX
CPU et RAM = cela va désigner les ressources CPU et mémoire de l’ESX
vCPU et vRam = ce sont les ressources attribuées à une VM
CPU et MEMOIRE
Une VM ne pourra jamais avoir plus de ressources que l’ESX. Si mon serveur ESX possède 2 CPU, le nombre maximum de vCPU pour une VM donnée ne pourra pas excéder 2.
Une VM ne peut jamais consommer plus de ressources que la quantité attribuée. Si j’ai configuré une VM avec 4Go de vRAM et bien que mon ESX en possède 8Go, la VM ne pourra jamais consommer plus de 4Go sur mon ESX.
Tout l’intérêt d’une plateforme virtualisé, c’est d’optimiser la consommation des ressources. Je peux avoir 4 Vms avec chacune 1vCPU sur un ESX qui ne possède que 2 CPU physique. La couche ESX va ordonnancer les demandes de ressources CPU afin que toutes les VMs puissent travailler ensemble.
Il y a le même principe au niveau de la mémoire, chaque VM possède un certains nombre de données dans sa mémoire propre. La partie ESX connait les données de chaque VM. Lorsqu’une donnée est commune à plusieurs VM, l’ESX ne va stocker dans sa RAM qu’une seule fois cette donnée. C’est de cette manière que l’on peut avoir plus de vRAM attribuée aux VMs qu’il n’y a de RAM sur l’ESX.
Attention au nombres de vCPU sur les VMs. Une VMs qui est configurée avec 2 vCPU ne pourra travailler que lorsque 2 CPU de l’ESX sont disponibles EN MÊME TEMPS. Si ce n’est pas le cas, elle va attendre la disponibilité des ressources. Si sur mon ESX je possède 2 CPU et que j’ai 2 VMs, une avec 2vCPU et une avec 1vCPU, lorsque la deuxième travaille, j’ai encore 1 CPU de disponible. La 1° VM étant configurée avec 2 vCPU ne pourra pas travailler car il n’y a qu’un seul CPU de disponible. Donc attention à la configuration des VMs.
La règle à utiliser en général, c’est 1 VM = 1vCPU, après on gère au cas par cas.
Bien entendu, une VM éteinte ne consomme pas de ressources CPU et RAM.
Il reste encore une différence entre la virtualisation et la magie. Faire s’exécuter plusieurs machines virtuelles sur un serveur physique, c’est fantastique, mais il y a un moment ou le virtuel rencontre le monde réel.
Les VMs ont besoin de mémoire et de ressources CPU pour fonctionner, il faut bien aller les chercher quelque part!!!
Pour être relativement à l’aise sur notre lab, on va prendre un ratio de 1:3.
Si mon ESX possède 2 CPU, la somme totale des vCPU de mes VMs devrait être de 6, idem pour la mémoire.
On commence à entrevoir les débuts du design de notre lab, on va pouvoir évaluer les ressources en CPU et RAM de nos ESX en fonction de ce que l’on souhaite faire. Plus on veut démarrer de VMs, plus il nous faudra de ressources sur l’ESX. Dans la très grande majorité des cas, c’est la RAM des ESX qui va être le facteur limitant, 8Go est un minimum, sachant que l’ESX lui même va consommer au minimum 1 Go.
RÉSEAU
Une infrastructure Vmware est également consommatrice en port réseau. Pour chaque ESX, on va retrouver plusieurs types de réseaux qui peuvent utiliser une ou plusieurs cartes physiques.
Vmkernel = un réseau de type Vmkernel est utilisé directement par la couche ESX pour communiquer avec l’extérieur. Pour chaque réseau Vmkernel, on aura une adresse IP configurée sur l’ESX.
On trouve 3 types de réseaux Vmkernel :
– Management Network = c’est le réseau de management de l’ESX, c’est via cette interface et donc via cette adresse IP, que l’on va pouvoir se connecter sur l’ESX. Ce réseau va permettre également à l’ESX de communiquer avec l’exterieur. Ce réseau est indispensable et obligatoire.
– vMotion = ce réseau permet le transfert de gestion d’une VM d’un ESX à l’autre. Il va servir à transférer l’état de la mémoire et le contexte CPU d’une VM entre 2 ESX pour que la VM se déplace sur un autre ESX. Ce déplacement peut se faire VM allumée sans impact au niveau de la VM (perte d’1 ping).
Ce réseau Vmkernel n’est pas obligatoire, il peut fonctionner si on a du stockage partagé entre les ESX ou non. Dans le second cas, cela sera plus lent car les échanges passeront via le réseau.
– iSCSI = un Vmkernel sera également indispensable si l’on souhaite que nos ESX accèdent à du stockage distant et partagé. En cas de création d’un cluster ESX et si on souhaite bénéficier au maximum des possibilités, il faudra avoir ce type de stockage. Ce point sera détaillé dans les chapitres suivants.
Réseau de machine Virtuelle = Ce réseau ne possède pas d’adresse IP, il permet aux VMs de communiquer et non à l’ESX. La configuration de l’adressage est donc faite directement dans les OS des VMs et non dans l’ESX. Ce réseau se comporte comme un relais et fourni aux VMs des interfaces réseaux physiques pour communiquer vers l’extérieur.
Pour une configuration minimale, on va pouvoir utiliser une seule carte réseau sur l’ESX pour faire passer tout le trafic. On retrouvera forcément le réseau de management et un réseau pour les VMs si l’on souhaite qu’elles communiquent vers l’extérieur. Il y a pas mal de différentes configurations au niveau réseau sur un ESX avec la possibilité de mettre plusieurs cartes actives, certaines actives et d’autres en standby pour du secours. Afin de faire des tests et de comprendre comment fonctionne cette partie, il est indispensable d’avoir au moins 2 cartes réseaux physiques sur son ESX.
STOCKAGE
Au niveau du stockage, c’est relativement simple, du moins au début !
Pour fonctionner, un serveur VMware a besoin d’avoir son propre stockage pour installer la partie système. Cet espace est relativement petit, une carte SD ou une clé usb de 4Go sera suffisante. On n’a pas besoin d’avoir de performance sur ce média car tout va partir en ram lors du démarrage. Cela occupera env 1Go.
On a ensuite besoin de stockage pour les machines virtuelles. Cet espace est dissocié du premier. Il utilise le système de fichier VMFS propre à Vmware et permet les accès concurrents. Sur un espace de stockage, un datastore, on va retrouver plusieurs VMs.
Le système de fichier étant spécifique (VMFS) il ne pourra pas être lu depuis un serveur Windows ou Linux.
Un datastore peut être local, c’est un disque dur qui est directement dans l’ESX.
Il peut également être distant, sur une baie de stockage, sur un équipement de type Synology…..
Un Datastore distant peut être accédé :
En NFS = c’est un protocole de partage de fichier utilisé dans le monde unix / linux. Ce système est très simple à mettre en place, il faut avoir un équipement de type NAS qui supporte le protocole NFS.
En iSCSI = le trafic va passer par le réseau et sera encapsulé par de l’IP. Ce système demande une configuration spécifique sur les ESX. Il faut également que le stockage supporte le protocole iSCSI. C’est une des configurations les plus répandues. Elle sera abordée en détails lors de la création du lab correspondant.
Il existe d’autres protocoles, d’autres types de réseaux de stockage comme le FC (Fiber Channel) ou FCOE (FC Over Ethernet) mais pour notre lab, ce n’est pas du tout envisageable. Par contre ce sont des systèmes extrêmement répandus dans l’industrie (surtout le FC)!;
Pour faire fonctionner à minima une infrastructure Vmware, il faudra que chaque ESX puisse accéder à du stockage, pour rappel, un simple partage cifs de type \\monserveur\partage ne fonctionne pas.
La première solution sera donc d’embarquer du disque en local dans chaque ESX. Comme nous allons le voir dans le chapitre suivant, lorsque l’on a plusieurs ESX qui fonctionne en cluster, il est recommandé d’avoir un stockage partagé et donc sur un équipement supplémentaire.
A noter que les fonctionnalités vmotion et storage vmotion peuvent quand même être utilisées sans stockage partagé.
ESX en cluster
Un ESX c’est bien, 2 c’est encore mieux !!!
Lorsque l’on parle de cluster ESX, il faut bien garder à l’esprit qu’une VM s’exécutera toujours sur un seul ESX, par contre il sera possible de la faire passer, et ce de façon transparente, d’un ESX à l’autre.
Pour cela, il faudra mettre en place un réseau de type vMotion et de disposer de stockage partagé (on peut éventuellement faire du vmotion via le réseau, sans stockage partagé, mais c’est moins drôle).
Lorsqu’on a un cluster d’ESX, on va avoir besoin d’un élément supplémentaire qui va piloter l’infra, il s’agit du vCenter. C’est une application qui s’installe soit sur une machine Windows (physique ou virtuelle), soit qui se déploie sous forme d’appliance virtuelle linux tout intégrée. Il faudra également utiliser une autre licence que le mode FREE sur les ESX.
LICENCE
On aborde ici un point qui n’est pas du tout d’ordre technique, les licences.
De par mon travail chez un intégrateur, j’ai accès à un très grand nombre de licences de tests, de licences de type NFR (Not For Resale).
Pour la partie Vmware, les ESX ont une licence illimitée en termes de fonctionnalités pendant 60 jours.
Ensuite, on a la possibilité de passer en mode free édition et ce pour une durée illimité.
Le vCenter a besoin d’une licence.
Les ESX en mode FREE ne peuvent pas être ajoutés dans un vCenter.
Au niveau des VMs, c’est la même chose, bien que Windows 2012 ne se bloque pas s’il n’est pas enregistré, il vous faudra disposer des licences correspondantes.
vhlab - Virtu@l home lab 