Embed Size (px)
DESCRIPTION
Citation preview
1
HYPER-V CLOUD
GUIDES DE DÉPLOIEMENT
MODULE 1: ARCHITECTURE ET
DIMENSIONNEMENT
2
INTRODUCTION Le guide Architecture et dimensionnement décrit les points à prendre en
considération dans les domaines de la conception, des matériels, des
logiciels et du support lors de l'étude d'une architecture serveur pour une
infrastructure de cloud privé.
Ce guide décrit les conditions minimales requises pour les ordinateurs,
ainsi que les systèmes d'exploitation pris en charge, la façon de concevoir
le stockage et la conception des serveurs pour déployer le système
d'exploitation Microsoft Windows Server® 2008 R2 avec les
technologies de virtualisation Hyper-V™, System Center Virtual
Machine Manager 2008 R2 et System Center Virtual Machine
Manager Self Service Portal 2.0.
Il est l'un des cinq volets des Guides de déploiement pour Microsoft
Hyper-V Cloud. Il est basé sur le cadre de travail qui permet, depuis
plusieurs années, à Microsoft Consulting Services d'assurer la
virtualisation des serveurs dans plus de 82 pays.
Les guides de déploiement de
Microsoft pour Hyper-V Cloud
contribuent à l'efficacité des
équipes informatiques. Ils
permettent :
d'accélérer le déploiement en
recommandant les mesures à
prendre pour planifier et
mettre en place une solution
de cloud privé fondée sur les
technologies de virtualisation
de Microsoft ;
de réduire les coûts de
formation en proposant des
méthodologies pour assurer la
virtualisation des serveurs ;
de minimiser les risques en
donnant des exemples concrets
de problèmes et de solutions
rencontrés par les architectes
et les consultants de Microsoft.
3
TABLE DES MATIÈRES
PRÉSENTATION DES COMPOSANTS ......................................................................5
Microsoft Windows Server ® 2008 R2 with Hyper-V™ ........................................5
System Center Virtual Machine Manager 2008 R2 .............................................5
SCVMM 2008 R2 Self-Service Portal 2.0 .............................................................6
Hypothèses ........................................................................................................7
MICROSOFT WINDOWS SERVER® 2008 R2 WITH HYPER-V™ .................................8
Conditions requises par Windows Server 2008 R2 et Hyper-V ............................8
Modèles d'architecture pour un hôte autonome.............................................. 10
Architecture de stockage hôte autonome ........................................................ 11
ARCHITECTURE DU SERVEUR HÔTE ..................................................................... 16
Architecture système ....................................................................................... 17
Architecture du système d'exploitation............................................................ 22
Architecture Hyper-V ....................................................................................... 23
Réseaux virtuels............................................................................................... 30
Remarques concernant la sécurité ................................................................... 32
DIMENSIONNEMENT DE L'HÔTE ET PLANIFICATION DE LA CONSOLIDATION...... 37
Analyse des scénarios de consolidation............................................................ 37
Modèle d'architecture du serveur hôte ............................................................ 38
Profils matériels pour les ordinateurs virtuels invités ....................................... 38
Test des performances des architectures de l'hôte et des serveurs virtuels ...... 40
Calcul du nombre d'hôtes nécessaires ............................................................. 40
SYSTEM CENTER VIRTUAL MACHINE MANAGER 2008 R2 ................................... 41
Composants de System Center Virtual Machine Manager ................................ 41
Place du serveur System Center Virtual Machine Manager .............................. 45
Considérations relatives au stockage ............................................................... 46
Considérations relatives à la sécurité ............................................................... 48
Planification des migrations physiques vers virtuelles (P2V) ............................. 50
4
SYSTEM CENTER VIRTUAL MACHINE MANAGER SELF SERVICE PORTAL 2.0
(VMMSSP) ........................................................................................................... 54
Composants VMMSSP...................................................................................... 54
Configuration matérielle requise ..................................................................... 55
Configuration logicielle requise ........................................................................ 55
Modèles d'architecture VMMSSP ..................................................................... 56
Remarques concernant la sécurité ................................................................... 58
Supervision et rapports .................................................................................... 60
Ressources supplémentaires............................................................................... 62
Accélérateurs de solutions Microsoft ............................................................... 62
Microsoft.com ................................................................................................. 63
5
PRÉSENTATION DES COMPOSANTS
Microsoft Windows Server ® 2008 R2 with Hyper-V™
Les serveurs hôtes sont l'un des composants les plus stratégiques d'une
infrastructure virtuelle dynamique. Les serveurs hôtes fonctionnant sous
Windows Server® 2008 R2 avec la technologie Hyper-V™ servent de socle
à l'exécution des ordinateurs virtuels hébergés, et assurent l'interface
d'administration entre les systèmes hébergés et Microsoft® System
Center Virtual Machine Manager.
Ce guide décrit de façon détaillée la conception des serveurs hôtes et
donne une méthodologie pour leur dimensionnement. Plusieurs
architectures serveurs de référence sont présentées. Elles constituent un
point de départ dans le processus de conception et servent de base à la
documentation du projet final.
Pour plus de détails sur l'installation et la configuration de Microsoft
Windows Server 2008 R2 Hyper-V, consultez la page
http://technet.microsoft.com/en-us/library/cc732470(WS.10).aspx
System Center Virtual Machine Manager 2008 R2
System Center Virtual Machine Manager est le principal outil utilisé pour
administrer l'infrastructure virtuelle. System Center Virtual Machine
Manager s'adapte à toute une variété d'environnements virtuels, qu'il
s'agisse d'un seul serveur pour les plus petites infrastructures ou d'un
environnement d'entreprise complètement distribué qui prend en charge
des centaines d'hôtes et des milliers d'ordinateurs virtuels sur ces hôtes.
Virtual Machine Manager propose les fonctionnalités suivantes :
Administration d'ordinateurs virtuels hébergés sur serveurs Windows
Server® 2008 Hyper–V™ et Microsoft Hyper-V.
Prise en charge d'ordinateurs virtuels fonctionnant sous Microsoft
Virtual Server et VMware ESX.
Prise en charge de bout en bout pour consolider des serveurs
physiques dans une infrastructure virtuelle.
Fonction « Performance and Resource Optimization » (PRO) pour une
administration dynamique et réactive de l'infrastructure virtuelle
(System Center Operations Manager requis).
Répartition intelligente des charges virtuelles sur les serveurs
physiques les plus appropriés.
Virtual Machine Manager gère une bibliothèque pour centraliser et
gérer tous les fichiers d’un centre de données virtuel.
Pour en savoir plus sur l'installation et la configuration de System Center
Virtual Machine Manager 2008 R2, visitez la page
http://technet.microsoft.com/en-us/systemcenter/vmm/default.aspx
6
SCVMM 2008 R2 Self-Service Portal 2.0
Avec Microsoft System Center Virtual Machine Manager Self-Service
Portal 2.0, les centres de données proposent aux divisions de l'entreprise
une infrastructure sous forme de service. Le portail en libre-service donne
aux différents groupes d'une entreprise la possibilité d'administrer leurs
propres besoins informatiques au sein d'une infrastructure centrale qui
gère un pool de ressources physiques (serveurs, réseaux et matériel
correspondant)
Le portail en libre-serve dispose de quatre composants :
Site Web VMMSSP. Composant Web qui donne accès au portail en
libre-service. Le site Web VMMSSP permet aux administrateurs de
réaliser différentes tâches comme : regrouper tous les actifs
informatiques dans le portail en libre-service, étendre les actions sur
les ordinateurs virtuels, formuler des demandes pour les divisions et
l'infrastructure, valider et approuver les demandes, mettre en service
les ordinateurs virtuels (via la fonction en libre-service
correspondante). Les administrateurs peuvent également utiliser le
site Web VMMSSP pour consulter toutes les informations relatives à
ces opérations.
Base de données VMMSSP. Base de données SQL Server où résident
les informations concernant les actifs configurés, les divisions et les
demandes, ainsi que tout ce qui a été mis en service dans les
différentes divisions de l’entreprise. La base de données contient le
code XML qui représente les actions standards et personnalisées
menées sur les ordinateurs virtuels, ainsi que les paramètres de
configuration du portail en libre-service.
Serveur VMMSSP. Service Windows qui exécute, sur les ordinateurs
virtuels, les actions standards et personnalisées que l'utilisateur
demande via le site Web VMMSSP.
Tableau de bord du reporting. Service de reporting bâti sur
Windows SharePoint Services 3.0 SP2. Le tableau de bord propose
des rapports tout prêts et permet de concevoir rapidement des
rapports personnalisés.
Les divisions de l’entreprise inscrites sur le portail en libre-service passent
par le portail pour réaliser les opérations suivantes :
Utiliser des formulaires standardisés pour demander de nouvelles
infrastructures ou apporter des modifications aux composants
d'infrastructure. Chaque division peut envoyer des demandes à
l'administrateur de l'infrastructure. Les formulaires standardisés
permettent à l'administrateur d'avoir toutes les informations sous la
main pour satisfaire la demande sans avoir sans cesse à demander
des détails à la division.
Créer et administrer des ordinateurs virtuels. Sur le site Web
VMMSSP, les divisions de l'entreprise peuvent utiliser des formulaires
de mise en service en accès libre pour créer des ordinateurs virtuels.
7
Dès qu'une division soumet une demande de création, le portail en
libre-service lance automatiquement une procédure de mise à
disposition. Les ordinateurs virtuels sont ainsi créés bien plus vite que
manuellement.
Déléguer les détails de l'administration des ordinateurs virtuels.
Chaque division peut désigner ses propres administrateurs,
opérateurs avancés et utilisateurs.
Les administrateurs de l'infrastructure utilisent le portail en libre-service
pour réaliser les opérations suivantes :
Étendre les actions d'ordinateur virtuel par défaut en fonction
des besoins du centre de données. Il suffit de travailler avec des
partenaires informatiques et des fournisseurs de matériel pour
modifier les « actions » standards utilisées par le portail en libre-
service pour créer et administrer des ordinateurs virtuels. Ainsi, vous
pouvez étendre le portail en libre-service pour utiliser des réseaux
SAN (Storage Area Network), des systèmes d'équilibrage de charge,
etc.
Simplifier l'inscription des divisions et la définition de leurs
besoins. Le portail en libre-service collecte des informations sur une
division de l'entreprise (une entité métier) et sur les ressources qu'elle
souhaite configurer.
Simplifier la validation et la mise en service des ressources
demandées par les divisions de l'entreprise. Les administrateurs du
centre de données utilisent le portail en libre-service pour affecter les
ressources en fonction des demandes des divisions.
Contrôler la modification de ces ressources. Les modifications à
apporter aux ressources suivent un cycle de demande-approbation,
et les demandes restent consignées dans la base de données.
Hypothèses
System Center Virtual Machine Manager 2008 R2 rend un certain nombre
de fonctions possibles. Toutefois, ce document part du principe que
System Center Virtual Machine Manager 2008 R2 et des hôtes Hyper-V
autonomes ne serviront que comme base à la mise en service
automatique des ordinateurs virtuels sur ces hôtes, réalisée au moyen de
Self-Service Portal v2.0. Par la suite, le document aborde la question de la
consolidation des serveurs au moyen des méthodes de conversion
physique-à-virtuel et virtuel-à-virtuel.
Microsoft System Center Virtual Machine Manager est conçu pour tirer
pleinement parti des fonctionnalités et des avantages offerts par
Windows® Server et la famille Microsoft® System Center. Compte tenu
de ces hypothèses, System Center Virtual Machine Manager ne s'installera
que sur des ordinateurs Windows Server® 2008 ou Windows Server®
2008 R2, avec Microsoft® SQL Server® 2008, afin de respecter les
prérequis de SSP 2.0.
8
MICROSOFT WINDOWS SERVER® 2008 R2
WITH HYPER-V™
Conditions requises par Windows Server 2008 R2 et
Hyper-V
Cette section décrit les systèmes d'exploitation pris en charge et les
conditions minimales requises pour un serveur Windows Server® 2008 R2
déployant le rôle Hyper-V™. D'autres parties de ce document décrivent
les procédures détaillées d'installation et de configuration.
Systèmes d'exploitation pris en charge pour l'hôte :
Windows Server® 2008 R2 Standard Edition x64 with Hyper-V™
Windows Server® 2008 R2 Enterprise Edition x64 with Hyper-V™
Windows Server® 2008 R2 Datacenter Edition x64 with Hyper-V™
Remarque
La Standard Edition ne prend pas en charge les configurations
Hyper-V™ en haute disponibilité.
Ce document ne prend pas en compte Microsoft® Hyper-V™ Server
R2 qui accepte les configurations en haute disponibilité.
Conditions requises pour les processeurs Intel :
Architecture x64 (64 bits)
Prise en charge de la fonctionnalité Hardware Execute Disable
Virtualisation matérielle VT Intel®
Conditions requises pour les processeurs AMD :
Architecture x64 (64 bits)
Prise en charge de la fonctionnalité Hardware Execute Disable
Virtualisation matérielle AMD-V®
Fréquence minimale du processeur : 1,4 GHz
Mémoire : 512 Mo de mémoire au minimum
Espace disque requis au minimum : 10 Go
9
Remarque
Les ordinateurs équipés de plus de 16 Go de mémoire nécessitent
davantage d'espace disque pour la pagination, la mise en veille et
les fichiers de vidage.
Limites pour un hôte Hyper-V R2
Fonctionnalité Windows
Server® 2008
R2 Standard
Edition
Windows
Server® 2008
R2 Enterprise
Edition
Windows
Server® 2008
R2 Datacenter
Edition
Nombre de
processeurs
logiques (PL)
64 PL 64 PL 64 PL
Mémoire
physique
Jusqu'à 32 Go Jusqu'à 1 To Jusqu'à 1 To
Nb max
d'ordinateurs
virtuels (VM)
8 processeurs
virtuels par PL
ou 384 VM, au
plus bas des 2
8 processeurs
virtuels par PL
ou 384 VM, au
plus bas des 2
8 processeurs
virtuels par PL
ou 384 VM, au
plus bas des 2
Licences VM 1 licence VM
gratuite par
licence hôte
4 licences VM
gratuites par
licence hôte
Illimitées
Remarque
Ces limitations s'appliquent uniquement au rôle Hyper-V R2, pas au
système d'exploitation Windows Server.
Limites pour un invité Hyper-V R2
Systèmes d'exploitation x86 ou x64
Jusqu'à 4 processeurs logiques
Jusqu'à 64 Go de mémoire par invité
Jusqu'à 4 périphériques IDE
Jusqu'à 4 contrôleurs SCSI prenant en charge jusqu'à 64 disques
chacun
Jusqu'à 4 adaptateurs réseau classiques
Jusqu'à 8 adaptateurs réseau synthétiques
10
Système d'exploitation prise en
charge
Processeurs virtuels
1 2 4
Windows Server® 2008 R2 x x x
Windows Server® 2003 x86 x64 SP2 x x
Windows® 2000 Server & Advanced
Server SP4
x
Windows® HPC Server 2008 x x x
SUSE® Linux Enterprise Server 10
x86 x64 SP1/SP2
x
Red Hat® Enterprise Linux x x x
Windows 7 x x x
Windows Vista® x86 x64 SP1 x x
Windows® XP Pro x64 SP2 & x86
SP3
x x
Windows® XP Pro x86 SP2 x
Modèles d'architecture pour un hôte autonome
Architecture serveur pour un hôte Hyper-V unique
Cette architecture comptant un seul hôte est représentée ci-dessous. Elle
se compose d'un serveur hôte unique exploitant Windows Server 2008 R2
with Hyper-V, faisant fonctionner un certain nombre d'ordinateurs virtuels
invités. Ce modèle assure la consolidation de serveurs mais ne permet pas
la haute disponibilité. Le serveur hôte devient de ce fait un risque
potentiel en cas de panne (point unique de panne). Cette architecture
nécessitera un arrêt ou une sauvegarde des ordinateurs virtuels invités
lorsque l'hôte sera en maintenance ou devra redémarrer.
11
Architecture de stockage hôte autonome
Le type de stockage utilisé dans l'architecture du serveur hôte a un impact
majeur sur les performances de l'hôte et des ordinateurs invités. Les
performances du stockage dépendent de nombreux paramètres comme
les disques, leurs interfaces, les contrôleurs, les caches, les protocoles, le
SAN, le HBA, les pilotes et le système d'exploitation. La performance
globale du stockage est généralement mesurée en Débit maximal,
Nombre maximal d'opérations d'entrées/sorties par seconde (IOPS) et
Temps de latence. Ces trois facteurs sont à prendre en compte mais dans
le cas de la virtualisation, latence et IOPS sont les plus importants.
Cette section décrit les différentes architectures de stockage et fournit des
recommandations pour chacune d'elles.
Connectivité du stockage
Les disques individuels et les baies de stockage peuvent être reliés à
l'hôte de trois façons différentes : stockage avec connexion directe (Direct
Attached Storage ou DAS), réseau de stockage (SAN) iSCSI et réseau de
stockage (SAN) fibre optique (Fibre Channel ou FC).
Stockage avec connexion directe
Il s'agit généralement des disques durs placés placés directement dans le
serveur hôte ou dans un boîtier relié directement à l'hôte par une
connexion eSATA, SAS ou SCSI. Le serveur hôte utilise un contrôleur
interne SATA, SAS ou SCSI pour permettre au serveur d'accéder au
stockage. Ce contrôleur propose un ou plusieurs niveaux RAID. Un
stockage relié en direct est généralement réservé à ce seul serveur.
SAN iSCSI
iSCSI est une architecture de stockage largement répandue qui permet
d'utiliser le protocole SCSI sur les infrastructures réseau TCP/IP. iSCSI
permet d'utiliser des équipements réseau traditionnels comme des
adaptateurs Ethernet, des commutateurs et des routeurs pour construire
un réseau de stockage (SAN). En général, les SAN iSCSI sont moins
coûteux que les SAN à fibre optique (FC). Les prix des baies iSCSI vont de
l'entrée de gamme au milieu de gamme et ces baies sont partageables
entre plusieurs serveurs hôtes. Il est recommandé d'utiliser des
adaptateurs réseau Ethernet redondants et dédiés pour assurer la
connectivité des hôtes au SAN iSCSI.
SAN fibre optique (FC)
Un réseau de stockage (SAN) avec des liaisons en fibre optique assure de
grands débits et une faible latence entre les hôtes et les baies de
stockage. Les adaptateurs de bus hôtes (HBA) assurent la connexion des
hôtes au SAN fibre optique via des commutateurs et des directeurs. Les
SAN fibre optique sont généralement utilisés avec des baies de stockage
12
milieu et haut de gamme. Ils proposent de nombreuses fonctionnalités
comme différents niveaux RAID, des instantanés de disques, des E/S à
chemins multiples (Multi-IO), etc.
Recommandation
Un stockage avec connexion directe ou un SAN iSCSI est
recommandé pour une architecture à serveur hôte unique.
Pour des raisons de performances et de sécurité, il est fortement
conseillé d'utiliser des adaptateurs réseau dédiés au SAN iSCSI ; le
réseau SAN iSCSI doit être totalement isolé des autres réseaux et
posséder ses propres commutateurs.
Types de disques
Les disques durs employés dans le serveur hôte et dans les baies de
stockage auront un impact important sur les performances globales de
l'architecture de stockage. Les facteurs les plus importants à prendre en
compte sont le type d'interface (par exemple U320 SCSI, SAS, SATA), la
vitesse de rotation (7200, 10000, 15000 tours par minute) et la latence
moyenne (temps d'accès moyen) en millisecondes. D'autres facteurs
comme la taille du cache inclus dans chaque disque et la prise en charge
de certaines fonctionnalités avancées comme la mise en file d'attente
native des commandes (NCQ) peuvent aussi améliorer les performances.
Comme pour la connectivité du stockage, un nombre élevé d'IOPS et une
faible latence sont des facteurs plus importants que le débit en mode
permanent lorsqu'il s'agit de dimensionner un serveur hôte et d'évaluer
les performances des ordinateurs invités. Lors du choix des disques, cela
se traduit par la recherche des vitesses de rotation les plus élevées et des
latences les plus faibles. Le fait d'utiliser des disques à 15 000 tours par
minute à la place de disques à 10 000 tours par minute peut induire une
augmentation de 35 % du nombre d'IOPS par disque.
Les informations ci-dessous vous permettent d'évaluer le meilleur
compromis entre coût et performances.
SCSI
Les disques SCSI ont été rapidement remplacés par des disques SATA,
SAS et FC (fibre optique). Les disques SCSI ne sont pas recommandés
pour de nouvelles architectures d'hôtes serveur. Toutefois, des serveurs
avec des disques SCSI U320 peuvent fournir d'excellentes performances.
SATA
Les disques SATA sont bon marché et présentent des performances
relativement élevées. Les disques SATA utilisent généralement les
standards SATA 1 (1,5 Go/s) et SATA 2 (3 Go/s) avec une vitesse de
13
rotation de 7200 tours/minute et une faible latence d'environ 4 ms.
Quelques disques SATA récents opèrent à 10 000 tours/minute et.
affichent une latence de 2 ms ; ils peuvent constituer une excellente
solution de stockage à faible coût.
SAS
Les disques SAS sont en général plus chers que les disques SATA mais ils
présentent de meilleures performances à la fois en débit et en faible
latence. Leur vitesse de rotation est de 10 000 ou 15 000 tours /minute,
avec une latence de 2 à 3 ms.
Fibre optique (FC)
Les disques FC sont les plus chers et présentent des caractéristiques
proches des disques SAS mais avec une interface différente. Le choix entre
disques SAS et disques FC est déterminé par le choix de la baie de
stockage.
Si vous utilisez un SAN fibre optique, vérifiez que les commutateurs et les
directeurs font face aux débits importants en E/S produits par des
serveurs consolidés.
Recommandation
Des disques SATA à 7200 tr/min sont recommandés pour un serveur
hôte isolé. Bien sûr, si vous disposez des disques SAS à 10 ou
15 000 tr/min, les performances n'en seront que meilleures.
Redondance des disques
Une architecture de type RAID (Redundant Array of Inexpensive Disk) est
fortement recommandée pour tous les stockages utilisés par les hôtes de
virtualisation. Par définition, un hôte Hyper-V héberge des ordinateurs
virtuels qui servent de nombreux flux de données. Un niveau RAID est
indispensable pour assurer la disponibilité de ces données en cas de
panne disque. De plus, s'il est correctement choisi et configuré, une
architecture RAID peut améliorer les performances.
RAID 1
RAID 1 est un miroir entre deux disques. Deux disques stockent les
mêmes informations, l'un étant le miroir de l'autre. Lors d'une écriture,
l'ordinateur doit écrire la même information sur les deux disques. Cette
double écriture peut dégrader les performances du système sauf si
chaque disque a son propre adaptateur dédié sur l'hôte. Un miroir
protège bien le système en cas de panne d'un disque mais il coûte
relativement cher car seule la moitié de la capacité du stockage total est
utilisable, l'autre moitié servant au miroir.
14
RAID 5
Aussi connu sous le nom d’agrégat de bandes avec parité tournante, ce
niveau de RAID est largement répandu sur les systèmes d'entrée et de
milieu de gamme. Lors d'une écriture, un RAID 5 coupe l'écriture en blocs
de grandes tailles, chaque bloc étant écrit sur un disque différent de la
baie de stockage. Il calcule simultanément une bande de parité, cette
bande étant écrite à tour de rôle sur un des disques de la baie. En cas de
panne d'un des disques, il est possible de reconstituer son contenu grâce
à la parité et aux données des autres disques. Les bandes de données et
la bande de parité qui leur correspond sont toujours écrites sur des
disques différents. Lors d'une écriture, plusieurs écritures physiques
s'effectuent sur les disques, ce qui réduit les performances, mais là aussi le
parallélisme des contrôleurs compense ce défaut. Le RAID 5 peut donner
de meilleurs résultats en écriture que le RAID 1. En revanche, lorsqu'un
disque tombe en panne, les performances en lecture peuvent être
fortement dégradées (reconstitution par calcul du contenu du disque en
panne). Un RAID 5 coûte moins cher qu'un RAID 1 car il n'a pas besoin du
double de la capacité disque utile mais seulement de l'équivalent d'un
disque en plus.
RAID 10 (RAID 1+0)
Ce niveau se nomme miroir avec bandes. Le RAID 10 utilise un miroir de
deux groupes de disques, chaque groupe étant organisé en agrégat de
bandes. Par exemple, un premier groupe est constitué de 5 disques et
utilise l'agrégat de bandes (sans parité). Ce groupe est ensuite mis en
miroir avec un deuxième groupe composé lui aussi de 5 disques en
agrégat de bandes. Le RAID 10 présente les performances de l'écriture par
bandes et la redondance du miroir. Cette architecture présente les
meilleures performances, tant en lecture qu'en écriture, mais elle coûte
cher car elle utilise le double de disques par rapport à la capacité utile
souhaitée.
RAID 50 (RAID 5+0)
Cette architecture combine une écriture par bandes sans parité (RAID 0)
sur des groupes de disques, chaque groupe étant organisé en RAID 5
(avec parité). Elle peut être vue comme un RAID 0 où chaque disque est
en réalité un ensemble de disques en RAID 5. Le RAID 50 présente des
performances en écriture meilleures qu'un RAID 5 seul, et permet une
meilleure tolérance aux pannes. La configuration choisie et le nombre de
disques détermineront les caractéristiques finales et la disponibilité de ce
niveau RAID. Le RAID 50 se rencontre fréquemment dans les baies de
stockage, même dans les systèmes d'entrée de gamme.
Il existe d'autres niveaux RAID qui peuvent proposer des améliorations
des performances et de la tolérance aux pannes. Il s'agit généralement de
niveaux liés à des systèmes propriétaires. Pour en savoir plus sur les
niveaux de RAID, contactez votre fournisseur de matériels de stockage.
15
Recommandation
Le RAID 1 est recommandé pour le disque système qui permet le
démarrage de l'hôte.
Les RAID 1 ou RAID 10 sont recommandés pour les volumes de
données dans une architecture à serveur hôte unique.
Les RAID 5 et 50 ne sont généralement pas recommandés dans les
environnements de virtualisation en raison de leurs performances
moyennes en écriture.
Architecture des contrôleurs de stockage
Le contrôleur du stockage se présente soit sous la forme d'une carte
insérée dans le serveur (contrôleur SAS ou SCSI), soit sous la forme d'un
élément dans la baie de stockage pour les systèmes milieu et haut de
gamme. Le contrôleur assure l'interface entre les disques et le serveur ou
entre les disques et le SAN. Les performances du contrôleur dépendent de
son type d'interface ou HBA, de la taille de sa mémoire cache et du
nombre de canaux qu'il peut gérer en parallèle.
Interface HBA
L'interface entre le contrôleur et les disques détermine le type des disques
à utiliser, ainsi que le débit et la latence des E/S du stockage. Le tableau
ci-dessous résume les interfaces les plus courantes et leur débit théorique.
Architecture Débit (théorique en Mo/s)
iSCSI (Gigabit Ethernet) 125 Mo/s
Fibre optique (2 GFC) 212,5 Mo/s
SATA (SATA II) 300 Mo/s
SCSI (U320) 320 Mo/s
SAS 375 Mo/s
Fibre optique (4 GFC) 425 Mo/s
Fibre optique (8 GFC) 850 Mo/s
iSCSI (Ethernet à 10 Gbit/s) 1250 Mo/s
Recommandation
Une architecture SATA II ou SAS est recommandée pour un serveur
hôte unique (avec préférence pour SAS).
16
Mémoire cache dans le contrôleur
La mémoire cache dans le contrôleur améliore les performances pendant
des écritures par vagues ou lorsque les mêmes données sont utilisées
fréquemment. L'hôte travaille alors en direct avec cette mémoire plutôt
qu'avec les disques, ce qui améliore considérablement les performances.
Recommandation
Lors du choix du contrôleur ou des options de stockage, favorisez
celui qui propose la mémoire cache la plus vaste et la plus rapide.
Canaux du contrôleur
Le nombre de canaux internes et externes d'un contrôleur peut avoir un
impact sur les performances globales. Plusieurs canaux augmentent le
nombre d'opérations IOPS pouvant être réalisées en parallèle, en lecture
comme en écriture. Cette fonctionnalité est particulièrement bien
exploitée sur les baies de stockage RAID.
Recommandation
Utilisez au minimum un contrôleur à deux canaux pour un serveur
hôte unique. Utilisez un canal pour la partition système en RAID 1 et
l'autre pour la partition des données en RAID 10.
Respectez les pratiques recommandées par le fournisseur de votre
solution de stockage afin de répartir correctement les miroirs et les
bandes du RAID 10 sur différents canaux pour obtenir les meilleures
performances.
Remarque
Cette section a passé en revue certaines recommandations pour le
stockage. La prochaine prend en compte les processeurs, la RAM et
les E/S.
ARCHITECTURE DU SERVEUR HÔTE
L'architecture du serveur hôte joue un rôle important dans l'infrastructure
virtualisée, dans le ratio de consolidation et l'analyse du coût. Si le serveur
hôte peut répondre à la charge induite par la consolidation d'un grand
nombre de serveurs, le ratio de consolidation augmente et l'opération est
plus rentable financièrement.
17
La machine « idéale » est généralement un serveur à deux ou quatre
processeurs multicœurs, avec une fréquence processeur parmi les plus
élevées disponibles.
Remarque
Des programmes existent pour aider les clients à sélectionner le
matériel mais ils ne sont généralement pas adaptés au cas
spécifique de la consolidation de serveurs. Le Catalogue Windows
Server répertorie tous les serveurs, le stockage et les autres
matériels qui sont certifiés pour Windows Server 2008 R2 et
Hyper-V.
Catalogue Windows Server :
Allez sur www.windowsservercatalog.com.
Cliquez sur Certified Servers.
Puis, cliquez sur Hyper-V (en bas à gauche).
Architecture système
L'architecture système du serveur hôte fait référence à la catégorie
générale du matériel serveur. Le Catalogue référence des serveurs en rack,
des serveurs lames et des serveurs SMP( multiprocesseur symétrique). Le
principal critère à prendre en considération lors de la sélection de
l'architecture est le nombre d'ordinateurs invités et les scénarios
d'utilisation qui seront regroupés sur un même hôte. Les processeurs, la
mémoire et le réseau sont tout aussi importants que le débit et la latence
des E/S disques. Le serveur hôte doit fournir les capacités nécessaires
dans chacune de ces catégories.
Serveurs montés en rack
L'architecture la plus courante est un montage en rack de serveurs
standards. Existants dans des hauteurs de 2U ou de 4U, ces serveurs
contiennent généralement 2 ou 4 processeurs physiques, 2 à 8
connecteurs PCI-E ou PCI-X, et 4 à 6 emplacements de disques. Des
serveurs de ce type montés en rack constituent un excellent choix pour
des hôtes Hyper-V en raison de leur faible coût et de leur capacité à
monter en charge par l'ajout d'adaptateurs réseau et de cartes contrôleurs
supplémentaires.
Recommandation
Des serveurs de ce type, montés en rack et équipés de processeurs
Intel ou AMD, sont recommandés pour tous les types d'architecture
de serveurs hôtes.
18
Serveurs lames
Des serveurs lames permettent d'accroître la capacité et la densité de
serveurs. Ces serveurs sont souvent utilisés en recherche et
développement ou chez des hébergeurs Internet. Mais ils sont parfois peu
compatibles entre eux, même s'ils sont du même constructeur, par
exemple en raison d'un changement d'architecture du châssis.
Dans les premières générations de serveurs lames, la densité des
processeurs et de la mémoire s'obtenait au détriment du nombre
d'interfaces réseau et disques disponibles, et donc au détriment des
capacités d'extension.
L'arrivée récente sur le marché de serveurs lames équipés de processeurs
à 8 ou 16 cœurs, de 64 Go de mémoire et de 6 interfaces d'E/S ou plus, a
résolu ces problèmes. Par conséquent, les serveurs lames deviennent
aujourd'hui de bons candidats dans des architectures de virtualisation.
Il faut vérifier que le serveur lame d'un hôte pourra recevoir les E/S
stockage et réseau nécessaires pour prendre en charge le nombre voulu
de systèmes invités.
Son architecture devra être étudiée avec soin. Par exemple, si un stockage
iSCSI est prévu, deux adaptateurs réseau dédiés sont nécessaires pour
accéder au stockage et assurer la redondance. Par ailleurs, deux autres
adaptateurs réseau sont nécessaires aux E/S réseau. Ainsi, un hôte peut
avoir facilement besoin de 4 à 6 adaptateurs réseau. Ce nombre dépasse
généralement les capacités physiques d'un serveur lame.
Avertissement
Microsoft ne prend pas en charge le groupement d'adaptateurs
réseau (teaming). Cette fonctionnalité doit être assurée par un
logiciel fourni par le fabricant des adaptateurs.
Recommandation
Les serveurs lames peuvent être utilisés dans n'importe quelle
architecture de serveur hôte. Une analyse approfondie des besoins
en E/S disques et réseau doit être effectuée afin de vérifier que
chaque serveur lame pourra être équipé du nombre d'adaptateurs
nécessaires.
Les serveurs lames sont aussi intéressants si des départements de
l'entreprise ou des entités souhaitent posséder leurs propres hôtes
Hyper-V ou des petits groupes d'hôtes.
Grands serveurs SMP
Dans le cadre de ce document, les grands serveurs SMP sont définis
comme possédant 8 processeurs ou plus. Au maximum, Windows Server
19
2008 R2 Datacenter Edition peut prendre en charge des serveurs 64 bits
équipés de 64 processeurs et de 2 To de mémoire. La plupart de ces
serveurs haut de gamme incluent des fonctionnalités avancées comme le
partitionnement matériel, l'ajout ou le remplacement de composants à
chaud, etc. Un serveur de ce type peut potentiellement héberger des
centaines d'ordinateurs virtuels.
Certes, ces serveurs atteignent d'excellents ratios de consolidation, mais
ils sont bien plus coûteux que les serveurs plus ordinaires à 2 ou 4
processeurs physiques décrits précédemment. Un serveur à
32 processeurs physiques peut coûter plus de 400 000 euros alors qu'un
serveur ordinaire à 4 processeurs coûte moins de 25 000 euros.
Un grand serveur SMP ou un cluster de serveurs SMP est approprié si de
nombreux serveurs doivent être consolidés en quelques serveurs ou si
l'entreprise utilise déjà de tels serveurs de type mainframe dans son
centre de données.
Recommandation
Les grands serveurs SMP sont uniquement recommandés pour les
entreprises qui ont une grande expérience dans l'exploitation de
serveurs stratégiques ou qui utilisent déjà ce type de matériel.
Architecture des processeurs
Windows Server 2008 R2 with Hyper-V nécessite des processeurs 64 bits
Intel ou AMD avec prise en charge par le matériel de fonctions de
virtualisation, comme les séries Intel VT ou AMD-V.
Intel et AMD proposent plusieurs processeurs qui répondent à ces
critères. La concurrence entre ces deux marques est rude et à un instant
donné, l'une peut avoir un avantage sur l'autre. Indépendamment du
fabricant de processeur choisi, d'autres caractéristiques sont importantes
pour les performances.
Le nombre de cœurs dans chaque processeur est un élément important.
Windows Server 2008 R2 with Hyper-V utilise bien les processeurs
multicœurs. Plus le nombre de cœurs est élevé, mieux c'est. Une autre
caractéristique importante est la fréquence à laquelle fonctionne le
processeur et donc, ses cœurs. Cette fréquence sera aussi celle de tous les
ordinateurs virtuels qui seront hébergés. C'est un élément clé dans le ratio
de consolidation car il joue sur le nombre de candidats que le serveur
hôte pourra gérer ET sur la vitesse de fonctionnement de ces hôtes. Par
exemple, choisir un processeur cadencé à 2 GHz plutôt qu'à 3 GHz pour
héberger 20 ordinateurs virtuels implique que ces vingt ordinateurs
fonctionneront tous à 2 GHz.
Le choix du processeur joue aussi sur le type et la quantité des mémoires
caches, sur l'architecture du contrôleur de mémoire et sur l'architecture
des bus dans le système. Une analyse détaillée de ces facteurs sort
20
toutefois du cadre de ce document.
Recommandation
Une architecture processeur 64 bits est nécessaire pour tous les
hôtes Hyper-V. Si vous achetez de nouveaux serveurs, interrogez
votre fournisseur pour savoir si le matériel choisi sera capable de
faire fonctionner Windows Server 2008 R2 et Hyper-V, et si ce
matériel est validé pour un cluster à basculement Windows Server
2008 R2. Pour de nouveaux serveurs, choisissez le plus grand
nombre de cœurs par processeur disponible et choisissez la
fréquence horloge la plus élevée possible.
Architecture de la mémoire
Lorsque l'architecture du système et des processeurs est déterminée,
l'architecture de la mémoire est généralement prédéfinie par le fabricant
du système. Les choix restants sont en général la taille, la fréquence et la
latence. Pour Hyper-V, le choix le plus important est la taille de la
mémoire. Chaque serveur virtuel invité nécessitera au minimum 512 Mo à
1 Go de mémoire. La plupart des serveurs à quatre processeurs physiques
peuvent généralement gérer entre 32 et 128 Go de mémoire. La taille de
la mémoire limitera donc la capacité d'hébergement de l'hôte en nombre
d'ordinateurs virtuels.
La taille de la mémoire est un facteur plus important que sa fréquence ou
sa latence.
Lorsque la taille est déterminée, il reste à choisir les barrettes mémoire
présentant la latence la plus faible.
Recommandation
Lorsque l'architecture de l'hôte et des processeurs est déterminée,
choisissez la plus grande taille mémoire possible en fonction du
budget disponible. Généralement, le remplacement de barrettes
DIMM d'une certaine capacité (par exemple 2 Go) par des barrettes
de capacité double (4 Go) peut coûter plus du double et le coût
total de la mémoire peut être du même ordre que celui de
l'ensemble du serveur. Étudiez avec soin la meilleure combinaison
prix par barrette – capacité totale que vous pouvez obtenir. Par
exemple, si le serveur est équipé de 8 emplacements pour barrettes
DIMM et si le prix d'une barrette de 4 Go est plus du double de
celui d'une barrette de 2 Go, nous vous conseillons d'équiper les 8
emplacements de barrettes de 2 Go et d'envisager un second
serveur hôte si une capacité supplémentaire d'hébergement est
requise.
Pour un serveur hôte, la taille minimale de la mémoire est de 16 Go.
21
Architecture du réseau
L'architecture réseau du serveur hôte est souvent négligée lors du
dimensionnement car les adaptateurs Ethernet Gigabit sont bon marché
et la plupart des serveurs en possèdent déjà deux d'origine. Toutefois, ce
sujet est important car l'architecture choisie pour le serveur influe
directement sur son architecture réseau. Comme mentionné
précédemment, si un stockage iSCSI est utilisé, les adaptateurs réseau du
stockage doivent être indépendants des autres adaptateurs réseau. Un
adaptateur Ethernet Gigabit affiche un débit important mais si le nombre
d'ordinateurs virtuels sur le serveur est élevé, un seul adaptateur peut être
saturé et d'autres cartes seront nécessaires. Enfin, un serveur hôte devrait
posséder un adaptateur réseau dédié à son administration et à ses
propres communications.
Dans ces conditions, l'hôte peut avoir besoin d'un nombre élevé
d'adaptateurs réseau. Ce facteur peut conduire l'entreprise à écarter les
serveurs lames, trop exigus pour prendre en charge de nombreuses
cartes. Récemment, les adaptateurs 10 gigabits/s sont apparus sur le
marché et leur prix commence à baisser, comme cela a été le cas pour les
adaptateurs 1 Gbit/s. Un serveur capable d'exploiter pleinement ces cartes
peut accroître son ratio de consolidation.
Recommandation
Utilisez plusieurs adaptateurs réseau à plusieurs ports sur chaque
serveur hôte.
Un adaptateur est dédié à l'administration du serveur.
Un ou plusieurs adaptateurs sont dédiés au trafic des ordinateurs
virtuels (jusqu'à 10 Gbit/s pour un ratio élevé de consolidation).
Deux adaptateurs au moins sont dédiés au stockage iSCSI avec
MPIO (E/S à plusieurs chemins).
Un adaptateur ou un port réseau doit être dédié sur le serveur au
réseau des ordinateurs virtuels. Pour obtenir le meilleur ratio de
consolidation, utilisez un ou plusieurs adaptateurs 10 Gbit/s pour les
E/S réseau des ordinateurs virtuels.
Architecture de l'adaptateur bus hôte (HBA)
Le stockage disque pour tous les ordinateurs virtuels invités s'effectue
dans des fichiers VHD placés dans le stockage du serveur hôte. Les E/S du
stockage hôte, en plus des architectures réseau, mémoire, processeur et
système déjà décrites, joue un rôle important dans le dimensionnement
du serveur hôte. Hyper-V implique un grand nombre d'IOPS (lectures et
écritures disque par seconde) sur le stockage du serveur en raison de
l'activité de tous les ordinateurs virtuels.
Si le stockage est connecté directement au serveur, un contrôleur interne
22
de type SATA II ou SAS avec RAID intégré est recommandé. Si un SAN ou
une baie de stockage est employé, des adaptateurs HBA sont nécessaires
sur le serveur. Ils assurent l'interface sur le serveur entre le bus interne et
le stockage. Cette connectivité ne doit pas être un goulet d'étranglement
pour le serveur.
Recommandation
Utilisez au moins un adaptateur HBA à fibre optique (FC) ou un
adaptateur réseau dédié (iSCSI) dans le cas d'un hôte autonome.
Dans le cas de la fibre optique, choisissez des adaptateurs à 4 ou
8 Gbit/s.
Dans le cas du protocole iSCSI, utilisez des E/S à chemins multiples
(MPIO) dans une configuration à équilibrage de charge pour obtenir
un débit maximal.
Architecture du système d'exploitation
Version du système d'exploitation
Le choix du système d'exploitation pour les serveurs hôtes Hyper-V est
important : il influe sur les performances, le support et le coût global.
Dans tous les scénarios, Windows Server doit être en version 64 bits.
Prenez aussi en compte les droits d'utilisation de la virtualisation lors du
choix du système d'exploitation. Certaines versions de Windows Server
2008 R2 (éditions Standard, Enterprise et Datacenter ) incluent des
« droits d'utilisation de la virtualisation » qui permettent de faire
fonctionner un certain nombre d'ordinateurs virtuels Windows. Windows
Server® 2008 R2 Standard Edition permet d'utiliser un ordinateur virtuel.
Windows Server® 2008 R2 Enterprise Edition permet d'utiliser jusqu'à
quatre ordinateurs virtuels. Cela ne signifie pas qu'il s'agit là du nombre
maximal d'ordinateurs virtuels que vous pouvez exploiter sur ces serveurs.
Il s'agit simplement du nombre de licences déjà incluses dans le système
d'exploitation serveur. Pour ajouter d'autres ordinateurs virtuels, il vous
suffit d'acquérir des licences Windows Server supplémentaires.
Windows Server® 2008 R2 Datacenter Edition inclut le droit d'installer un
nombre quelconque d'ordinateurs virtuels sur le serveur hôte qui exécute
Windows Server 2008 R2 Datacenter Edition.
Recommandation
Utilisez Windows Server® 2008 R2 Enterprise Edition ou Windows
Server® 2008 R2 Datacenter Edition pour tous les hôtes Hyper-V.
Dialoguez avec votre responsable de compte chez Microsoft pour
déterminer à partir de quel point la version Datacenter devient plus
rentable, une fois que vous avez déterminé le nombre d'ordinateurs
virtuels que vous souhaitez installer sur chaque hôte.
23
Consultez la page Microsoft Licensing for Virtualization.
Architecture Hyper-V
Ordinateurs virtuels
Hyper-V accroît nettement la capacité à monter en charge des ordinateurs
virtuels par rapport à Virtual Server 2005. Les ordinateurs virtuels
contrôlés par Hyper-V et équipés de systèmes d'exploitation
recommandés par Microsoft, prennent en charge les options décrites ci-
dessous.
Remarque
Vérifiez que chaque système d'exploitation que vous envisagez de
déployer sur les ordinateurs virtuels prend en charge les
processeurs multiples et les grandes capacités mémoire.
Hyper-V est capable de gérer des ordinateurs virtuels puissants. Par
conséquent, de nombreux types de serveurs peuvent être consolidés, y
compris ceux nécessitant plusieurs processeurs, plusieurs cœurs ou de
nombreuses E/S.
Toutefois, il est prudent de configurer chaque ordinateur virtuel avec les
ressources dont il a besoin, sans prévoir trop de marge au départ. Ainsi,
des ressources resteront disponibles pour d'autres ordinateurs virtuels ou
pour une expansion future. Par exemple, il n'est pas recommandé que
tous les ordinateurs virtuels utilisent quatre processeurs logiques s'ils n'en
ont pas impérativement besoin. Des ressources supplémentaires comme
des processeurs ou de la mémoire, peuvent être ajoutées si nécessaire.
Recommandation
Configurez les ordinateurs virtuels de telle sorte qu'ils n'utilisent que
les ressources nécessaires pour obtenir les performances souhaitées
et un taux de consolidation maximal.
Le tableau ci-dessous montre un ordinateur virtuel configuré de façon
modérée, avec 4 processeurs logiques, 4 Go de mémoire, plusieurs
contrôleurs SCSI et plusieurs adaptateurs réseau, avec Windows Server
2008. Dans cet exemple, l'ordinateur virtuel inclut un disque de
démarrage IDE (VHD) et quatre disques SCSI directs. L'architecture du
stockage de l'ordinateur virtuel est décrite à la prochaine section.
24
Invité Hyper-V
Windows Server 2008 Enterprise Edition 64 bits
Adaptateur réseau 0 – vSwitch 1
MAC : VLAN :
Adaptateur réseau 1 – vSwitch 2
MAC : VLAN :
Disque 1 direct via LUN 2
Contrôleur SCSI 0 Contrôleur SCSI 1
Disque 1 direct via LUN 4
Disque 0 direct via LUN 1 Disque 0 direct via LUN 3
Contrôleur IDE 0
Disque de boot (VHD)
Contrôleur IDE 0
<libre>
Contrôleur IDE 1
Lecteur de DVD
Contrôleur IDE 1
<libre>
4 Go de RAM
Processeur logique 1 Processeur logique 2
Processeur logique 3 Processeur logique 4
Stockage des ordinateurs virtuels
Volumes et partitions
La plupart des techniques d'optimisation des performances d'E/S disque
applicables aux serveurs Microsoft® SQL Server® ou Microsoft®
Exchange Server s'appliquent parfaitement aux ordinateurs virtuels qui
fonctionnent sur un hôte équipé de Windows Server 2008 R2 avec
Hyper-V. Il est recommandé de réserver un LUN à haut débit au système
d'exploitation et de placer les fichiers des disques durs virtuels (VHD) et
les fichiers de configuration des ordinateurs virtuels sur des LUN distincts
à haut débit. Dans certains cas d'utilisation des ordinateurs virtuels, la
répartition des E/S disques sur des axes physiques différents peut aussi
améliorer les performances. Veuillez consulter les pratiques
recommandées en fonction des applications utilisées pour bien répartir
les E/S disques.
Hyper-V propose aussi l'option d'utiliser des disques directs : l'ordinateur
virtuel peut directement accéder à un LUN sans que l'hôte n'ait à
intervenir. Cette fonction est intéressante lorsqu'il s'agit de réallouer le
stockage. Par exemple, lorsque les données d'un ordinateur virtuel
atteignent un certain volume, il est plus simple de réallouer le LUN plutôt
que de copier les données. L'option disque direct est à étudier dans ce
cas.
Si vous utilisez une baie de stockage, confirmez avec l'aide de votre
fournisseur que les valeurs de pistes et de secteurs ont été correctement
définies pour votre stockage, et utilisez l'outil Diskpart.exe pour vérifier
l'alignement du début de chaque partition avec la taille des bandes
utilisées (dans le cas d'un stockage avec agrégat par bandes). Dans la
plupart des cas, cela n'est pas nécessaire avec Windows Server 2008 R2
mais vous devriez le faire pour une baie de stockage.
25
Recommandation
Utilisez des disques physiques et des LUN séparés pour les données
et le fichier VHD du système d'exploitation de chaque ordinateur
virtuel.
Répartissez les E/S disques en respectant les pratiques
recommandées pour l'application qui s'exécute sur l'ordinateur
virtuel.
Utilisez NTFS pour tous les volumes du serveur hôte.
Pour les systèmes d'exploitation qui ont précédé Windows Server
2008, alignez le début des partitions de l'ordinateur virtuel comme
cela est décrit à la page http://support.microsoft.com/kb/929491
Défragmentez et compactez régulièrement les fichiers VHD sur
l'ordinateur virtuel, et défragmentez les volumes de l'hôte pour optimiser
les performances d'E/S disque. Si vous utilisez des VHD de taille fixe, la
défragmentation au niveau de l'hôte n'est pas nécessaire car l'espace
disque est alloué sous la forme d'une suite continue de secteurs lors de la
création de chaque VHD.
Information
La défragmentation pour l'hôte peut être réalisée avec l'outil de
défragmentation inclus dans Microsoft Windows®. Pour la
défragmentation, le précompactage et le compactage des VHD,
veuillez lire l'article
http://vscommunity.com/blogs/virtualzone/archive/2007/01/17/thre
e-steps-to-vhd-compaction-with-virtual-server-2005-r2-sp1.aspx
Disques durs virtuels ou VHD (Virtual Hard Disks)
Un disque dur virtuel représente un disque dur de l'ordinateur virtuel et
se présente sous la forme d'un fichier VHD dans le stockage de l'hôte. Les
disques VHD peuvent être agrandis dynamiquement, ils peuvent faire
l'objet d'un cliché instantané de volume sur l'hôte et se déplacent
facilement d'un serveur à un autre. Il existe trois formes de disques
virtuels VHD :
Disque à taille dynamique
Un tel disque peut être agrandi dynamiquement en fonction des besoins
de stockage. La taille du fichier .vhd est petite lorsque le disque est créé,
et elle croît à mesure que les données sont enregistrées dans le disque. La
taille d'un fichier .vhd ne diminue pas lorsque des données sont
supprimées du disque virtuel. Toutefois, il est possible de compacter le
disque pour réduire sa taille après effacement des données, en utilisant
l'Assistant Edit Virtual Hard Disk.
26
Disque à taille fixe
Un tel disque utilise un fichier .vhd dont la taille est définie lors de sa
création. La taille de ce fichier ne change pas à mesure qu'il enregistre des
données. Toutefois, il est possible d'utiliser l'Assistant Edit Virtual Hard
Disk pour accroître la taille du disque virtuel, ce qui accroît la taille du
fichier .vhd. En allouant une capacité importante au moment de la
création, vous supprimez la fragmentation au niveau de l'hôte. (La
fragmentation au niveau de l'ordinateur virtuel peut être traitée de façon
classique via l'administration de l'ordinateur virtuel.)
Disque de différenciation
Un disque dur virtuel de différenciation est un disque associé à un autre
disque virtuel via une relation enfant-parent. Le disque de différenciation
stocke les modifications qui seraient apportées au disque parent sans
réellement modifier ce disque. La taille du fichier .vhd d'un disque de
différenciation grandit à mesure que des données sont enregistrées.
Recommandation
Dans des environnements de production, utilisez des disques à taille
fixe qui permettent les meilleures performances et simplifient le
suivi de l'espace libre dans le stockage. Allouez toute la taille prévue
pour le disque virtuel lors de sa création.
Dans Hyper-V R2, les performances des disques à taille dynamique
(ce qui inclut les clichés instantanés de volume, les .AVHD et les
disques de différenciation) se sont nettement améliorées et
constituent désormais des options viables dans un environnement
de production. Toutefois, ces disques présentent quelques
inconvénients comme un risque de sous-évaluation du stockage
nécessaire et une fragmentation dans le stockage de l'hôte. Utilisez-
les avec précaution.
Disque direct
Hyper-V permet aux ordinateurs virtuels d'accéder directement aux
disques locaux ou aux LUN du SAN connectés au serveur physique sans
passer par le système de fichiers de l'hôte. L'ordinateur virtuel accède au
disque directement (via le GUID du disque) sans passer par le système de
fichiers de l'hôte. Toutefois, la différence de performance entre un disque
à taille fixe et un disque direct étant désormais négligeable, la décision
repose sur des critères de facilité d'administration. Par exemple, si la
volumétrie des données est importante (des centaines de gigaoctets), un
VHD de cette taille devient difficilement portable en raison du temps
nécessaire pour la copie des données. Tenez compte aussi des
sauvegardes. Lors de l'utilisation de disques directs, les sauvegardes ne
peuvent être réalisées qu'à partir de l'ordinateur virtuel.
27
Aucun fichier VHD n'est créé : le LUN est directement exploité par
l'ordinateur virtuel. Sans fichier VHD, les fonctionnalités de taille
dynamique ou de cliché instantané de volume sont inopérantes.
Recommandation
Utilisez des disques directs uniquement lorsque vous avez besoin
des meilleures performances possibles et quand la perte de
fonctionnalités comme le cliché instantané de volume est
acceptable. Le niveau de performance étant très proche entre les
disques directs et les disques à taille fixe, il existe peu de scénarios
où les disques directs sont requis.
Options d'accès aux disques
Les ordinateurs virtuels accèdent au stockage via trois mécanismes
possibles : IDE, SCSI et iSCSI. Lors de la configuration des disques IDE ou
SCSI pour un ordinateur virtuel, il est possible de choisir entre un disque
direct ou un disque VHD, dans l'ensemble du stockage connecté au
serveur physique (disques directement connectés à l'hôte, LUN du SAN ou
LUN iSCSI auxquels accède l'hôte).
Bien que distinctes, ces options peuvent se combiner et être utilisées
ensemble.
Dans les schémas ci-dessous, les disques bleus représentent le stockage
monté par l'hôte : ils contiennent les fichiers VHD des ordinateurs virtuels.
Les disques orange représentent le stockage utilisé directement par les
ordinateurs virtuels, soit sous la forme de disques directs (en utilisant des
contrôleurs virtuels IDE ou SCSI) soit par connexion directe aux LUN iSCSI
qui sont accessibles aux ordinateurs virtuels.
Dans ce schéma, un stockage avec connexion directe composé de disques
SATA, SCSI ou SAS est utilisé.
28
Dans ce schéma, un stockage de type SAN à fibre optique est utilisé.
Remarque
Un ordinateur virtuel Hyper-V ne peut démarrer qu'à partir d'un
disque IDE. Le BIOS d'un ordinateur virtuel sous Hyper-V prend en
charge deux contrôleurs IDE acceptant chacun jusqu'à deux disques,
soit un total de quatre unités IDE par ordinateur virtuel.
Un ordinateur virtuel sous Hyper-V prend en charge jusqu'à 4
contrôleurs SCSI, acceptant chacun jusqu'à 64 disques, soit un total
de 256 disques SCSI par ordinateur virtuel.
Contrairement à Virtual Server 2005 R2, lorsque les composants
d'intégration Hyper-V ont été installés dans l'ordinateur virtuel, il
n'existe pas de différence entre les disques virtuels IDE ou SCSI en
termes de performances.
Recommandation
Utilisez un disque IDE comme disque de démarrage de l'ordinateur
virtuel. Ajoutez un contrôleur et des disques SCSI pour les volumes
de données de l'ordinateur virtuel.
Dans Hyper-V R2, les disques des ordinateurs virtuels peuvent être
ajoutés à chaud via le contrôleur SCSI virtuel. Par conséquent, il est
utile de prévoir la création à l'avance d'un contrôleur SCSi sur tous
les ordinateurs virtuels afin de permettre d'ajouter à chaud des VHD
si nécessaire.
Hyper-V peut aussi exploiter le stockage iSCSI en se connectant
directement aux LUN iSCSI via les adaptateurs réseau virtuel de
l'ordinateur virtuel. Un ordinateur virtuel ne peut pas démarrer à partir
d'un LUN iSCSI via un adaptateur réseau virtuel sans utiliser un initiateur
iSCSI d'un autre fournisseur.
Dans ce schéma, un stockage iSCSI est employé. Avec iSCSI, un troisième
scénario d'accès est possible : accès direct iSCSI en utilisant la connectivité
réseau de l'ordinateur virtuel.
29
Remarque
Ne confondez pas les LUN iSCSI présentés à l'hôte puis utilisés par
l'ordinateur virtuel, avec les LUN iSCSI directement présentés à
l'ordinateur virtuel. Dans le premier cas, l'accès au LUN iSCSI
s'effectue via la connectivité réseau de l'hôte. Dans le second cas,
l'accès au LUN iSCSI s'effectue via la connectivité réseau de
l'ordinateur virtuel. La prochaine section décrit ces options.
Recommandation
Si vous utilisez iSCSI, vérifiez que des réseaux virtuels et physiques
distincts des autres réseaux de communication (y compris au niveau
du câblage et des commutateurs) sont utilisés pour accéder au
stockage iSCSI afin d'obtenir de bonnes performances.
Si vous utilisez des LUN iSCSI présentés à l'hôte, cela implique que
des adaptateurs réseau physiques sont dédiés au réseau de
stockage iSCSI.
L'utilisation de trames jumbo sur les adaptateurs réseau dédiés au
stockage sur l'ordinateur virtuel et sur l'ordinateur hôte permet
d'améliorer les performances.
Si vous utilisez des LUN iSCSI présentés directement aux ordinateurs
virtuels, cela signifie la présence d'adaptateurs réseau physiques dédiés
au stockage dans l'hôte, un (ou des) commutateur virtuel dédié relié à ces
adaptateurs physiques, et des adaptateurs réseau virtuels dans les
ordinateurs virtuels reliés à ce commutateur virtuel. Chaque ordinateur
virtuel est ainsi équipé de deux adaptateurs virtuels ou plus : l'un assure la
connectivité réseau ordinaire, l'autre la connectivité iSCSI.
30
Réseaux virtuels
Vous pouvez créer sur le serveur Hyper-V autant de réseaux virtuels que
vous le souhaitez pour mettre en place des canaux de communication. par
exemple, vous pouvez créer des réseaux pour assurer les communications
suivantes :
Communications entre ordinateurs virtuels uniquement. Ce type de
réseau virtuel se nomme réseau privé.
Communications entre le serveur hôte et les ordinateurs virtuels. Ce
type de réseau virtuel se nomme réseau interne.
Communications entre un ordinateur virtuel et un réseau physique en
créant une association avec un adaptateur réseau physique du
serveur hôte. Ce type de réseau virtuel se nomme réseau externe.
Vous pouvez utiliser Virtual Network Manager pour ajouter, supprimer et
modifier les réseaux virtuels. Virtual Network Manager est accessible à
partir de la console MMC Hyper-V. Les types de réseaux sont illustrés par
le schéma suivant.
Lors de la création d'un réseau externe dans Hyper-V, un commutateur
virtuel est créé et relié à l'adaptateur réseau physique sélectionné. Un
nouvel adaptateur réseau virtuel est créé dans la partition parent et
connecté au commutateur virtuel. Les partitions enfants peuvent être liées
au commutateur virtuel via des adaptateurs réseau virtuels. Le schéma ci-
dessous illustre cette architecture.
31
En plus des scénarios déjà décrits, Hyper-V prend aussi en charge
l'utilisation de réseaux locaux virtuels (VLAN) et d'identifiants de réseaux
locaux virtuels avec le commutateur virtuel et les adaptateurs réseau
virtuels. Pour cela, Hyper-V utilise l'encapsulation VLAN 802.1q. Pour
exploiter cette fonctionnalité, il faut créer un commutateur réseau virtuel
sur l'hôte et le lier à un adaptateur réseau physique qui prend en charge
la balisage VLAN de l'en-tête de la trame Ethernet selon le standard IEEE
802.1q. Les identifiants VLAN sont configurés à deux endroits :
Sur le commutateur virtuel lui-même, qui définit l'identifiant VLAN
que l'adaptateur réseau virtuel de la partition parent utilisera.
Sur l'adaptateur réseau virtuel de chaque ordinateur virtuel, qui
définit l'identifiant VLAN que l'ordinateur virtuel utilisera.
Le schéma ci-dessous est un exemple de l'utilisation d'un adaptateur
réseau unique dans l'hôte qui est connecté à un réseau physique 802.1q
et qui encapsule trois réseaux virtuels (5, 10, 20). Dans cet exemple :
Un lien 802.1q encapsulant trois réseaux virtuels (5, 10, 20) est relié à
un adaptateur physique de l'hôte.
Un commutateur virtuel unique est créé et relié à l'adaptateur
physique.
L'identifiant VLAN du commutateur virtuel est configuré à 5, ce qui
permet à l'adaptateur réseau virtuel du parent à communiquer sur le
réseau virtuel 5.
L'identifiant VLAN de l'adaptateur réseau virtuel de la partition
enfant 1 est configuré à 10, ce qui lui permet de communiquer sur le
réseau virtuel 10.
32
L'identifiant VLAN de l'adaptateur réseau virtuel de la partition
enfant 2 est configuré à 20, ce qui lui permet de communiquer sur le
réseau virtuel 20.
Dans cette configuration, le parent et les deux enfants ne peuvent
communiquer que sur leurs réseaux locaux respectifs, sans pouvoir
communiquer entre eux.
Remarques concernant la sécurité
Microsoft Hyper-V a été conçu pour réduire la surface d'attaque dans
l'environnement virtuel. L'hyperviseur lui-même est isolé dans un
micronoyau, indépendant des pilotes tiers. Les activités Hyper-V
s'exécutant dans l'hôte sont isolées dans une partition parent isolée de
chaque ordinateur virtuel invité. Cette partition parent est elle-même un
ordinateur virtuel. Chaque ordinateur virtuel invité fonctionne dans sa
propre partition enfant.
Ces pratiques sont recommandées pour un environnement Hyper-V afin
d'assurer la meilleure sécurité. Elles complètent les pratiques
recommandées pour les serveurs physiques :
Utilisez l'isolation de domaines avec IPSec à la fois pour les hôtes et
les ordinateurs virtuels invités.
Sécurisez les communications entre le serveur Hyper-V, ses
administrateurs et ses utilisateurs.
Configuration du système d'exploitation hôte
Utilisez une installation minimale (Server Core) pour le système
d'exploitation d'administration.
Maintenez ce système d'exploitation en permanence à jour en lui
33
appliquant toutes les mises à jour de sécurité.
Utilisez un réseau séparé, avec un adaptateur réseau dédié, pour
l'administration du serveur physique Hyper-V.
Sécurisez les équipements de stockage où sont placés les fichiers de
ressources des ordinateurs virtuels.
Renforcez le système d'exploitation d'administration en appliquant
les recommandations pour les paramètres de base de la sécurité,
décrites dans le Windows Server 2008 Security Compliance
Management Toolkit.
Configurez les logiciels antivirus d'analyse en temps réel installés sur
le système d'exploitation d'administration pour en exclure les
ressources Hyper-V.
Ne faites fonctionner aucune application sur le système d'exploitation
d'administration.
N'accordez pas aux administrateurs des ordinateurs virtuels le droit
de se connecter sur le système d'exploitation d'administration.
Utilisez le niveau de sécurité de vos ordinateurs virtuels pour
déterminer le niveau de sécurité du système d'exploitation
d'administration.
Utilisez Windows® BitLocker™ Drive Encryption pour protéger les
ressources. (Remarque : BitLocker ne fonctionne pas sur un cluster à
basculement.)
Configuration des ordinateurs virtuels
Utilisez de préférence des disques durs virtuels (VHD) de taille fixe.
Stockez les VHD et les clichés instantanés de volume dans des
emplacements sûrs.
Décidez la taille mémoire allouée à chaque ordinateur virtuel.
Imposez des limites sur l'utilisation des processeurs.
Configurez les adaptateurs réseau virtuels de chaque ordinateur
virtuel en choisissant correctement les types des réseaux virtuels afin
d'isoler les trafics réseau entre eux.
Configurez le minimum de stockage requis pour chaque ordinateur
virtuel.
Renforcez le système d'exploitation de chaque ordinateur virtuel en
fonction du rôle serveur qu'il joue. Appliquez les recommandations
de sécurité décrites dans le Windows Server 2008 Security
Compliance Management Toolkit.
Configurez les logiciels d'antivirus, de pare-feu et de détection
d'intrusion dans les ordinateurs virtuels en tenant compte du rôle
serveur de chacun d'eux.
Vérifiez que chaque ordinateur virtuel a reçu les dernières mises à
34
jour de sécurité avant d'être mis en production.
Vérifiez que les services d'intégration sont installés sur les ordinateurs
virtuels.
Configuration du réseau
Le serveur Hyper-V doit posséder au minimum deux adaptateurs réseau
physiques, et certainement davantage, pour isoler des groupes
d'ordinateurs virtuels entre eux.
Le premier adaptateur sert à administrer la partition de l'hôte. Les autres
adaptateurs servent aux ordinateurs virtuels pour communiquer avec le
réseau physique et le stockage. La séparation entre ces interfaces est
importante car si les adaptateurs des partitions enfants sont saturés,
l'administrateur pourra toujours accéder à la partition hôte.
De plus, des ordinateurs invités qui gèrent des données particulièrement
sensibles pourront être configurés pour utiliser un seul adaptateur réseau
afin d'accéder au réseau physique. Avec les LAN et d'autres critères qui
permettent de contrôler les accès à ces systèmes, les administrateurs
peuvent ajouter une autre couche de sécurité sur l'accès à un adaptateur
réseau physique ou à un réseau virtuel.
Isolation de domaine
La mise en œuvre d'une isolation de domaine basée sur IPSec présente
des avantages et peu d'inconvénients, notamment si elle utilise une
authentification Kerberos, dans le domaine auquel appartient l'hôte
Hyper-V. Les administrateurs sont alors assurés que seuls les systèmes qui
sont authentifiés par Kerberos peuvent accéder à l'hôte Hyper-V.
L'isolation de domaine interdit le branchement d'un ordinateur inconnu
sur le réseau interne pour explorer les serveurs. L'intrus ne verra aucune
liste de serveurs apparaître. Aucun serveur n'acceptera ses requêtes.
L'isolation de domaine reposant uniquement sur l'authentification IPSec
35
pour isoler les systèmes, l'impact sur les performances est minimal. Dans
ce cadre, et contrairement au scénario d'isolation des serveurs, IPSec ne
chiffre pas les données.
En général, il est recommandé d'utiliser l'isolation de domaine autant que
possible dans l'environnement virtuel et d'utiliser l'isolation de serveur
uniquement lorsque c'est absolument nécessaire. S'il n'est pas possible
d'isoler physiquement la console d'administration du reste du réseau,
l'isolation de serveur peut être utilisé avec une stratégie IPSec pour lier
uniquement la console de l'administrateur à l'adaptateur réseau
d'administration qui accède à la partition parent et permet d'administrer
l'hôte Hyper-V
Impact sur les performances
Les accélérateurs matériels IPSec ne sont pas efficaces dans les
environnements virtuels et ne peuvent pas alléger le trafic IPSec.
Exceptions recommandées pour le pare-feu pour Hyper-V
Certains ports doivent être ouverts pour que Hyper-V fonctionne
correctement. Ils le sont automatiquement lorsque le rôle Hyper-V est
ajouté à Windows 2008 R2 Server. Cette configuration ne doit pas être
changée ni localement ni par une stratégie de groupe. Elle doit être
appliquée en permanence par une stratégie de groupe afin que d'autres
stratégies ne viennent pas la modifier et arrêter des services Hyper-V
essentiels.
Ces ports sont extraits de la référence Windows Server 2008 Hyper-V
Attack Surface Reference.xlsx, un guide de tous les fichiers, services et
ports concernés par le rôle Hyper-V. Ce tableau peut être téléchargé ici :
http://download.microsoft.com/download/02/08/09/829bee7b-821b-
4c4c-8297-13762aa5c3e4/Windows%20Server%202008%20Hyper-
V%20Attack%20Surface%20Reference.xlsx
BitLocker
Un attaquant pourrait accéder physiquement au serveur et aux disques
physiques du serveur. Il pourrait alors accéder aux partitions NTFS sans
authentification simplement en insérant un CD Microsoft Windows Pre-
installation Environment (WinPE) et en redémarrant le système. Si les
données ne sont pas chiffrées par Encrypted File System (EFS) ou par une
autre méthode, tous les fichiers sont alors exposés.
La meilleure réponse à ce risque consiste à sécuriser avec Windows®
BitLocker™ Drive Encryption les volumes qui stockent les fichiers système
Hyper-V et les ordinateurs virtuels. Il s'agit d'un algorithme de chiffrement
de volume inclus dans Windows Server 2008 et utilisant un composant
matériel spécifique intégré dans l’ordinateur.
36
Impact sur les performances
Un chiffrement de volume, quelle que soit la technologie mise en
œuvre, ajoute une légère surcharge au serveur. Il n'existe pas de
document officiel sur ce sujet, mais des tests menés par le groupe
Produits montre que BitLocker induit une charge de 8 % dans le pire
des cas, et généralement une charge de 3 à 5 %. Mesurez les
performances avant et après l'activation de BitLocker et le
chiffrement de volume.
Délégation des droits d'administration
Lorsqu'un serveur physique est configuré pour héberger plusieurs
instances virtuelles, il faut attribuer avec soin les droits d'administration
sur chaque instance afin de sécuriser au maximum l'environnement
Hyper-V.
Authorization Manager (Azman.msc) fait partie de RBAC, contrôle d'accès
Windows basé sur les rôles. Il sert à déléguer les droits d'administration
de telle sorte que chaque utilisateur puisse réaliser les tâches qui lui
incombent en fonction de son rôle. Par défaut, seuls les membres du
groupe des administrateurs peuvent créer et contrôler les systèmes
virtuels.
Remarque
Si Microsoft® System Center Virtual Machine Manager est utilisé,
toute autorisation doit être configurée à partir de la console Virtual
Machine Manager plutôt que par AzMan.
Voici les principaux concepts d'AzMan :
Portée : une collection de ressources similaires qui partagent toutes la
même stratégie d'autorisation, par exemple un ordinateur virtuel ou
un réseau virtuel.
Rôle : Une responsabilité ou un type de poste dans l'entreprise.
Exemples : administrateurs, utilisateurs du portail en libre-service
(dans Virtual Machine Manager).
Tâche : Une collection d'opérations ou d'autres tâches. Exemples :
Gérer les paramètres du serveur Hyper- V, créer des ordinateurs
virtuels.
Opération : Les opérations composent les tâches, ou peuvent
être affectées individuellement à un rôle. Une opération est une
action élémentaire qu'un utilisateur peut effectuer. Exemples :
« Démarrer un ordinateur virtuel » ; « Arrêter un ordinateur
virtuel ». Grouper des opérations crée une tâche. La tâche permet
à un rôle d'effectuer une fonction d'administration spécifique.
37
DIMENSIONNEMENT DE L'HÔTE ET
PLANIFICATION DE LA CONSOLIDATION
Le dimensionnement d'un hôte consiste à déterminer le total des
scénarios à consolider (pour en déduire les processeurs, la taille de la
mémoire, les E/S disques, les E/S réseau, etc.) ainsi que les charges les
plus lourdes à consolider. Puis, une architecture (ou plusieurs) d'hôte
standard est définie et testée pour déterminer sa capacité réelle. Le total
des scénarios est divisé par la capacité réelle d'un hôte pour déterminer le
nombre d'hôtes nécessaire. Ce calcul est pratiqué par catégorie
(processeurs, mémoire, E/S disques, etc.). Le nombre d'hôtes ramené au
nombre total de serveurs au départ permet de connaître le ratio de
consolidation.
Lorsque la phase de dimensionnement est terminée, le client sait le
nombre d'architectures hôtes nécessaires et le nombre d'hôtes par
architecture pour faire face à l'ensemble de la charge prévue et
consolidée.
Dans la plupart des cas, la taille de la mémoire de l'hôte est le paramètre
qui détermine le nombre d'ordinateurs virtuels qu'il pourra faire
fonctionner. De plus, la taille de la mémoire allouée à un ordinateur virtuel
détermine souvent les performances du système d'exploitation invité.
Heureusement, le prix de la mémoire a baissé ces dernières années tandis
que la capacité maximale prise en charge a augmenté. Par conséquent,
nous recommandons le choix d'un serveur hôte acceptant une grande
capacité mémoire, et l'allocation d'au moins 2 Go de RAM à chaque
ordinateur virtuel. Bien qu'il soit certainement possible d'obtenir des
ratios de consolidation encore meilleurs, les conseils donnés dans ce
guide permettent d'obtenir des ordinateurs virtuels performants.
Analyse des scénarios de consolidation
Au cours de la phase Découverte et évaluation, le service informatique
détermine les serveurs physiques qui se prêtent bien à une consolidation.
Ces candidats potentiels sont analysés pendant un certain temps afin de
déterminer l'utilisation moyenne et l'utilisation maximale des processeurs,
de la mémoire, des E/S disques, des E/S réseau, etc. Cette analyse est
importante dans le processus de dimensionnement car elle déterminera la
charge totale qui sera supportée par les hôtes, ainsi que les applications
les plus lourdes. Il faudra veiller à ce que chaque application parmi les
plus lourdes ne dépasse pas les limites physiques d'un ordinateur virtuel
(par exemple, 4 cœurs de processeur, 64 Go de mémoire, etc.). Si une
application seule dépasse les limites d'un ordinateur virtuel, il ne faudra
pas la placer sur un ordinateur virtuel sans modifier l'architecture de l'hôte
afin de pouvoir monter en puissance ses ordinateurs virtuels.
38
Modèle d'architecture du serveur hôte
Lors de la détermination de la capacité disponible pour les ordinateurs
virtuels, réservez un cœur processeur, 1 Go de mémoire, 1 adaptateur
réseau et 1 partition disque en RAID 1 pour l'hôte lui-même. La taille de la
partition disque doit être de 20 Go + la taille de toute la mémoire du
serveur. Par exemple, si le serveur possède 32 Go de mémoire, la taille de
la partition en RAID 1 pour le système d'exploitation de l'hôte doit être de
52 Go afin de permettre un vidage complet de la mémoire sur disque en
cas de crash du système d'exploitation hôte. Toute la capacité restante de
l'hôte est à la disposition des ordinateurs virtuels invités.
Profils matériels pour les ordinateurs virtuels invités
System Center Virtual Machine Manager introduit le concept de profil
matériel. Il s'agit d'une collection définie par l'utilisateur de paramètres
matériels appliqués aux ordinateurs virtuels, comme le nombre de
processeurs logiques, la taille de la RAM, etc. Lors de la création d'un
nouvel ordinateur virtuel, le profil matériel permet d'assurer une
cohérence dans la configuration de tous les ordinateurs virtuels utilisant
ce même profil. Il est possible de définir plusieurs profils.
Pour des raisons de simplicité et de cohérence, nous conseillons de ne
pas dépasser trois profils décrits dans les tableaux ci-dessous.
39
Invité Hyper-V (grand)
Windows Server 2008 Enterprise Edition 64 bits
Adaptateur réseau 0 – vSwitch 1
MAC : VLAN :
Adaptateur réseau 1 – vSwitch 2
MAC : VLAN :
Disque direct 1 via LUN 2
Contrôleur SCSI 0 Contrôleur SCSI 1
Disque direct 1 via LUN 4
Disque direct 0 via LUN 1 Disque direct 0 via LUN 3
Contrôleur IDE 0
Disque de boot (VHD)
Contrôleur IDE 0
<libre>
Contrôleur IDE 1
Lecteur de DVD
Contrôleur IDE 1
<libre>
16 Go de mémoire
Processeur logique 1 Processeur logique 2
Processeur logique 3 Processeur logique 4
Invité Hyper-V (moyen)
Windows Server 2008 Enterprise Edition 64 bits
Adaptateur réseau 0 – vSwitch 1
MAC : VLAN :
Adaptateur réseau 1 – vSwitch 2
MAC : VLAN :
Disque direct 1 via LUN 2
Contrôleur SCSI 0 Contrôleur SCSI 1
Disque direct 1 via LUN 4
Disque direct 0 via LUN 1 Disque direct 0 via LUN 3
Contrôleur IDE 0
Disque de boot (VHD)
Contrôleur IDE 0
<libre>
Contrôleur IDE 1
Lecteur de DVD
Contrôleur IDE 1
<libre>
4 Go de mémoire
Processeur logique 1 Processeur logique 2
Processeur logique 3 Processeur logique 4
Invité Hyper-V (petit)
Windows Server 2008 Enterprise Edition 64 bits
Adaptateur réseau 0 – vSwitch 1
MAC : VLAN :
Adaptateur réseau 1 – vSwitch 2
MAC : VLAN :
Contrôleur IDE 0
Disque de boot (VHD)
Contrôleur IDE 0
Lecteur de DVD
Contrôleur IDE 1
Disque de données
(VHD)
Contrôleur IDE 1
<libre>
2 Go de mémoire
Processeur logique 1 Processeur logique 2
Nous vous conseillons d'associer chaque consolidation à un de ces trois
profils matériels. Les profils matériels peuvent servir à calculer combien
d'ordinateurs virtuels dans chaque profil peuvent être gérés par un même
hôte en divisant la capacité totale d'un hôte par les ressources nécessaires
à chaque profil multipliées par le nombre d'ordinateurs virtuels de ce
profil.
40
Test des performances des architectures de l'hôte et
des serveurs virtuels
Il est nécessaire de réaliser des essais avec des charges maximales sur les
processeurs, la mémoire, les E/S disques et réseau. Ces essais fournissent
des nombres précis à utiliser dans les formules de dimensionnement ci-
dessous. Ils mettent aussi en évidence des problèmes de configuration ou
la faiblesse d'un élément. Si les performances obtenues ne répondent pas
aux attentes, il faut refaire une analyse détaillée du matériel, des logiciels
et de la configuration.
Le test d'un ordinateur virtuel invité standard, ou d'un ensemble d'invités,
permettra de vérifier que les performances obtenues correspondront aux
nombres obtenus par les formules ci-dessous.
En étudiant avec soin les combinaisons hôte-invités, les performances de
l'infrastructure virtualisée devraient répondre aux attentes ou les
dépasser. Si vous ne menez pas des tests pour confirmer les calculs et la
méthodologie du dimensionnement utilisée, vous pourriez constater des
performances insuffisantes.
Calcul du nombre d'hôtes nécessaires
Besoin total en ressources des candidats à la consolidation
En utilisant les données de l'analyseur de performances collectées dans
les phases précédentes, déterminez le besoin total en ressources des
candidats à la consolidation sur un même site.
41
Ressources du serveur hôte
Pour chaque site, sélectionnez le modèle d'architecture et l'architecture
du serveur hôte. En utilisant les équations ci-dessous, divisez les
ressources de l'hôte par les besoins en ressources des candidats à la
consolidation. Vous pouvez aussi diviser les ressources de l'hôte par les
ressources du profil matériel.
Capacité processeur serveur hôte pour invités
=((Nb proc. * Nb cœurs par proc) - 1)*85 %
Capacité mémoire serveur hôte pour invités = Total mémoire hôte (Go) - 2 Go
Capacité E/S disque serveur hôte pour invités = IOPS du test E/S hôte * .85
Capacité E/S réseau serveur hôte pour invités
= Nb moyen d'octets par seconde * .85
En utilisant ces formules, vous obtenez de différentes façons le nombre
d'hôtes nécessaire sur le site. Vous devez choisir le plus grand de ces
nombres.
SYSTEM CENTER VIRTUAL MACHINE
MANAGER 2008 R2
Composants de System Center Virtual Machine
Manager
Cette section présente de façon succincte les composants de System
Center Virtual Machine Manager et donne quelques informations qui
doivent être prises en compte avant leur installation.
Serveur Microsoft® System Center Virtual Machine Manager
Le serveur System Center Virtual Machine Manager (SCVMM) constitue le
cœur d'un déploiement System Center Virtual Machine Manager car tous
les autres composants System Center Virtual Machine Manager
interagissent et communiquent avec lui.
Le serveur SCVMM exécute le service SCVMM. Ce service exécute des
commandes, effectue des transferts de fichiers et contrôle les
communications avec d'autres composants System Center Virtual
Machine Manager et avec tous les hôtes et les serveurs de bibliothèques
SCVMM. Ces systèmes sont désignés par les termes « ordinateurs gérés ».
Le service SCVMM dialogue avec des agents SCVMM installés sur les
42
ordinateurs gérés.
Le serveur SCVMM est aussi connecté à une base de données Microsoft
SQL Server® 2005 qui stocke toutes les informations de configuration de
SCVMM.
Par défaut, le serveur SCVMM est aussi un serveur de bibliothèque qui
sert à stocker des ressources sous forme de fichiers, comme des disques
VHD, des disquettes virtuelles, des modèles, des scripts PowerShell™, des
fichiers de réponse pour installation silencieuse, des images ISO et des
métadonnées SCVMM comme les profils matériels.
Console d'administration SCVMM
La console d'administration de System Center Virtual Machine Manager
sert à :
Créer, déployer et administrer des ordinateurs virtuels et des
modèles.
Surveiller et gérer des hôtes (Windows Server® 2008/ Windows
Server® 2008R2 Hyper-V™, Microsoft® Virtual Server 2005 et
serveurs VMware® Virtual Center ESX) et des serveurs de
bibliothèques.
Gérer des objets de la bibliothèque et des travaux.
Gérer les paramètres de configuration globaux.
La console System Center Virtual Machine Manager s'installe après le
serveur SCVMM. Elle peut être installée sur le même ordinateur que le
serveur ou sur un système séparé. Toutes les fonctions disponibles dans la
console d'administration SCVMM sont aussi disponibles sous forme de
cmdlets dans Windows PowerShell.
Portail en libre-service Microsoft System Center Virtual
Machine Manager v1
Le portail en libre-service SCVMM est un composant Web optionnel qui
permet aux utilisateurs de créer et de gérer leurs propres ordinateurs
virtuels dans un environnement contrôlé.
Important
VMMSSP n'est pas une mise à jour du portail en libre-service
existant dans VMM 2008 R2. Libre à vous de déployer et d'utiliser
l'un des deux portails libre-service, ou les deux, en fonction de vos
besoins.
Agent Microsoft® System Center Virtual Machine Manager
L'agent SCVMM gère les ordinateurs virtuels sur les hôtes et permet aux
hôtes et aux serveurs de bibliothèque de communiquer avec le serveur
SCVMM et d'échanger des fichiers avec lui.
43
Quand un hôte ou un serveur de bibliothèque rejoint un domaine
approuvé et est ajouté via la console d'administration SCVMM, il reçoit
automatiquement un agent transmis et installé par SCVMM avec les
paramètres par défaut.
Si un hôte est sur un réseau de périmètre ou s'il ne rejoint pas un
domaine approuvé, un administrateur doit ajouter l'agent manuellement
sur cet hôte avant de pouvoir l'ajouter à SCVMM.
Hôte d'ordinateurs virtuels
Un hôte est un ordinateur physique qui héberge un ou plusieurs
ordinateurs virtuels. Les hôtes sont ajoutés dans SCVMM via l'assistant
Add Hosts (Ajouter des hôtes) dans la console d'administration de
SCVMM. Quand un hôte est ajouté à SCVMM, un agent est
automatiquement installé sur cet hôte. Lorsque vous ajoutez un
ordinateur hôte Windows, SCVMM installe ou met automatiquement à
jour la version adéquate de Virtual Server ou active Hyper-V.
Important
Afin de gérer des hôtes Virtual Server qui utilisent le système
d'exploitation Windows Server® 2003, la version appropriée de
Windows Remote Management (WinRM) doit être installée.
Groupes hôtes
Les hôtes des systèmes virtuels peuvent être organisés en groupes afin de
faciliter les tâches de supervision et d'administration des hôtes et des
ordinateurs virtuels. Les groupes d'hôtes peuvent être calqués sur
l'organisation de votre entreprise.
La fonction de base d'un groupe hôte est d'agir comme un conteneur qui
regroupe de façon pratique des hôtes et des ordinateurs virtuels. Les
groupes d'hôtes servent à :
Définir des ressources sur les hôtes qui seront réservées au système
d'exploitation hôte lui-même.
Définir les hôtes qui seront utilisés en libre-service.
Désigner les hôtes qui seront connectés à un réseau de stockage
SAN. (C'est une pratique recommandée.)
Permettre le placement automatique d'ordinateurs virtuels sur l'hôte
le plus approprié dans un groupe d'hôtes.
Héritage des propriétés d'un groupe d'hôtes
Un groupe d'hôtes enfant peut hériter des paramètres de réservation et
des délégations de rôles de son groupe parent. Toutefois, l'héritage de
propriété fonctionne différemment pour les deux fonctions suivantes :
Réserves de ressources pour ordinateur hôte. Lors d'une
44
modification des paramètres de réservation dans un groupe parent
hôte, l'administrateur peut demander que ces modifications soient
propagées aux hôtes des groupes enfants. Si l'héritage est autorisé,
les paramètres de réservation présents dans les groupes enfants
seront écrasés.
Délégation de rôle. Si un groupe hôte parent est utilisé pour la
délégation de rôle, chacun de ses groupes hôtes enfants héritera
automatiquement des paramètres du parent.
Isolation d'un groupe
Un groupe hôte peut être utilisé pour isoler un hôte ou une collection
d'hôtes. Si, par exemple, un hôte a des invités virtuels qui hébergent des
applications importantes, il peut être isolé en étant placé seul dans son
propre groupe. De cette manière, seuls les utilisateurs ayant les
autorisations appropriées pourront y accéder et les ressources réservées à
l'hôte seront maximisées pour des raisons de disponibilité.
Serveur de bibliothèque Microsoft® System Center Virtual
Machine Manager
Chaque serveur de bibliothèque SCVMM contient un catalogue de
ressources qui peut être utilisé pour créer et configurer des ordinateurs
virtuels dans SCVMM. La bibliothèque contient des fichiers qui sont
stockés sur des partages. Elle peut contenir des ressources sous forme de
fichiers, comme des disques VHD, des disquettes virtuelles, des images
ISO et des scripts.
Important
Lorsque l'installation est terminée, le serveur de bibliothèque par
défaut et le partage ne peuvent pas être déplacés. Il est donc
important de bien étudier leurs emplacements lors de l'installation.
De plus, le serveur de bibliothèque peut contenir des modèles
d'ordinateurs virtuels, des profils matériels et des profils de systèmes
d'exploitation invités qui servent à créer des ordinateurs virtuels. Il stocke
aussi les ordinateurs virtuels qui ne sont pas en cours d'utilisation.
Groupes de bibliothèques
Lors de la création des serveurs de bibliothèque, des groupes peuvent
être créés pour organiser ces serveurs de façon pratique.
Il est conseillé d'aligner les serveurs de bibliothèque avec les groupes
hôtes qui exploitent ces ressources, notamment quand le serveur de
bibliothèque est connecté au SAN. De cette façon, les serveurs de
bibliothèque et les hôtes exploitent mieux les transferts de fichiers SAN.
45
Place du serveur System Center Virtual Machine
Manager
Dans la plupart des déploiements SCVMM, un seul serveur SCVMM est
suffisant. Un déploiement SCVMM peut monter en charge en ajoutant des
hôtes et des serveurs de bibliothèque à mesure que l'environnement se
développe. Un serveur SCVMM unique avec une base de données unique
devient le point d'administration central pour tout l'environnement
virtuel. Toutefois, mettre en place plusieurs serveurs SCVMM peut
présenter des avantages dans les cas suivants :
Quand les environnements de test et de développement sont gérés
séparément de l'environnement virtuel en production.
Quand l'environnement virtuel croît et va dépasser le maximum pris
en charge de 400 hôtes et 8000 ordinateurs virtuels.
S'il est nécessaire d'installer plus d'un serveur System Center Virtual
Machine Manager, les points suivants doivent être pris en considération :
Chaque serveur SCVMM doit être installé sur un ordinateur qui lui est
exclusif et doit posséder sa propre base de données SCVMM.
Le déplacement de fichiers d'un déploiement SCVMM vers un autre
n'est pas pris en charge.
Nombres d'hôtes et d'ordinateurs virtuels pris en charge
Les nombres maximaux d'hôtes et d'ordinateurs virtuels pris en charge
par SCVMM sur les plus puissantes configurations matérielles actuelles
sont 400 hôtes et 8000 ordinateurs virtuels. Il ne s'agit pas de limitations
techniques mais de limitations pratiques. Ces nombres peuvent varier en
fonction des besoins du client ou de tolérance de panne.
Le nombre d'ordinateurs virtuels qui peuvent fonctionner sur un même
hôte dépend principalement de la configuration de l'hôte et des
ordinateurs virtuels.
Considérations relatives au réseau
Pour SCVMM, les points principaux à prendre en considération pour le
réseau sont :
Connectivité
Bande passante
Trafic réseau
Connectivité
Vérifiez qu'aucun pare-feu ne bloque les communications nécessaires
entre les composants SCVMM.
Lors de l'installation de SCVMM, l'administrateur définit les ports utilisés
par SCVMM pour les communications avec les agents et pour les
transferts de fichiers entre hôtes et serveurs de bibliothèques. Par défaut,
46
ces ports sont 22 (SFTP), 80 et 443.
Bande passante
L'utilisation de SCVMM pour créer et gérer des ordinateurs virtuels peut
engendrer des transferts de plusieurs gigaoctets sur le réseau, par
exemple lors de migrations « physique vers virtuel » (P2V), lors du
déplacement d'un ordinateur virtuel d'un hôte vers un autre, ou lors du
déploiement d'un nouvel ordinateur virtuel à partir d'un modèle.
Il est recommandé de connecter tous les ordinateurs présents dans une
configuration SCVMM par des liens Ethernet full duplex à 100 Mbit/s au
minimum. Si vous utilisez des liens Ethernet Gigabit, choisissez des
processeurs plus puissants que le minimum requis ; les performances
seront améliorées.
Si vous étendez SCVMM au-delà du centre de données, par exemple dans
des agences :
Ajoutez un serveur de bibliothèque SCVMM dans chaque site distant
où il sera nécessaire de créer des ordinateurs virtuels ou des modèles,
ou d'accéder à des images ISO.
Évitez de transférer des fichiers via des liens longue distance peu
fiables ou de faible débit.
Trafic réseau
System Center Virtual Machine Manager effectue une actualisation
périodique des bibliothèques, des hôtes et des ordinateurs virtuels. Dans
de grands environnements, ce trafic peut devenir significatif.
Si vous utilisez un SAN iSCSI ou fibre optique, l'impact sur le réseau sera
réduit car ces mises à jour effectueront des transferts SAN plutôt que des
transferts réseau. Lors d'un transfert SAN, le LUN qui contient l'ordinateur
virtuel est remappé de l'ordinateur source à l'ordinateur destination (au
lieu d'effectuer un transfert de fichier sur le réseau). Ainsi, les transferts
SAN sont bien plus rapides et indépendants de la taille des fichiers
transférés. Si vous utilisez iSCSI, prenez en compte le trafic réseau qui sera
induit par les connexions iSCSI avec System Center Virtual Machine
Manager.
Considérations relatives au stockage
SCVMM prend en charge toutes les formes de stockage avec connexion
directe ainsi que les SAN iSCSI et fibre optique. SCVMM prend aussi en
charge la virtualisation N_Port ID (NPIV) sur un SAN fibre optique. NPIV
utilise la technologie de l'adaptateur bus hôte (HBA) qui crée des ports
HBA virtuels sur des hôtes en faisant abstraction du port physique sous-
jacent. Cela permet à un port HBA unique de fonctionner comme
plusieurs ports logiques, chacun ayant sa propre identité. Chaque
ordinateur virtuel peut alors être relié à son propre port virtuel HBA et
constituer une zone indépendante avec un nom mondial distinct (WWN).
47
Transferts SAN avec System Center Virtual Machine Manager
SCVMM peut effectuer les types suivants de transferts SAN entre un
ordinateur source et un ordinateur destination :
Stocker un ordinateur virtuel d'un hôte dans une bibliothèque
SCVMM.
Déployer des ordinateurs virtuels d'une bibliothèque SCVMM vers un
hôte.
Migrer un ordinateur virtuel d'un hôte vers un autre.
Lors d'un transfert SAN, le LUN qui contient l'ordinateur virtuel est
remappé de l'ordinateur source à l'ordinateur destination (au lieu
d'effectuer un transfert de fichier sur le réseau). Par conséquent, les
transferts SAN sont bien plus rapides que des transferts réseau et ils sont
indépendants de la taille des fichiers.
Si un transfert SAN est possible, SCVMM l'utilisera automatiquement. Ce
comportement peut être modifié pour forcer SCVMM à utiliser un
transfert réseau.
Avant que SCVMM puisse être utilisé pour un transfert de fichier SAN, les
étapes de configuration suivantes doivent être réalisées :
1. Installez Virtual Disk Service (VDS) 1.1, un composant de Windows
Server 2003 R2, sur chaque ordinateur qui servira comme source ou
comme destination.
2. Installez le fournisseur de matériel VDS uniquement sur le serveur
SCVMM.
3. Installez un initiateur iSCSI pour un SAN iSCSI.
4. Installez un pilote MPIO pour un SAN fibre optique même si le
système utilise un seul port HBA.
Avant que SCVMM puisse être utilisé pour un transfert de fichier SAN sur
des hôtes Windows Server 2008/Hyper-V, les étapes de configuration
suivantes doivent être réalisées :
1. Installez un initiateur iSCSI pour un SAN iSCSI.
2. Installez un pilote MPIO pour un SAN fibre optique même si le
système utilise un seul port HBA.
Mise en œuvre rapide de SCVMM 2008 R2 avec un SAN
Certains SAN ont des ressources pour cloner un LUN contenant un VHD
et pour le présenter à l'hôte. Afin d'utiliser SCVMM pour la
personnalisation du système d'exploitation et l'installation IC, SCVMM R2
propose le commutateur UseLocalVirtualHardDisk pour la cmdlet new-VM
sans copie réseau. Vous pouvez créer un modèle qui inclut le fichier de
réponse pour le système d'exploitation, et qui fait référence à un disque
VHD factice qui ne sera pas utilisé. Cette fonctionnalité n'est disponible
qu'en utilisant Windows PowerShell™.
Voici un script d'exemple :
48
Get-VMMServer -ComputerName "VMMServer1.Contoso.com"
$JobGroupID = [Guid]::NewGuid().ToString()
$Template = Get-Template | where {$_.Name -eq "MyTemplate"}
$VMHost = Get-VMHost | where {$_.Name -eq "VMHost.Contoso.com"}
Move-VirtualHardDisk -IDE -BUS 0 -LUN 0 -Path "L:\OS.VHD" -
JobGroup $JobGroupID
New-VM -Name "VM Name" -Path "L:\" -Template $Template -VMHost
$VMHost -JobGroup -$JobGroupID -UseLocalVirtualHardDisks
Considérations relatives à la sécurité
Considérations générales relatives à la sécurité
Prenez en compte les informations suivantes lors de la planification d'un
déploiement SCVMM :
Lors de l'utilisation de forêts Active Directory multiples, une relation
d'approbation bidirectionnelle est nécessaire pour installer les
composants SCVMM.
Par défaut, les ordinateurs virtuels fonctionnent dans le contexte de
sécurité du compte qui a démarré l'ordinateur. Pour renforcer la
sécurité, vous pouvez spécifier un compte possédant moins de
privilèges.
Lors de l'utilisation d'une instance à distance de SQL Server, l'instance
doit fonctionner sous un compte autre que LocalSystem.
Les utilisateurs du libre-service doivent s'authentifier lorsqu'ils se
connectent à des ordinateurs virtuels. Pour éviter cela, ajoutez le nom
de l'hôte aux sites Intranet local dans les paramètres de sécurité de
Microsoft® Internet Explorer®.
Lors de l'ajout d'un hôte ou d'un serveur de bibliothèque, SCVMM
installe le compte ordinateur du serveur SCVMM en tant
qu'Administrateur local sur l'ordinateur géré. Vérifiez que des
groupes restreints par une stratégie de groupe ne peuvent pas
supprimer ce compte ; sinon, SCVMM ne fonctionnerait pas
correctement.
Vulnérabilités de sécurité
Pour éviter des vulnérabilités classiques en sécurité, prenez en compte les
remarques suivantes :
Une pratique recommandée consiste à ne pas conserver les valeurs
par défaut des ports proposées lors de l'installation des composants
SCVMM.
Les logiciels antivirus et pare-feu qui fonctionnent sur l'hôte ne
protègent pas les ordinateurs virtuels. Pour une protection optimale,
49
vous devez aussi installer ces logiciels sur chaque ordinateur virtuel
hébergé.
Limitez l'accès au système de fichiers de l'hôte. La liste de contrôles
d'accès (ACL) pour le partage de la bibliothèque ne doit contenir que
les administrateurs SCVMM, le compte ordinateur du serveur SCVMM
et des utilisateurs du libre-service (si approprié).
Lorsqu'un hôte ou un serveur de bibliothèque est ajouté, SCVMM y
installe un agent SCVMM. Ce processus ouvre une gamme de ports
DCOM et utilise le protocole SMB (Server Message Block). Si cela
pose un problème aux administrateurs système, l'agent SCVMM peut
être installé à la main sur l'hôte, puis découvert à distance à partir de
la console d'administration SCVMM en utilisant uniquement le port
Microsoft Windows® Remote Management (WinRM) (80 par défaut)
et le service de transfert intelligent en arrière-plan qui utilise le port
443 par défaut.
Pour créer et gérer des ordinateurs virtuels sur un hôte, un
administrateur doit posséder le rôle approprié et n'a pas besoin des
privilèges d'administration locale.
Supervision et rapports
Dans System Center Virtual Machine Manager, les fonctions de reporting
sont assurées par le pack d'administration Server Virtualization for System
Center Operations Manager 2007. Avant de pouvoir afficher et utiliser des
rapports, vous devez installer Operations Manager et déployer le pack
d'administration Server Virtualization. Les rapports sont produits par
Operations Manager mais peuvent être ouverts dans l'affichage Reporting
de la console d'administration SCVMM.
De plus, l'agent Operations Manager 2007 doit être installé sur chaque
ordinateur qui sera contrôlé.
Le rapport Virtualization Candidates (candidats à la virtualisation) est
particulièrement utile dans la planification d'un environnement virtuel. Il
permet d'identifier les ordinateurs physiques qui seraient de bons
candidats à la conversion en ordinateurs virtuels. Le rapport Virtualization
Candidates identifie des serveurs peu utilisés. Il affiche les valeurs
moyennes de certains compteurs de performance pour les processeurs, la
mémoire et l'utilisation des disques, ainsi que des informations sur le
matériel comme la fréquence du processeur, le nombre de processeurs et
la mémoire. Le rapport peut se limiter aux ordinateurs qui répondent à
certains critères de processeur et de mémoire. Enfin, il peut trier les
résultats. Le pack d'administration Server Virtualization découvre les
objets suivants :
Ordinateur virtuel géré par System Center Virtual Machine Manager
Agent System Center Virtual Machine Manager
Hôte géré par System Center Virtual Machine Manager
Groupe hôte System Center Virtual Machine Manager
50
Serveur moteur System Center Virtual Machine Manager
Serveur de bibliothèque System Center Virtual Machine Manager
Base de données System Center Virtual Machine Manager
Serveur libre-service System Center Virtual Machine Manager
Site Web libre-service System Center Virtual Machine Manager
Groupe d'administration System Center Virtual Machine Manager
Virtual Server 2005 R2
Virtual Machine
Ordinateur Virtual Machine
Planification des migrations physiques vers virtuelles
(P2V)
S'il est pris en charge par le système d'exploitation candidat, SCVMM
constituera la meilleure méthode pour faire migrer un environnement
physique vers un ordinateur virtuel. Dans SCVMM, une conversion P2V est
le processus par lequel un ordinateur physique opérationnel est copié sur
un ordinateur virtuel présentant quasiment les mêmes caractéristiques.
Une conversion P2V crée sous la forme de disques virtuels (VHD) les
images des disques physiques de l'ordinateur concerné. Ces disques
virtuels seront ensuite utilisés par le nouvel ordinateur virtuel. Cet
ordinateur virtuel aura la même identité que l'ordinateur physique
d'origine.
SCVMM peut effectuer une migration P2V en mode connecté (en ligne)
ou déconnecté (hors connexion) pour tous les systèmes d'exploitation pris
en charge. (Pour Windows 2000, seule une migration en mode
déconnecté est possible.) Une conversion en ligne utilise le service de
cliché instantané de volume (VSS) ; l'ordinateur source n'a pas besoin
d'être redémarré au cours du processus. Lors d'une conversion hors
connexion, l'ordinateur est redémarré dans Windows PE (Pre-installation
Environment) pour créer l'image des disques physiques.
Le tableau ci-dessous répertorie les migrations en ligne et hors connexion
prises en charge par System Center Virtual Machine Manager 2008 R2 :
Système d'exploitation P2V hors
connexion
P2V en
ligne
V2V
Windows Server® 2008 / Windows
Server® 2008 R2 avec le rôle
Hyper-V activé
Non Non Non
Windows Server® 2008 / Windows
Server® 2008 R2 sans le rôle
Hyper-V activé
Oui Oui Oui
Windows Server® 2003 SP1 ou
version suivante
Oui Oui Oui
51
Windows Server® 2003 édition 64
bits
Oui Oui Oui
Windows® 2000 Server SP4 Oui Non Oui
Windows® XP SP2 ou version
suivante
Oui Oui Oui
Windows® XP édition 64 bits Oui Oui Oui
Windows Vista® Oui Oui Oui
Windows Vista® 64 bits Oui Oui Oui
Windows® 7 Oui Oui Oui
Windows® 7 64 bits Oui Oui Oui
S'il existe des candidats à la consolidation qui utilisent Microsoft Windows
NT® 4.0 ou d'autres systèmes d'exploitation ou service packs qui ne sont
pas pris en charge par SCVMM, vous pouvez utiliser le Microsoft Virtual
Server 2005 Migration Toolkit (VSMT) ou des outils tiers qui gèrent ces
serveurs.
Conditions requises pour une migration
Avant de commencer une conversion P2V avec System Center Virtual
Machine Manager, passez en revue les limitations et les conditions
suivantes :
Besoins pour le serveur hôte. Une conversion P2V requiert que
l'hôte destination qui fera fonctionner l'ordinateur virtuel, utilise
Hyper-V ou Virtual Server 2005 R2 SP1.
Conversions P2V en ligne ou hors connexion. Lors d'une
conversion P2V hors connexion, l'ordinateur source est démarré en
mode Windows PE pour la création des disques physiques. Lors d'une
conversion en ligne, VSS est utilisé et l'ordinateur n'a pas à être
redémarré avant la migration.
Besoin en mémoire pour une conversion P2V hors connexion.
Une conversion P2V hors connexion demande au moins 512 Mo de
mémoire sur l'ordinateur source. Il est possible que vous ayez à
fournir des pilotes additionnels pour le réseau et le stockage afin que
WINPE puisse fonctionner correctement.
Besoins en mises à jour (si nécessaire). Une conversion P2V peut
nécessiter l'ajout de fichiers supplémentaires dans le cache des
correctifs interne à SCVMM. Dans ce cas :
Utilisez les informations fournies par l'assistant pour identifier les
mises à jour requises.
Téléchargez les fichiers des correctifs et copiez-les dans le
répertoire Patch Import du serveur SCVMM.
Cliquez sur Check Again pour continuer.
Secteurs défectueux qui ne peuvent être transférés. Les secteurs
défectueux d'un disque ne peuvent pas être transférés lors d'une
conversion P2V. Pour éviter une perte de données, utilisez un outil de
52
maintenance disque (comme chkdsk) sur l'ordinateur source avant de
commencer la migration.
Considérations à prendre en compte avant une migration
Pour assurer un maximum de chance de réussite aux migrations P2V, vous
devez prendre en compte certains points supplémentaires. C'est l'objet
des prochaines sections.
Test
La méthodologie mise en œuvre pour assurer une migration P2V doit être
soigneusement testée et documentée dans un environnement dans un
environnement de laboratoire avant d'être exploitée dans un
environnement de production. Vérifiez que les points suivants sont testés
et documentés :
Préparation du serveur avant la migration. Testez et documentez
les procédures qui vérifient que le serveur candidat à une migration
P2V est en bon état de fonctionnement : utilisez chkdsk et defrag, et
effectuez les diagnostics applicables au matériel.
Configuration de System Center Virtual Machine Manager.
Vérifiez que la configuration recommandée pour System Center
Virtual Machine Manager ainsi que son emplacement répondent à
vos besoins.
Reprise après sinistre. Préparez des plans de restauration en cas de
migration P2V en échec, ou pour remettre le serveur en état de
marche sur le serveur physique source dans l'éventualité de
complications découvertes après la migration.
Utilisation d'outils P2V. Certains scénarios P2V incluent des
systèmes d'exploitation qui ne sont pas directement pris en charge
par System Center Virtual Machine Manager. Ils nécessitent alors
l'utilisation d'autres outils comme VSMT ou des outils tiers pour
assurer la migration P2V.
Ordre de réalisation d'une migration
Démarrez dans le centre de données avec les candidats P2V qui
présentent le plus de chance de réussite. Cette approche mettra l'équipe
informatique en confiance avant d'attaquer les sites distants, les agences,
et d'autres scénarios plus complexes.
Lors du traitement des sites distants et des agences, vérifiez que le
matériel requis et les rôles serveur sont en place et opérationnels avant
d'envoyer l'équipe de virtualisation sur le site. Prenez une marge de
sécurité dans les délais de réalisation.
Continuité métier
Bien qu'une migration P2V ne soit pas destructrice pour les données sur
l'ordinateur source, prenez toutes les précautions nécessaires pour que
l'application installée sur ce système puisse être restaurée en cas de
53
problème au cours de la migration. Assurez-vous que l'équipe de la
virtualisation est capable d'effectuer toutes les opérations nécessaires (et
documentées) pour restaurer un système en cas d'incident majeur.
Vérifiez que les ordinateurs source sont complètement sauvegardés avant
toute tentative de migration.
Maintenez le serveur physique source en place pendant un certain temps
après la migration. Il pourra servir éventuellement de serveur de secours
en cas de problème. Généralement, une durée de deux semaines est
suffisante. Une période plus longue peut être requise en cas de forte
activité qui pourrait produire un problème de performance imprévu.
Test d'acceptation par les utilisateurs
Avant de mettre un ordinateur virtuel en production, vérifiez auprès d'un
panel d'utilisateurs que la migration est réussie est donne toute
satisfaction. Dans certains cas, il est nécessaire d'effectuer une migration
P2V et de laisser le serveur source en service pendant une courte période
après la migration, le temps d'obtenir l'acceptation des utilisateurs.
Dans le cas d'applications complexes, critiques ou sensibles, il peut être
nécessaire de réaliser la migration P2V puis d'installer l'ordinateur virtuel
dans un environnement de laboratoire pour effectuer une validation
approfondie.
Si le candidat à la virtualisation est un contrôleur de domaine, soyez
conscient du risque d'un retour en arrière USN (Update Sequence
Number) si le serveur ne peut pas immédiatement être mis en ligne.
Planification de la communication
Utilisez les fenêtres de maintenance prévues pour réaliser des migrations
P2V. Identifiez tous les utilisateurs du service ou de l'application concerné,
et informez-les longtemps à l'avance de la migration prévue. Par
exemple :
Lors de la virtualisation de contrôleurs de domaine Active Directory,
informez tous les utilisateurs de ce site. lorsque c'est applicable,
vérifiez que le site Active Directory de secours est disponible et
fonctionne. Vérifiez aussi que le site à migrer n'est pas un site de
secours vis-à-vis d'un autre site.
Pour les applications métier, assurez-vous d'avoir prévenu tous les
utilisateurs et les personnes concernées.
Pour les autres services, comme le service fichiers et impression,
avertissez tous les utilisateurs qui les utilisent.
Les plans de migration doivent être communiqués au personnel du
service d'assistance (help desk) et aux exploitants du réseau. Tout
problème relatif à une migration doit être résolu rapidement.
54
SYSTEM CENTER VIRTUAL MACHINE
MANAGER SELF SERVICE PORTAL 2.0
(VMMSSP)
Composants VMMSSP
Cette section donne un bref aperçu des composants du portail en libre-
service VMMSSP et quelques informations sur chacun d'eux.
Site Web VMMSSP
Composant Web qui donne accès au portail en libre-service. Le site Web
VMMSSP permet aux administrateurs de réaliser différentes tâches
comme : regrouper tous les actifs informatiques dans le portail en libre-
service, étendre les actions des ordinateurs virtuels, créer des demandes
pour les divisions et l'infrastructure, valider et approuver les demandes,
mettre en service les ordinateurs virtuels (via la fonction en libre-service
correspondante). Les administrateurs peuvent également utiliser le site
Web VMMSSP pour consulter toutes les informations relatives à ces
opérations.
Base de données VMMSSP
Base de données SQL Server où résident les informations concernant les
actifs configurés, les divisions et les demandes, ainsi que tout ce qui a été
mis en service sur les différentes divisions. La base de données contient le
langage XML qui code les actions standards et personnalisées menées sur
les ordinateurs virtuels, ainsi que les paramètres de configuration du
portail en libre-service.
Serveur VMMSSP
Service Windows qui exécute, sur les ordinateurs virtuels, les actions
standards et personnalisées que l'utilisateur demande via le site Web
VMMSSP. Le service utilise un port TCP Windows Communication
Foundation (WCF) pour écouter les communications en provenance des
clients, et un environnement d'exécution Windows Workflow Foundation
(WF). Avec WF, le composant serveur exécute les séquences de tâches
concernant les ordinateurs virtuels. Vous pouvez optimiser les
performances du composant serveur en utilisant des paramètres
disponibles dans le portail en libre-service ou dans des fichiers de
configuration ; ces paramètres contrôlent le nombre d'opérations qui
peuvent être exécutées simultanément.
Tableau de bord du reporting VMMSSP
Le portail VMMSSP propose un tableau de bord de reporting basé sur
Windows SharePoint Services. Le tableau de bord emploie des WebParts
SharePoint Dashboard Configuration et Viewer pour ses fonctions de
reporting. Un tableau de bord est fourni par défaut et vous pouvez créer
55
des rapports personnalisés.
Remarque
Windows SharePoint Services 3.0 SP2 est nécessaire au
fonctionnement. Toutefois, SharePoint Server 2007 est une autre
configuration possible et prise en charge.
Configuration matérielle requise
Le tableau ci-dessous décrit les configurations matérielles minimale et
recommandée.
Composant matériel Au minimum Recommandé
Mémoire vive (RAM) 2 Go 4 Go
Espace libre sur le
disque dur
50 Go 50 Go
Configuration logicielle requise
Avant d'installer les composants du portail en libre-service, installez et
configurez les logiciels suivants sur l'ordinateur.
Logiciels Commentaires
Système
d'exploitation :
Windows Server®
2008 R2
Les versions Windows Server 2008 R2 Enterprise
Edition et Windows Server 2008 R2 Datacenter
Edition sont prises en charge.
Windows Server
Internet Information
Services (IIS) 7.0
Vous devez ajouter le rôle de serveur Web (IIS), puis
installez les services de rôle suivants :
Compatibilité avec la métabase de données
IIS 6
Contenu statique
Document par défaut
ASP.NET
Extensibilité .NET
Extensions ISAPI
Filtres ISAPI
Filtrage des demandes
56
Utilisez l'authentification Windows intégrée (NTLM
ou Kerberos). Désactivez l'authentification anonyme.
Pour plus d'informations, voir Configurer Windows
Authentification dans la documentation IIS.
Utilisez le mode de compatibilité IIS v6.0.
Microsoft .NET
Framework 3.5 SP1
Windows
PowerShell™ 2.0
Important : Si vos scripts d'extensibilité mettent en
jeu des composants enfichables Windows
PowerShell spécifiques, installez-les en même temps
que le composant serveur du toolkit.
Remarque : Si la stratégie d'exécution de Windows
PowerShell est définie à Restricted, l'Assistant
Installation fait passer ce paramètre à AllSigned.
Files d’attente de
messages Microsoft
(MSMQ)
Console
Administrateur
VMM 2008 R2
SQL Server 2008 Les versions SQL Server 2008 Enterprise (64 bits) et
SQL Server 2008 Standard (64 bits) sont prises en
charge.
Modèles d'architecture VMMSSP
Architecture à serveur unique
Cette architecture comptant un seul serveur est représentée ci-dessous.
L'architecture se compose d'un seul serveur hôte exploitant Windows
Server 2008 R2 (pour le serveur physique ou un ordinateur virtuel) avec
les composants console d'administration SCVMM 2008 R2, SQL Server
2008 et SSP installés.
57
Cette configuration est suffisante dans des environnements de test et de
développement ou pour de petites agences.
Architecture à quatre serveurs
Cette architecture comptant quatre serveurs est représentée ci-dessous.
Elle se compose de quatre serveurs Windows Server 2008 R2 (pour les
serveurs physiques ou les ordinateurs virtuels) avec les composants
console d'administration SCVMM 2008 R2 et serveur installés sur le
premier système, SQL Server 2008 sur le deuxième, Windows SharePoint
Services 3.0 SP2 ou Windows SharePoint Server 2007 sur le troisième et
les composants Web SSP sur le quatrième.
58
Cette architecture est mieux adaptée à des environnements plus
importants et permet de monter en charge si nécessaire.
Remarques concernant la sécurité
La sécurisation du portail en libre-service implique les tâches suivantes :
Comprendre et planifier les rôles des utilisateurs par défaut et
personnalisés qui sont définis dans le portail en libre-service.
Planifier et préparer les comptes de service.
Comprendre les ports et les protocoles requis pour établir des canaux
de communication entre différents portails en libre-service.
Renforcer le serveur Web qui exécutera le composant site Web
VMMSSP.
Comptes et groupes pour les rôles utilisateurs SSP
Le portail en libre-service propose par défaut quatre rôles utilisateurs ;
vous pouvez en créer d'autres. Le portail utilise l'authentification
Windows. Il est donc possible de diffuser ces rôles utilisateurs via les
groupes de sécurité et les comptes Active Directory. Prévoyez le mappage
entre les groupes de sécurité et les rôles des utilisateurs. En particulier,
identifiez les groupes de sécurité et les comptes utilisateurs que vous
ajouterez au rôle utilisateur prédéfini Admin DCIT. Les membres de ce rôle
sont des super-administrateurs : ils peuvent réaliser toutes les tâches
59
possibles sur le site Web VMMSSP. Vous pouvez ajouter des membres au
rôle Admin DCIT lors de l'installation, ou par la suite, lorsque vous
configurerez le portail en libre-service.
Comptes de service
Si vous utilisez un compte de domaine et que, pour votre objet stratégie
de groupe (GPO) de domaine, la stratégie d’expiration du mot de passe
est définie par défaut comme il convient, vous devrez soit changer les
mots de passe sur les comptes de service en fonction d'un calendrier, soit
utiliser des comptes dont les mots de passe n'expirent jamais.
Exceptions pour le pare-feu
Si le Pare-feu Windows est configuré sur les ordinateurs sur lesquels vous
avez prévu d'installer le portail en libre-service, pensez à ajouter des
exceptions au Pare-feu de ces ordinateurs afin que le portail puisse
fonctionner correctement.
Si vous utilisez un pare-feu d'un autre fournisseur, consultez sa
documentation.
Renforcer le site Web du portail en libre-service
Le fait d'installer le composant site Web VMMSSP crée dans IIS un site
Web dédié au portail du libre-service. Cette section précise les
recommandations à respecter pour renforcer la sécurité de ce site Web.
Configuration de SSL pour le portail en libre-service
Pour chiffrer les communications entre le client et le composant site Web
VMMSSP, vous devez configurer la sécurité SSL sur votre serveur Web.
Vous pouvez obtenir le certificat dont SSL a besoin selon une des
méthodes ci-dessous, en fonction de l'utilisation du portail :
Si le site Web est sur l'intranet de votre entreprise, sans accès public,
le certificat peut être fourni par l'infrastructure à clé publique (PKI) qui
existe dans votre entreprise.
Si les utilisateurs peuvent accéder au portail depuis Internet,
Microsoft vous conseille d'obtenir un certificat auprès d'une autorité
de certification.
Si vous utilisez IIS 7.0, consultez Sécuriser les communications avec Secure
Socket Layer (SSL) dans la documentation IIS pour en savoir plus.
Désactivation des gestionnaires ISAPI inutiles
Lorsque vous installez le composant site Web VMMSSP, IIS active les
gestionnaires et les filtres par défaut pour des extensions courantes
comme .soap, .xoml et .asmx. Pour éviter toute exposition inutile à des
risques potentiels de sécurité, désactivez les gestionnaires que le
composant Web n'utilise pas.
Le tableau ci-dessous répertorie les gestionnaires ISAPI dont le
composant site Web VMMSSP a besoin.
60
OPTIONSVerbHandler
PageHandlerFactory-ISAPI-2.0
PageHandlerFactory-ISAPI-2.0-64
TRACEVerbHandler
WebServiceHandlerFactory-ISAPI-2.0
WebServiceHandlerFactory-ISAPI-2.0-64
StaticFile
AXD-ISAPI-2.0
AXD-ISAPI-2.0-64
La procédure suivante explique comment désactiver les gestionnaires
ISAPI dans IIS 7.0.
Important
Pour éviter des effets indésirables dans d'autres sites Web, prenez
soin de ne mettre à jour que les gestionnaires pour le site Web
configuré pour le portail en libre-service.
Désactiver les gestionnaires ISAPI pour le portail en libre-
service
1. Sur le serveur Web, dans Outils d'administration, ouvrez le
Gestionnaire Internet Information Services (IIS).
2. Développez Sites, et naviguez jusqu'au site Web du portail en libre-
service.
3. Dans le volet Afficher les fonctionnalités, sous IIS, ouvrez Mappages
de gestionnaire.
4. Pour chaque gestionnaire qui n'est pas répertorié dans le tableau
précédent, sélectionnez-le, cliquez sur Supprimer et confirmez en
cliquant sur Oui.
Supervision et rapports
Tableau de bord VMMSSP
Le tableau de bord Microsoft® System Center Virtual Machine Manager
Self-Service Portal (VMMSSP) Dashboard est une application Windows®
61
SharePoint® Services qui regroupe sur une seule page Web plusieurs
ensembles de statistiques du portail. Les utilisateurs peuvent consulter les
données sous la forme de graphiques sectoriels, d'histogrammes ou de
jauges Dundas.
Le tableau de bord VMMSSP complète le portail en libre-service Virtual
Machine Manager 2008 R2 en fournissant une vue centrale et unique des
données relatives aux infrastructures, aux ressources, aux ordinateurs
virtuels et à la refacturation. Pour chacun de ces domaines, le tableau de
bord présente des informations d'état détaillées. Le tableau de bord
VMMSSP aide les directeurs informatiques à prendre des décisions bien
fondées, à réduire les coûts des services et à améliorer la productivité
globale du centre de données.
Le tableau de bord s'appuyant sur Windows SharePoint Services, les
utilisateurs peuvent y accéder sans passer par le portail en libre-service.
62
Ressources supplémentaires
Vous trouverez ci-dessous d'autres ressources qui faciliteront la
virtualisation des serveurs et accéléreront le déploiement.
Accélérateurs de solutions Microsoft
Microsoft propose des outils et des conseils pour vous aider à résoudre
d'éventuels problèmes de déploiement, de planification et d'exploitation.
Ils sont offerts gracieusement et totalement pris en charge.
Ensemble d'outils pour Microsoft Assessment and Planning
(MAP)
Téléchargez cet outil d'inventaire et d'évaluation réseau pour déterminer
les candidats à la virtualisation pour Windows Server 2008 R2 Hyper-V et
la virtualisation des applications. Si votre client travaille actuellement avec
VMware, la boîte à outils inclut désormais une fonctionnalité de
découverte VMware identifiant les serveurs déjà virtualisés via VMware
qu'il sera possible de gérer avec System Center Virtual Machine Manager
ou de faire migrer vers Hyper-V.
Pour en savoir plus :
http://technet.microsoft.com/en-
us/solutionaccelerators/dd537570.aspx?SA_CE=VIRT-MAP-WEB-SAT-
2009-07-13
Offline Virtual Machine Servicing Tool 2.1
Le pack d'outils Offline Virtual Machine Servicing Tool 2.1 propose des
conseils gratuits et testés et permet d'orchestrer la mise à jour
automatique des ordinateurs virtuels hors connexion sans mettre en péril
votre infrastructure informatique. Ce pack conjugue le modèle de
programmation Windows Workflow à l'interface Windows PowerShell™
pour déployer automatiquement des groupes d'ordinateurs virtuels en
mode de maintenance, leur appliquer les dernières mises à jour de
sécurité et les remettre hors connexion.
Pour en savoir plus :
http://technet.microsoft.com/en-
us/library/cc501231.aspx?SA_CE=OVMST21-Release-VIRTPROD-2009-12-
07
Guides de planification et de conception de l'infrastructure
pour la virtualisation
Simplifiez votre étape de conception en vous aidant des guides de
planification et de conception de l'infrastructure pour la virtualisation des
postes de travail. Chaque guide concerne une technologie ou un scénario
de virtualisation spécifique, explique les décisions stratégiques à prendre
en termes d'architecture ainsi que les options possibles, et donne la
possibilité de valider les décisions de conception de façon à satisfaire les
63
besoins métier et informatiques.
Pour en savoir plus :
http://technet.microsoft.com/en-us/solutionaccelerators/ee395429.aspx
Microsoft.com
Outre les ressources ci-dessus, visitez le site http://www.microsoft.com
pour trouver des informations complémentaires sur les technologies de
virtualisation de serveurs de Microsoft.
© 2010 Microsoft Corporation. Tous droits réservés. Les informations
contenues dans ce document représentent l'opinion actuelle de Microsoft
Corporation sur les points cités à la date de publication. Ces informations
peuvent être modifiées sans préavis. Ce document est fourni « TEL QUEL »
sans aucune garantie d'aucune sorte. Ces informations ne doivent pas
être considérées comme un engagement de la part de Microsoft et
Microsoft n'en garantit pas l’exactitude. Les informations contenues dans
ce document représentent l'opinion actuelle de Microsoft Corporation sur
les points cités. MICROSOFT EXCLUT TOUTE GARANTIE, EXPRESSE,
IMPLICITE OU STATUTAIRE, EN CE QUI CONCERNE CE DOCUMENT.
Le cas échéant, les descriptions des produits des autres entreprises
mentionnées dans ce document sont fournies pour vous rendre service.
Ces références n'impliquent aucune recommandation ni soutien de la part
de Microsoft. Microsoft ne peut garantir l'exactitude de ces informations
et les produits peuvent évoluer au fil du temps. Ces descriptions ne visent
qu'à vous faire comprendre les offres, elles n'abordent en aucun cas la
question en détail. Pour obtenir une description précise de ces produits,
contactez les fabricants respectifs.
