HYPER-V CLOUD GUIDES DE DÉPLOIEMENT MODULE 1: ARCHITECTURE ET DIMENSIONNEMENT

HYPER-V CLOUD GUIDES DE DÉPLOIEMENT MODULE 1: ARCHITECTURE ET DIMENSIONNEMENT

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. 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. 2

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 3 Planification des migrations physiques vers virtuelles (P2V)... 50

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 4

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 5

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. 6

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 libreservice 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. 7

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 8

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é Nombre de processeurs logiques (PL) Mémoire physique Windows Server 2008 R2 Standard Edition Windows Server 2008 R2 Enterprise Edition 64 PL 64 PL 64 PL Windows Server 2008 R2 Datacenter Edition 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 9

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 Windows HPC Server 2008 x x x SUSE Linux Enterprise Server 10 x86 x64 SP1/SP2 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 Windows XP Pro x86 SP2 x x x x 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. 10

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 11

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 12 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

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. 13

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. 14

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) Fibre optique (2 GFC) SATA (SATA II) SCSI (U320) SAS Fibre optique (4 GFC) Fibre optique (8 GFC) iscsi (Ethernet à 10 Gbit/s) 125 Mo/s 212,5 Mo/s 300 Mo/s 320 Mo/s 375 Mo/s 425 Mo/s 850 Mo/s 1250 Mo/s Recommandation 15 Une architecture SATA II ou SAS est recommandée pour un serveur hôte unique (avec préférence pour SAS).

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. 16

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. 17

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 18

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 19

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. 20