Guide de considérations en matière de conception d'une structure de virtualisation

 

À qui ce guide s'adresse-t-il ? Aux professionnels de l'informatique travaillant dans des moyennes à grandes entreprises qui sont responsables de la conception d'une structure de virtualisation prenant en charge de nombreux ordinateurs virtuels. Dans la suite de ce document, ces personnes sont appelées administrateurs de structure. Les personnes qui administrent les ordinateurs virtuels hébergés sur la structure sont appelées administrateurs d'ordinateurs virtuels, mais elles ne constituent pas le public cible de ce document. Au sein de votre organisation, vous pouvez avoir ces deux rôles.

En quoi ce guide peut-il vous aider ? Vous pouvez utiliser ce guide pour comprendre comment concevoir une structure de virtualisation capable d'héberger de nombreux ordinateurs virtuels dans votre organisation. Dans ce document, l'ensemble formé par la collection de serveurs et d'hyperviseurs, et par le matériel de stockage et de mise en réseau utilisé pour héberger les ordinateurs virtuels dans une organisation, est appelé une structure de virtualisation. Le graphique suivant illustre un exemple de structure de virtualisation.

Figure 1 :Exemple de structure de virtualisation

Remarque : chacun des schémas de ce document existe dans un onglet distinct du document Guide des considérations en matière de conception d'une structure de virtualisation - Diagrammes que vous pouvez télécharger en cliquant sur chaque intitulé de figure.

Bien que toutes les structures de virtualisation contiennent des serveurs pour le stockage et l'hébergement d'ordinateurs virtuels, en plus des réseaux qui les connectent, dans chaque entreprise, la conception d'une structure de virtualisation sera probablement différente de l'exemple illustré dans la Figure 1 en raison d'exigences différentes.

Ce guide détaille une série d'étapes et de tâches que vous pouvez suivre pour vous aider à concevoir une structure de virtualisation qui répond aux exigences uniques de votre organisation. Au fil des étapes et des tâches, il présente les options qui sont à votre disposition e matière de technologies et de fonctionnalités pour répondre aux exigences de niveau fonctionnel et de qualité de service (comme la disponibilité, l'évolutivité, les performances, la facilité de gestion et la sécurité).

Même si ce document peut vous aider à concevoir une structure de virtualisation facile à gérer, il ne traite pas des considérations et des options de conception du point de vue de la gestion et de l'exploitation de la structure de virtualisation avec un produit tel que Microsoft System Center 2012 ou System Center 2012 R2. Pour plus d'informations, voir System Center 2012 dans la bibliothèque TechNet.

Ce guide vous aide à concevoir une structure de virtualisation avec Windows Server 2012 R2, Windows Server 2012 et du matériel sans préférence particulière. Certaines fonctionnalités décrites dans ce document sont propres à Windows Server 2012 R2 et sont évoquées tout au long de ce document.

Hypothèses : vous avez de l'expérience dans le déploiement d'Hyper-V, d'ordinateurs virtuels, de réseaux virtuels, de services de fichiers Windows Server et du clustering avec basculement, de même que dans le déploiement de serveurs physiques, d'équipements de stockage et d'équipements réseau.

Ressources supplémentaires

Avant de concevoir une structure de virtualisation, les informations des documents suivants pourront vous être utiles :

• Architecture de référence de Microsoft Cloud Services Foundation – Modèle de référence

• Architecture de référence de Microsoft Cloud Services Foundation – Principes, concepts et modèles

Ces deux documents présentent les concepts fondamentaux qui sont observés dans de multiples conceptions de structure de virtualisation et peuvent servir de base à toute conception de structure de virtualisation.

Commentaires : pour nous faire part de vos commentaires sur ce document, envoyez un e-mail à l'adresse virtua@microsoft.com.

Vue d'ensemble des considérations en matière de conception

La suite de ce document présente un ensemble d'étapes et de tâches que vous pouvez réaliser pour concevoir une structure de virtualisation répondant parfaitement à vos besoins. Ces étapes sont présentées dans un ordre précis. À mesure que vous progresserez, vous serez peut-être amené à revenir sur des décisions que vous aurez prises à des étapes antérieures en raison de conflits. Néanmoins, tout est fait pour vous alerter des conflits de conception potentiels tout au long de ce document.

Vous n'arriverez à la conception répondant le mieux à vos besoins qu'après être repassé sur les différentes étapes autant de fois que nécessaire pour intégrer l'ensemble des considérations présentées dans ce document.

Étape 1 : Déterminer les besoins en ressources des ordinateurs virtuels

Étape 2 : Planifier la configuration des ordinateurs virtuels

Étape 3 : Planifier les groupes hôtes de virtualisation de serveur

Étape 4 : Planifier les hôtes de virtualisation de serveur

Étape 5 : Planifier les concepts d'architecture de la structure de virtualisation

Étape 6 : Planifier les caractéristiques de capacité initiales

Étape 1 : Déterminer les besoins en ressources des ordinateurs virtuels

La première étape de conception d'une structure de virtualisation consiste à déterminer les besoins en ressources des ordinateurs virtuels qui seront hébergés par la structure. La structure doit inclure le matériel physique nécessaire pour répondre à ces besoins. Les besoins en ressources des ordinateurs virtuels sont dictés par les systèmes d'exploitation et les applications qui s'exécutent dans ces ordinateurs virtuels. Dans la suite de ce document, la combinaison du système d'exploitation et des applications qui s'exécutent dans un ordinateur virtuel est appelée une charge de travail. Les tâches de cette étape vous aident à définir les besoins en ressources de vos charges de travail.

Conseil : au lieu d'évaluer les besoins en ressources de vos charges de travail existantes, puis de concevoir une structure de virtualisation capable de les prendre en charge, vous pouvez décider de concevoir une structure de virtualisation capable de répondre aux besoins des charges de travail les plus courantes. Vous pourrez ensuite traiter les charges de travail ayant des besoins spécifiques.

Ce type de structures de virtualisation est par exemple proposé par les fournisseurs de cloud public, comme Microsoft Azure (Azure). Pour plus d'informations, voir Tailles de machines virtuelles et de services cloud pour Microsoft Azure.

Les fournisseurs de cloud public proposent généralement une sélection de configurations des ordinateurs virtuels qui répondent aux besoins de la plupart des charges de travail. Si vous décidez de suivre cette approche, vous pouvez passer directement à l'Étape 2 : Planifier la configuration des ordinateurs virtuels de ce document. Autres avantages de cette approche :

• Lorsque vous décidez de migrer une partie de vos ordinateurs virtuels locaux vers un fournisseur de cloud public, si les types de configuration de vos ordinateurs virtuels sont similaires à ceux de votre fournisseur public, la migration des ordinateurs virtuels sera plus facile que si les types de configuration sont différents.

• Vous pourrez plus facilement prévoir les besoins en capacité et mettre en place un système d'approvisionnement en libre-service pour votre structure de virtualisation. Cela signifie que les administrateurs d'ordinateurs virtuels au sein de l'organisation peuvent automatiquement auto-approvisionner de nouveaux ordinateurs virtuels sans l'intervention des administrateurs de la structure.

Tâche 1 : Déterminer les besoins en ressources des charges de travail

Chaque charge de travail a besoin des ressources suivantes. La première chose que vous souhaiterez faire est de répondre aux questions suivantes pour chacune de vos charges de travail.

• Processeur : Quelle vitesse ou architecture de processeur (Intel ou AMD) ou quel nombre de processeurs est requis ?

• Réseau : En gigabits par seconde (Gbits/s), quelle bande passante réseau est requise pour le trafic entrant et sortant ? Quelle latence du réseau maximale la charge de travail peut-elle tolérer pour fonctionner correctement ?

• Stockage : De combien de gigaoctets (Go) de stockage les fichiers d'application et de système d'exploitation de la charge de travail ont-ils besoin ? De combien de gigaoctets la charge de travail a-t-elle besoin pour ses données ? De combien d'opérations d'entrées/sorties (E/S) par seconde dans son stockage la charge de travail a-t-elle besoin ?

• Mémoire : En gigaoctets (Go), quelle est la quantité de mémoire requise par la charge de travail ? La charge de travail prend-elle en charge l'accès mémoire non uniforme ?

Outre ces besoins en ressources, il est important de trouver une réponse aux questions suivantes :

• Les besoins en ressources correspondent-ils à des besoins minimaux ou à des besoins recommandés ?

• Quels sont les besoins maximum et moyens pour chaque besoin matériel sur une base horaire, quotidienne, mensuelle ou annuelle ?

• Quel est le nombre de minutes d'arrêt par mois acceptable pour la charge de travail et ses données ? Pour répondre à cette question, prenez en considération les éléments suivants :

  • La charge de travail s'exécute-t-elle sur un seul ordinateur virtuel ou s'exécute-t-elle sur une collection d'ordinateurs virtuels agissant comme un seul, par exemple une collection de serveurs réseau à charge équilibrée exécutant tous la même charge de travail ? Si vous utilisez une collection de serveurs, le temps d'arrêt exprimé doit clairement indiquer s'il s'applique à chaque serveur de la collection, à tous les serveurs de la collection ou au niveau de la collection.

  • Heures de travail et heures en dehors des heures de travail. Par exemple, si personne n'utilisera la charge de travail entre 21 h 00 et 06 h 00, mais qu'elle doit impérativement être disponible le plus possible entre 6 h 00 et 21 h 00, avec un temps d'arrêt acceptable par mois de dix minutes seulement, cette exigence doit être spécifiée.

• Quelle est la perte de données acceptable en cas d'échec inattendu de l'infrastructure virtuelle ? Celle-ci est exprimée en minutes car les stratégies de réplication de l'infrastructure virtuelle reposent généralement sur le temps. Bien que l'exigence de zéro perte de données soit souvent exprimée, sachez que pour y parvenir, le coût est élevé et que cela s'accompagne souvent de performances réduites.

• Les fichiers de la charge de travail et/ou leurs données doivent-ils être chiffrés sur disque et les données de la charge de travail doivent-elles être chiffrées entre les ordinateurs virtuels et leurs utilisateurs finaux ?

Les options suivantes sont disponibles pour déterminer ces besoins en ressources.

Option	Avantages	Inconvénients
Évaluer et consigner manuellement l'utilisation des ressources	Possibilité de faire un rapport sur tout ce que vous choisissez	Peut exiger un effort manuel important
Utiliser la boîte à outils Microsoft Assessment and Planning Toolkit pour évaluer et consigner automatiquement l'utilisation des ressources	Permet de créer différents rapports d'utilisation des ressources Ne nécessite pas l'installation d'un agent sur la charge de travail	Les rapports peuvent ou non fournir toutes les données dont vous avez besoin

Remarque : si vous choisissez de déterminer manuellement vos besoins en ressources, vous pouvez télécharger le Guide des considérations en matière de conception d'une structure de virtualisation - Feuilles de calcul et entrez les informations dans la feuille de calcul Workload resource req. (Besoins en ressources de la charge de travail). Ce guide contient les feuilles de calcul référencées dans ce document.

Tâche 2 : Définir les caractéristiques des charges de travail

Vous pouvez définir autant de caractéristiques que vous le souhaitez pour les charges de travail de votre environnement. Les exemples suivants ont été choisis car chacun requiert une configuration différente des composants de la structure de virtualisation, qui seront abordés plus en détail dans les étapes ultérieures.

• Sans état : Les charges de travail sans état n'écrivent aucune information unique sur leur disque dur local une fois qu'elles sont initialement approvisionnées et que des noms d'ordinateur et des adresses réseau uniques leur ont été attribués. Elles peuvent toutefois écrire des informations uniques dans un élément de stockage distinct, comme une base de données. Les charges de travail sans état sont idéalement exécutées sur une structure de virtualisation car une image « maître » peut être créée pour l'ordinateur virtuel. Cette image peut facilement être copiée et démarrée dans la structure de virtualisation pour ajouter des ressources à la charge de travail ou pour remplacer rapidement un ordinateur virtuel devenu indisponible suite à une défaillance d'un hôte de virtualisation. Un serveur web exécutant une application web frontale est un exemple de charge de travail sans état.

• Avec état : Les charges de travail avec état écrivent des informations uniques sur leur disque dur local une fois qu'elles sont initialement approvisionnées et que des noms d'ordinateur et des adresses réseau uniques leur ont été attribués. Elles peuvent également écrire des informations uniques dans un élément de stockage distinct, comme une base de données. Les charges de travail avec état requièrent généralement des stratégies d'approvisionnement et de montée en puissance plus complexes que les charges de travail sans état. Les stratégies de haute disponibilité pour les charges de travail avec état peuvent exiger le partage d'état avec d'autres ordinateurs virtuels. Le moteur de base de données SQL Server est un exemple de charge de travail avec état.

• Avec état partagé : Charges de travail avec état qui requièrent un état partagé avec d'autres ordinateurs virtuels. Ces charges de travail utilisent souvent le clustering avec basculement dans Windows Server pour obtenir une haute disponibilité, ce qui nécessite l'accès au stockage partagé. Microsoft System Center Virtual Machine Manager est un exemple de charge de travail avec état partagé.

• Autre : Caractérise les charges de travail qui peuvent ne pas s'exécuter du tout, ou ne pas s'exécuter de façon optimale, sur une structure de virtualisation. Ces charges de travail présentent les exigences suivantes :

  • Accès à des périphériques physiques. Par exemple, une charge de travail de téléphonie qui communique avec une carte réseau téléphonique dans un hôte physique.

  • Besoins en ressources beaucoup plus importants que la plupart des autres charges de travail. Par exemple, une application en temps réel qui a besoin d'un temps de latence inférieur à une milliseconde entre les couches d'application.

  Ces applications peuvent ou non s'exécuter sur votre structure de virtualisation ou elles peuvent avoir besoin de matériel ou d'une configuration très spécifique que n'ont pas la plupart de vos autres charges de travail.

Remarque : vous pouvez définir les caractéristiques de vos charges de travail dans la feuille de calcul Settings (Paramètres), puis sélectionner la caractéristique appropriée pour chaque charge de travail dans la feuille de calcul Workload resource req. (Besoins en ressources de la charge de travail).

Étape 2 : Planifier la configuration des ordinateurs virtuels

Dans cette étape, vous allez définir les types d'ordinateurs virtuels dont vous aurez besoin pour répondre aux besoins en ressources et aux caractéristiques des charges de travail que vous avez définies à l'Étape 1.

Tâche 1 : Définir la configuration de calcul

Dans cette tâche, vous allez déterminer la quantité de mémoire et de processeurs requise par chaque ordinateur virtuel.

Tâche 1a : Définir le type de génération des ordinateurs virtuels

Windows Server 2012 R2 a introduit les ordinateurs virtuels de 2e génération. Les ordinateurs virtuels de 2e génération prennent en charge des fonctionnalités matérielles et de virtualisation qui ne sont pas prises en charge par les ordinateurs virtuels de 1e génération. Il est important de prendre la bonne décision car une fois l'ordinateur virtuel créé, son type ne peut pas être modifié.

Un ordinateur de 2e génération offre les nouvelles fonctionnalités suivantes :

• démarrage PXE avec une carte réseau standard ;

• démarrage à partir d'un disque dur virtuel SCSI ;

• démarrage à partir d'un DVD virtuel SCSI ;

• démarrage sécurisé (activé par défaut) ;

• prise en charge du microprogramme UEFI.

Les ordinateurs virtuels de 2e génération prennent en charge les systèmes d'exploitation invités suivants :

• Windows Server 2012 R2

• Windows Server 2012

• Versions 64 bits de Windows 8.1

• Versions 64 bits de Windows 8

• Versions spécifiques de Linux. Pour obtenir la liste des distributions et des versions qui prennent en charge les ordinateurs virtuels de 2e génération, voir Ordinateurs virtuels Linux sur Hyper-V.

Le tableau suivant répertorie les avantages et les inconvénients des ordinateurs virtuels de 1e et de 2e génération.

Option	Avantages	Inconvénients
1e génération	Prise en charge de tous les systèmes d'exploitation invités Hyper-V pris en charge Compatibilité avec les machines virtuelles Azure Prise en charge des versions précédentes d'Hyper-V	Aucun accès aux nouvelles fonctionnalités des ordinateurs virtuels
2e génération	Prise en charge des nouvelles fonctionnalités Légère amélioration du temps de démarrage des ordinateurs virtuels et du temps d'installation des invités Utilisation de périphériques SCSI ou d'une carte réseau standard pour démarrer un ordinateur virtuel Empêche l'exécution des microprogrammes, systèmes d'exploitation ou pilotes UEFI non autorisés lorsque le démarrage sécurisé est activé	Prise en charge limitée des systèmes d'exploitation invités Absence de compatibilité avec les machines virtuelles Azure Aucune prise en charge de RemoteFX Aucune prise en charge des disquettes virtuelles

Important : les ordinateurs virtuels de 2e génération Linux ne prennent pas en charge le démarrage sécurisé. Lorsque vous créez un ordinateur virtuel sur lequel vous voulez installer Linux, vous devez désactiver le démarrage sécurisé dans les paramètres de l'ordinateur virtuel.

Informations complémentaires :

Vue d'ensemble des ordinateurs virtuels de 2e génération

Tâche 1b : Définir la mémoire

Vous devez planifier la taille de la mémoire de vos ordinateurs virtuels comme vous le faites habituellement pour les applications serveur sur un ordinateur physique. Elle doit permettre de gérer la charge prévue aux heures normales et aux heures de pointe. Une mémoire insuffisante peut augmenter de manière significative les temps de réponse et l'utilisation du processeur ou des E/S.

Mémoire statique ou mémoire dynamique

La mémoire statique est la quantité de mémoire attribuée à l'ordinateur virtuel. Elle est toujours allouée au démarrage de l'ordinateur virtuel et ne change pas lors de son exécution. Toute la mémoire est attribuée à l'ordinateur virtuel et la mémoire qui n'est pas utilisée par l'ordinateur virtuel n'est pas disponible pour les autres ordinateurs virtuels. Si la mémoire disponible sur l'hôte est insuffisante pour être allouée à l'ordinateur virtuel lors de son démarrage, il ne démarrera pas.

La mémoire statique est utile pour les charges de travail gourmandes en mémoire et les charges de travail qui ont leurs propres systèmes de gestion de mémoire, telles que SQL Server. Ces types de charges de travail seront plus performantes avec la mémoire statique.

Remarque : il n'existe aucun paramètre pour activer la mémoire statique. La mémoire statique est activée lorsque le paramètre Mémoire dynamique n'est pas activé.

La mémoire dynamique vous permet de mieux utiliser la mémoire physique sur un système en équilibrant la mémoire physique totale entre plusieurs ordinateurs virtuels. Davantage de mémoire est allouée aux ordinateurs virtuels qui sont occupés, tandis que de la mémoire est retirée pour les ordinateurs virtuels moins utilisés. Cela permet d'obtenir des ratios de consolidation plus élevés, en particulier dans les environnements dynamiques comme les serveurs VDI (Virtual Desktop Infrastructure) ou web.

Avec la mémoire statique, si 10 Go de mémoire sont attribués à un ordinateur virtuel et qu'il n'en utilise que 3 Go, les 7 Go de mémoire restants ne peuvent pas être utilisés par d'autres ordinateurs virtuels. Lorsque la mémoire dynamique est activée sur un ordinateur virtuel, ce dernier utilise uniquement la quantité de mémoire dont il a besoin, mais sans aller en-deçà de la mémoire vive minimale qui est configurée. Cela permet de libérer de la mémoire supplémentaire pour les autres ordinateurs virtuels.

Le tableau suivant répertorie les avantages et inconvénients de la mémoire statique et de la mémoire dynamique.

Option	Avantages	Inconvénients
Mémoire statique	Fournit en permanence aux ordinateurs virtuels la mémoire configurée disponible Offre de meilleures performances Peut être utilisée avec la topologie NUMA virtuelle	La mémoire non utilisée par un ordinateur virtuel ne peut pas être allouée à un autre ordinateur virtuel. Les ordinateurs virtuels ne démarreront pas si la mémoire disponible est insuffisante.
Mémoire dynamique	Offre une meilleure densité d'ordinateurs virtuels lors de l'exécution de charges de travail inactives ou à faible charge Permet l'allocation de la mémoire qui n'est pas utilisée à d'autres ordinateurs virtuels.	Vous pouvez sur-souscrire la mémoire configurée. Un temps système supplémentaire est nécessaire pour gérer les allocations de mémoire. Non compatible avec la topologie NUMA virtuelle. Non compatible avec les charges de travail qui implémentent leurs propres gestionnaires de mémoire.

Les paramètres de configuration de la mémoire sont les suivants :

• RAM de démarrage : Spécifie la quantité de mémoire requise pour démarrer l'ordinateur virtuel. La valeur doit être suffisamment élevée pour permettre le démarrage du système d'exploitation invité, mais aussi faible que possible pour permettre une utilisation optimale de la mémoire et des ratios de consolidation potentiellement plus élevés.

• RAM minimale : Spécifie la quantité minimale de mémoire qui doit être allouée à l'ordinateur virtuel après son démarrage. Cette valeur peut être comprise entre 32 Mo et une valeur maximale égale à la valeur de la RAM de démarrage. Ce paramètre est disponible uniquement si la mémoire dynamique est activée.

• RAM maximale : Spécifie la quantité maximale de mémoire que cet ordinateur virtuel est autorisé à utiliser. Cette valeur peut être comprise entre la valeur de la RAM de démarrage et 1 To. Toutefois, un ordinateur virtuel ne peut utiliser que la quantité de mémoire maximale prise en charge par le système d'exploitation invité. Par exemple, si vous attribuez 64 Go de mémoire à un ordinateur virtuel exécutant un système d'exploitation invité prenant en charge 32 Go de mémoire au maximum, l'ordinateur virtuel ne pourra pas utiliser plus de 32 Go de mémoire. Ce paramètre est disponible uniquement si la mémoire dynamique est activée.

• Poids de la mémoire : Permet à Hyper-V de déterminer comment répartir la mémoire entre les ordinateurs virtuels si la mémoire physique disponible dans l'hôte n'est pas suffisante pour donner à chaque ordinateur virtuel la quantité de mémoire qu'il demande. Les ordinateurs virtuels avec un poids de mémoire supérieur sont prioritaires sur les ordinateurs virtuels avec des poids de mémoire inférieurs.

Remarques :

• Les fonctionnalités Mémoire dynamique et NUMA virtuelle ne peuvent pas être utilisées en même temps. Un ordinateur virtuel sur lequel la mémoire dynamique est activée n'a qu'un seul nœud NUMA virtuel et aucune topologie NUMA n'est présentée à l'ordinateur virtuel quels que soient les paramètres de NUMA virtuelle.

• Lors de l'installation ou de la mise à niveau du système d'exploitation d'un ordinateur virtuel, la quantité de mémoire disponible pour l'ordinateur virtuel pendant le processus d'installation ou de mise à niveau est la valeur spécifiée comme RAM de démarrage. Même si la mémoire dynamique a été configurée pour l'ordinateur virtuel, celui-ci n'utilise que la quantité de mémoire qui est configurée dans le paramètre RAM de démarrage. Assurez-vous que la valeur de RAM de démarrage correspond à la mémoire minimale requise par le système d'exploitation au cours des procédures d'installation ou de mise à niveau.

• Le système d'exploitation invité exécuté sur l'ordinateur virtuel doit prendre en charge la mémoire dynamique.

• Les applications de base de données complexes telles que SQL Server ou Exchange Server implémentent leurs propres gestionnaires de mémoire. Consultez la documentation de la charge de travail pour déterminer si elle est compatible avec la mémoire dynamique.

Informations complémentaires :

Vue d'ensemble de la mémoire dynamique Hyper-V

Tâche 1c : Définir le processeur

Les paramètres de configuration suivants doivent être déterminés pour configurer les ordinateurs virtuels :

• Nombre de processeurs nécessaires pour chaque ordinateur virtuel. Ce nombre est souvent identique au nombre de processeurs requis par la charge de travail. Hyper-V prend en charge au maximum 64 processeurs virtuels par ordinateur virtuel.

• Contrôle des ressources pour chaque ordinateur virtuel. Il est possible de définir des limites pour garantir qu'aucun ordinateur virtuel ne peut monopoliser les ressources de processeur de l'hôte de virtualisation.

• Topologie NUMA. Pour les charges de travail NUMA hautes performances, vous pouvez spécifier le nombre maximal de processeurs, la quantité de mémoire autorisée sur un même nœud NUMA virtuel et le nombre maximal de nœuds autorisés sur un même socket de processeur. Pour plus d'informations, voir Vue d'ensemble de la topologie NUMA virtuelle Hyper-V.

Remarque : la topologie NUMA virtuelle et la mémoire dynamique ne peuvent pas être utilisées en même temps. Pour décider si vous allez utiliser la mémoire dynamique ou la topologie NUMA, répondez aux questions suivantes. Si la réponse aux deux questions est Oui, activez la topologie NUMA virtuelle et n'activez pas la mémoire dynamique.

1. La charge de travail exécutée sur l'ordinateur virtuel est-elle compatible NUMA ?

2. L'ordinateur virtuel consommera-t-il davantage de ressources, de processeurs ou de mémoire que ce qui est disponible sur un même nœud NUMA physique ?

Tâche 1d : Définir les systèmes d'exploitation pris en charge

Vous devez confirmer que le système d'exploitation requis par votre charge de travail est pris en charge comme un système d'exploitation invité. Considérez les points suivants :

• Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1

• Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8

• Pour Linux : pour plus d'information sur les distributions Linux prises en charge, voir Ordinateurs virtuels Linux sur Hyper-V.

Remarque : Hyper-V inclut un package logiciel pour les systèmes d'exploitation invités pris en charge qui améliore les performances et l'intégration entre l'ordinateur physique et l'ordinateur virtuel. Cette collection de services et de pilotes logiciels est appelée services d'intégration. Pour des performances optimales, vos ordinateurs virtuels doivent exécuter les services d'intégration les plus récents.

Licences

Vous devez vous assurer que la licence des systèmes d'exploitation invités est valide. Consultez la documentation du fournisseur pour connaître les conditions de licence spécifiques lorsque vous exécutez un environnement virtualisé.

Activation automatique d'ordinateur virtuel (AVMA, Automatic Virtual Machine Activation) est une fonctionnalité introduite dans Windows Server 2012 R2. AVMA lie l'activation de l'ordinateur virtuel au serveur de virtualisation sous licence et active l'ordinateur virtuel lorsqu'il démarre. Cela évite de devoir entrer les informations de licence et de devoir activer individuellement chaque ordinateur virtuel.

AVMA nécessite que l'hôte exécute Windows Server 2012 R2 Datacenter et le système d'exploitation invité de l'ordinateur virtuel doit être Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard ou Windows Server 2012 R2 Essentials.

Remarque : vous devez configurer AVMA sur chaque hôte déployé dans votre structure de virtualisation.

Informations complémentaires :

Activation automatique d'ordinateur virtuel

Tâche 1e : Définir la convention d'affectation de noms aux ordinateurs virtuels

Votre stratégie de noms d'ordinateurs existante peut indiquer où se trouve physiquement l'ordinateur ou le serveur. Les ordinateurs virtuels peuvent passer d'un hôte à un autre, voire changer de centre de données, la stratégie de noms existante peut donc ne plus être applicable. Une mise à jour de la convention d'affectation de noms existante pour indiquer que l'ordinateur s'exécute comme un ordinateur virtuel peut permettre de savoir où s'exécute actuellement l'ordinateur virtuel.

Tâche 2 : Définir la configuration du réseau

Chaque ordinateur virtuel recevra ou enverra différents types de trafic réseau. Chaque type de trafic réseau aura des exigences de performances, de disponibilité et de sécurité différentes.

Les ordinateurs virtuels de 1e génération peuvent comporter au maximum 12 cartes réseau (4 cartes réseau héritées et 8 cartes réseau virtuelles). Les ordinateurs virtuels de 2e génération ne prenant pas en charge les cartes réseau héritées, le nombre maximal de cartes pris en charge est de 8.

Tâche 2a : Déterminer les types de trafic réseau

Chaque ordinateur virtuel envoie et reçoit différents types de données :

• Données d'application

• Sauvegarde de données

• Communications avec des ordinateurs clients, serveurs ou services

• Communication intracluster, si la charge de travail fait partie d'un cluster de basculement d'ordinateur virtuel invité

• Assistance

• Stockage

Si des réseaux existants sont déjà dédiés à différents types de trafic réseau, vous pouvez choisir de les utiliser pour cette tâche. Si vous définissez de nouvelles conceptions de réseau pour prendre en charge votre structure de virtualisation, vous pouvez définir pour chaque ordinateur virtuel les types de trafic réseau qu'il prendra en charge.

Tâche 2b : Définir les options de performances du trafic réseau

Il existe pour chaque type de trafic réseau des exigences en matière de bande passante maximale et de latence minimale. Le tableau suivant présente les stratégies qui peuvent être utilisées pour répondre à différentes exigences de performances réseau.

Stratégie	Avantages	Inconvénients
Séparation des types de trafic sur différentes cartes réseau physiques	Sépare le trafic afin qu'il ne soit pas partagé par d'autres types de trafic	Des cartes réseau physiques distinctes doivent être installées sur l'hôte pour chaque type de trafic réseau. Du matériel supplémentaire est requis pour chaque réseau nécessitant une haute disponibilité du réseau. N'évolue pas bien avec un grand nombre de réseaux.
Gestion de la bande passante Hyper-V (QoS Hyper-V)	Fournit la qualité de service pour le trafic réseau virtuel Permet d'appliquer une bande passante minimale et une bande passante maximale à un flux de trafic, ce qui est identifié par un numéro de port de commutateur virtuel Hyper-V. Permet de configurer la bande passante minimale et la bande passante maximale par port de commutateur virtuel Hyper-V à l'aide des applets de commande PowerShell ou Windows Management Instrumentation (WMI). Permet de configurer plusieurs cartes réseau virtuelles dans Hyper-V et de définir la qualité de service individuellement sur chaque carte réseau virtuelle. Complète la stratégie de qualité de service du réseau physique.	La qualité de service logicielle et la qualité de service matérielle ne doivent pas être utilisées en même temps sur la même carte réseau. Vous devez planifier correctement la stratégie de qualité de service pour le réseau et pour Hyper-V afin qu'elles ne se substituent pas l'une à l'autre. Lorsque vous définissez le mode de qualité de service pour un commutateur virtuel, il ne peut pas être modifié. Vous ne pouvez pas migrer des ordinateurs virtuels vers un hôte avec un commutateur virtuel configuré pour utiliser un autre mode de qualité de service. La migration est bloquée quand des valeurs absolues configurées pour un ordinateur virtuel ne peuvent pas être honorées.
SR-IOV	Fournit la latence de réseau la plus faible pour un ordinateur virtuel Fournit les E/S réseau les plus élevées pour un ordinateur virtuel Réduit le temps processeur requis pour un réseau virtuel	Vous avez besoin d'une carte réseau et d'un pilote compatibles SR-IOV dans l'hôte et dans chaque ordinateur virtuel où une fonction virtuelle est affectée. Les cartes réseau virtuelles compatibles SR-IOV ne peuvent pas être membres de l'association de cartes réseau sur l'ordinateur hôte. Pour la haute disponibilité du réseau, deux cartes réseau SR-IOV ou davantage doivent être installées sur l'hôte et l'association de cartes réseau doit être configurée sur l'ordinateur virtuel. SR-IOV ne doit être utilisé que par les charges de travail approuvées, car le trafic contourne le commutateur Hyper-V et a un accès direct à la carte réseau physique. La configuration de listes de contrôle d'accès pour le port de commutateur virtuel, de QoS Hyper-V, de RouterGuard et de DHCPGuard empêchera l'utilisation de SR-IOV. SR-IOV n'est pas pris en charge pour les machines virtuelles exécutant Azure.
Mise à l'échelle côté réception virtuelle	Prend en charge la mise à l'échelle côté réception virtuelle, ce qui permet aux ordinateurs virtuels de répartir la charge de traitement réseau sur plusieurs processeurs virtuels afin d'augmenter le débit réseau des ordinateurs virtuels Assure la compatibilité avec : Association de cartes réseau Migration en direct NVGRE	La mise à l'échelle côté réception virtuelle nécessite que la carte réseau physique prenne en charge Virtual Machine Queue (VMQ) et qu'elle soit activée sur l'hôte. Non compatible avec une carte réseau virtuelle SR-IOV. Les ordinateurs virtuels doivent exécuter Windows Server 2012 R2 ou Windows 8.1. Désactivée par défaut si la carte VMQ est inférieure à 10 Gbits/s.
Trames Jumbo	Permet le transfert de plus de données avec chaque transaction Ethernet, ce qui réduit le nombre d'images qui doivent être transmises Généralement utilisée pour la communication avec le stockage, mais peut être utilisée pour tous les types de communication Réduit le traitement sur les ordinateurs virtuels, l'équipement réseau et le serveur final auquel les données sont envoyées Configuré pour la communication au sein d'un centre de données où vous pouvez contrôler les paramètres d'unité de transmission maximale (MTU) à tous les sauts	Fournit une probabilité de détection des erreurs légèrement inférieure. Chaque périphérique réseau sur le chemin doit prendre en charge les trames Jumbo et être configuré avec un paramètre MTU identique ou supérieur. Utilisez la commande Ping pour vérifier les paramètres MTU de bout en bout. Si un saut de l'itinéraire ne prend pas en charge les trames Jumbo ou est configuré avec un paramètre MTU inférieur, les paquets seront supprimés.

Tâche 2c : Définir les options de disponibilité du trafic réseau

L'association de cartes réseau, également appelée équilibrage de charge et basculement (LBFO), permet à plusieurs cartes réseau d'être placées dans une équipe aux fins d'agrégation de la bande passante et de basculement de trafic. Cela maintient la connectivité en cas de défaillance d'un composant réseau. L'association de cartes réseau est généralement configurée sur l'hôte, et quand vous créez le commutateur virtuel, il est lié à l'association de cartes réseau.

Les commutateurs réseau qui sont déployés déterminent le mode d'association de cartes réseau. Les paramètres par défaut dans Windows Server 2012 R2 doivent être suffisants pour la majorité des déploiements.

Remarque : SR-IOV n'est pas compatible avec l'association de cartes réseau. Pour plus d'informations sur SR-IOV, voir Tâche 2b : Définir les options de performances du trafic réseau.

Informations complémentaires :

Vue d'ensemble de l'association de cartes réseau

Tâche 2d : Définir les options de sécurité du trafic réseau

Chaque type de trafic réseau peut avoir des exigences de sécurité différentes, comme c'est par exemple le cas pour les exigences liées à l'isolement et au chiffrement. Le tableau suivant explique les stratégies qui peuvent être utilisés pour répondre à des exigences de sécurité différentes.

Stratégie	Avantages	Inconvénients
Séparation sur des cartes réseau distinctes	Permet de séparer le trafic de tout autre trafic réseau	N'évolue pas bien. Plus vous avez de réseaux et plus vous avez de cartes réseau à installer et à gérer sur l'hôte.
IPsec avec IPsec Déchargement de tâches	Prend en charge le déchargement IPsec pour le chiffrement du trafic réseau vers et depuis des ordinateurs virtuels avec Hyper-V Chiffre le trafic lorsqu'il parcourt le réseau	La configuration est complexe Peut compliquer la résolution des problèmes, car le trafic entre les hôtes et les ordinateurs virtuels ne peut pas être ouvert. Utilisation accrue du processeur lorsque les cartes réseau physiques dans l'hôte ne prennent pas en charge le déchargement IPsec
Identification de réseau local virtuel (VLAN)	Déjà utilisé par la plupart des entreprises Compatible avec les stratégies de qualité de service Prend en charge les réseaux locaux virtuels privés Prend en charge le mode VLAN trunk pour les ordinateurs virtuels Réduit le nombre de cartes physiques qui doivent être installées dans l'hôte	Limité à 4 094 réseaux locaux virtuels Une configuration est requise pour les commutateurs, les hôtes et les ordinateurs virtuels Une modification incorrecte des paramètres de configuration de réseau local virtuel peut entraîner des problèmes réseau spécifiques au serveur ou à l'échelle du système
Virtualisation de réseau Hyper-V	Flexibilité de la sélection élective des charges de travail, notamment isolation réseau et réutilisation d'adresses IP sans réseau local virtuel Facilité de déplacement des charges de travail sur le cloud Migration dynamique entre sous-réseaux sans avoir à injecter une nouvelle adresse IP sur le nouveau serveur Solutions de mise en réseau mutualisées Conception simplifiée du réseau et meilleure utilisation des ressources serveur et réseau. La rigidité des VLAN et le fait que la sélection élective des ordinateurs virtuels dépende d’une infrastructure réseau physique se traduisent généralement par un surapprovisionnement et une sous-utilisation.	La gestion de la virtualisation de réseau Hyper-V nécessite System Center2012 R2 - Virtual Machine Manager ou une solution de gestion non-Microsoft. Une passerelle de virtualisation de réseau Hyper-V est nécessaire pour permettre la communication à l'extérieur du réseau virtuel.
DHCPGuard	Empêche l'ordinateur virtuel de faire des offres DHCP sur le réseau virtuel Configuré par carte réseau virtuelle N'empêche pas l'ordinateur virtuel de recevoir une adresse depuis un serveur DHCP	Impact minimal sur les performances en cas d'activation
RouterGuard	Bloque les paquets suivants : ICMPv4 Type 5 (message de redirection) ICMPv4 Type 9 (annonce de routeur) ICMPv6 Type 134 (annonce de routeur) ICMPv6 Type 137 (message de redirection) Configuré par carte réseau virtuelle	Impact minimal sur les performances en cas d'activation

Décision de conception - Vous pouvez télécharger le Guide des considérations en matière de conception d'une structure de virtualisation - Feuilles de calcul et changer les exemples de données dans la feuille de calcul Virtual machine configs. (Configurations des ordinateurs virtuels) pour consigner les décisions que vous prenez dans chacune des tâches de cette étape. Pour les décisions de conception suivantes, ce document fait référence à des feuilles de calcul spécifiques de ce même guide dans lesquelles vous pouvez entrer vos données.

Tâche 2e : Définir les cartes réseau virtuelles

Maintenant que vous avez déterminé les types de trafic requis par les ordinateurs virtuels et défini les stratégies de performances, de disponibilité et de sécurité pour le trafic, vous pouvez déterminer le nombre de cartes réseau virtuelles que nécessitera chaque ordinateur virtuel.

Une carte réseau virtuelle est connectée à un commutateur virtuel. Il existe trois types de commutateurs virtuels :

• commutateur virtuel externe,

• commutateur virtuel interne,

• commutateur virtuel privé.

Le commutateur virtuel externe fournit à l'ordinateur virtuel un accès au réseau physique via l'adaptateur réseau associé au commutateur virtuel auquel il est connecté. Une carte réseau physique de l'hôte ne peut être associée qu'à un seul commutateur externe.

Les ordinateurs virtuels de 1e génération peuvent comporter au maximum 12 cartes réseau (4 cartes réseau héritées et 8 cartes réseau virtuelles). Les ordinateurs virtuels de 2e génération ne prenant pas en charge les cartes réseau héritées, le nombre maximal de cartes pris en charge est de 8. Un ID de réseau local virtuel peut être affecté à la carte réseau virtuelle, sauf si elle est configurée en mode trunk.

Si vous envisagez d'affecter le trafic de l'ordinateur virtuel à différents réseaux locaux virtuels, une carte réseau qui prend en charge les réseaux locaux virtuels doit être installée sur l'hôte et affectée au commutateur virtuel. Vous pouvez définir l'ID de réseau local virtuel de l'ordinateur virtuel dans les propriétés de l'ordinateur virtuel. L'ID de réseau local virtuel qui est défini dans le commutateur virtuel est l'ID de réseau local virtuel qui sera attribué à la carte réseau virtuelle affectée au système d'exploitation hôte.

Remarque : si un ordinateur virtuel nécessite l'accès à plus de réseaux qu'il n'y a de cartes disponibles, vous pouvez activer le mode VLAN trunk pour une carte réseau de l'ordinateur virtuel à l'aide de l'applet de commande Windows PowerShell Set-VMNetworkAdapterVlan.

Tâche 2f : Définir la stratégie d'adressage IP

Vous devez déterminer comment vous allez attribuer des adresses IP à vos ordinateurs virtuels. Si vous ne le faites pas, des conflits d'adresses IP risquent de se produire, ce qui peut avoir un impact négatif sur les autres ordinateurs virtuels et les périphériques physiques du réseau.

De plus, des serveurs DHCP non autorisés peuvent provoquer des dégâts sur votre infrastructure réseau, et ils peuvent être particulièrement difficiles à repérer lorsque le serveur s'exécute en tant qu'ordinateur virtuel. Vous pouvez protéger votre réseau contre les serveurs DHCP non autorisés exécutés sur un ordinateur virtuel en activant DHCPGuard dans les paramètres de vos ordinateurs virtuels. DHCPGuard assure la protection contre un ordinateur virtuel malveillant se présentant comme un serveur DHCP pour effectuer des attaques de l'intercepteur (« man-in-the-middle »).

Informations complémentaires :

Vue d'ensemble du protocole DHCP (Dynamic Host Configuration Protocol)

DHCPGuard

Vue d'ensemble de la gestion des adresses IP (IPAM)

Tâche 3 : Définir la configuration du stockage

Pour déterminer votre configuration de stockage, vous devez définir les types de données qui seront stockés par les ordinateurs virtuels et le type de stockage dont ils ont besoin.

Tâche 3a : Définir les types de données

Le tableau suivant répertorie les types de données qu'un ordinateur virtuel peut avoir besoin de stocker et où ce type de données est souvent stocké.

Type de données	Emplacement de stockage pour le type de données
Fichiers du système d'exploitation	Dans un fichier de disque dur virtuel qui est stocké par l'hôte de virtualisation. Les considérations en matière de stockage pour l'hôte de virtualisation sont abordées plus en détail à l'Étape 4 : Planifier les hôtes de virtualisation de serveur ci-dessous.
Fichier d'échange Windows	Généralement stocké au même emplacement que les fichiers du système d'exploitation.
Fichiers de programme d'application	Généralement stockés au même emplacement que les fichiers du système d'exploitation.
Données de configuration d'application	Généralement stockées au même emplacement que les fichiers du système d'exploitation.
Données d'application	Généralement stockées séparément des fichiers d'application et du système d'exploitation. Par exemple, si l'application est une application de base de données, les fichiers de base de données sont souvent stockés dans une solution de stockage réseau haute disponibilité et efficace qui est distincte de l'emplacement où sont stockés les fichiers du système d'exploitation ou les fichiers d'application.
Volumes partagés en cluster (CSV) et témoin de disque (nécessaires pour le clustering d'ordinateurs virtuels invités)	Souvent stockés séparément des fichiers d'application et du système d'exploitation. Le stockage CSV est l'endroit où les applications en cluster stockent les données afin qu'elles soient disponibles pour tous les nœuds du cluster. Un témoin de disque est un disque dans l'espace de stockage en cluster qui est conçu pour conserver une copie de la base de données de configuration du cluster. Un cluster de basculement possède un témoin de disque uniquement si cela est spécifié dans la configuration de quorum.
Fichiers de vidage sur incident	Généralement stockés au même emplacement que les fichiers du système d'exploitation.

Tâche 3b : Définir les types de stockage

Le tableau suivant répertorie les types de stockage qui peuvent être utilisés pour les types de données définis à l'Étape 2, Tâche 2 ci-dessus.

Type de stockage	Éléments à prendre en considération
Disque IDE virtuel	Ordinateurs virtuels de 1e génération : 2 contrôleurs IDE ; chaque contrôleur peut prendre en charge au maximum 2 périphériques IDE pour un maximum de 4 périphériques IDE. Le disque de démarrage doit être attaché à l'un des périphériques IDE en tant que disque dur virtuel ou disque physique. Les ordinateurs virtuels de 2e génération ne prennent pas en charge les périphériques IDE.
SCSI virtuels	4 contrôleurs SCSI virtuels sont pris en charge ; chaque contrôleur prenant en charge jusqu'à 64 périphériques pour un total de 256 périphériques SCSI. Les ordinateurs virtuels de 2e génération ne prenant en charge qu'un lecteur SCSI, ils prennent en charge les disques de démarrage SCSI.
Initiateur iSCSI dans l'ordinateur virtuel	Profitez du stockage sur des réseaux SAN sans installation de cartes Fibre Channel dans l'hôte. Ne peut pas être utilisé pour le disque de démarrage. Utilisez les stratégies de qualité de service réseau pour garantir la disponibilité appropriée de la bande passante pour le stockage et autre trafic réseau. Non compatible avec le réplica Hyper-V. Quand vous utilisez un serveur principal de stockage SAN, utilisez les options de réplication SAN fournies par votre fournisseur de stockage.
Fibre Channel virtuel	Nécessite une ou plusieurs cartes de bus hôte Fibre Channel ou une ou plusieurs cartes réseau convergées Fibre Channel sur Ethernet (FCoE) dans chaque hôte qui hébergera des ordinateurs virtuels avec les cartes Fibre Channel virtuel. Les pilotes HBA et FCoE doivent prendre en charge Fibre Channel virtuel. Un réseau SAN compatible NPIV. Nécessite une configuration supplémentaire pour prendre en charge la migration dynamique. Pour plus d'informations sur la migration dynamique et Fibre Channel virtuel, voir Vue d'ensemble de Fibre Channel virtuel Hyper-V Non compatible avec le réplica Hyper-V. Quand vous utilisez le stockage SAN, vous devez utiliser les options de réplication SAN fournies par votre fournisseur de stockage. Un ordinateur virtuel peut avoir jusqu'à quatre ports virtuels. Les numéros d'unité logique Fibre Channel virtuel ne peuvent pas être utilisés comme support de démarrage de l'ordinateur virtuel.
SMB 3.0	Accédez aux fichiers stockés sur des partages SMB (Server Message Block) 3.0 à partir de l'ordinateur virtuel.

Tâche 3c : Définir le format et le type de disque dur virtuel

Si vous utilisez le type de stockage sur disque dur virtuel, vous devez d'abord sélectionner le format de disque dur virtuel que vous allez utiliser dans les options répertoriées dans le tableau suivant.

Format de disque	Avantages	Inconvénients
VHD	Pris en charge par toutes les versions d'Hyper‑V Pris en charge par les implémentations locales et par Azure	Capacité de stockage maximale de 2 040 Go La taille maximale de disque dur virtuel pris en charge par Azure est de 1 To Non pris en charge par les ordinateurs virtuels de 2e génération
VHDX	Capacité de stockage maximale de 64 téraoctets (To) Protection contre la corruption des données pendant une panne d'alimentation Meilleur alignement du format de disque dur virtuel afin qu'il s'exécute correctement sur des disques à grand secteur. Un disque virtuel à secteurs logiques de 4 Ko qui permet d'améliorer les performances lorsqu'il est utilisé par les applications et les charges de travail qui sont conçues pour les secteurs de 4 Ko Utilisable comme stockage partagé pour les ordinateurs virtuels qui nécessitent le clustering avec basculement	Actuellement non pris en charge par les machines virtuelles dans Azure Ne peut pas être utilisé avec les versions d'Hyper-V antérieures à Windows Server 2012
VHDX partagé	Utilisé pour le stockage partagé des clusters d'ordinateurs virtuels invités	Requiert Windows Server 2012 R2 sur l'ordinateur hôte exécutant Hyper-V Les systèmes d'exploitation invités pris en charge pour les clusters invités qui utilisent un disque dur virtuel partagé incluent Windows Server 2012 R2 et Windows Server 2012. Pour prendre en charge Windows Server 2012 en tant que système d'exploitation invité, Windows Server2012 R2 Integration Services doit être installé dans l'invité (ordinateur virtuel). Les fonctionnalités suivantes ne sont pas compatibles avec VHDX partagé : Réplica Hyper-V Redimensionnement du disque dur virtuel pendant l'exécution d'ordinateurs virtuels configurés Migration dynamique du stockage Sauvegardes VSS au niveau de l'hôte. Les sauvegardes au niveau invité doivent être effectuées avec les mêmes méthodes que dans le cas d'un cluster s'exécutant sur des serveurs physiques. Points de contrôle des ordinateurs virtuels Qualité de service de stockage

Ensuite, sélectionnez le type de disque que vous allez utiliser dans les options répertoriées dans le tableau suivant.

Type de disque	Avantages	Inconvénients
Fixe	Moins susceptible d'être affecté par la fragmentation que les autres types de disque Temps processeur inférieur par rapport aux autres types de disque Une fois le fichier de disque dur virtuel créé, la question de l'espace disque disponible est moins préoccupante qu'avec les autres types de disque Pris en charge par les implémentations locales et par Azure	Un disque dur virtuel créé nécessite que tout l'espace soit disponible, même si l'ordinateur virtuel n'utilise pas tout l'espace. Le disque dur virtuel ne sera pas créé si l'espace de stockage disponible est insuffisant. Impossible d'allouer à d'autres disques durs virtuels l'espace inutilisé dans le disque dur virtuel.
Dynamique	Utilise l'espace disque uniquement en fonction des besoins, au lieu d'utiliser tout l'espace qui a été approvisionné	Actuellement non pris en charge par Azure, bien que les disques dynamiques puissent être convertis en disques fixes Il est important d'analyser l'espace disque libre lors de l'utilisation de disques durs virtuels dynamiques. Si l'espace disque n'est pas disponible pour permettre la croissance d'un disque dur virtuel dynamique, l'ordinateur virtuel entrera dans un état critique où il sera suspendu. Le fichier de disque dur virtuel peut se fragmenter. Temps processeur légèrement plus long pour les opérations de lecture et d'écriture que dans le cas d'un disque fixe
De différenciation	Peut utiliser moins d'espace disque si plusieurs disques de différenciation utilisent le même parent	N'est actuellement pas pris en charge par Azure Les modifications apportées à un disque parent peuvent entraîner une incohérence des données dans le disque enfant Temps processeur légèrement plus long pour les opérations de lecture et d'écriture pour les charges de travail intensives avec nombreuses E/S

Considérez les éléments suivants lorsque vous sélectionnez le type et le format de fichier de disque dur virtuel :

• Lorsque vous utilisez le format VHDX, un disque dynamique peut être utilisé car il offre des garanties de résilience, en plus des économies d'espace qui sont associées à l'allocation d'espace uniquement en cas de besoin.

• Un disque fixe peut également être utilisé, quel que soit son format, lorsque le stockage sur le volume hôte n'est pas activement analysé. Cela garantit qu'un espace disque suffisant est présent lorsque le fichier de disque dur virtuel est développé au moment de l'exécution.

• Les points de contrôle (anciennement appelés instantanés) d'un ordinateur virtuel créent un disque dur virtuel de différenciation pour stocker les écritures sur les disques. Le fait de n'avoir que quelques points de contrôle peut augmenter l'utilisation du processeur pour les E/S de stockage, sans que cela n'affecte considérablement les performances (sauf dans le cas des charges de travail serveur intensives avec nombreuses E/S).

  Toutefois, une longue chaîne de points de contrôle peut affecter notablement les performances car la lecture à partir des disques durs virtuels peut nécessiter le contrôle des blocs demandés dans de nombreux disques de différenciation. Il est important que les chaînes de contrôle restent courtes afin de conserver de bonnes performances d'E/S sur disque.

Tâches 3d : Définir le type de stockage à utiliser pour chaque type de données

Après avoir défini les types de données et stockage qui seront stockés par les ordinateurs virtuels, vous pouvez déterminer quel type de stockage et quel format et type de disque virtuel vous utiliserez pour chaque type de données.

Tâche 4 : Définir la stratégie de disponibilité des ordinateurs virtuels

Même si les administrateurs de structure sont responsables de la disponibilité de la structure, les administrateurs d'ordinateurs virtuels sont en fin de compte responsables de la disponibilité de leurs ordinateurs virtuels. Par conséquent, l'administrateur des ordinateurs virtuels doit comprendre les fonctionnalités de la structure de manière à concevoir la stratégie de disponibilité appropriée pour les ordinateurs virtuels.

Les tableaux suivants analysent trois stratégies de disponibilité pour les ordinateurs virtuels exécutant des charges de travail ayant les caractéristiques définies à l'Étape 1, Tâche 2 ci-dessus. D'une manière générale, l'administrateur de structure informe les administrateurs d'ordinateurs virtuels à l'avance des activités d'interruption de service planifiées pour la structure afin que ces derniers puissent définir leur planning en conséquence. Les trois stratégies de disponibilité sont les suivantes :

• Sans état

• Avec état

• Avec état partagé

Sans état

Option	Éléments à prendre en considération
Migration dynamique des ordinateurs virtuels au niveau de l'hôte	Si un hôte doit être arrêté en vue d'une maintenance planifiée, les ordinateurs virtuels en cours d'exécution peuvent être migrés vers un hôte exécutable sans temps d'arrêt pour les ordinateurs virtuels. Pour plus d'informations sur les considérations relatives aux hôtes, voir Tâche 5 : Définir la stratégie de disponibilité des hôtes de virtualisation de serveur., plus bas. Si les ordinateurs virtuels ne sont pas stockés sur un équipement de stockage accessible par les deux hôtes, vous devez déplacer l'équipement de stockage des ordinateurs virtuels au cours d'une migration dynamique. Si un hôte échoue de manière inattendue, tous les ordinateurs virtuels exécutés sur cet hôte s'arrêtent. Vous devez démarrer les ordinateurs virtuels en exécutant la même charge de travail sur un autre hôte.
Clusters à charge équilibrée (avec Équilibrage de la charge réseau Windows)	Nécessite que l'administrateur d'ordinateurs virtuels ait au moins deux ordinateurs virtuels exécutant une charge de travail identique hébergée sur des hôtes différents. L'équilibrage de la charge réseau (NLB, Network Load Balancing) est configuré dans les ordinateurs virtuels par l'administrateur d'ordinateurs virtuels. L'équilibrage de la charge réseau nécessite que des adresses IP statiques soient affectées aux cartes réseau. L'affectation d'adresses DHCP n'est pas prise en charge. L'administrateur d'ordinateurs virtuels doit collaborer avec l'administrateur de structure afin d'obtenir les adresses IP à utiliser pour l'adresse IP virtuelle NLB et de créer l'entrée DNS demandée. Activez l'usurpation MAC pour le réseau virtuel qui est utilisé par l'équilibrage de la charge réseau sur les invités. Cela peut être fait dans les paramètres de carte réseau de chaque ordinateur virtuel faisant partie du cluster NLB en tant que nœud. Vous pouvez créer des clusters NLB, ajouter des nœuds et mettre à jour les configurations de cluster NLB sans redémarrer les ordinateurs virtuels. Tous les ordinateurs virtuels qui font partie du cluster NLB doivent se trouver sur le même sous-réseau. Pour garantir la disponibilité de la charge de travail (même en cas de défaillance de l'hôte), l'administrateur d'ordinateurs virtuels doit vérifier que les ordinateurs virtuels s'exécutent sur des hôtes différents.
Clusters à charge équilibrée (avec un programme d'équilibrage de la charge matérielle)	Cette fonctionnalité doit être fournie au niveau de la structure et les administrateurs de structures doivent configurer des clusters à charge équilibrée pour les ordinateurs virtuels qui en ont besoin. Ou bien, ils peuvent permettre aux administrateurs d'ordinateurs virtuels de configurer cette fonctionnalité via le portail de gestion pour le programme d'équilibrage de la charge matérielle. Nécessite que l'administrateur d'ordinateurs virtuels ait au moins deux ordinateurs virtuels exécutant une charge de travail identique hébergée sur la structure. Pour plus d'informations, consultez la documentation produit du fournisseur du matériel.

Avec état

Option

Éléments à prendre en considération

Cluster Hyper-V

Nécessite la configuration d'un cluster de basculement. Nécessite un stockage partagé entre tous les nœuds du cluster pour les fichiers CSV. Il peut s'agir d'un stockage SAN ou d'un partage de fichiers SMB 3.0. Quand le cluster détecte un problème avec un hôte ou quand Hyper-V détecte un problème avec le réseau ou le stockage de l'ordinateur virtuel, ce dernier peut être déplacé vers un autre hôte. L'ordinateur virtuel continue à s'exécuter pendant le déplacement. En cas de défaillance irrémédiable d'un hôte, les ordinateurs virtuels qui s'exécutaient sur cet hôte peuvent être démarrés sur d'autres nœuds du cluster. Les ordinateurs virtuels critiques peuvent être configurés pour démarrer automatiquement. Cela limite le temps d'arrêt en cas de défaillance irrémédiable d'un hôte. Corrigez les hôtes sans affecter les ordinateurs virtuels en cours d'exécution avec la mise à jour adaptée aux clusters. Configurez l'anti-affinité des ordinateurs virtuels pour éviter l'exécution d'ordinateurs virtuels sur le même nœud. Par exemple, si vous exécutez deux serveurs web qui fournissent des services frontaux pour une application principale, vous ne souhaitez pas que ces deux serveurs web s'exécutent sur le même nœud. Quand un nœud est placé en mode maintenance, le service de cluster de basculement déplace les ordinateurs virtuels en cours d'exécution vers un autre nœud du cluster. Si aucun ordinateur virtuel n'est en cours d'exécution sur le nœud, la maintenance demandée peut être effectuée. Le cluster de basculement ne déplace pas des ordinateurs virtuels vers un nœud en mode maintenance. Avant de placer un nœud en mode maintenance, assurez-vous que la capacité sur les autres nœuds du cluster Hyper-V est suffisante pour exécuter les ordinateurs virtuels existants tout en conservant les contrats SLA pour vos clients.

Avec état partagé

En cas d'exécution de charges de travail adaptées aux clusters, vous pouvez fournir une couche supplémentaire de disponibilité en activant le clustering invité d'ordinateurs virtuels. Le clustering invité prend en charge la haute disponibilité pour les charges de travail de l'ordinateur virtuel. Le clustering invité offre une protection à la charge de travail qui est en cours d'exécution sur les ordinateurs virtuels, même en cas de défaillance de l'hôte sur lequel l'ordinateur virtuel s'exécute. Étant donné que la charge de travail était protégée par le clustering avec basculement, l'ordinateur virtuel sur l'autre nœud peut prendre automatiquement le contrôle.

Option

Éléments à prendre en considération

Clustering invité d'ordinateurs virtuels

Nécessite un stockage partagé accessible par deux ou plusieurs ordinateurs virtuels en même temps. Les types de connexion pris en charge sont les suivants : iSCSI Fibre Channel virtuel VHDX partagé Configurez l'anti-affinité des ordinateurs virtuels pour éviter que les deux ordinateurs virtuels s'exécutent sur le même nœud de cluster. Le clustering invité d'ordinateurs virtuels n'est pas pris en charge par Azure. Les fonctionnalités suivantes ne sont pas compatibles avec VHDX partagé : Réplica Hyper-V Redimensionnement du disque dur virtuel pendant l'exécution d'ordinateurs virtuels configurés Migration dynamique du stockage Sauvegardes VSS au niveau de l'hôte. Les sauvegardes au niveau invité doivent être effectuées avec les mêmes méthodes que dans le cas d'un cluster s'exécutant sur des serveurs physiques. Points de contrôle des ordinateurs virtuels Qualité de service de stockage

Informations complémentaires :

Déployer un cluster invité avec un disque dur virtuel partagé

Utilisation du clustering invité pour une haute disponibilité

Récupération d'urgence

En cas de défaillance grave, en combien de temps pouvez-vous rendre opérationnelles les charges de travail demandées afin qu'elles puissent être utilisées par les clients ? Dans certains cas, le délai imparti peut être de seulement quelques minutes.

La réplication des données de vos centres de données principaux vers vos centres de récupération d'urgence doit garantir que les données les plus récentes peuvent être répliquées avec une perte de données acceptable en raison des délais. En exécutant les charges de travail dans des ordinateurs virtuels, vous pouvez répliquer les disques durs virtuels et les fichiers de configuration des ordinateurs virtuels de votre site principal vers un site de réplication.

Le tableau suivant compare les options de récupération d'urgence.

Option	Éléments à prendre en considération
Réplica Hyper-V	Bon marché et il n'est pas nécessaire de dupliquer le matériel hôte et le matériel de stockage sur les sites de récupération d'urgence. Les mêmes outils de gestion sont utilisés pour gérer la réplication et pour gérer les ordinateurs virtuels. Les intervalles de réplication peuvent être configurés pour répondre à vos besoins en matière de perte de données. Configurez des adresses IP différentes à utiliser au niveau du site de réplication. Impact minimal sur l'infrastructure réseau. Non pris en charge pour les ordinateurs virtuels configurés avec des disques physiques (également appelés disques relais), le stockage Fibre Channel virtuel ou des disques durs virtuels partagés. Le réplica Hyper-V ne doit pas se substituer au stockage des sauvegardes de données ni à la récupération de données. La capacité de stockage devra être augmentée sur le site de réplicas si des points de récupération supplémentaires sont configurés. La durée de l'intervalle de réplication déterminera la quantité de perte de données. La capacité de stockage devra être augmentée au niveau du site de réplicas lorsqu'un ordinateur virtuel avec une grande quantité de modifications est configuré avec un court intervalle de réplication.
Sauvegarde	Sauvegardez l'ordinateur virtuel complet avec une solution de sauvegarde prise en charge par Hyper-V, comme System Center Data Protection Manager. La perte de données sera déterminée par l'ancienneté de la dernière sauvegarde. Les ordinateurs virtuels configurés avec un fichier VHDX partagé ne peuvent pas être sauvegardés au niveau de l'hôte. Installez un agent de sauvegarde dans l'ordinateur virtuel et sauvegardez les données depuis cet ordinateur virtuel.

Remarques :

• Pour gérer la réplication de façon centralisée et l'automatiser quand System Center 2012 R2 - Virtual Machine Manager est exécuté, vous devez utiliser Microsoft Azure Site Recovery.

• Pour répliquer des ordinateurs virtuels vers Azure, vous devez utiliser Microsoft Azure Site Recovery. La réplication d'un ordinateur virtuel vers Azure est actuellement en mode Aperçu.

Informations complémentaires :

Microsoft Azure Site Recovery

Important :

• Utilisez Hyper-V Replica Capacity Planner pour comprendre l'impact du réplica Hyper-V sur votre infrastructure réseau, sur l'utilisation du processeur sur le serveur principal, le serveur de réplica et le serveur de réplica étendu, sur l'utilisation de la mémoire sur le serveur principal et le serveur de réplica, ainsi que sur les opérations d'E/S par seconde du disque sur le serveur principal, le serveur de réplica et le serveur de réplica étendu qui reposent sur vos ordinateurs virtuels existants.

• Votre charge de travail comprend peut-être une solution de récupération d'urgence intégrée, comme Groupes de disponibilité AlwaysOn dans SQL Server. Consultez la documentation de la charge de travail pour vérifier qu'elle prend en charge le réplica Hyper-V.

Informations complémentaires :

Réplica Hyper-V

System Center Data Protection Manager

Tâche 5 : Définir les types d'ordinateurs virtuels

Pour prendre en charge les charges de travail de votre environnement, vous pouvez créer des ordinateurs virtuels avec des besoins en ressources uniques afin de répondre aux besoins de chaque charge de travail. Vous pouvez également adopter une approche similaire aux fournisseurs publics de services d'hébergement d'ordinateurs virtuels (également appelés Infrastructure-as-a-Service (IaaS)).

Voir Tailles de machines virtuelles et de services cloud pour Microsoft Azure pour obtenir une description des configurations de machines virtuelles proposées par les services d'infrastructure de Microsoft Azure. Au moment d'écrire ce lignes, le service prenait en charge 13 configurations de machines virtuelles ayant chacune des combinaisons d'espace différentes pour le processeur, la mémoire, le stockage et les opérations d'E/S.

Décision de conception - Les décisions que vous prenez dans chacune des tâches de cette étape peuvent être entrées dans les feuilles de calcul Virtual machine configs. (Configurations des ordinateurs virtuels).

Étape 3 : Planifier les groupes hôtes de virtualisation de serveur

Avant de définir les hôtes de serveur individuels, vous voudrez peut-être commencer par définir les groupes hôtes. Les groupes hôtes sont simplement une collection nommée de serveurs qui sont regroupés afin d'atteindre les objectifs communs qui sont décrits dans les tâches restantes de cette étape.

Tâche 1 : Définir des emplacements physiques

Vous allez probablement regrouper et gérer les ressources matérielles par emplacement physique. Vous voudrez donc commencer par définir les emplacements qui contiendront les ressources de structure de votre organisation.

Tâche 2 : Définir les types de groupes hôtes

Vous pouvez créer des groupes hôtes pour différentes raisons, comme pour héberger des charges de travail présentant des spécificités à différents niveaux :

• caractéristiques de la charge de travail ;

• besoins en ressources ;

• exigences en matière de qualité de service.

L'image suivante illustre une organisation qui a créé cinq groupes hôtes dans deux emplacements.

Figure 2 :Exemple de groupes hôtes

L'organisation a créé les groupes hôtes pour les raisons indiquées dans le tableau suivant.

Groupe hôte	Raisons de sa création
Charge de travail sans état et avec état	Ces caractéristiques de charge de travail sont les plus courantes dans cette organisation. Ce type de groupe hôte est donc présent dans les deux emplacements. Ces charges de travail ont des exigences similaires en matière de performances et de niveau de service.
Charges de travail avec état et sans état du service Comptabilité	Bien que la configuration matérielle des serveurs de ce groupe hôte soit la même que celle des autres groupes hôtes de charge de travail avec état et sans état dans leur environnement, le service Comptabilité possède des applications qui ont des exigences de sécurité plus élevées que les autres services de l'organisation. Par conséquent, un groupe hôte dédié a été créé pour ce service afin qu'il puisse être sécurisé différemment des autres groupes hôtes dans la structure.
Charges de travail avec état partagé	Les charges de travail hébergées par ce groupe hôte nécessitent un stockage partagé car elles s'appuient sur le clustering avec basculement dans Windows Server pour maintenir leur disponibilité. Ces charges de travail sont hébergées par un groupe hôte dédié car la configuration de ces ordinateurs virtuels est différente de celle des autres ordinateurs virtuels de l'organisation.
Charges de travail avec état et E/S élevées	Tous les hôtes de ce groupe hôte sont connectés à des réseaux plus rapides que les hôtes des autres groupes hôtes.

Bien que les groupes hôtes de l'organisation puissent couvrir différents emplacements, le choix a été fait de conserver tous les membres de chaque groupe hôte dans le même emplacement pour faciliter leur gestion. Comme vous pouvez le constater dans cet exemple, les groupes hôtes peuvent être créés pour diverses raisons, et ces raisons varient d'un organisation à l'autre. Plus vous créez de groupes hôtes dans votre organisation, plus l'environnement est complexe à gérer, ce qui alourdit le coût de l'hébergement d'ordinateurs virtuels.

Conseil : plus le matériel serveur est normalisé dans un groupe hôte, plus il sera facile de faire évoluer et de gérer ce groupe dans le temps. Si vous décidez de normaliser le matériel au sein d'un groupe hôte, vous pouvez ajouter les données de configuration normalisées à la feuille de calcul Host groups (Groupes hôtes) dans le Guide des considérations en matière de conception d'une structure de virtualisation - Feuilles de calcul. Pour plus d'informations sur les considérations en matière de matériel physique, voir Étape 4 : Planifier les hôtes de virtualisation de serveur.

Prenez en considération le fait qu'actuellement la plupart des fournisseurs de cloud public qui hébergent des ordinateurs virtuels :

• hébergent uniquement des ordinateurs virtuels qui ne nécessitent pas d'état partagé ;

• n'ont souvent qu'un jeu de mesures de qualité de service qu'ils fournissent à tous les clients ;

• ne dédient pas de matériel spécifique à clients spécifiques.

Nous vous recommandons de commencer avec un type de groupe hôte contenant du matériel identique et de n'ajouter d'autres types de groupes hôtes que si les avantages d'une telle démarche compensent le coût.

Tâche 3 : Déterminer si les membres du groupe hôte doivent être mis en cluster

Par le passé, le clustering avec basculement dans Windows Server n'était utilisé que pour augmenter la disponibilité du serveur. Il s'est développé et offre aujourd'hui beaucoup plus de fonctionnalités. Appuyez-vous sur les informations du tableau ci-dessous pour vous aider à décider si vous voudrez mettre en cluster les membres de votre groupe hôte.

Option	Avantages	Inconvénients
Les membres du groupe hôte font partie d'un cluster de basculement	Si un hôte échoue, les ordinateurs virtuels qu'il héberge redémarreront automatiquement sur les nœuds survivants. Un ordinateur virtuel peut être déplacé vers un autre nœud du cluster si le nœud sur lequel il s'exécute détecte un problème avec le nœud ou dans l'ordinateur virtuel. Utilisez la mise à jour adaptée aux clusters pour facilement mettre à jour les nœuds du cluster sans impact sur les ordinateurs virtuels en cours d'exécution.	Les hôtes demandent une configuration spécifique pour être membres du cluster. Les hôtes doivent être membres d'un domaine Active Directory. Le clustering avec basculement présente des exigences de stockage et de réseau supplémentaires.
Les membres du groupe hôte ne font pas partie d'un cluster de basculement	Les hôtes ne nécessitent pas une configuration de cluster spécifique. Les hôtes n'ont pas besoin d'être membres d'un domaine Active Directory. Aucune exigence supplémentaire en matière de stockage et de réseau.	Les ordinateurs virtuels s'exécutant sur un hôte qui échoue doivent être déplacés manuellement (ou avec un certain degré d'automatisation) vers un hôte survivant et redémarrés.

Décision de conception - Les décisions que vous prenez dans chacune des tâches de cette étape peuvent être entrées dans la feuille de calcul Settings (Paramètres).

Étape 4 : Planifier les hôtes de virtualisation de serveur

Dans cette étape, vous allez définir les types d'hôtes dont vous aurez besoin pour héberger les ordinateurs virtuels que vous projetez d'exécuter sur votre structure de virtualisation. Vous voudrez limiter le nombre de configurations d'hôtes, dans certains cas à une seule configuration, pour réduire les coûts d'approvisionnement et de support. De plus, les coûts de déploiement peuvent grimper par l'achat du mauvais matériel.

Cloud Platform System

Gérant des services cloud et des datacenters comptant parmi les plus importants, Microsoft réunit son expérience et son savoir-faire dans un système convergé entièrement validé et intégré en usine. CPS combine un éventail de logiciels Microsoft, comprenant Windows Server 2012 R2, System Center 2012 R2 et Pack Windows Azure avec le matériel de serveur cloud, de stockage et de mise en réseau de Dell. En tant que composant évolutif de votre cloud, CPS accélère la valorisation et garantit l'uniformité de l'expérience du cloud.

CPS propose un environnement cloud mutualisé en libre-service pour les ordinateurs virtuels Windows et Linux et le service Platform-as-a-Service, et intègre des packs de déploiement optimisés pour des applications Microsoft comme SQL Server, SharePoint et Exchange. L'intégration en usine réduit les risques et la complexité tout en accélérant la durée de déploiement qui se compte désormais en jours (et plus en mois). Le processus de support simplifié et l'automatisation des tâches courantes sur l'infrastructure libèrent également des ressources IT qui peuvent ainsi se consacrer à l'innovation.

Pour plus d'informations, consultez le site Cloud Platform System.

Programme Fast Track

Au lieu de concevoir votre configuration matérielle (et logicielle), vous pouvez acheter des configurations matérielles préconfigurées auprès de nombreux partenaires via le programme Microsoft Private Cloud Fast Track.

Microsoft Private Cloud Fast Track est une démarche commune de Microsoft et de ses partenaires visant à proposer des solutions validées et préconfigurées qui réduisent la complexité et le risque liés à l'implémentation d'une structure de virtualisation et des outils pour la gérer.

Le programme Fast Track offre une flexibilité au niveau des solutions et un plus large choix aux clients parmi les technologies des fournisseurs de matériels. Il utilise les fonctions principales du système d'exploitation Windows Server, de la technologie Hyper-V et de Microsoft System Center pour proposer les piliers sur lesquels construire une infrastructure de cloud privé en tant qu'offre de service.

Informations complémentaires :

Site Microsoft Private Cloud - Fast Track

Tâche 1 : Définir la configuration de calcul

Dans cette tâche, vous aller déterminer la quantité de mémoire, le nombre de processeurs et la version de Windows Server qui sont nécessaires pour chaque hôte. Le nombre d'ordinateurs virtuels à exécuter sur un hôte sera déterminé par les composants matériels présentés dans cette section.

Remarque : pour garantir la prise en charge totale de votre solution, tout le matériel que vous achetez doit comporter le logo Certifié pour Windows Server pour la version de Windows Server que vous exécutez.

Le logo Certifié pour Windows Server indique qu'un système serveur atteint la barre technique la plus élevée de Microsoft en matière de sécurité, de fiabilité et de facilité de gestion. Associé à d'autres pilotes et périphériques certifiés, il peut prendre en charge les rôles, fonctionnalités et interfaces des charges de travail de cloud et d'entreprise, et des applications stratégiques.

Pour obtenir la liste à jour du matériel certifié pour Windows Server, voir le Catalogue Windows Server.

Tâche 1a : Définir le processeur

Hyper-V présente les processeurs logiques à chaque ordinateur virtuel sous la forme d'un ou de plusieurs processeurs virtuels. Vous pouvez obtenir une meilleure efficacité à l'exécution avec des processeurs prenant en charge les technologies SLAT (Second Level Address Translation), comme les processeurs EPT (Extended Page Tables) ou NPT (Nested Page Tables). Hyper-V dans Windows Server 2012 R2 prend en charge un maximum de 320 processeurs logiques.

Éléments à prendre en considération :

• Les charges de travail qui ne sollicitent pas beaucoup le processeur doivent être configurées pour utiliser un processeur virtuel unique. Analysez l'utilisation du processeur hôte dans le temps pour vérifier que vous avez alloué des processeurs pour une efficacité maximale.

• Les charges de travail qui sollicitent beaucoup le processeur doivent utiliser deux processeurs virtuels ou plus. Vous pouvez attribuer un maximum de 64 processeurs virtuels à un ordinateur virtuel. Le nombre de processeurs virtuels reconnus par l'ordinateur virtuel dépend du système d'exploitation invité. Par exemple, Windows Server 2008 Service Pack 2 ne reconnaît que quatre processeurs virtuels.

Informations complémentaires :

Vue d'ensemble d'Hyper-V

Réglage des performances pour les serveurs Hyper-V

Tâche 1b : Définir la mémoire

Le serveur physique a besoin d'une mémoire suffisante pour les ordinateurs virtuels hôtes et les ordinateurs virtuels en cours d'exécution. L'hôte a besoin de mémoire pour réaliser efficacement des E/S au nom des ordinateurs virtuels et pour effectuer des opérations telles qu'un point de contrôle d'ordinateur virtuel. Hyper-V vérifie que la mémoire disponible pour l'hôte est suffisante et il autorise l'affectation de la mémoire restante aux ordinateurs virtuels. Les ordinateurs virtuels doivent être dimensionnés en fonction des besoins de la charge prévue pour chaque ordinateur virtuel.

L'hyperviseur virtualise la mémoire physique de l'invité pour isoler les ordinateurs virtuels les uns des autres et fournir un espace mémoire contiguë de base zéro à chaque système d'exploitation invité, comme sur les systèmes non virtualisés. Pour garantir des performances optimales, utilisez du matériel SLAT de manière à réduire au maximum le coût de la virtualisation de mémoire sur les performances.

Dimensionnez la mémoire de l'ordinateur virtuel comme vous le faites habituellement pour les applications serveur sur un ordinateur physique. La quantité de mémoire allouée à l'ordinateur virtuel doit lui permettre de gérer raisonnablement la charge attendue aux heures normales et aux heures de pointe car une mémoire insuffisante peut augmenter considérablement les temps de réponse et l'utilisation du processeur ou des E/S.

La mémoire allouée à un ordinateur virtuel réduit la quantité de mémoire disponible pour les autres ordinateurs virtuels. Si la mémoire disponible sur l'hôte est insuffisante, l'ordinateur virtuel ne démarre pas.

La mémoire dynamique vous permet d'atteindre des chiffres de consolidation plus élevés avec une meilleure fiabilité pour les opérations de redémarrage. Cela peut contribuer à réduire les coûts, en particulier dans les environnements comportant de nombreux ordinateurs virtuels inactifs ou à faible charge, comme les environnements VDI regroupés. Les changements de configuration à l'exécution de la mémoire dynamique peuvent réduire le temps d'arrêt et permettre de mieux répondre aux changements des exigences.

Pour plus d'informations sur la mémoire dynamique, voir Tâche 1b : Définir la mémoire, qui explique comment déterminer la mémoire d'un ordinateur virtuel.

Informations complémentaires :

Vue d'ensemble de la mémoire dynamique Hyper-V

Vue d'ensemble de la topologie NUMA virtuelle Hyper-V

Tâche 1c : Définir l'édition du système d'exploitation Windows Server

Les ensembles de fonctionnalités proposés dans Windows Server Standard Edition et Windows Server Datacenter sont parfaitement identiques. Windows Server Datacenter fournit un nombre illimité d'ordinateurs virtuels. Avec Windows Server Standard, vous êtes limité à deux ordinateurs virtuels.

Dans Windows Server 2012 R2, la fonctionnalité d'activation automatique d'ordinateur virtuel a été ajoutée. Celle-ci vous permet d'installer des ordinateurs virtuels sur un serveur correctement activé sans avoir à gérer les clés de produit pour chaque ordinateur virtuel, même dans des environnements déconnectés.

Elle nécessite que les systèmes d'exploitation invités exécutent Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard ou Windows Server 2012 R2 Essentials. Le tableau suivant compare les éditions.

Édition	Avantages	Inconvénients
Standard	Inclut toutes les fonctionnalités de Windows Server Acceptable pour les environnements non virtualisés ou peu virtualisés	Limité à deux ordinateurs virtuels
Datacenter	Inclut toutes les fonctionnalités de Windows Server Autorise un nombre illimité d'ordinateur virtuels Acceptable pour les environnements de cloud privé hautement virtualisés	Plus coûteux

Hyper-V peut être installé sur une option d'installation Server Core de Windows Server. Une installation Server Core permet de réduire l'espace nécessaire sur le disque, la surface d'attaque potentielle et en particulier les besoins en maintenance. Une installation Server Core est gérée à l'aide de la ligne de commande, de Windows PowerShell ou par administration à distance.

Il est important de consulter les termes du contrat de licence de tout logiciel que vous prévoyez d'utiliser.

Microsoft Hyper-V Server

Microsoft Hyper-V Server fournit une solution de virtualisation fiable et simple pour aider les organisations à améliorer leur utilisation du serveur et à réduire les coûts. Il s'agit d'un produit autonome qui contient uniquement l'hyperviseur Windows, un modèle de pilote Windows Server et les composants de virtualisation.

Hyper-V Server peut s'intégrer aux environnements informatiques existants des clients et tirer parti de la configuration, des processus de gestion et des outils de support existants. Il prend en charge la même liste de compatibilité matérielle que les éditions correspondantes de Windows Server et s'intègre parfaitement avec Microsoft System Center et les technologies Windows telles que Windows Update, Active Directory et le clustering avec basculement.

Hyper-V Server est disponible en téléchargement gratuit et son installation est automatique. Toutefois, une licence appropriée est nécessaire pour chacun des systèmes d'exploitation qui s'exécutent sur un ordinateur virtuel hébergé.

Informations complémentaires :

Activation automatique d'ordinateur virtuel

Microsoft Hyper-V Server

Gérer Hyper-V Server à distance

Tâche 2 : Définir la configuration du réseau

À l'Étape 2, Tâche 2 ci-dessus, nous avons abordé les considérations de conception relatives à la mise en réseau de l'ordinateur virtuel. Nous allons maintenant aborder ces même considérations pour la mise en réseau de l'hôte. Il existe plusieurs types de trafic réseau que vous devez prendre en compte et planifier lorsque vous déployez Hyper-V. Vous devez concevoir la configuration de votre réseau avec les objectifs suivants à l'esprit :

• garantir la qualité de service du réseau ;

• assurer la redondance du réseau ;

• isoler le trafic dans des réseaux définis.

Tâche 2a : Définir les types de trafic réseau

Lorsque vous déployez un cluster Hyper-V, vous devez planifier différents types de trafic réseau. Le tableau suivant récapitule les types de trafic.

Type de trafic	Description
Gestion	Fournit la connectivité entre le serveur qui exécute Hyper-V et les fonctionnalités d'infrastructure de base Utilisé pour gérer le système d'exploitation de l'hôte Hyper-V et les ordinateurs virtuels
Cluster et volumes partagés de cluster	Utilisés pour la communication entre les nœuds de cluster comme la pulsation de cluster et la redirection de volumes partagés de cluster (CSV, Cluster Shared Volumes) Uniquement si Hyper-V a été déployé à l'aide du clustering avec basculement
Migration en direct	Utilisé pour la migration dynamique d'ordinateur virtuel et la migration dynamique « shared nothing »
Stockage	Utilisé pour le trafic SMB ou le trafic iSCSI
Réplica	Utilisé pour le trafic de réplication d'ordinateur virtuel via la fonctionnalité Réplica Hyper-V
Trafic de l'ordinateur virtuel (client)	Utilisé pour la connectivité de l'ordinateur virtuel Nécessite généralement une connectivité réseau externe pour traiter les demandes clients Remarque : voir Étape 2 : Planifier la configuration des ordinateurs virtuels pour obtenir la liste des types de trafic des ordinateurs virtuels.
Sauvegarde	Utilisé pour sauvegarder les fichiers de disque dur virtuel

Tâche 2b : Définir les options de performances du trafic réseau

Pour chaque type de trafic réseau, une bande passante minimale et maximale, ainsi qu'une latence minimale sont requises. Voici les stratégies qui peuvent être utilisées pour répondre à différentes exigences de performances réseau.

Qualité de service (QoS) basée sur la stratégie

Lorsque vous déployez un cluster Hyper-V, vous avez besoin au minimum de six modèles de trafic ou réseaux. La redondance réseau est nécessaire pour chaque réseau. Commencez avec environ 12 cartes réseau dans l'hôte. Il est possible d'installer plusieurs cartes réseau quadruple port, mais vous finirez par manquer d'emplacements dans votre hôte.

L'équipement de mise en réseau est de plus en plus rapide. Il n'y a pas si longtemps, les cartes réseau de 1 Go étaient le haut de gamme. Les cartes de 10 Go se généralisent sur les serveurs et le coût de prise en charge des infrastructures de 10 Go devient plus raisonnable.

L'installation de deux cartes réseau associées de 10 Go fournit davantage de bande passante que deux cartes 1 Go quadruple port, nécessite moins de ports commutés et simplifie le câblage. À mesure que vous convergez vos types de trafic réseau sur les cartes réseau associées de 10 Go, la QoS basée sur la stratégie vous permet de gérer le trafic réseau pour répondre correctement aux besoins de votre infrastructure de virtualisation.

La QoS basée sur la stratégie vous permet de spécifier le contrôle de bande passante réseau, en fonction du type d'application, des utilisateurs et des ordinateurs. Les stratégies de qualité de service vous permettent de répondre aux impératifs de service d'une charge de travail ou d'une application en mesurant la bande passante réseau, en détectant les changements de conditions réseau (par exemple, congestion ou disponibilité de la bande passante) et en hiérarchisant (ou en limitant) le trafic réseau.

En plus la bande passante maximale, les stratégies de QoS dans Windows Server 2012 R2 fournissent une nouvelle fonctionnalité de gestion de la bande passante : la bande passante minimale. Contrairement à la bande passante maximale, qui est un plafond de bande passante, la bande passante minimale est un seuil de bande passante qui affecte une certaine quantité de bande passante à un type de trafic donné. Vous pouvez implémenter simultanément des limites de bande passante minimale et maximale.

Avantages	Inconvénients
Gérée par la stratégie de groupe Facilement appliquée aux réseaux locaux virtuels pour fournir les paramètres de bande passante appropriés lorsque plusieurs réseaux locaux virtuels sont en cours d'exécution sur la carte réseau ou utilisent l'association de cartes réseau. La QoS basée sur la stratégie peut être appliqué au trafic IPsec	Ne permet pas de gérer la bande passante pour le trafic utilisant un commutateur virtuel Les hôtes Hyper-V doivent être joints au domaine Les stratégies de QoS basées sur les logiciels et les stratégies de QoS basées sur le matériel (DCB) ne doivent pas être utilisées en même temps

Informations complémentaires :

Vue d'ensemble de la qualité de service (QoS)

Qualité de service (QoS) basée sur la stratégie

Data Center Bridging

Data Center Bridging (DCB) offre une attribution de bande passante reposant sur le matériel à un type spécifique de trafic et améliore la fiabilité du transport Ethernet avec l’utilisation d’un contrôle de flux fondé sur les priorités. DCB est recommandé si FCoE et iSCSI sont utilisés.

Avantages	Inconvénients
Prise en charge de Microsoft iSCSI Prise en charge de FCoE	Investissements matériels requis, notamment : Cartes Ethernet prenant en charge DCB Commutateurs matériels prenant en charge DCB Déploiement et gestion complexes Pas de gestion de la bande passante pour le trafic de commutateur virtuel Les stratégies de QoS basées sur les logiciels et les stratégies de QoS basées sur le matériel ne doivent pas être utilisées en même temps

Informations complémentaires :

Vue d'ensemble de Data Center Bridging (DCB)

SMB Direct

SMB Direct (SMB sur RDMA) est un protocole de stockage dans Windows Server 2012 R2. Il permet les transferts directs de données de mémoire à mémoire entre le serveur et le système de stockage. Il nécessite une consommation minime du processeur et utilise des cartes réseau standard prenant en charge RDMA. Ainsi, les réponses aux demandes du réseau sont extrêmement rapides et du coup, les temps de réponse pour le stockage de fichiers à distance et pour le stockage par bloc en attachement direct sont les mêmes.

Avantages

Inconvénients

Débit accru : tire parti du débit complet des réseaux à haut débit dans lesquels les cartes réseau coordonnent le transfert de grandes quantités de données à la vitesse de ligne Latence faible : fournit des réponses extrêmement rapides aux demandes du réseau et par conséquent, le stockage de fichiers à distance semble être un stockage par bloc directement attaché Utilisation faible du processeur : utilise moins de cycles processeur lors du transfert de données sur le réseau, ce qui libère des cycles processeur pour les ordinateurs virtuels La migration dynamique peut être configurée pour utiliser SMB Direct afin d'accélérer les migrations dynamiques. Activé par défaut sur l'hôte Le client SMB détecte et utilise automatiquement plusieurs connexions réseau si une configuration appropriée est identifiée. Configurez la gestion de la bande passante SMB de manière à définir des limites pour la migration dynamique, les ordinateurs virtuels et le trafic de stockage par défaut SMB Multichannel ne nécessite pas de cartes réseau prises en charges par RDMA

Les cartes réseau compatibles RDMA ne sont pas compatibles avec l'association de cartes réseau Nécessite le déploiement d'au moins deux cartes réseau RDMA dans chaque hôte pour fournir une haute disponibilité Actuellement limité aux types de cartes réseau suivants : iWARP Infiniband RoCE RDMA avec RCI nécessite DCB pour le contrôle de flux.

RSC (Receive Segment Coalescing)

RSC (Receive Segment Coalescing) réduit l’utilisation du processeur pour le traitement réseau entrant en déchargeant des tâches de l’unité centrale vers une carte réseau compatible RSC.

Avantages

Inconvénients

Améliore l'évolutivité des serveurs en réduisant la surcharge pour le traitement d'une grande quantité de trafic réseau entrant Réduit au maximum les cycles processeur consacrés au stockage réseau et aux migrations dynamiques

Nécessite une carte réseau compatible RSC N'apporte aucune amélioration significative pour les charges de travail intensives en envois Non compatible avec le trafic IPsec chiffré S'applique au trafic hôte. Pour appliquer RSC au trafic d'un ordinateur virtuel, celui-ci doit exécuter Windows Server 2012 R2 et être configuré avec une carte réseau SR-IOV. Non activé par défaut sur les serveurs mis à niveau vers Windows Server 2012 R2

Partage du trafic entrant

Partage du trafic entrant (RSS, Receive Side Scaling) permet aux cartes réseau de distribuer la charge de traitement réseau en mode noyau sur plusieurs cœurs de processeurs dans des ordinateurs multicœurs. La distribution de ce traitement permet la gestion de charges de trafic réseau plus élevées qu’un simple cœur ne pourrait assumer. RSS parvient à ce résultat en répartissant la charge de traitement réseau entre plusieurs processeurs et en équilibrant de manière active la charge du trafic terminé par TCP (Transmission Control Protocol).

Avantages	Inconvénients
Répartit l'analyse des interruptions sur plusieurs processeurs, ainsi la gestion de toutes les interruptions d'E/S, qui étaient courantes avec les versions antérieures de Windows Server, ne revient pas à un seul processeur. Fonctionne avec l'association de cartes réseau Fonctionne avec le trafic UDP (User Datagram Protocol)	Nécessite une carte réseau compatible RSS Désactivé si la carte réseau virtuelle est liée à un commutateur virtuel. VMQ est utilisé à la place de RSS pour les cartes réseau liées à un commutateur virtuel.

SR-IOV

Hyper-V prend en charge les périphériques réseau compatibles SR-IOV et permet l'affectation directe d'une fonction virtuelle SR-IOV d'une carte réseau physique à un ordinateur virtuel. Cela augmente le débit du réseau, réduit la latence du réseau et réduit le temps processeur hôte nécessaire pour traiter le trafic réseau.

Pour plus d'informations sur SR-IOV, voir Tâche 2b : Définir les options de performances du trafic réseau ci-dessous.

Tâche 2c : Définir la stratégie de haute disponibilité et d'agrégation de bande passante du trafic réseau

L'association de cartes réseau, également appelée fonctionnalité d'équilibrage de charge et de basculement, permet de regrouper plusieurs cartes réseau pour les besoins de basculement du trafic et d'agrégation de bande passante. Cela permet de maintenir la connectivité en cas de défaillance d’un composant réseau.

Cette fonctionnalité était disponible chez les fournisseurs de cartes réseau. Introduite dans Windows Server 2012, l'association de cartes réseau est incluse en tant que fonctionnalité dans le système d'exploitation Windows Server.

L'association de cartes réseau est compatible avec toutes les fonctionnalités réseau de Windows Server 2012 R2 à trois exceptions près :

• SR-IOV

• RDMA

• Authentification 802.1X

Du point de vue de l'évolutivité, dans Windows Server 2012 R2, 1 carte réseau minimum et 32 cartes maximum peuvent être ajoutées à une association. Un nombre illimité d'associations peuvent être créées sur un hôte unique.

Informations complémentaires :

Vue d'ensemble de l'association de cartes réseau

Microsoft Virtual Academy : Association de cartes réseau dans Windows Server 2012

Applets de commande d'association de cartes réseau (NetLBFO) dans Windows PowerShell

Déploiement et gestion de l'association de cartes réseau (LBFO) dans Windows Server 2012 R2

Centre de données convergé avec stockage des serveurs de fichiers

Tâche 2d : Définir la stratégie d'isolation et de sécurité du trafic réseau

Chaque type de trafic réseau peut avoir des exigences de sécurité différentes pour des fonctions comme l'isolation et le chiffrement. Le tableau suivant répertorie les stratégies qui peuvent être utilisées pour répondre à différentes exigences de sécurité.

Stratégie	Avantages	Inconvénients
Chiffrement (IPsec)	Le trafic est sécurisé tout au long de sa transmission	Impact sur les performances du chiffrement et du déchiffrement du trafic Configuration, gestion et dépannage complexes La modification incorrecte de la configuration IPsec peut conduire à des perturbations du réseau ou au chiffrement erroné du trafic
Réseaux physiques distincts	Le réseau est physiquement séparé	Nécessite l'installation de cartes réseau supplémentaires dans l'hôte Si le réseau requiert une haute disponibilité, deux ou plusieurs cartes réseau sont nécessaires pour chaque réseau.
Réseau local virtuel (VLAN)	Isole le trafic avec l'attribution d'un ID de réseau local virtuel Prise en charge du protocole VTP (VLAN Trunking Protocol) Prise en charge des réseaux locaux virtuels privés Déjà utilisé par de nombreux clients en entreprise	Limité à 4 094 réseaux locaux virtuels et la plupart des commutateurs ne prennent en charge que 1 000 réseaux locaux virtuels Nécessite des tâches supplémentaires de configuration et de gestion de l'équipement réseau Les réseaux locaux virtuels ne peuvent pas s'étendre sur plusieurs sous-réseaux Ethernet, ce qui limite le nombre de nœuds dans un même réseau local virtuel et restreint la sélection élective d'ordinateurs virtuels en fonction des emplacements physiques.

Tâche 2e : Définir les cartes réseau virtuelles

Maintenant que vous avez déterminé les types de trafic requis par les hôtes serveur de virtualisation et défini les stratégies de performances, disponibilité et sécurité pour le trafic, vous pouvez déterminer le nombre de cartes réseau physiques qui sont nécessaires pour chaque hôte et les types de trafic réseau qui sera transmis sur chaque carte.

Tâche 2f : Définir les commutateurs virtuels

Pour connecter un ordinateur virtuel à un réseau, vous devez connecter la carte réseau à un commutateur virtuel Hyper-V.

Il existe trois types de commutateurs virtuels qui peuvent être créés dans Hyper-V :

• Commutateur virtuel externe

  Utilisez un commutateur virtuel externe lorsque vous souhaitez fournir aux ordinateurs virtuels un accès à un réseau physique pour communiquer avec les clients et serveurs externes. Ce type de commutateur virtuel permet également à des ordinateurs virtuels situés sur le même hôte de communiquer entre eux. Ce type de réseau peut également être utilisé par le système d'exploitation hôte, en fonction de la configuration de la mise en réseau.

  Important : une carte réseau physique ne peut être liée qu'à un seul commutateur virtuel à la fois.

• Commutateur virtuel interne

  Utilisez un commutateur virtuel externe lorsque vous souhaitez autoriser la communication entre les ordinateurs virtuels situés sur le même hôte et entre les ordinateurs virtuels et le système d'exploitation hôte. Ce type de commutateur virtuel est généralement utilisé pour créer un environnement de test dans lequel vous devez vous connecter aux ordinateurs virtuels à partir du système d'exploitation hôte. Un commutateur virtuel interne n'est pas lié à une carte réseau physique. Par conséquent, un réseau virtuel interne est isolé du trafic réseau externe.

• Commutateur virtuel privé

  Utilisez un commutateur virtuel privé lorsque vous souhaitez autoriser la communication uniquement entre les ordinateurs virtuels situés sur le même hôte. Un commutateur virtuel interne n'est pas lié à une carte réseau physique. Un commutateur virtuel privé est isolé de l'ensemble du trafic réseau externe sur le serveur de virtualisation et de tout trafic réseau entre le système d'exploitation hôte et le réseau externe. Ce type de réseau est utile lorsque vous avez besoin de créer un environnement réseau isolé, comme un domaine de test isolé.

  Remarque : les commutateurs virtuels privés et internes ne bénéficient pas des fonctionnalités d'accélération matérielle qui sont disponibles pour un ordinateur virtuel connecté à un commutateur virtuel externe

Décision de conception - Les décisions que vous prenez dans chacune des tâches de cette étape peuvent être entrées dans la feuille de calcul Virtualization hosts (Hôtes de virtualisation).

Conseil : les commutateurs virtuels sur différents hôtes qui se connectent au même réseau doivent porter le même nom. Cela évite toute confusion sur le commutateur virtuel auquel un ordinateur doit se connecter et simplifie le déplacement d'un ordinateur virtuel d'un hôte vers un autre. L'applet de commande Windows PowerShell Move-VM échoue si le même nom de commutateur virtuel n'existe pas sur l'hôte de destination.

Tâche 3 : Définir la configuration du stockage

En plus d'avoir accès au stockage nécessaire pour le système d'exploitation hôte, chaque hôte doit avoir accès au stockage dans lequel se trouvent les fichiers de configuration des ordinateurs virtuels et les disques durs virtuels. Cette tâche concerne uniquement le stockage de l'ordinateur virtuel.

Tâche 3a : Définir les types de données

Voici les exemples de types de données dont vous devez tenir compte pour déterminer vos besoins de stockage :

Type de données	Emplacement de stockage du type de données
Fichiers du système d'exploitation hôte	En général, sur un disque dur local
Fichier d'échange hôte et vidages sur incident dans Windows	En général, sur un disque dur local
État partagé du cluster de basculement	Stockage réseau partagé ou volume partagé de cluster
Fichiers de disque dur virtuel et fichier de configuration d'ordinateur virtuel	En général, sur un stockage réseau partagé ou un volume partagé de cluster

La suite de cette étape est axée sur le stockage nécessaire pour les ordinateurs virtuels.

Tâche 3b : Options de stockage

Les options suivantes sont disponibles pour le stockage des fichiers de configuration des ordinateurs virtuels et les disques durs virtuels.

Option 1 : Stockage en attachement direct

Le stockage en attachement direct fait référence à un système de stockage informatique qui est directement attaché à votre serveur, au lieu d'être directement attaché à un réseau. Le stockage en attachement direct n'est pas limité au stockage interne. Il peut également utiliser un boîtier externe qui contient des lecteurs de disques durs, notamment les boîtiers JBOD (just-a-bunch-of-disks) et les boîtiers qui sont connectés via SAS ou un autre contrôleur de disque.

Avantages

Inconvénients

Ne nécessite pas de réseau de stockage E/S disque rapides ; les demandes de stockage n'ont donc pas besoin de transiter sur un réseau Il peut s'agir d'un stockage interne ou d'un boîtier de disques externe, notamment les boîtiers JBOD Vous pouvez utiliser un boîtier JBOD avec la technologie des espaces de stockage pour combiner tous vos disques physiques dans un pool de stockage, puis créer un ou plusieurs disques virtuels (appelés espaces de stockage) à partir de l'espace libre dans le pool. Les boîtiers JBOD sont généralement moins chers et souvent plus flexibles et faciles à gérer que les boîtiers RAID car ils utilisent les systèmes d'exploitation Windows ou Windows Server pour gérer le stockage au lieu d'utiliser des adaptateurs RAID dédiés.

Nombre limité de serveurs pouvant être attachés au boîtier de disques externe Seul le stockage partagé externe, comme SAS partagé avec espaces de stockage, prend en charge le clustering avec basculement

Option 2 : Stockage NAS

Les dispositifs de stockage NAS connectent le stockage à un réseau où ils sont accessibles via les partages de fichiers. Contrairement au stockage en attachement direct, ils ne sont pas directement attachés à l'ordinateur.

Les dispositifs de stockage NAS prennent en charge les connexions Ethernet et permettent généralement à un administrateur de gérer l'espace disque, de définir les quotas de disques, d'assurer la sécurité et d'utiliser les technologies de point de contrôle. Les dispositifs de stockage NAS prennent en charge plusieurs protocoles parmi lesquels le protocole NFS (Network File System), le protocole CIFS (Common Internet File Systems) et le protocole SMB (Server Message Block).

Avantages

Inconvénients

Plus simple à configurer que le stockage SAN, nécessitant moins de matériel de stockage dédié Plug-and-play Peut utiliser le réseau Ethernet existant

Le dispositif de stockage NAS doit prendre en charge SMB 3.0. Le protocole CIFS n'est pas pris en charge. Pas directement attaché aux serveurs hôtes qui accèdent au stockage Plus lent que d'autres options Nécessite généralement un réseau dédié pour des performances optimales Fonctionnalités et gestion limitées Hyper-V prend en charge les dispositifs de stockage NAS qui prennent en charge SMB 3.0 et SMB 2.0 ; mais pas CIFS Peut ou non prendre en charge RDMA

Option 3 : Réseau de zone de stockage

Un réseau de zone stockage (SAN) est un réseau dédié qui vous permet de partager un stockage. Un réseau SAN est constitué d'un dispositif de stockage, de l'infrastructure réseau d'interconnexion (commutateurs, adaptateurs de bus hôte et câblage) et des serveurs qui sont connectés à ce réseau. Les périphériques SAN fournissent un accès continu et rapide à de grandes quantités de données. Le mécanisme de communication et de transfert de données pour un déploiement donné est généralement appelé une structure de stockage.

Un réseau SAN utilise un réseau distinct et il n'est généralement pas accessible par d'autres périphériques sur le réseau local. Un réseau SAN peut être géré à l'aide du protocole SMI-S (Storage Management Initiative Specification), SNMP (Simple Network Management Protocol) ou d'un protocole de gestion propriétaire.

Un réseau SAN ne propose pas l'abstraction de fichier, mais uniquement les opérations de niveau bloc. Les protocoles SAN les plus courants utilisés sont iSCSI, Fibre Channel et Fibre Channel on Ethernet (FCoE). Un protocole SMI-S ou un protocole de gestion propriétaire peut fournir des fonctionnalités supplémentaires, telles que la segmentation de disque, le mappage de disque, le masquage LUN et la gestion des erreurs.

Avantages

Inconvénients

Le réseau SAN utilise un réseau séparé ce qui limite l'impact sur le réseau de données Fournit un accès continu et rapide à de grandes quantités de données. En général, fournit des fonctionnalités supplémentaires telles que la protection et la réplication des données Peut être partagé entre différentes équipes Prise en charge de Fibre Channel virtuel pour l'accès direct aux numéros d'unité logique de stockage Prise en charge du clustering invité Les ordinateurs virtuels qui doivent accéder à des volumes de données supérieurs à 64 To peuvent utiliser Fibre Channel virtuel pour accéder directement aux numéros d'unités logiques

Coûteux Nécessite des compétences particulières pour le déploiement, la gestion et la maintenance Des cartes réseau HBA ou FCoE doivent être installées sur chaque hôte. La migration d'un cluster Hyper-V nécessite une planification supplémentaire et un temps d'arrêt limité. Pour assurer la gestion de la bande passante pour le trafic FCoE, une stratégie de QoS qui utilise le pontage de centre de données est nécessaire. Le trafic FCoE ne peut pas être routé.

Option 4 : Partages de fichiers SMB 3.0

Hyper-V peut stocker des fichiers d'ordinateur virtuel, comme les fichiers de configuration, les fichiers de disque dur virtuel et les points de contrôle, dans des partages de fichiers qui utilisent le protocole Server Message Block (SMB) 3.0. Les partages de fichiers seront généralement placés sur un serveur de fichiers avec montée en puissance parallèle pour assurer la redondance. Lorsque vous exécutez un serveur de fichiers avec montée en puissance parallèle, si un nœud est inactif, les partages de fichiers sont toujours disponibles à partir des autres nœuds du serveur.

Avantages

Inconvénients

Possibilité d'utiliser les protocoles et réseaux existants SMB Multichannel fournit l'agrégation de la bande passante réseau et la tolérance de panne lorsque plusieurs chemins sont disponibles entre le serveur exécutant Hyper-V et le partage de fichiers SMB 3.0. Vous pouvez utiliser un boîtier JBOD avec la technologie des espaces de stockage pour combiner tous vos disques physiques dans un pool de stockage, puis créer un ou plusieurs disques virtuels (appelés espaces de stockage) à partir de l'espace libre dans le pool. SMB Multichannel peut être utilisé pour les migrations d'ordinateurs virtuels. Moins chers que les déploiements SAN Configurations de stockage souples sur le serveur de fichiers exécutant Windows Server Services Hyper-V séparés des services de stockage, ce qui vous permet de faire évoluer chaque service en fonction des besoins Flexibilité lors de la mise à niveau vers la version suivante lors de l'exécution d'un cluster Hyper-V. Vous pouvez mettre à niveau les serveurs exécutant Hyper-V ou les serveurs de fichiers avec montée en puissance parallèle dans n'importe quel ordre sans temps d'arrêt. Vous avez besoin d'une capacité suffisante dans le cluster pour supprimer un ou deux nœuds afin d'effectuer la mise à niveau. Le serveur de fichiers avec montée en puissance parallèle prend en charge VHDX partagé La gestion de la bande passante SMB vous permet de définir des limites pour la migration dynamique, le disque dur virtuel et le trafic de stockage par défaut. Prise en charge du chiffrement du trafic SMB avec un impact minimal sur les performances Économie d'espace disque avec la déduplication des données pour les déploiements VDI Ne nécessite aucune compétence particulière pour le déploiement, la gestion et la maintenance

Performances d'E/S pas aussi rapides que dans les déploiements SAN. La déduplication des données n'est pas prise en charge sur les fichiers d'ordinateurs virtuels en cours d'exécution, sauf pour les déploiements VDI.

SMB Direct

SMB Direct fonctionne dans le cadre des partages de fichiers SMB. SMB Direct nécessite des cartes réseau et des commutateurs qui prennent en charge RDMA pour fournir un accès au stockage à vitesse maximale et faible latence. SMB Direct permet aux serveurs de fichiers à distance de passer pour un stockage local et un stockage en attachement direct. Outre les avantages de SMB, SMB Direct offre les avantages et inconvénients suivants.

Avantages

Inconvénients

Fonctionne à pleine vitesse avec une faible latence, tout en utilisant très peu le processeur Permet à un serveur de fichiers avec montée en puissance parallèle d'offrir des performances de stockage et une résilience similaires à un réseau SAN traditionnel avec l'utilisation des solutions de stockage Microsoft et du stockage en attachement direct partagé peu coûteux Option la plus rapide pour les migrations dynamiques et les migrations de stockage

Non pris en charge avec l'association de cartes réseau Deux ou plusieurs cartes réseau prenant en charge RDMA sont requises pour les connexions redondantes au stockage.

Figure 3 :Exemple de serveur de fichiers avec montée en puissance parallèle qui utilise la mise en réseau convergée avec RDMA

Informations complémentaires :

Fournir un stockage économique pour les charges de travail Hyper-V à l'aide de Windows Server

Centre de données convergé avec stockage des serveurs de fichiers

Déployer Hyper-V sur SMB

Atteindre plus de 1 millions d'E/S par seconde sur des ordinateurs virtuels Hyper-V dans un cluster de serveur de fichiers avec montée en puissance parallèle à l'aide de Windows Server 2012 R2

Tâche 3c : Définir les types d'architecture de lecteur physique

Le type d'architecture de lecteur physique que vous sélectionnez pour votre stockage aura un impact sur les performances de votre solution de stockage. Pour plus d'informations sur les types de disques, voir la Section 7.1 du document Architecture de la gamme de produits Infrastructure en tant que service.

Tâches 3d : Définir le type de mise en réseau de stockage

Les types de contrôleur de stockage ou de contrôleur de mise en réseau de stockage que vous utilisez sont déterminés par l'option de stockage que vous sélectionnez pour chaque groupe hôte. Pour plus d'informations, voir Tâche 3b : Options de stockage.

Tâche 3e : Déterminer le type de stockage à utiliser pour chaque type de données

Maintenant que vous avez déterminé vos types de données, vous pouvez déterminer quelle option de stockage, contrôleur de stockage, contrôleur de mise en réseau de stockage et architectures de disques physiques répondent le mieux à vos besoins.

Décision de conception - Les décisions que vous prenez dans cette tâche peuvent être entrées dans la feuille de calcul Virtualization hosts (Hôtes de virtualisation).

Informations complémentaires :

Configurations de mise en réseau pour Hyper-V sur SMB dans Windows Server 2012 et Windows Server 2012 R2

Poster et autres références sur l'architecture du composant Hyper-V de Windows Server 2012

Vue d'ensemble des technologies de stockage

Tâche 4 : Définir les unités d'échelle de l'hôte de virtualisation de serveur

L'achat de serveurs individuels suppose l'approvisionnement, l'installation et la configuration de chacun des serveurs. Les unités d'échelle vous permettent d'acheter des collections de serveurs (dont le matériel est généralement identique). Ils sont préconfigurés, ce qui vous permet d'augmenter la capacité du centre de données en ajoutant des unités d'échelle, plutôt qu'en ajoutant des serveurs individuels.

L'image ci-dessous illustre une unité d'échelle qui pourrait avoir été achetée préconfigurée auprès de bon nombre de fournisseurs de matériel. Elle comprend un rack, un onduleur, une paire de commutateurs réseau redondants pour les serveurs contenus dans le rack et dix serveurs.

Figure 4 :Exemple d'unité d'échelle d'hôte serveur de virtualisation

L'unité d'échelle est préconfigurée et précâblée à l'onduleur et aux commutateurs réseau. L'unité doit simplement être ajoutée à un centre de données, branché sur l'alimentation électrique et connecté au réseau et au stockage. Elle est ensuite prête à être utilisée. Si les composants individuels n'ont pas été achetés en tant qu'unité d'échelle, l'acheteur devra monter en rack et câbler tous les composants.

Décision de conception - Si vous décidez d'utiliser des unités d'échelle d'hôte de virtualisation de serveur, vous pouvez définir le matériel de vos unités d'échelle d'hôte de virtualisation dans la feuille de calcul Host scale units (Unités d'échelle hôte).

Conseil : vous pouvez acheter des unités d'échelle préconfigurées auprès de nombreux partenaires Microsoft via le programme Microsoft Private Cloud Fast Track.

Tâche 5 : Définir la stratégie de disponibilité des hôtes de virtualisation de serveur.

Les hôtes serveur de virtualisation peuvent devenir indisponibles pour des raisons planifiées (comme la maintenance) ou des raisons non planifiées. Voici quelques stratégies qui peuvent être utilisées dans les deux cas.

Planifié

Vous pouvez utiliser la migration dynamique pour déplacer les ordinateurs virtuels d'un hôte vers un autre hôte. Cela ne nécessite aucune interruption de service pour les ordinateurs virtuels.

Non planifié

Ce scénario dépend des types de caractéristiques de la charge de travail hébergés par l'hôte.

• Pour les charges de travail avec état partagés, utilisez le clustering avec basculement dans les ordinateurs virtuels.

• Pour les charges de travail avec état, lancez l'exécution en tant qu'ordinateur virtuel haute disponibilité sur un cluster Hyper-V.

• Pour les charges de travail sans état, démarrez de nouvelles instances manuellement ou via des moyens automatisés.

Si vous utilisez le clustering avec basculement dans Windows Server avec Hyper-V, envisagez d'utiliser les fonctionnalités répertoriées dans le tableau suivant. Pour plus d'informations sur chaque fonctionnalité, cliquez sur le lien hypertexte.

Fonctionnalité	Éléments à prendre en considération
Analyse des applications Hyper-V	Analysez un ordinateur virtuel pour les défaillances de mise en réseau et de stockage qui ne sont pas contrôlées par le service de clustering avec basculement.
Paramètres de priorité des ordinateurs virtuels	Définissez la priorité des ordinateurs virtuels, en fonction de la charge de travail. Vous pouvez attribuer les mêmes paramètres de priorité aux ordinateurs virtuels haute disponibilité (également appelés ordinateurs virtuels en cluster) : Élevé Moyenne (par défaut) Faible Pas de démarrage automatique Les rôles en cluster avec une priorité plus élevée sont démarrés et placés sur des nœuds avant ceux de priorité inférieure. Si une priorité Pas de démarrage automatique est affectée, le rôle ne se connecte pas automatiquement après un échec, ce qui laisse les ressources disponibles et permet le démarrage d'autres rôles.
Anti-affinité des ordinateurs virtuels	Définissez l'anti-affinité pour les ordinateurs virtuels que vous ne voulez pas exécuter sur le même nœud dans un cluster Hyper-V. Il peut s'agir d'ordinateurs virtuels qui fournissent des services redondants ou font partie du cluster d'ordinateur virtuel invité. Remarque : les paramètres anti-d'affinité sont configurés avec Windows PowerShell.
Drainage de nœud automatisé	Le cluster draine automatiquement un nœud (déplace les rôles en cluster qui sont en cours d'exécution sur le nœud vers un autre nœud) avant de mettre le nœud en mode de maintenance ou de lui apporter d'autres modifications. Les rôles sont automatiquement restaurés sur le nœud d'origine après les opérations de maintenance. Les administrateurs peuvent drainer un nœud en une seule action dans le gestionnaire du cluster de basculement ou à l'aide de l'applet de commande Windows PowerShell Suspend-ClusterNode. Le nœud cible des rôles en cluster déplacés peut être spécifié. La mise à jour adaptée aux clusters utilise le drainage de nœuds dans le processus automatisé pour appliquer des mises à jour logicielles aux nœuds de cluster.
Mise à jour adaptée aux cluster	La mise à jour adaptée aux clusters vous permet de mettre à jour les nœuds d'un cluster sans impact sur les ordinateurs virtuels en cours d'exécution dans votre cluster. Un nombre suffisant de nœuds de cluster doit rester disponible pendant le processus de mise à jour pour gérer la charge des ordinateurs virtuels en cours d'exécution.
Préemption des ordinateurs virtuels en fonction de la priorité	Une autre raison pour laquelle définir la priorité des ordinateurs virtuels est que le service de cluster peut mettre hors connexion un ordinateur virtuel dont le niveau de priorité est plus bas lorsqu'un ordinateur virtuel de haute priorité n'a pas la mémoire et autres ressources nécessaires pour démarrer. La préemption commence par l'ordinateur virtuel dont le niveau de priorité est plus bas et continue jusqu'aux ordinateurs virtuels de haute priorité. Les ordinateurs virtuels qui sont préemptés sont redémarrés plus tard dans l'ordre de priorité.

Remarque : les clusters Hyper-V peuvent avoir au maximum 64 nœuds et 8 000 ordinateurs virtuels.

Étape 5 : Planifier les concepts d'architecture de la structure de virtualisation

Cette étape prévoit la définition des concepts logiques sur lesquels s'alignera l'architecture de la structure.

Tâche 1 : Définir des domaines de maintenance

Les domaines de maintenance sont des collections logiques de serveurs qui sont traités ensemble. La maintenance peut inclure les mises à niveau matérielles ou logicielles, ou encore les modifications de configuration. Les domaines de maintenance englobent généralement les groupes hôtes de chaque type ou dans chaque emplacement, même si cela n'est pas obligatoire. L'objectif est de prévenir tout impact négatif de la maintenance du serveur sur les charges de travail des consommateurs.

Remarque : ce concept s'applique au réseau physique et aux composants de stockage.

Tâche 2 : Définir des domaines d'erreur physique

Les groupes d'hôtes serveur de virtualisation échouent souvent ensemble suite à l'échec d'un composant de l'infrastructure partagée, comme un commutateur réseau ou un onduleur (UPS). Les domaines d'erreur physique permettent de prendre en charge la résilience dans la structure de virtualisation. Il est important de comprendre l'impact d'un domaine d'erreur sur chacun des groupes hôtes que vous avez définis pour votre structure.

Remarque : ce concept s'applique au réseau physique et aux composants de stockage.

Prenons l'exemple de l'image ci-dessous dans lequel les domaines de maintenance et d'erreur physique se superposent sur une collection de groupes hôtes au sein d'un centre de données.

Figure 5 :Exemple de définition de domaine de maintenance et de domaine d'erreur physique

Dans cet exemple, chaque rack de serveurs est défini comme un domaine d'erreur physique distinct numéroté. Cela du fait que chaque rack contient un commutateur réseau en haut et un émulateur en bas. Tous les serveurs du rack s'appuient sur ces deux composants, et si l'un ou l'autre échoue, tous les serveurs du rack échouent également.

Étant donné que tous les serveurs d'un rack sont également membres de groupes hôtes uniques, cette conception signifie qu'en cas de défaillance d'un des domaines d'erreur physique aucune mesure d'atténuation n'est possible. Pour atténuer les problèmes, vous pouvez ajouter les domaines d'erreur physique de chaque type de groupe hôte. Dans les environnements plus petits, vous pourriez potentiellement ajouter un commutateur et des alimentations redondants dans chaque rack ou utiliser le clustering avec basculement pour les hôtes serveur de virtualisation dans les domaines d'erreur physique.

Dans la Figure 5, chacune zone délimitée par une ligne pointillée de couleur définit un domaine de maintenance (étiquetés DM 1 à 5). Notez comment chacun des serveurs du cluster à charge équilibrée d'ordinateurs virtuels est hébergé sur un hôte de virtualisation de serveur qui se trouve dans un domaine de maintenance distinct et un domaine d'erreur physique distinct.

Cela permet à l'administrateur de structure d'arrêter tous les hôtes serveur de virtualisation au sein d'un domaine de maintenance sans que cela ait un impact majeur sur les applications qui ont plusieurs serveurs répartis sur plusieurs domaines de maintenance. Cela signifie également que l'application en cours d'exécution sur le cluster à charge équilibrée n'est pas totalement indisponible en cas d'échec d'un domaine d'erreur physique.

Décision de conception - Les décisions que vous prenez dans les Tâches 1 et 2 peuvent être entrées dans la feuille de calcul Settings (Paramètres).

Tâche 3 : Définir la capacité de réserve

La défaillance de serveurs individuels dans la structure est inévitable. La conception de la structure doit prendre en compte la défaillance de serveurs individuels, comme il prend en compte la défaillance de collections de serveurs dans les domaines d'erreur et de maintenance. L'illustration suivante est identique à la Figure 5, mais la couleur rouge est utilisée pour identifier les trois serveurs en échec.

Figure 6 :Serveurs en échec

Dans la Figure 6, les hôtes de virtualisation de serveur ont échoué dans les groupes hôtes, les domaines de maintenance et les domaines d'erreurs physiques suivants.

Groupe hôte	Domaine d'erreur physique	Domaine de maintenance
2	2	3
3	3	2
4	4	2

L'application en cours d'exécution sur le cluster à charge équilibrée est toujours disponible, même si l'hôte dans le domaine d'erreur physique 2 a échoué, mais l'application fonctionnera à une capacité inférieure d'un tiers.

Envisagez ce qui se passerait si l'hôte de virtualisation de serveur qui hébergeait l'un des ordinateurs virtuels dans le domaine d'erreur physique 3 avait échoué ou si le domaine de maintenance 2 avait été arrêté pour maintenance. Dans ce cas, la capacité de l'application aurait baissé de 2/3.

Vous pouvez décider que cela est inacceptable pour votre structure de virtualisation. Pour atténuer l'impact des serveurs en échec, vous pouvez vous assurer que chacun de vos domaines d'erreur physique et domaines de maintenance dispose d'une capacité de réserve suffisante afin que la capacité ne descende jamais sous le niveau acceptable que vous définissez.

Pour plus d'informations sur le calcul de la capacité de réserve, voir Capacité de réserve dans le documents Cloud Services Foundation Reference Architecture – Principes, concepts et modèles.

Étape 6 : Planifier les caractéristiques de capacité initiales

Après avoir effectué toutes les tâches de ce document, vous serez en mesure de déterminer les coûts initiaux d'hébergement d'ordinateurs virtuels et de stockage sur la structure, de même que les niveaux de qualité de service initiaux que peut atteindre la structure. Vous ne pourrez pas finaliser ces tâches tant que vous n'aurez pas implémenté les outils de gestion de votre structure et les ressources humaines, qui sont présentés dans la section Étapes suivantes de ce document.

Tâche 1 : Définir les mesures SLA initiales pour le stockage et les ordinateurs virtuels

En tant qu'administrateur de structure, vous allez probablement définir un contrat de niveau de service (SLA) qui détaille les mesures de qualité de service auxquelles la structure répondra. Les administrateurs de votre ordinateur virtuel auront besoin de cette information pour planifier la manière dont les utilisateurs utiliseront la structure.

Au minimum, ces mesures incluront une mesure de disponibilité, mais elles peuvent également inclure d'autres mesures. Pour avoir une idée des mesures SLA d'une structure de virtualisation, vous pouvez consulter ce qui est proposé par les fournisseurs de cloud public comme Microsoft Azure. Pour l'hébergement d'ordinateurs virtuels, ce contrat garantit que lorsqu'un client déploie sur deux ou plusieurs instances d'un ordinateur virtuel exécutant la même charge de travail et déploie ces instances dans différents domaines d'erreur et de mise à niveau (appelés « domaines de maintenance » dans ce document), au moins un de ces ordinateurs virtuels sera disponible 99,95 % du temps.

Pour obtenir une description complète du contrat SLA pour Azure, voir Contrats de niveau de service. Idéalement, votre structure de virtualisation égalera ou dépassera les contrats de niveau de service des fournisseurs de cloud public.

Tâche 2 : Définir les coûts initiaux pour l'hébergement de stockage et d'ordinateurs virtuels

Une fois votre structure conçue, vous pourrez également calculer :

• les coûts en matériel, espace, alimentation et refroidissement de structure ;

• la capacité d'hébergement de la structure.

Ces informations, combinées aux autres coûts, comme le coût des outils de gestion de votre structure et des ressources humaines, vous permettront de déterminer les coûts finaux de l'hébergement des ordinateurs virtuels et du stockage.

Pour avoir une idée des coûts de base pour les ordinateurs virtuels et le stockage, vous pouvez examiner les coûts d'hébergement de fournisseurs de cloud public comme Microsoft Azure. Pour plus d'informations, voir Machines virtuelles - Tarification.

Même si ce n'est pas toujours le cas, vous constaterez généralement que vos coûts d'hébergement sont supérieurs à ceux des fournisseurs publics, car votre structure sera beaucoup plus petite que les structures de grands fournisseurs publics qui sont capables d'obtenir des remises sur volume pour le matériel, l'espace de centre de données et l'alimentation.

Étapes suivantes

Une fois que vous aurez terminé toutes les tâches de ce document, vous disposerez d'une conception de structure qui répond aux besoins de votre organisation. Vous disposerez également d'une définition des caractéristiques de service initiale qui inclut les coûts et les mesures de niveau de service. Vous ne pourrez pas déterminer vos métriques de niveau de service ni vos coûts finaux tant que vous n'aurez pas déterminé les coûts des ressources humaines et les outils et processus de gestion que vous utiliserez pour votre structure.

Microsoft System Center 2012 offre un ensemble complet de fonctionnalités vous permettant de configurer, d'analyser et de gérer votre structure de virtualisation. Pour plus d'informations sur l'utilisation de System Center pour la gestion de la structure, lisez les ressources suivantes :

Bibliothèque de documentation technique System Center

Guide de gestion de la structure