La gestion des serveurs répond à certaines bonnes pratiques communément adoptées. L’une de ces pratiques est de limiter le nombre de services proposé par un même serveur. Ainsi, on évitera sur un serveur hébergeant un service de messagerie d’y ajouter un service d’impression ou encore un service d’annuaire. On isole les fonctions, ce qui offre l’avantage, en cas de compromission d’un service, de ne pas compromettre les autres. Il en découle souvent une utilisation inadaptée des ressources utilisées, les serveur étant surdimensionnés par rapport à la tâche unique qu’ils ont à effectuer.
Conçue dans une idée de mutualisation des ressources, et donc de réduction des coûts, la virtualisation s’est très largement répandue au fil des années.
L’hyperviseur constitue le socle matériel, il s’agit d’un serveur physique, disposant de suffisamment de CPU et de mémoire pour prendre en charge de multiples machines virtuelles hébergeant chacun leur propre système d’exploitation.
On distingue deux types d’hyperviseurs
Les hyperviseurs de types 1 et ceux de type 2.
L’hyperviseur de type 1 est une machine dont c’est la seule fonction, il est conçu et optimisé pour cette tache. Le matériel est directement présenté aux machines virtuelles par l’intermédiaire du logiciel d’hypervision.Les ESXi de Vmware ainsi que Hyper-V de Microsoft sont des hyperviseurs de type 1
A l’inverse, l’hyperviseur de type 2 évolue au sein d’un système d’exploitation qui est installé sur la machine physique. Il y a donc une couche supplémentaire entre le matériel et et la présentation des ressources aux machines virtuelles. Le très célèbre VirtualBox (oracle) est un hyperviseur de type 2, on l’installe souvent sur un poste de travail.
Les Notions d’Host et de VM
Un Host est un hyperviseur.
Une VM est une machine virtuelle (Virtual Machine), c’est un conteneur qui héberge un système d’exploitation.
Allocation des ressources
Les CPUs sont divisés en tranche de temps processeur, la mémoire (ram), lorsqu’elle n’est pas utilisée, est libérée pour retourner dans les ressources communes, et donc allouable aux autres machines virtuelles. Enfin, concernant le stockage, chaque VM dispose d’un fichier qui représente son disque dur, ce fichier peut être stocké sur un disque physique de l’hyperviseur ou bien, comme c’est généralement le cas, sur un montage réseau (typiquement, sur une baie de disques).
Exemple de la solution VMWare
Dans l’univers VMWare vSphere, nous l’avons vu, l’hypeviseur se nomme ESXi (Elastic Sky X**)**. Il est possible de gérer l’Esxi et les VMs depuis un accès ssh ou via un navigateur web.
Cependant, dans de nombreux cas, l’infrastructure de virtualisation compote plusieurs ESXi (soit pour supporter une charge importante, soit, c’est plus souvent le cas, pour assurer la haute disponibilité), c’est ici qu’entre en jeu le vCenter. Le vCenter server est soit un serveur physique, soit une VM. Il permet d’administrateur l’ensemble des hôtes (ESXi), et des VMs de manière centralisée.
On retrouve également la notion de Data Store, sur lesquels sont stockés les Vms. Le Data Store héberge un système de fichier de type VMFS.
Le Data Store est le plus souvent une baie disque de type SAN (les ESXi y sont raccordés afin que chaque VM soit visible par l’ensemble des ESXi)
Nous avons donc les composantes suivantes :
Les ESXi qui pilotent les Vms et leur alloues les ressources leur permettant de fonctionner (CPU, RAM).
Les Data Stores, lieux de stockage des machines virtuelles (disques dur)
Le Vcenter, le chef d’orchestre qui permet de gérer le fonctionnement de l’architecture, il s’agit du point centrale d’administration.
Le vCenter peut être une appliance, c’est-à-dire une machine virtuelle dotée d’un linux préconfiguré et optimisé. Autrement, il s’agira obligatoirement d’une machine (virtuelle ou physique) hébergeant un système d’exploitation Windows.
Le VMFS est le système de fichier (Virtual Machine File System) qui héberge les machines virtuelles.
Des réseaux virtuels assurent les échanges de toute natures au sein de cet écosystème
On y retrouve donc, très logiquement, des « vSwitchs ».
A la création d’un vSwitch, nous lui attribuons des NIC Ports (des ports physiques). Ces NICS ports sont à l’usage exclusif du vSwitch en question, et ne seront donc plus disponible pour un autre vSwitch.
Le nombre de ports sur le vSwitch s’adaptera automatiquement au fur et à mesure de l’ajout de VMs. On pourra modifié le MTU, ainsi que la vitesse et l’occupation de la bande passante.
Les « ports groups » sont des ports du vSwitch qui sont paramétrés, et utilisés par les VMs de l’hôte. La configuration de ces ports décrits notamment : le/les VLAN (Virtual Local Area Network), la vitesse de connexion, les sécurités utilisées, les associations teaming ect …Un port group définit comment les connexions sont faites sur le réseau physique.
Les « VMKernel ports » sont conçus pour délivres des serives à l’hôte, les VMs ne communiquent pas à travers ces ports, mais communique avec eux. Les services en questions sont le Managment, Fault tolerance, vMotion et vSAN. Ces services doivent être configurés exactement de la même façon sur les Hôtes qui doivent êtres associés, et ces services utiliser les mêmes VLAN
La fonctionnalité de vMotion (déplacement d’une VM d’un hôte à un autre nécessite un vMkernel port dédié, car les data y circulent en clair. Il est également nécessaire d’avoir une grosse bande passante (agrégation de lien)
Le principe de tagging consiste à l’ajout au sein d’un paquet reseau l’ID du VLAN. Cela permet aux paquets d’être invisibles aux équipements n’ayant pas ce VLAN de configurés
Il existe 3 types de tagging des VLANs
External switch tagging (VLAN ID 0) : Le tagging des paquets est assuré par le switch physique.
Virtual switch tagging (VLAN 1 – 4094) : Ici, c’est le vswitch qui réalise le tag des paquets.
Virtual Guest Tagging (VLAN 4095) : enfin, dans ce mode, c’est la VM qui effectue le tag.
Point important, Toutes les VMs associées au même port group ou VLAN peuvent communiquer directement à travers le vSwitch. A l’invester, des VMs associées à des vLANs différents sont considérées comme étant sur des réseaux différents, le trafic devra passer à travers un routeur physique pour y être redirigé.
Nic teaming
Il est possible d’utiliser plusieurs ports Ethernet afin de proposer à un port group ou Vlan d’un vSwitch les fonctionnalisés de LoadBalancing et de FailOver.
Fonctionnalités d’un Cluster d’ESXi
Lorsque l’on dispose de plusieurs ESXi, il est possible de les regrouper en cluster. Il est possible d’avoir plusieurs clusters. Il est possible de déplacer un ESXi d’un cluster à un autre (il faut préalablement le mettre en mode maintenance).
Fault Tolerance : La tolérance de panne permet d’assurer le fonctionnement des VMs en cas de défaillance d’un ESXi. Concrètement, la VM tourne simultanément sur les 2 Hôtes. Si l’hôte primaire tombe, le second prend automatiquement le relais, sans coupure de service. Le second hôte devient primaire et un nouveau hôte secondaire est désigné à travers le cluster. En fonctionnement nominal, les fichiers sont maintenus synchronisés entre l’hôte primaire et le secondaire grâce au FTLoggingNetwork.
Il est recommandé d’avoir à minima 3 hôtes au sein du cluster pour bénéficier d’une bonne couverture à la tolérance de pannes.
Hight Avaibility : En cas de défaillance, la VM est redémarrée sur un autre hôte du cluster. Ce mode introduit la notion de Maître et d’Esclave au niveau des hôtes du cluster.
Il existe biensur d’autres solutions de virtualisation (VirtualBox de type 2, Proxmox de type1, Ovirt de type 1..), que vous pouvez mettre en place pour un homelab par exemple.