ENI Cours Virtualisation ASR v2.2

version 2.
Formations à l’informatique
Découvrez la différence ENI
Virtualisation - Conception et Architecture

Support de cours
By sofien Mhatli
ISI KEF|ENI France
www.eni-ecole.fr
Votre formation - Programme
Virtualisation - Conception et architecture
 Module 1 – Retour sur les fondamentaux
 Module 2 – Les fonctionnalités du Datacenter vSphere
 Module 3 – Gestion des ressources et exploitation
 Module 4 – Haute disponibilité de l’infrastructure virtuelle
www.eni-ecole.fr n° 2
Module 1
Retour sur les fondamentaux
Contenu du module
 Les composantes d’une infrastructures vSphere
 Configuration du réseau
 Configuration du stockage
 Stockage et MPIO en environnement vSphere
Activons les souvenirs…
 2 serveurs ESXi et un vCSA vous sont livrés…
 Configurez les Hôtes pour les intégrer au vCenter
 Ajoutez 5 cartes réseaux à chaque hôte
 Configurez la partie réseau
 Configurez le stockage
 Vous simulerez une baie SAN avec le rôle iSCSI Target Server sur votre machine hôte.
Créez un espace de 60Go qui sera accessible par les 2 ESXi.
 Astuce : Pour que votre machine hôte communique avec vos VM, vous devrez
configurer la carte VMNET1 (sur votre machine hôte) avec l’adresse IP :
192.168.1.254/24
 A vous de jouer….
Un peu de vocabulaire…
Fonctionnalité / acronyme Définition / Utilité
Hyperviseur
Hôte
vCenter
vSwitch
vNIC
vmNIC
VMKernel
Adaptateur de stockage
iSCSI / NFS
La machine hôte
 C’est le serveur physique qui dispose des ressources matérielles
 Processeurs et technologies de virtualisation

Intel AMD
Mécanisme de VT-x AMD-v
prise en charge de
la virtualisation
Mécanisme de EPT NPT / RVI
prise en charge de
SLAT
La solution de gestion globale d’hyperviseurs
 Les hyperviseurs (HV) peuvent être gérés de manière autonome ou peuvent
être regroupés au sein d’un même contexte de gestion
 Ce regroupement, qui en simplifie l’administration, se traduit par :
 L’intégration à un contexte de domaine AD des serveurs sur lesquels le rôle Hyper V
est installé (en environnement Microsoft)
 L’ajout du composant vCenter (en environnement vSphere)
 A ces solutions peuvent être ajoutées des fonctionnalités de prise en charge de

la haute disponibilité (contexte de clusters)
Les principales fonctionnalités
Fonctionnalité Utilité
vMotion Déplacement de machine virtuelle d’un hôte vers un autre hôte.
Storage vMotion Déplacement du stockage d’une machine virtuelle d’une banque de
données vers une autre.
DRS Automatisation du déplacement de machines virtuelles : d’un hôte
Storage DRS vers un autre hôte disposant de plus de ressources ; ou d’un
datastore vers un autre.
DPM Fonctionnalité permettant d’automatiser l’entrée et la sortie de veille
d’hyperviseurs en fonction de la charge d’activité du cluster.
HA High Availability : fonctionnalité de haute disponibilité. Lors de la
défaillance d’un hôte, les machines virtuelles ciblées seront
redémarrées sur un autre hôte du cluster.
FT Fault Tolerance : fonctionnalité de très haute disponibilité protégeant
des machines virtuelles ciblées de la défaillance d’un hôte. Aucune
interruption de service n’affectera les VM ciblées.
Les ressources de l’hyperviseur
 Les types de ressources suivants sont nécessaires au fonctionnement de
machines virtuelles :
 CPU
 RAM
 Réseau
 Disque
 Ces ressources sont disponibles sur l’hôte et réparties par l’hyperviseur aux
machines virtuelles hébergées
Le vSphere Switch – (standard et distribué)
 C’est le composant central de gestion du réseau de l’ESXi
 Il est géré
 indépendamment pour chaque ESXi de l’infrastructure (vSwitch standard)
 depuis le vCenter et utilisable par tous les hyperviseurs du datacenter
Liaison
 Un vSwitch est lié à un ou plusieurs groupements de ports
 Un vSS peut être raccordé à zéro, une ou plusieurs cartes réseaux
Par défaut le vSwitch0 est créé, il est utilisable :

- Pour les tâches de gestion de l’ESXi
- Par les machines virtuelles
Il est lié à la carte réseau de l’ESXi présente à l’installation.
Les groupements de ports
 Ils définissent un type d’utilisation du réseau
pour l’ESXi parmi les suivants :
Type Utilisation
Création de réseau à destination des
VM Kernel
besoins de l’infrastructure de
virtualisation
VM Création de réseau à destination des
Network machines virtuelles
La segmentation en VLAN peut être configurée depuis

les groupements de ports.
Le groupement de ports de type VM Kernel
 Le groupement de port de type VM Kernel est utilisé pour les différents besoins
de l’infrastructure vSphere
 Un identifiant de VLAN peut lui être associé.

 Pour permettre l’utilisation des fonctionnalités suivantes, elles doivent être
actives sur le groupement de port :
 vMotion
 FT
 Gestion
 L’état d’activation de l’iSCSI résulte de la configuration du stockage
Les vmNIC et vNIC
 Les vmNIC sont les cartes réseaux  Les vNIC sont les cartes réseaux
physiques de l’ESXi. associées aux machines virtuelles.
 Les contraintes de liaison  Elles peuvent être connectées aux

vmNIC <=> vSwitch groupements de port de type Virtual
 Chaque carte peut être liée à un Machine
seul vSwitch
 Plusieurs cartes peuvent être liées La segmentation en VLAN peut être
au même vSwitch configurée au niveau des vNIC
Hote VM
Network adapters Networking
ENI E©ole
vmnic0 vnic
vmnic1 vSwitch0 Port group
de type Virtual Machine
Exemple d’illustration
Les VLAN en environnement virtualisé
 En environnement vSphere les VLAN peuvent affectés :
 Au niveau du switch
(un seul VLAN ciblera alors
tout le trafic)
 Sur des groupements de ports

 Sur des VNIC
 Si les VLAN sont affectés par l’hyperviseur, le switch doit être configuré en mode
trunk et lié à tous les VLAN nécessaires aux composantes d’infrastructure
vSphere et aux VM.
Les composantes vSphere de stockage
Dans une infrastructure vSphere, on distingue deux composantes de configuration
du stockage :
 Les adaptateurs de stockage servent à lier des solutions de stockage aux hôtes
amenés à les utiliser
 Les banques de données ou datastores correspondent aux conteneurs

« virtuels » dans lesquels sont hébergées les données
vSphere et le stockage
 De nombreuses possibilités sont prises en charge pour l’hébergement des
machines virtuelles dans l’environnement vSphere
 Les points suivants vous permettront de cibler la solution de stockage la plus

adaptée à une situation donnée :
 Stockage dédié à un hôte ou mutualisé
 Quel protocole d’accès à la solution de stockage
 Quel support
 Quel mode d’accès
 Quel système de fichiers utiliser
La diapositive suivante illustre ces différents aspects
iSCSI en environnement vSphere
 Illustration des éléments constitutifs d’une solution de stockage iSCSI
SAN Storage Area Network : le réseau de stockage qui est caractérisé par son
(ses) protocole(s) d’accès et connectivité, sa volumétrie, ses fonctionnalités
associées, ses performances
LUN Logical Unit Number : unité de stockage d’une baie de disques
HBA Host Bus Adapter : adaptateur de stockage qui (une fois configuré)
permettra l’accès à un ou plusieurs espaces disques
iSCSI Target L’élément qui met à disposition de l’espace disque physique
iSCSI Initiator L’élément qui accède à de l’espace disque mis à sa disposition
Banques de données et formatage
 On distingue 3 types de banques de données :
 VMFS
 RDM avec VMFS
 NFS
 Les banques de données exploitant un espace disque en mode bloc doivent être
formatées. Le système de fichier de formatage pris en charge par vSphere est
VMFS.
 VMFS est un système de fichier qui permet un accès concurrentiel en lecture et
écriture à un ensemble d’hôtes.
 La banque de donnée NFS cible un système de fichier réseau, accessible via le

protocole NFS. Pour celle-ci, le formatage est réalisé sur le serveur en charge du
partage de la ressource.
Gestion des banques de données
Les principales tâches de gestion des banques de données sont :
 Création et formatage
 Suivi de son taux d’utilisation
 Extension dynamique
 Parcours, import et export de données
Affichage des fichiers masqués

Tous les fichiers ne sont pas visibles depuis l’outil d’exploration, ils peuvent l’être depuis la
console de l’ESXi ou après s’y être connecté via ssh, au moyen de la commande ls
Terminer la MSP précédente
 Prise en charge de la redondance réseau :
 2 cartes pour le management
 2 cartes pour les VM
o Le vSwitch de l’ESX1 sera nommé VM ESX1
o Le vSwitch de l’ESX2 sera nommé VM ESX2
 2 cartes pour l’ISCSI
 Configurez l’iSCSI. Vérifiez en déconnectant une des 2 cartes réseaux que vous
ne perdez pas l’accès au datastore.
MPIO - intérêt d’utilisation en environnement vSphere
 MPIO : Multipath I/O est une méthode basée sur l’utilisation de chemins d’accès
multiples à un périphérique de stockage.
 Cette méthode est applicable à différents contextes, elle permet :

 D’accroitre la tolérance de pannes
 D’optimiser les performances
 En environnement vSphere, son utilisation peut être mise au profit

d’hyperviseurs pour leur desserte de solution de stockage distant.
 Cela accroit la disponibilité d’accès au stockage des éléments de l’infrastructure
vSphere et permet d’appliquer de l’équilibrage de charge pour l’accès au
stockage.
 La prise en charge de base du MPIO en environnement vSphere est native.
MPIO – Contextes et contraintes de mise en œuvre
Contexte de mise en œuvre en environnement vSphere
 MPIO permet de configurer sur un serveur ESXi plusieurs chemins et réseaux
pour l’accès à une unité de stockage logique via le protocole iSCSI.
Contraintes de conformité des groupes de ports pour l’accès au stockage :

 Plusieurs adaptateurs réseau peuvent être ajoutés à un adaptateur iSCSI donné.
 Les adaptateurs virtuels utilisés doivent être associés à une seule carte réseau
active (et aucune carte en standby)
Lors de l’association de VMNic

à un adaptateur de stockage,
la conformité des contraintes
est vérifiée.
MPIO – exemples de configuration réseau
 Les exemples suivants illustrent deux configurations réseaux pouvant être
utilisées pour le raccordement au stockage iSCSI d’un ESXi
 Exemple 1
Utilisation d’un vSwitch avec
deux groupes de ports (chacun
lié à une VMNic de l’hyperviseur)
 Exemple 2
Utilisation de deux vSwitchs avec
un groupe de port chacun
(chaque groupe de port étant lié
à une VMNic de l’hyperviseur)
MPIO – Configuration de l’adaptateur de stockage
 Configuration de la liaison de l’adaptateur iSCSI à des réseaux multiples
Module 2
Les fonctionnalités du Datacenter
vSphere
Contenu du module
 vCenter et la gestion vSphere
 Single Sign On (SSO)
 Les migrations
 Gestion distribuée du réseau
VMware vCenter
 vCenter a pour objectif de permettre la gestion centralisée de multiples serveurs
hôtes de virtualisation ESXi et des machines virtuelles hébergées sur ces
serveurs.
 Deux types de mise en œuvre de vCenter sont possibles :

 Installation du serveur vCenter sur un serveur Windows et liaison de celui-ci à une
base de données de type SQL.
 Utilisation de l'appliance vCSA (Virtual Center Server Appliance) limitée à 5 hôtes sur
vCenter 5.1 et 300 hôtes sur vCenter 5.5
vCenter est le point central de l’infrastructure virtualisée
Architecture vCenter
Serveur VMware vCenter
Gestion
VMware vSphere VMware vSphere VMware vSphere
Fonctionnalités vCenter
VMware vSphere
Disponibilité Sécurité Evolutivité
vShield Zones DRS
vMotion
VMSafe Hot Add
Services Storage vMotion
Application HA
Fault Tolerance
Data Recovery
Calcul Stockage Réseau

ESX and ESXi VMFS Distributed Switch
DRS and DPM Thin Provisioning Network I/O
Services Memory Storage I/O Control
Infrastructure Overcommit Control
vCenter et le contexte de Datacenter
 L’ajout de vCenter à une infrastructure de virtualisation vSphere permet la
création de contexte(s) de Datacenter vSphere.
 Les Datacenters définissent des périmètres de gestion de l'infrastructure

virtuelle. Peuvent être associés à un contexte de datacenter donné les
ressources suivantes :
 Cluster
 Serveur hôte
 Machine virtuelle
 Datastore
 Modèle
 Réseau virtuel
vCenter et le contexte de Datacenter
 L’organisation des ressources au sein de Datacenters multiples permet de
regrouper ces ressources selon certains critères comme :
 Leur emplacement géographique
 Leur client d’affectation
 Leur contexte d’utilisation (production, maquette)
Serveur vCenter
Datacenter Datacenter Datacenter Datacenter Datacenter

Nantes Rennes Montpellier Lyon Barcelone
Organisation des objets de l'inventaire
 La création de dossiers permet de regrouper des ressources d’un même type
pour la délégation et/ou pour des contraintes physiques.
Datacenter
Nantes
VDI Serveurs Hôtes Hôtes

Intel AMD
Bénéfices du Single Sign On
 Gestion centralisée des utilisateurs
 Support de multiples fournisseurs d'identités
 Découverte automatique des serveurs vCenter de l'infrastructure
 Granularité des délégations sur les objets
Composants Single Sign On (SSO)
vSphere client ou
Inventaire Serveur vCenter
Web
Authentification Serveur SSO Audit
Active Directory
Open LDAP NIS Base locale
2003 et +
Services d'identité
Composants Single Sign On (SSO)
 Ajout d'un service d'identité
Gestion des machines virtuelles
 Le gestion de machines physiques entraine des opérations en général lourdes à

réaliser (migration de serveurs, migration de SAN, réplication de configuration…)
 Le serveur vCenter permet de réaliser ces opérations dans l'environnement

virtuel en prenant en charge les opérations :
 de clonage,
 de déploiement de modèles préexistant de machines virtuelles
 de capture de l'état de machines virtuelles
 Le serveur vCenter est aussi nécessaire pour

 la migration à chaud des machines virtuelles et des datastores (sous réserve de
disposer des licences adéquates).
Migration de machines virtuelles
 La migration consiste à déplacer une machine virtuelle d’un hôte ESXi vers un
autre hôte ESXi. Il existe quatre types de migration :
 À Froid : La machine à migrer est arrêtée
 Suspendue : La machine à migrer est en pause (suspendue)
 vMotion : La machine virtuelle est en cours de fonctionnement
 Storage vMotion : Migration des fichiers de la machine virtuelle en cours de
fonctionnement d’un datastore à un autre
 Enhanced vMotion : Migration des fichiers de la machine virtuelle en cours de
fonctionnement sans stockage partagé. Cette opération ne peut être réalisée qu’à
l’aide du vSphere Web Client.
Méthodes de migration
 Source Vmware
vMotion
Stockage partagé
Disques virtuels et fichiers
VM 1 VM 1
(Réseau Production)
de configuration
(Réseau Production)
Image
ESX A
Mémoire
ESX B
Mémoire
Réseau vMotion
Réseau Production
Storage vMotion
 Storage vMotion permet la réalisation d’opération de maintenance et de
reconfiguration des espaces de stockage sans arrêt de production.
 Cette fonctionnalité est indépendante des types de stockage
1. Démarrage de la migration
2. Utilisation du VMkernel data
mover ou de l’API VAAI pour
copier les données
3. Démarrage d’un nouveau process
de VM
4. Le driver miroir intercepte tous
les appels et effectue les copies
sur les datastores source et
destination
 Source Vmware
Conception d’une gestion distribuée du réseau
 Dans un contexte de gestion isolée d’hyperviseurs, la gestion du réseau est
propre à chaque hyperviseur. Elle se traduit par l’utilisation de vSwitchs
standards et de groupes de ports locaux associés à ces commutateurs virtuels.
 Ces vSwitchs et groupes de ports sont créés et gérés localement sur chaque
hyperviseurs.
 Il est possible d’utiliser ces objets réseaux propres à chaque hyperviseur en

contexte de gestion global, dans une infrastructure vSphere intégrant vCenter.
Cependant la gestion d’une multitude de composantes réseaux isolées peut
s’avérer laborieuse. De plus cela accroit les risques d’incohérences en particulier
en cas de migration de VM.
 Pour simplifier la gestion du réseau et limiter ces contraintes, l’utilisation de

Switchs Distribués vSphere peut être envisagée.
 Cette fonctionnalité est disponible à partir de la version Entreprise Plus.
vDS : vSphere Distributed Switch
vSwitch vSwitch
vDS vSwitch
Hôte ESXi Hôte ESXi Hôte ESXi
Les composantes d’infrastructure réseau distribuée
 L’utilisation de réseaux vSphere distribués s’appuie sur la configuration d’un
ensemble d’éléments. Certains éléments sont gérés au niveau du vCenter /
Datacenter, d’autres sont à configurer sur les hôtes prenant part au réseau
distribué.
 Les composantes vCenter d’une infrastructure de réseau distribuée sont :

 Le vSphere Distributed Switch (vDS)
 Le Distributed Port Group (DPortGroup)
 Les éléments gérés sur les ESXi prenant part au réseau distribué sont :
 Les VMNic de l’hyperviseurs affectées au vDS
 Les adaptateurs virtuels associés aux vDS et DPortGroup
 Ces éléments seront abordés dans le détail dans les diapositives suivantes.
Le vSphere Distributed Switch
 Le vSphere Distributed Switch
 Il est caractérisé par
 sa version (contrainte par les ESXi)
 un nombre de ports de liens montants
 l’état d’activation de la fonctionnalité
Network I/O Control
 Il peut être associé à :

 un (ou plusieurs) groupes de ports distribués
 un ou plusieurs hyperviseurs (ainsi que les VMNic à utiliser)
Ajout du vDS
à un(ou Gestion des Groupes de
plusieurs) ports distribués associés
hyperviseurs au vSwitch
Le groupe de port distribué
 L’association d’un ou plusieurs groupes de ports distribués à un vSwitch
 permet de raccorder des machines virtuelles au réseau
 permet de répondre aux besoins d’infrastructure vSphere
 Les groupes de ports distribués sont notamment caractérisés par :

 Une méthode de liaison et d’allocation de port
 Un nombre de ports
Configuration réseau sur l’ESXi - 1
 Pour être utilisable par des hyperviseurs de l’infrastructure, un vDS doit être
ajouté aux hyperviseurs concernés.
 Lors de cet ajout, on sélectionne la ou les VMNic de l’hyperviseur utilisée(s)
pour le raccordement à ce vSwitch. Les machines virtuelles de l’ESXi peuvent
alors être raccordées à ce groupe de ports du vDS.
Configuration réseau sur l’ESXi - 2
 Pour qu’un groupe de port distribué soit utilisable pour répondre aux besoins de
l’infrastructure vSphere d’un hyperviseur, il faut lui associer un adaptateur
virtuel du (ou des) ESXi concerné.
 Le ciblage des différentes fonctionnalités vSphere est configuré sur les

adaptateurs virtuels.
Desserte réseau des machines virtuelles
Les types de cartes réseaux suivants peuvent être ajoutés aux machines virtuelles :
 E1000 : Emulation de la carte Intel 82545EM Gigabit Ethernet, reconnue par un

grand nombre d’OS récents, proposée par défaut, lors de la création de VM.
 E1000e : Emulation de la carte Intel Gigabit NIC 82574. Proposée par défaut
pour Windows 8 et Windows 2012 offre des performances supérieures.
 VMXNET 2 (Enhanced): Version supérieure de la carte VMXTNET et qui offre de

meilleures performances, et le support du jumbo frames. Nécessite les VMware
Tools.
 VMXNET 3 : Dernière génération des cartes réseaux paravirtualisées ajoutant

de la performance et des fonctionnalités supplémentaires. Requiert les VMWare
Tools, elle est reconnue comme une carte 10Gbps.
Débits comparés des différents types de cartes réseaux
 Comparaison des taux de transfert des différentes cartes :
entre ESXi intra ESXi
E1000 935 Mbits/sec 4.47 Gbits/sec
E1000e 926 Mbits/sec 4.47 Gbits/sec
VMXNET3 917 Mbits/sec 5.65 Gbits/sec
 Tests réalisés par Cedric Megroz

source : http://www.virtualementvotre.ch/blog/2014/11/17/performances-des-cartes-virtuelles/
Bonnes pratiques
 La partie réseau dans un environnement virtualisé est souvent cause de
ralentissements et de goulots d’étranglements.
 Pour palier à cette problématique, l’ajout d’un maximum de cartes réseaux

permet un meilleur équilibrage de la charge réseau et une meilleure tolérance
de panne.
 Aujourd’hui on peut considérer qu’il faut :
o 2 cartes pour le Management
o 2 cartes pour le vMotion
o 2 cartes pour le stockage IP (si SAN)
o 2 cartes minimum pour les VM
 Le faible coût financier des cartes réseaux aujourd’hui peut très facilement le
permettre.
MSP : vMotion, Storage vMotion, vDS
 Réaliser un déplacement de la VM Win7-ESX1 vers l’ESX2. Le stockage sera
également modifié vers le datastore local de l’ESX2.
 Quelle problématique se présente ?
 Créez un vSphere Distributed Switch pour les VM et incluez les cartes réseaux
correspondantes des hôtes à ce vDS.
 Assignez les 2 Vm à ce vDS et déplacez ensuite la VM Win7-ESX1 vers l’ESX1 (VM
+ Stockage vers le Datastore local).
 Vérifiez l’étiquette réseau assignée à la VM après son déplacement.
Module 3
Gestion des ressources et
Exploitation
Contenu du module
 Les Snapshots
 Gestion de l’automatisation du démarrage des VM
 Gestion des ressources
 Réservations / limites / pools : rappels
 Les parts
 L’extensibilité
 Allocation de ressources CPU
Snapshots
 Les snapshots ou instantanés de VM permettent de conserver l'état d'une

machine virtuelle et de réaliser un retour arrière en cas de nécessité.
 Un snapshot peut-être réalisé sur une machine virtuelle :

 en cours de fonctionnement
 en pause
 arrêtée
 Un snapshot capture l'état de la mémoire, des paramètres et du ou des

disque(s) de la machine virtuelle
Snapshots
 Le gestionnaire de snapshot permet de consolider des snapshots existants ou de

faire des retours arrières sur des versions précédentes de la machine virtuelle.
 Des applications destinées à la sauvegarde vont se baser sur des Snapshots pour
effectuer leur sauvegarde (Veeam Backup&Replication…)
 Dans le cadre de VM Windows, l’utilisation du protocole VSS (Volume Snapshot

Service) est indispensable.
 Il est chargé de geler la VM
 Doit être supporté par l’application sauvegardée (AD, Exchange, SQL…)
Automatisation du démarrage des VM
 Il est possible de configurer le démarrage automatique de VM au lancement de
l’hyperviseur. Cette fonctionnalité permet de réduire l’indisponibilité de machine
virtuelles après redémarrage de l’hyperviseur les hébergeant.
 A défaut de paramétrage les machines virtuelles sont à démarrer manuellement.
Configuration du démarrage automatique de VM
Réservation et limites
 La réservation de ressources
Permet de garantir le provisionnement en ressources physiques de l’hôte pour des
…….……………………………………………………………………………………………………………………………
machines virtuelles.
…….……………………………………………………………………………………………………………………………
…….……………………………………………………………………………………………………………………………
 La configuration de limites de ressources

Permet de limiter l’utilisation de ressources physiques pour des machines virtuelles
…….……………………………………………………………………………………………………………………………
…….……………………………………………………………………………………………………………………………
…….……………………………………………………………………………………………………………………………
Ciblage Pool / VM
 La
Mise en en
mise œuvre
œuvrede de
limites et réservations
limites sursur
et réservations une VMVM
une
Affecte les ressources de l’hyperviseur AU DEMARRAGE de la VM.
…….……………………………………………………………………………………………………………………………
Peut bloquer le démarrage d’une VM (VM seul) ou le garantir (VM + POOL).

…….……………………………………………………………………………………………………………………………
…….……………………………………………………………………………………………………………………………
 La
Mise en en
mise œuvre
œuvrede de
limites et réservations
limites sursur
et réservations unun
pool dede
pool ressources
ressource
Affecte les ressources de l’hyperviseur immédiatement.
…….……………………………………………………………………………………………………………………………
Les ressources affectées au pool sont utilisables par les VM du pool sur lesquelles
…….……………………………………………………………………………………………………………………………
des réservations sont configurées.

…….……………………………………………………………………………………………………………………………
Ressources : fonctionnement des parts
 Quand l’hyperviseur utilise toutes ses ressources, mémoire ou processeur il
privilégie certaines machines au détriment d’autres.
 Les machine privilégiées se voient accorder plus de ressources physiques, ou
plus de parts de ressources matérielles.
10GiB
 L’affectation de parts se configure sur une 3000 parts
machine virtuelle ou sur un pool (parts 10GiB
VM-ERP
réparties entre les machines du pool). 10GiB
10GiB
SRV-INF1
 La gestion des parts possède 3 niveaux 10GiB
par défaut Low, Normal, High 4000 parts DC01

10GiB
 Ils s’appuient sur des ratios 1:2:4.
SRV-PROD1 10GiB
 Un pool de ressources avec une priorité
High aura donc 4 fois plus de ressources 1000 parts SRV-MAIL1 10GiB
qu’un pool en priorité Low. 1000 parts SRV-BACKUP 10GiB
SRV-PROD2
1000 parts SRV-INF2
10GiB
10 000 parts Capacité 100 GiB

Exemple de configuration des parts
Un cluster possède une capacité totale de calcul de 30GHz et 300Go de RAM.
On crée 2 pools de ressources :
- Un pool production avec parts configurées en High hébergeant 8 VM
- Un pool tests avec parts configurées en Normal hébergeant 2 VM
TESTS (normal) Capacité totale

PRODUCTION (high)
CPU : 30 GHz
RAM : 300Go
 Contexte : on considère que toutes les ressources de l’hôte sont utilisées

 Les parts définies sur les pools sont donc exploitées
o Le pool production a un ratio de 4
o Le pool tests a un ratio de 2
 Ressources allouées aux pools :
o Production : 20Ghz, 200Go RAM
o Tests : 10 Ghz, 100Go RAM
Résultante de la configuration des parts
PRODUCTION (high) TESTS (normal)

20GHz / 200 Go RAM 10Ghz / 100Go RAM
Capacité totale
CPU : 30 GHz
RAM : 300Go
La résultat appliqué aux machines virtuelles des pools est le suivant :

 Sur le pool production (8 VM) on aura donc une moyenne par VM de :
 2,5 GHz
 25 Go RAM
 Sur le pool tests (2 VM) :
 5 Ghz / VM
 50 Go RAM / VM
Configuration des parts : conception
 Le nombre de VM présentes dans le pool est capital pour effectuer les calculs. Il
faut avoir conscience que les ressources attribuées au pool sont réparties entre
les différentes machine.
 Pour donner plus de priorité aux VM du pool de production il faudra donc

effectuer des calculs et configurer le nombre de parts de celui-ci à personnalisé.
Imbrication de pools et extensibilité
 L’extensibilité est un point de configuration qui peut être activé (par défaut) ou
désactivé sur un pool de ressources. Un pool de ressources « extensible » peut
emprunter des ressources réservables aux pools parents. Cette opération peut-
être récursive jusqu’au pool racine.
 Scénario mettant en œuvre cette notion :

 Le service informatique de l’entreprise OMB fournit des services à deux clients
internes : les services administratif-finances et le service ingénierie-production.
 Le service ingénierie-production finance les 2/3 du budget informatique

 Le service administratif-finance finance 1/3 du budget informatique
 Chaque service exploite des machines de production et de test
Scénario – exemple de configuration
Pool de ressource Racine
CPU Total : 12000 MHz

Mémoire Totale : 8 000 Mo
Pool Ing-Prod
Les machines virtuelles du pool Ingénierie
pourront emprunter des ressources au
Réservation : 3000 MHz
pool parent.
Réservation extensible : oui
Pool Ingénierie Pool Production Les machines virtuelles

du pool production sont
Réservation : 1400 MHz Réservation : 1000 MHz limitées aux ressources
Réservation extensible : oui Réservation extensible : Non de leur pool
VM 4 VM 5 VM 6 VM 7 VM 1 VM 2 VM 3
R =500 R =500 R =500 R =500 R =400 R =300 R =500
Allocation de ressources CPU aux machines virtuelles
 L’allocation de ressources CPU par machine virtuelle se traduit par la
configuration :
 D’un nombre de socket virtuel
 D’un nombre de cœurs d’exécution
par socket
Þ Le produit de ces deux valeurs détermine le nombre de vCPU alloué à la VM.
 L’affectation d’une limite de fréquence CPU peut compléter la configuration du

nombre de vCPU en affectant précisément les ressources CPU dont elle a
besoin.
 Lorsqu’une VM demande des ressources CPU à l’hyperviseur, elle requiert la

disponibilité d’autant de vCPU que configurés.
Conséquences de la sur allocation CPU
 L’hôte physique sur lequel est installé l’hyperviseur dispose d’un ou plusieurs
socket CPU à un ou plusieurs cœurs chacun. Le produit de ces deux valeurs
forme le nombre de vCPU de l’hôte.
 Il est possible d’allouer à l’ensemble des VM plus de vCPU que n’en dispose
l’hôte. Cela n’a pas de conséquence sur les performances des VM tant que les
ressources utilisées par les VM sont inférieures aux ressources de l’hyperviseur.
 Cela impacte les performances des VM quand plus de ressources sont
demandées par les VM que n’en dispose l’hyperviseur.
vCPU Hôte Machines virtuelles

vCPU
vCPU vCPU
vCPU
vCPU vCPU
vCPU
vCPU vCPU vCPU
vCPU vCPU vCPU
vCPU
vCPU vCPU
vCPU
vCPU vCPU
Allocation de vCPU multiple à une VM
 En cas de surallocation de vCPU, lors du besoin de ressources CPU par les VM,
celles-ci peuvent :
 Soit disposer d’autant de vCPU que configuré
 Soit être en attente de disponibilité CPU
 Plus le nombre de vCPU alloué à une VM est grand, plus ses demandes de
ressources risquent d’être mises en attente.
VM en attente CPU
vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU 1 cycle d’horloge
vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU
Ressources CPU 2 4 8
configurées vCPU vCPU vCPU
Module 4
Haute disponibilité
de l'infrastructure virtuelle
Contenu du module
 Disponibilité et solutions
 Le cluster vSphere
 vSphere HA
 vSphere FT
 vSphere DRS
 vSphere DPM
Introduction
 La plupart des organisations s’appuient aujourd'hui sur un système

d’information qui est devenu critique pour leur bon fonctionnement. La
défaillance d’un service d’infrastructure ou un service applicatifs peut entrainer
des dysfonctionnements importants et des pertes de production conséquentes.
 La mise en œuvre de services permettant de garantir des niveaux de

disponibilité est donc primordiale.
Contextes de haute disponibilité
 Le rôle du service informatique ou d’un fournisseur de service est de garantir le
bon fonctionnement et la disponibilité des services mis en œuvres.
 Pour les services critiques, des contraintes de disponibilité peuvent être
imposées, notamment quand leur indisponibilité impactent directement le
fonctionnement de l’entreprise.
 La notion de haute disponibilité est liée à la mise en œuvre d’un ensemble de
techniques visant à accroitre la disponibilité d’un environnement donné.
 Les principaux niveaux de disponibilités

Niveau de Temps d’interruption/an
 Pas de haute disponibilité disponibilité
 Haute disponibilité 99 % 87,5 heures (3,5jours)
interruption de service limitée 99,9% 8,76 heures
 Très haute disponibilité
99,99% 52 minutes
aucune interruption de service
99,999% 5 minutes
Les solutions pour accroitre la disponibilité
 Une multitude de mesures peut être mise en œuvre pour accroitre la
disponibilité d’éléments ciblés d’une infrastructure.
 Approche granulaire : accroitre la disponibilité d’un service nécessite des

compétences, des taches de gestion supplémentaires, des ressources, la mise en
œuvre de solutions complexes et coûteuses … C’est donc une approche qui doit
être menée service par service et un traitement au cas par cas.
 Une fois ciblé les services, devra être

choisie la couche et la solution à Services
appliquer afin d’accroitre leur
disponibilité. OS
Infrastructure vSphère
Matériel
Discussion
Solutions de haute disponibilité

Quelles solutions avez-vous déjà mis en œuvre ou
rencontré afin d’accroitre la disponibilité de services ?
www.eni-ecole.fr Module 1 - n° 76
Analyse des besoins
 La mise en place d’un ensemble de solutions, pour accroitre la disponibilité
d’une multitude de services doit se faire après un important travail d’analyse des
besoins et contraintes de disponibilité service par service.
 On ne met pas en place une solution de haute disponibilité pour les services de
l’entreprise, mais des solutions personnalisées pour des services ciblés.
 La mise en œuvre et configuration de solutions ne représente qu’une petite

partie du processus d’accroissement de la disponibilité de ressources. C’est
cependant cette partie qui est majoritairement traitée dans ce support.
/!\
Seules les fonctionnalités de haute disponibilité propre à
l’environnement vSphere sont présentées dans la suite de ce
module.
Haute disponibilité en environnement vSphere
 L’environnement vSphere correspond à la couche de virtualisation de serveur de
l’infrastructure. Les solutions prises en charge par vSphere permettent d’agir à
ce niveau.
 La haute disponibilité se traduit par la mise en place d’un contexte de cluster

vSphere auquel on associe un ensemble d’hôtes.
 Les fonctionnalités suivantes sont liées au cluster vSphere :

 vSphere HA (vSphere High Availability)
 vSphere FT (vSphere Fault Tolerance)
 vSphere DRS (vSphere Distributed Ressource Scheduler)
 vSphere Storage DRS (vSphere Storage Distributed Ressource Scheduler)
 vSphere DPM (vSphereDistributed Power Management)
vSphere HA
 vSphere HA permet de minimiser le temps d’indisponibilité. L’interruption de
service existe toujours mais est très largement minimisée.
 Tous les systèmes d’exploitation invités sont supportés
 La fonctionnalité est disponible dans le cadre d'un cluster
 Protection contre la défaillance d’un hôte ESXi, d’une machine virtuelle, d’une
application
 Le Heartbeat est chargé de détecter les défaillances
vSphere HA: Fonctionnement du cluster
 Lors de l’ajout d’un hôte dans un cluster HA, un agent FDM (Fault Domain
Manager) est transféré sur l’hôte.
 L’agent FDM est chargé de la communication entre les hôtes du cluster et de la
remontée d’informations :
 Etat des VMs
 Placement, redémarrage des VMs
 Mécanisme de heartbeat
 En relation directe avec l’agent hostd
VM 2 VM 4
VM 1 VM 3
FDM FDM
ESXi master ESXi slave
Cluster
hostd hostd
Serveur vCenter
vSphere HA: Fonctionnement du cluster
 Un processus d’élection détermine un serveur Maitre, tous les autres sont
esclaves. En cas de défaillance du serveur Maitre, une nouvelle élection a lieu.
 Le choix du nouveau maître est basé sur celui qui possède le plus grand nombre
de datastores connectés.
 Le serveur principal :
 Surveille l’état des hôtes secondaires
 Surveille l'état d'alimentation des VM protégées
 Collecte les informations des VM protégées par le HA.
 Les serveurs esclaves :

 Indiquent l’état de leurs VM et informent le serveur maître des changements d’états.
 Si le serveur maître est injoignable, ils provoquent une élection.
vSphere HA : HeartBeat
 Deux mécanismes de heartbeat différents sont utilisés dans le cluster:
 Un mécanisme de heartbeat utilisant tous les réseaux VMKernel configurés pour un
trafic de gestion.
o Maitres et esclaves s’envoient un heartbeat chaque seconde.
 Si il y a une rupture de communication sur le heartbeat, le maître envoie un ping

ICMP sur l’adresse IP du serveur esclave injoignable.
 Pour vérifier qu’il n’est pas en situation d’isolement réseau, un hôte effectue
également une requête ICMP sur son adresse de passerelle par défaut. Sans réponse
à cette requête HA ne se déclenchera pas. Les VMs ne seront pas redémarrées sur un
autre hôte.
 Un mécanisme de heartbeat utilisant les datastores partagés.

o Quand un isolement réseau est détectée (le heartbeat réseau n’est plus détecté) et
uniquement dans ce cas là, le serveur maitre recherche sur les datastores partagés (deux
par défaut) la présence d’un fichiers spécial généré par chacun des hôtes actifs.
Redondance des réseaux pour Heartbeat
 Si plusieurs hôtes sont isolés et peuvent continuer à s’échanger des pulsations
au travers d’un des réseau de gestion ou bien d’un datastore, on parlera de
Partitionnement du réseau et un processus d’élection sera déclenché.
 Lorsqu’un hôte est isolé, HA va forcer les VM à s’arrêter.
 Dans un cluster HA les pulsations heartbeat sont :

 Envoyées entre le serveur maitre et les serveurs esclaves
 Utilisées pour savoir si un hôte est défaillant
 Mises en œuvre sur un port Vmkernel configuré pour le trafic de gestion
 La redondance des réseaux sur lesquels circulent les pulsations est primordiale
pour éviter un isolement des hôtes pouvant entrainer le démarrage de deux
machines identiques sur le réseau.
Redondance réseau pour Heartbeat
Différentes méthodes sont envisageables pour rendre redondant le réseau utilisé pour le
heartbeat :
 Redondance avec agrégation de liens
 Redondance avec plusieurs réseaux de heartbeat
 Le trafic de gestion doit être coché sur

le·s groupement·s de ports concerné·s
Datastore Heartbeat
En cas de défaillance des réseaux de gestion, les datastores communs sont utilisés
pour déterminer si un hôte est isolé ou non. Minimum 2 datastores sont nécessaires.
vSphere HA : Défaillance d’un hôte
 En cas de défaillance le service HA redémarre les VM sur un autre hôte ESXi
VM 2 VM 4 VM 6
VM 1 VM 3 VM 5
ESXi ESXi
! ESXi
Cluster
Serveur vCenter
vSphere HA : Défaillance d’une VM
 Quand une VM n’envoie plus son heartbeat ou que le process de la machine
virtuelle échoue, HA redémarre la VM. Les VMware tools doivent être installé
ls
Too
VM
VM 6
ls ls
Too Too
VM VM
VM 5 VM 9
ls o ls ls
Too To Too
VM VM VM
VM 2 VM 4 VM 8
ls ls ls
Too Too Too
VM VM VM
VM 1 VM 3 VM 7
ESXi ESXi ESXi
Cluster
Serveur vCenter
vSphere HA : Défaillance d’une application
 En cas de défaillance d’une application pouvant dialoguer avec les VMware
tools, HA redémarre la VM concernée.
ls
P Too
AP VM 6 VM
ls ls
Too Too
P
AP VM 5 VM P
AP VM 9
VM
ls ls
P Too
ls
P Too Too
AP VM 2 VM AP VM 4 VM P
AP VM 8 VM
ls ls ls
P Too P Too Too
AP VM 1 VM AP VM 3 VM P
AP VM 7 VM
ESXi ESXi ESXi
Cluster
Serveur vCenter
vSphere HA : Configuration
 Un cluster regroupe un ensemble d’hyperviseurs et leurs machines hébergées
sur lesquels les fonctions de haute disponibilité (HA et/ou DRS) sont activées.
 Les différentes fonctionnalités de haute disponibilité peuvent :
 Etre activées à la création du cluster
 Etre activées sur un cluster existant
vSphere HA : Configuration
Désactiver ce
paramètres lors de
maintenance du
réseau
Le contrôle
d'admission garantit
que suffisamment de
ressources sont
disponibles pour le
fonctionnalité HA
 En cas de modification de la configuration réseau (ajout de groupement de port,

suppression de vswitchs … ) pour prévenir des dysfonctionnement du cluster HA, il est
nécessaire de désactiver la surveillance de l'hôte et de le placer en mode maintenance
Options des machines virtuelles
 Dans la configuration de vSphere HA sont défini les comportements par défaut :
 De priorité de redémarrage des VM
 D’action à mener en cas d’isolement réseau de l’hôte
Options des machines virtuelles
 Ces règles peuvent être redéfinies machine par machine au besoin afin de
répondre à des besoins précis.
 Il est ainsi possible de gérer l’ordre de redémarrage des VM dans le cadre de HA.
 On pourra par exemple dans le cadre d’applications métier redémarrer le
serveur hébergeant la base de données avant le serveur applicatif.
Surveillance des machines virtuelles
Réinitialisation par l’hyperviseur de la machine virtuelle en cas de non réception des
heartbeats (requiert les VMware tools)
Paramètres Intervalle de Période de

défaillance réinitialisation
Haut 30 1h
Moyen 60 24h
Faible 120 7 jours
Surveillance du cluster HA
vSphere FT (Fault Tolerance)
 La fonctionnalité HA entraine une indisponibilité (downtime) non négligeable
puisqu’une machine virtuelle considérée comme non disponible est redémarrée
sur un autre hôte ESXi. Cela entraine donc la perte de toutes les transactions qui
n'ont pas été validées sur les disques stockés sur les datastores. Une application
pourrait également avoir conservé des fichiers ouverts et se trouver dans un état
incohérent.
 vSphere FT (Fault Tolerance) va permettre de répondre à ces deux

problématiques et de protéger d’une interruption de service les machines
critiques.
 FT est une solution de très haute disponibilité qui est utilisée dans le cadre
d’applications critiques.
 Cette fonctionnalité requiert le contexte de cluster vSphere.
vSphere FT (Fault Tolerance)
 La fonctionnalité FT fonctionne sur le modèle du cluster actif / passif : une VM
en fonctionnement est active sur un hôte et passive sur le second. Tous les flux
d’E/S de cette VM sont répliqués en permanence vers sa « copie » passive.
VMware ESXi VMware ESXi VMware ESXi
Hôte Hôte Hôte

opérationnel défaillant opérationnel
 En cas de défaillance de l’hôte sur lequel la VM est active, celle-ci devient active
sur l’autre hôte immédiatement, sans aucune interruption de service.
vSphere FT (Fault Tolerance) : Contraintes
 Un nombre suffisant de serveurs ESXi doit être disponible pour protéger des VM
tolérantes aux pannes. (VMware recommande un nombre maximum de 4 VM-
FT primaires ou secondaires par hôte)
 Les datastores doivent être accessibles par tous les hôtes.
 Des contraintes du nombre de vCPU s’appliquent aux machines virtuelles
concernées (en fonction de la version de l’hyperviseur et des licences).
 La fonctionnalité storage vMotion est incompatible avec FT.
 Un réseau vmkernel différent du réseau vMotion est nécessaire à des fins de
redondance.
vSphere FT (Fault Tolerance) : Contraintes
 Les snapshots sont impossibles.
 Les sauvegardes exploitant l'API VADP (vStorage API for Data protection) sont
indisponibles.
 Les disques durs doivent être de taille fixe (Thick Eager Zeroed) ou RDMv.
L’activation de FT modifiera leur état et ajustera automatiquement la réservation
de la RAM.
vSphere FT : Evolutions de avec vSphere 6
 Depuis la version 6, certains logiciels de Backup comme Veeam
Backup&Replication prennent en charge la sauvegarde de machines protégées
par FT.
 Les limites techniques ont été repoussées sur de nombreux points, en particulier
sur le nombre de vCPU par VM qui est passé de 1 à 4.
Elements vSphere 5.5 vSphere 6

Virtual machine maximums
Virtual CPUs per core 32 32
Fault Tolerance maximums

Virtual disks 16 16
Virtual CPUs per virtual machine 1 4
RAM per FT VM 64 Go 64 Go
Virtual machines per host 4 4
MSP : HA
 Mettez en place HA entre les 2 hôtes.
 Vérifiez le bon fonctionnement en arrêtant physiquement un des deux ESX
 Vérifiez le bon fonctionnement en déconnectant les cartes réseaux d’un des hôtes
DRS, SDRS, DPM
 Les services de migration vMotion et Storage vMotion permettent de déplacer
VM et contenu dans l'infrastructure virtuelle.
 Les services de Haute disponibilité HA et FT permettent d’accroitre la
disponibilité de VM.
 La charge des hyperviseur peut être inégale dans le temps ce qui requiert un
suivi des administrateurs afin de positionner / migrer les VM sur les hôtes de
manière appropriée afin d’équilibrer leur charge.
 vSphere propose plusieurs services pour répondre à ces besoins :

 Distributed Ressource Scheduler (DRS) : optimisation du placement des VM
 Storage Distributed Ressource Scheduler (Storage DRS) : optimisation des Datastores
 Distributed Power Management (DPM) : consolidation des VM sur les hôtes
Cluster DRS
 Les fonctions DRS sont disponibles dans le cadre d'un cluster vSphere.
 Le cluster DRS est géré par un serveur vCenter et propose la gestion :

 Du placement initial des VM
 De l'équilibrage de charge
 De la gestion de l'énergie (Power Management)
Cluster DRS : Prérequis
 Pour le fonctionnement du cluster DRS :
 les hôtes doivent être reliés par un réseau virtuel configuré pour vMotion
 les hôtes doivent être connectés à un stockage partagé
 Tous les datastores doivent être accessibles par les hôtes membres du cluster
 Un certain niveau de compatibilité matérielle est requis pour utiliser cette
fonctionnalité
EVC (Enhanced vMotion Compatibility)
 Dans le cadre de la mise en place d’un Cluster, il est essentiel de tenir compte de
la couche matérielle, bien souvent oubliée lors de la mise en place
d’hyperviseurs.
 La famille de processeurs (Intel / AMD) est une donnée essentielle puisque dans
le cadre d’un cluster, il sera impossible de mixer les technologies.
 Au-delà du constructeur, la génération du processeur va également avoir un
rôle.
 Les processeurs évoluent et certaines instructions CPU apparaissent. Elles ne seront
donc pas forcement prises en charge par l’ancienne génération.
 Ces différentes instructions non prises en charge peuvent notamment poser des
problèmes dans un contexte vMotion (impossible de migrer les VM).
 Pour faire face à ces problématiques, EVC (Enhanced vMotion Compatibility) à

fait sont apparition.
EVC (Enhanced vMotion Compatibility)
 Cette fonctionnalité favorise la compatibilité des processeurs de génération
différentes dans un contexte vMotion.
 EVC garantit que tous les serveurs hôtes d'un cluster présenteront les mêmes
jeux d'intruction aux VM
DRS: Niveau d'automatisation
 Trois niveaux d'automatisation sont disponibles
 En mode entièrement automatisé, un seuil de migration permet de définir 5

niveaux d'automatisation, du plus conservateur au plus agressif.
Niveau d'automatisation Placement initial des VM Equilibrage de charge dynamique
Manuel Manuel Manuel
Partiellement automatisé Automatique Manuel
Entièrement automatisé Automatique Automatique
DRS : Règles d'affinité du cluster
 L'automatisation du placement des VM dans un cluster peut être la source de
problème de performances ou de sécurité. Exemple : les deux membres d'un
cluster à basculement positionnés sur le même hôte. En cas de défaillance de
l'hôte, le cluster à basculement serait pris en défaut.
 Des règles d'affinité ou d'anti-affinité permettent de définir si des machines
virtuelles peuvent se trouver sur le même hôte ou si au contraire ils doivent être
sur deux hôtes distincts.
DRS : Niveau d'automatisation des machines virtuelles
 Si l’option d’activation des niveaux d’automatisation au niveau des VM est
cochée dans les propriétés du cluster DRS, les paramètres de migration peuvent
être définis par VM
Storage DRS
 Les performances d'une infrastructure de virtualisation sont très dépendantes
des ressources de stockage. L'optimisation des performances de ces ressources
peut-être effectuée au niveau des services de stockage SAN (sous réserve de
compatibilité avec le tiering automatique) ou bien par vSphere.
 La fonctionnalité Storage DRS permet d'analyser les I/O sur les datastores pour
positionner au mieux ceux-ci sur les ressources de stockage les plus appropriées.
Cette fonctionnalité requiert la création d’un cluster de banques de données
Storage DRS
 Des mesures sont effectuées régulièrement pour proposer des
recommandations à l'administrateur
DPM: Distributed Power Management
 La fonction Distributed Power Management (DPM) de vSphere permet à un
cluster DRS de réduire sa consommation d'énergie en activant et désactivant
des hôtes sur la base de l'utilisation des ressources de cluster.
 vSphere DPM surveille le cumul des exigences de toutes les machines virtuelles
dans le cluster en termes de mémoire et de ressources CPU et les compare à la
capacité totale de ressources disponible de tous les hôtes dans le cluster. Si la
surcapacité suffisante est trouvée, vSphere DPM place un ou plusieurs hôtes en
mode standby et les désactive après avoir migré leurs machines virtuelles vers
d'autres hôtes.
 À l'inverse, quand la capacité est considérée insuffisante, DRS met fin au mode
veille des hôtes (les active) et emploie vMotion pour migrer des machines
virtuelles vers eux.
 Ici, un des 3 hôtes n’héberge qu’une seule VM.
 Un des autres hôtes n’est pas surchargé et possède les ressources nécessaires pour
accueillir cette VM supplémentaire
 La VM est déplacée et l’hôte qui l’hébergeait est mis en standby
VM 2 VM 5
VM 1 VM 3 VM 4
ESXi ESXi ESXi
Cluster
Serveur vCenter
 Si un hôte est surchargé, DPM va rallumer un hôte en standby pour décharger
l’hôte et mieux répartir la charge.
VM 5
VM 2 VM 4
VM 1 VM 3
ESXi ESXi ESXi
Cluster
Serveur vCenter
Comment DPM allume et éteint-il les hôtes ?
 Pour que vSphere DPM puissent gérer l’alimentation des hôtes, il sera
indispensable que ces hôtes disposent de « cartes de management ».
 Selon le constructeur, elles portent des noms différents
 DELL : Carte iDRAC
 HP : Carte ILO
 IBM : Carte RSA
 …
 Ces cartes permettent de gérer les hôtes même si ils sont éteints.
DPM : Activation
MSP : Pools de ressources et de DRS
 Validation du mode DRS partiellement automatisé
 Déplacez les 2 VM sur un seul hôte
 Arrêtez une des VM
 Mettez en place DRS en mode partiellement automatisé
 Démarrer la VM éteinte
 Validation du mode DRS totalement automatisé
 Déplacez les 2 VM allumées sur un seul hôte
 Installez l’outil Loadstorm sur une des VM (disponible en ISO sur « Distrib »)
 Mettez en place DRS en mode totalement automatisé
 Générez de la charge CPU via Loadstorm sur la VM
 Vérifiez que les machines ont bien été déplacées

ENI Cours Virtualisation ASR v2.2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ENI Cours Virtualisation ASR v2.2

Transféré par

Droits d'auteur :

Formats disponibles

version 2.

Virtualisation - Conception et Architecture

 Processeurs et technologies de virtualisation

 A ces solutions peuvent être ajoutées des fonctionnalités de prise en charge de

Par défaut le vSwitch0 est créé, il est utilisable :

Il est lié à la carte réseau de l’ESXi présente à l’installation.

La segmentation en VLAN peut être configurée depuis

 Un identifiant de VLAN peut lui être associé.

 L’état d’activation de l’iSCSI résulte de la configuration du stockage

 Les contraintes de liaison  Elles peuvent être connectées aux

 Sur des groupements de ports

 Les banques de données ou datastores correspondent aux conteneurs

 Les points suivants vous permettront de cibler la solution de stockage la plus

La diapositive suivante illustre ces différents aspects

 La banque de donnée NFS cible un système de fichier réseau, accessible via le

Affichage des fichiers masqués

 Cette méthode est applicable à différents contextes, elle permet :

 En environnement vSphere, son utilisation peut être mise au profit

 La prise en charge de base du MPIO en environnement vSphere est native.

Contraintes de conformité des groupes de ports pour l’accès au stockage :

Lors de l’association de VMNic

 Deux types de mise en œuvre de vCenter sont possibles :

vCenter est le point central de l’infrastructure virtualisée

Serveur VMware vCenter

VMware vSphere VMware vSphere VMware vSphere

Calcul Stockage Réseau

 Les Datacenters définissent des périmètres de gestion de l'infrastructure

Datacenter Datacenter Datacenter Datacenter Datacenter

VDI Serveurs Hôtes Hôtes

Authentification Serveur SSO Audit

 Le gestion de machines physiques entraine des opérations en général lourdes à

 Le serveur vCenter permet de réaliser ces opérations dans l'environnement

 Le serveur vCenter est aussi nécessaire pour

 Il est possible d’utiliser ces objets réseaux propres à chaque hyperviseur en

 Pour simplifier la gestion du réseau et limiter ces contraintes, l’utilisation de

Hôte ESXi Hôte ESXi Hôte ESXi

 Les composantes vCenter d’une infrastructure de réseau distribuée sont :

 Il peut être associé à :

 Les groupes de ports distribués sont notamment caractérisés par :

 Le ciblage des différentes fonctionnalités vSphere est configuré sur les

 E1000 : Emulation de la carte Intel 82545EM Gigabit Ethernet, reconnue par un

 VMXNET 2 (Enhanced): Version supérieure de la carte VMXTNET et qui offre de

 VMXNET 3 : Dernière génération des cartes réseaux paravirtualisées ajoutant

entre ESXi intra ESXi

E1000 935 Mbits/sec 4.47 Gbits/sec

E1000e 926 Mbits/sec 4.47 Gbits/sec

VMXNET3 917 Mbits/sec 5.65 Gbits/sec

 Tests réalisés par Cedric Megroz

 Pour palier à cette problématique, l’ajout d’un maximum de cartes réseaux

 Les snapshots ou instantanés de VM permettent de conserver l'état d'une

 Un snapshot peut-être réalisé sur une machine virtuelle :

 Un snapshot capture l'état de la mémoire, des paramètres et du ou des

 Le gestionnaire de snapshot permet de consolider des snapshots existants ou de

 Dans le cadre de VM Windows, l’utilisation du protocole VSS (Volume Snapshot

 A défaut de paramétrage les machines virtuelles sont à démarrer manuellement.

 La configuration de limites de ressources

Peut bloquer le démarrage d’une VM (VM seul) ou le garantir (VM + POOL).

des réservations sont configurées.

par défaut Low, Normal, High 4000 parts DC01

qu’un pool en priorité Low. 1000 parts SRV-BACKUP 10GiB

10 000 parts Capacité 100 GiB

TESTS (normal) Capacité totale

 Contexte : on considère que toutes les ressources de l’hôte sont utilisées

PRODUCTION (high) TESTS (normal)