Gestion de la capacité et haute disponibilité dans un environnement virtuel (SharePoint Server 2010)

Article
02/05/2017

Dernière rubrique modifiée : 2016-11-30

Cet article fournit des informations sur la gestion de la capacité et sur la haute disponibilité pour un environnement virtuel hébergeant Microsoft SharePoint Server 2010. Ces deux concepts sont combinés dans cet article, car la capacité et le dimensionnement sont des composantes très importantes du développement d’un plan de virtualisation et de l’architecture d’un environnement virtuel et parce que la gestion de la capacité n’est pas isolée de la haute disponibilité dans un environnement virtuel. Dans le cas des hôtes de virtualisation, une capacité insuffisante risque de bloquer la haute disponibilité au niveau de la batterie de serveurs et au niveau de l’hôte.

Comme cela est le cas dans d’autres aspects d’un environnement virtuel, tels que la sauvegarde et la récupération, la gestion de la capacité et la haute disponibilité doivent prendre en charge les deux niveaux d’un environnement virtuel, à savoir les ordinateurs virtuels utilisés pour SharePoint Server 2010 et les serveurs physiques destinés à héberger ces ordinateurs virtuels. Dans le cas d’un environnement hybride, vous devez également gérer des serveurs de batterie Microsoft SharePoint Server physiques.

Dans cet article :

Vue d’ensemble de la virtualisation

La virtualisation de serveur, telle qu’implémentée par la Technologie Hyper-V de Windows Server 2008 ou Microsoft Hyper-V Server 2008, repose sur une configuration matérielle et est également appelée assistance matérielle à la virtualisation, par opposition à l’assistance logicielle à la virtualisation. L’hyperviseur Hyper-V dispose d’une voie de communication vers les composants matériels des serveurs physiques, et d’interaction avec ceux-ci, plus directe que les technologies d’assistance logicielle à la virtualisation qui, au final, s’avèrent moins performantes. Pour plus d’informations sur l’architecture Hyper-V, voir Introduction de Hyper-V dans Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=188006&clcid=0x40C) et Surveillance des performances Hyper-V (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=187746&clcid=0x40C).

Bien qu’un serveur physique puisse satisfaire à la configuration requise par Hyper-V, chaque serveur physique est unique. Chaque constructeur utilise sa propre implémentation des processeurs, de la technologie multicœur, de la mémoire, du bus de données, des disques durs et des cartes réseau. En outre, la conception et l’implémentation matérielles varient d’un modèle à l’autre, même si les modèles sont produits par le même constructeur. Il est donc indispensable que vous procédiez à des tests rigoureux lorsque vous déployez SharePoint Server 2010 dans un environnement virtuel.

Les logiciels et les applications présentent les mêmes variantes en termes de performances que le matériel. Certains programmes sont gourmands en ressources processeur, d’autres sont très exigeants en termes de mémoire, tandis que d’autres utilisent les disques durs de manière intensive. SharePoint Server a ses propres besoins en termes de capacité, de même qu’Internet Information Server (IIS) et SQL Server 2008. Là encore, des tests rigoureux s’imposent.

Dans le cadre de la gestion de la capacité, vous devez prendre en considération le serveur de virtualisation, la solution de stockage, l’infrastructure du réseau, les technologies en cours d’exécution dans un environnement SharePoint Server et les fonctionnalités activées pour l’implémentation de votre solution SharePoint Server.

Gestion de la capacité

La gestion de la capacité étend le concept de planification de la capacité de manière à exprimer une approche cyclique dans laquelle la capacité d’un déploiement SharePoint Server 2010 est en permanence surveillée et optimisée en fonction de l’évolution des conditions et des besoins. Vous pouvez appliquer cette approche à toutes les batteries de serveurs SharePoint Server, y compris à celles qui sont entièrement ou partiellement virtualisées. Pour une vue d’ensemble de la gestion de la capacité, voir Capacity management and sizing for SharePoint Server 2010. Des ressources supplémentaires sur la gestion de la capacité sont disponibles dans le Centre de ressources de la gestion de la capacité pour SharePoint Server 2010 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=194748&clcid=0x40C).

Capacité et dimensionnement des serveurs de virtualisation

Une fois établies les recommandations liées à la conception et au dimensionnement d’une batterie de serveurs SharePoint Server pour les serveurs de la batterie, vous concevez l’architecture de l’hôte de virtualisation physique nécessaire à la prise en charge de la batterie de serveurs virtuelle. Pour plus d’informations sur les architectures virtuelles, voir Planifier des architectures virtuelles (SharePoint Server 2010).

Il est recommandé d’appliquer des principes pouvant être tirés de la gestion de la capacité de SharePoint Server 2010 et de les utiliser comme guides pour un environnement virtuel. Les activités suivantes illustrent la nature itérative de la conception, du dimensionnement et de l’ajustement d’une architecture virtuelle et physique depuis la planification initiale jusqu’au déploiement dans un environnement de production.

Notes

Si vous effectuez une planification et des tests minutieux, les modifications à apporter aux configurations de l’architecture et des serveurs ne sont normalement requises qu’en cas d’augmentation significative et soudaine de la batterie de serveurs ou d’ajout de nouvelles fonctionnalités à votre solution SharePoint Server.

Avant de commencer le déploiement de la batterie de serveurs, créez une architecture virtuelle et physique avec dimensionnement des ordinateurs virtuels et des serveurs de virtualisation. Si l’environnement comprend plusieurs hôtes de virtualisation, cette architecture doit recourir à la répartition des ordinateurs virtuels.
Lors du déploiement, pendant la phase pilote, collectez les données d’intégrité et de performances permettant d’établir des tests d’évaluation des hôtes de virtualisation et des ordinateurs virtuels de la batterie de serveurs.
Lors du déploiement, pendant la phase de test d’acceptation utilisateur, ajustez les configurations des hôtes de virtualisation et des ordinateurs virtuels en fonction des données des tests d’évaluation. Au besoin, modifiez l’architecture physique en réajustant la répartition des ordinateurs virtuels sur les hôtes de virtualisation.
Après le déploiement, continuez à collecter des données de tests d’évaluation de l’intégrité et des performances et affinez la configuration des ordinateurs virtuels et, le cas échéant, celle des ordinateurs physiques. Au besoin, ajustez les deux architectures.

Il est essentiel de pouvoir analyser les données des performances des hôtes de virtualisation et des ordinateurs virtuels afin d’en tirer des conclusions sur les besoins en termes de capacité et sur l’incidence des applications sur la capacité. En outre, vous devez assimiler les limites propres aux performances et à la capacité. Étant donné le rapport réciproque entre le niveau virtuel et le niveau physique, tout élément qui affecte la capacité et les performances des ordinateurs virtuels a une incidence directe sur l’hôte ou doit être pris en charge par le biais d’une modification de la configuration des hôtes de virtualisation afin que les performances demeurent acceptables dans la batterie de serveurs.

Dans certains cas, il peut être nécessaire de modifier l’architecture physique en ajoutant des hôtes de virtualisation, puis en modifiant la répartition des ordinateurs virtuels dans l’architecture physique.

Important

Dans les tests d’évaluation consistant à comparer les performances d’un ordinateur physique et celles d’un ordinateur virtuel, le débit de l’ordinateur virtuel ne peut pas, en règle générale, être équivalent à celui d’un ordinateur physique. Les performances d’un ordinateur virtuel sont, à de rares exceptions près, toujours inférieures à celles d’un ordinateur physique. L’écart des performances dépend des capacités des hôtes de virtualisation, des applications en cours d’exécution et des tests d’évaluation que vous choisissez d’utiliser en guise d’indicateurs de performance principaux.

Il est recommandé de consulter le FAQ version 2 consacré aux performances Hyper-V (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=187745&clcid=0x40C), mis à jour de manière à refléter les informations sur la capacité et sur les performances pour Windows Server 2008 R2 et Windows Server 2008 avec Service Pack 2 (SP2). Ce FAQ contient des réponses aux questions courantes sur Hyper-V, fournit de l’aide et comprend des liens vers des articles détaillés qui vous permettent de développer des tests afin d’évaluer l’hôte de virtualisation, les ordinateurs virtuels et la gestion de réseau Windows.

Il est également opportun de consulter les publications suivantes au sujet des compteurs de performance Hyper-V :

Création et affinement des architectures

Une architecture complète se compose des hôtes de virtualisation, des ordinateurs virtuels et des ordinateurs physiques qui constituent l’environnement SharePoint Server que vous envisagez de déployer. Pour plus d’informations sur les architectures de virtualisation, voir Planifier des architectures virtuelles (SharePoint Server 2010).

Le développement et l’implémentation d’une architecture virtuelle se composent des étapes suivantes :

Créez l’architecture virtuelle et physique. Créez une architecture qui prendra en charge les objectifs de votre batterie de serveurs SharePoint Server 2010.
Analysez les architectures. Identifiez et obtenez les informations manquantes ou qui amélioreront la conception de l’environnement que vous envisagez de déployer.
Affinez les architectures. Utilisez les informations obtenues à l’étape 2 pour affiner l’architecture.
Continuez à affiner les architectures et les configurations des serveurs à mesure que vous passez d’une phase de déploiement à l’autre. Pour plus d’informations sur les phases de déploiement, voir les modèles de déploiement et de processus de virtualisation des produits SharePoint 2010, disponibles dans l’article Diagrammes techniques (SharePoint Server 2010).

Créer l’architecture

Créez un modèle de l’architecture, qui vous servira d’outil d’évaluation et d’ajustement des configurations des ordinateurs virtuels et des hôtes de virtualisation. Appuyez-vous sur les critères suivants pour développer votre modèle :

Identifiez le nombre d’ordinateurs virtuels requis et le rôle de chacun d’eux dans la batterie de serveurs SharePoint Server.
Spécifiez la configuration requise pour chaque ordinateur virtuel (espace disque, mémoire et nombre de processeurs). Ces configurations sont basées sur les contraintes de capacité spécifiques à SharePoint Server.
Spécifiez la configuration requise pour les hôtes de virtualisation (espace disque, mémoire et nombre de processeurs logiques). Cette configuration est basée sur la configuration requise pour les ordinateurs virtuels.
Identifiez la répartition des ordinateurs virtuels sur les hôtes de virtualisation. Cet aspect est tributaire des exigences de haute disponibilité pour la batterie de serveurs, ainsi que de la quantité et de la capacité des hôtes de virtualisation.
Identifiez les exigences de stockage et de gestion de réseau générales.
Prévoyez une possibilité de croissance pour les hôtes de virtualisation et les ordinateurs virtuels (montée en puissance par unité ou montée en puissance parallèle).

Après avoir créé un modèle d’architecture, vous devez analyser les deux architectures pour valider la conception, ainsi que les configurations des hôtes de virtualisation et des ordinateurs virtuels.

Analyser les architectures

L’objectif fondamental de l’analyse de l’architecture consiste à déterminer si celle-ci est en mesure de prendre en charge la solution SharePoint Server 2010 que vous souhaitez déployer. Toutefois, gardez à l’esprit que la conception et les configurations des serveurs sont susceptibles de changer à mesure que vous progressez dans le processus de déploiement.

L’illustration suivante montre un exemple d’architecture virtuelle pour une batterie de serveurs qui se compose de serveurs Web frontaux, de serveurs d’applications et de serveurs de bases de données. Cette architecture est représentative des batteries de serveurs de taille petite à moyenne décrites dans Exemple d'architectures virtuelles pour des batteries de serveurs de taille petite à moyenne et elle permet de souligner les éléments clés que vous devez prendre en considération lorsque vous analysez les besoins en termes de capacité et de disponibilité pour une batterie de serveurs virtuelle.

Important

Le dimensionnement des serveurs de virtualisation et des ordinateurs virtuels dans l’illustration suivante n’est pas normatif.

Figure 1. Architecture préliminaire

Topologie de batterie de serveurs virtuelle SharePoint Server 2010

À partir des critères indiqués pour la création d’une architecture virtuelle, analysez l’exemple d’architecture illustré dans la figure précédente. L’architecture illustrée suppose que tous les serveurs Web et les serveurs d’applications sont des ordinateurs virtuels. Il n’a pas été déterminé si les serveurs de bases de données de la batterie de serveurs sont des ordinateurs physiques ou des ordinateurs virtuels.

Analyse des hôtes de virtualisation

Les tableaux suivants (HÔTE-1 et HÔTE-2) fournissent une analyse de chaque hôte de virtualisation et utilisent comme critères la mémoire, les processeurs et l’évolutivité. L’analyse des hôtes est suivie d’une analyse de la conception.

HÔTE-1

Critères	Analyse
Mémoire	L’utilisation exclusive de 2 Go de RAM par le système d’exploitation hôte et la prise en compte des besoins prévisibles en termes de RAM permettent d’estimer à 2 Go la quantité de RAM disponible pour une utilisation future.
Processeurs	Le ratio processeurs logiques/processeurs virtuels est de 8 pour 10 (soit 1 pour 1,25), ce qui signifie que l’UC est légèrement surabonnée, situation qui ne constituerait pas un problème dans un environnement de test. Important Le surabonnement de l’UC sur un serveur de virtualisation réduit les performances globales. La portée de cette incidence dépend de la charge placée sur les ordinateurs virtuels. En guise de meilleure pratique, évitez, dans la mesure du possible, tout surabonnement de l’UC du serveur de virtualisation.
Évolutivité	Il ne s’agit pas d’une option, car la mémoire est insuffisante. En outre, le degré de surabonnement de l’UC (même en ajoutant un ordinateur virtuel doté de deux processeurs) aurait une incidence notable sur les performances.

HÔTE-2

Critères	Analyse
Mémoire	L’utilisation exclusive de 2 Go de RAM par le système d’exploitation hôte et la prise en compte des besoins prévisibles en termes de RAM permettent d’estimer à 6 Go la quantité de RAM disponible pour une utilisation future.
Processeurs	Le ratio processeurs logiques/processeurs virtuels est de 8 pour 8 (soit 1 pour 1), ce qui est conforme aux meilleures pratiques.
Évolutivité	Il existe suffisamment de mémoire pour accroître l’allocation de mémoire aux ordinateurs virtuels. Il existe suffisamment de capacité pour ajouter un nouvel ordinateur virtuel doté de deux processeurs et de 4 Go de RAM. Cela signifie que l’UC des hôtes de virtualisation serait légèrement surabonnée (8 pour 10), mais, à l’image de la configuration HÔTE-1, cela ne constituerait pas un problème dans un environnement de test.

Analyse de la conception

L’exemple d’architecture montre généralement un degré de haute disponibilité pour les serveurs de la batterie de serveurs. Par exemple, il existe trois serveurs Web frontaux répartis sur les configurations HÔTE-1 et HÔTE-2, tandis que les serveurs de bases de données (en cluster ou en miroir) résident également sur des hôtes de virtualisation distincts ou sur des serveurs physiques distincts. La haute disponibilité au niveau des hôtes de virtualisation ne fait pas partie de l’architecture et des informations pertinentes sont manquantes. Les informations suivantes sont nécessaires pour réexaminer la conception :

Taille de la base de données

La taille de la base de données de contenu détermine la façon dont vous configurez et répartissez tous les serveurs de la batterie de serveurs.
Sous-système de stockage

Par exemple, dans l’exemple d’architecture, aucune information n’est fournie au sujet du nombre de disques requis pour chaque ordinateur virtuel, ni aucune indication sur la répartition et la capacité des disques. Ces informations sont très importantes pour la détermination et la configuration du système de stockage. L’exemple d’architecture utilise un stockage local. Vous devez déterminer si cela convient pour votre environnement ou si vous souhaitez utiliser une configuration de disque pass-through liée à un numéro d’unité logique sur un réseau SAN.
Contraintes liées à la gestion de réseau

Le nombre de cartes réseau et le débit minimal doivent être identifiés.
Configurations des disques durs virtuels

Vous devez également déterminer la configuration de disque dur Hyper-V à utiliser (par exemple, taille fixe, pass-through). Pour plus d’informations, voir Planification des disques et du stockage (https://go.microsoft.com/fwlink/?linkid=188007&clcid=0x40C) et le livre blanc Performances des disques durs virtuels : Windows Server 2008 / Windows Server 2008 R2 / Windows 7 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=186519&clcid=0x40C).

Après avoir révisé la conception, vous pouvez passer à l’étape suivante, qui consiste à affiner l’architecture.

Affiner l’architecture

La portée de l’affinement de l’architecture dépend de votre architecture initiale, des résultats de votre analyse et de votre plan d’implémentation. Sur la base de l’exemple fourni, il existe des scénarios dans lesquels vous pouvez décider de n’apporter aucune modification. Par exemple :

L’architecture préliminaire convient pour un test initial, une validation technique et un déploiement pilote limité.
Les hôtes de virtualisation sont utilisés à des fins de test uniquement et seront remplacés par des hôtes de capacité supérieure pendant la phase de test d’acceptation utilisateur.
La batterie de serveurs virtuelle est utilisée à des fins de test uniquement et sera arrêtée au terme de la phase de test. Dans certains cas, l’environnement peut être conservé et utilisé à une date ultérieure pour la réalisation de tests de mises à jour logicielles.

L’illustration suivante montre une architecture révisée qui convient mieux pour une batterie de serveurs de production.

Figure 2. Architecture révisée

Révision d’une architecture virtuelle

L’architecture révisée repose essentiellement sur l’hypothèse que vous souhaitez conserver des serveurs de virtualisation polyvalents à huit cœurs. Les modifications apportées dans l’illustration précédente reflètent cette hypothèse et tiennent compte des observations suivantes :

La taille estimée de la base de données de contenu est de 1 téraoctet (To).
L’objectif est de fournir une haute disponibilité pour tous les serveurs de la batterie de serveurs et d’optimiser les performances au sein de l’infrastructure.
Les serveurs de bases de données de la batterie de serveurs sont des serveurs physiques pouvant être organisés en cluster ou mis en miroir afin de prendre en charge la haute disponibilité. Chaque serveur est doté de 8 cœurs, de 16 Go de RAM et utilise des lecteurs locaux pour réduire la latence.

Analyse des hôtes de virtualisation

Les tableaux suivants (HÔTE-1 révisé et HÔTE-2 révisé) fournissent une analyse de chaque hôte de virtualisation en utilisant comme critères la mémoire, les processeurs et l’évolutivité. L’analyse des hôtes est suivie d’une analyse de la conception.

HÔTE-1 révisé

Critères	Analyse
Mémoire	L’utilisation exclusive de 2 Go de RAM par le système d’exploitation hôte et la prise en compte des besoins prévisibles en termes de RAM permettent d’estimer à 2 Go la quantité de RAM disponible pour une utilisation future.
Processeurs	Le ratio processeurs logiques/processeurs virtuels est de 8 pour 10 (soit 1 pour 1,25), ce qui dénote un léger surabonnement.
Évolutivité	La quantité de mémoire disponible pour une augmentation de l’allocation de mémoire aux ordinateurs virtuels est marginale. Compte tenu de la quantité de mémoire et du ratio des processeurs, la capacité des hôtes ne permet pas d’ajouter un ordinateur virtuel.

HÔTE-2 révisé

Critères	Analyse
Mémoire	L’utilisation exclusive de 2 Go de RAM par le système d’exploitation hôte et la prise en compte des besoins prévisibles en termes de RAM permettent d’estimer à 4 Go la quantité de RAM disponible pour une utilisation future.
Processeurs	Le ratio processeurs logiques/processeurs virtuels est de 8 pour 12 (soit 1 pour 1,50), ce qui dénote un surabonnement de 50 %.
Évolutivité	La quantité de mémoire disponible pour une augmentation de l’allocation de mémoire aux ordinateurs virtuels est marginale. Compte tenu de la quantité de mémoire et du ratio des processeurs, la capacité des hôtes ne permet pas d’ajouter un ordinateur virtuel.

Analyse de la conception

Chaque ordinateur virtuel utilise une configuration à trois lecteurs, dimensionnée conformément aux meilleures pratiques définies pour SharePoint Server. Ces lecteurs sont généralement configurés comme suit :
- lecteur C (50 Go) pour l’installation de Windows ;
- lecteur D (50 Go) pour les fichiers SharePoint Server 2010 ;
- lecteur E (300 Go) pour le contenu Web et les fichiers journaux.
Chaque serveur Web frontal est configuré avec quatre processeurs virtuels (4xPV) et 8 Go de RAM. Il s’agit de la configuration minimale recommandée pour un environnement de production.
Le nombre de serveurs Web frontaux est porté à quatre afin que la configuration offre un clustering efficace et une haute disponibilité. Cette configuration à quatre serveurs convient particulièrement pour l’installation des mises à jour logicielles, car deux serveurs sont toujours disponibles lorsque vous installez des mises à jour.
Les deux serveurs d’applications (App-1 et App-2) fournissent une haute disponibilité. App-1 héberge l’Administration centrale, le composant d’analyse de recherche et l’index passif du composant de requête de recherche. Le nombre de processeurs et la quantité de mémoire sont basés sur la taille estimée de la base de données de contenu.

App-2 est un serveur de requête pour le traitement des requêtes dédié. En outre, il contient une copie de l’Administration centrale. Le nombre de processeurs et la quantité de mémoire sont basés sur la taille estimée de la base de données de contenu.
Pour une haute disponibilité, l’Administration centrale est également installée sur un serveur Web frontal sur un autre hôte.
Les serveurs de bases de données sont des serveurs physiques qui sont organisés en cluster ou mis en miroir afin de garantir une haute disponibilité. L’adoption d’une configuration de ce type reposant sur des serveurs physiques permet d’accroître la capacité des hôtes de virtualisation pour les serveurs de la batterie de serveurs virtuelle et d’améliorer les performances globales des bases de données.

Notes

Comme indiqué précédemment dans cet article, la décision de virtualiser ou de ne pas virtualiser les serveurs de bases de données est une décision complexe qui requiert une planification et des tests complets.
Du point de vue de la gestion de réseau, les deux hôtes de virtualisation sont configurés avec deux cartes réseau physiques 1 gigabit distinctes. Cette configuration est recommandée, car elle permet de séparer le trafic de données lié aux hôtes de virtualisation de celui lié aux ordinateurs virtuels et ainsi d’améliorer les performances et d’apporter une certaine redondance au niveau des cartes réseau.
Chaque hôte de virtualisation utilise un réseau local virtuel, ce qui peut présenter les avantages suivants : répartition des ressources réseau, amélioration de la sécurité et amélioration des performances.

L’architecture virtuelle et physique révisée est sensiblement améliorée et pourrait être déployée dans un environnement de production. Toutefois, il est important de noter que, en raison de sa configuration, les ressources disponibles des hôtes de virtualisation ne prennent pas en charge une montée en puissance de la batterie de serveurs. En outre, elles ne peuvent pas prendre en charge la migration d’un serveur de batterie de serveurs depuis un hôte vers un autre en cas de besoin.

Pour des raisons pratiques, si vous souhaitez déployer l’exemple de batterie de serveurs dans un environnement de production, il est recommandé d’envisager les mises à niveau suivantes :

Augmentez la capacité des hôtes de virtualisation en utilisant un ordinateur à 16 cœurs doté de 48 ou 64 gigaoctets de RAM.
Ajoutez un ou plusieurs hôtes de virtualisation.

Pour atteindre le niveau de haute disponibilité optimal, envisagez les options supplémentaires présentées dans la section suivante.

Options supplémentaires pour améliorer l’architecture

La section précédente contient des options pour la révision du modèle. Bien sûr, il existe d’autres options pour améliorer les performances et atteindre un certain niveau de haute disponibilité. La montée en puissance parallèle de l’environnement des hôtes de virtualisation ou la montée en puissance par unité des hôtes de virtualisation constituent des solutions intéressantes, bien que le coût lié à ces opérations soit parfois un problème. La stratégie de virtualisation de votre organisation permet de définir la meilleure approche.

Conseil

En termes de coût, il est généralement préférable d’acheter un serveur doté de davantage de capacité que celle requise à court terme que de mettre à niveau un serveur pour accroître la capacité. Cela est particulièrement vrai dans le cas des mises à niveau de mémoire, au cours desquelles vous devez généralement vous débarrasser des modules de mémoire existants et acheter un jeu complet de nouvelle mémoire pour mettre à niveau la mémoire.

Les options suivantes permettent d’améliorer les performances :

Déployez ou achetez des serveurs dotés de processeurs à technologie SLAT (Second-Level Address Translation). Chez Intel, cette fonctionnalité est appelée Nested Page Tables et est disponible dans les processeurs de la série Nehalem 55xx. Chez AMD, cette fonctionnalité est appelée Enhanced Page Tables (EPT).
Déployez ou achetez des serveurs dotés de la fonctionnalité d’immobilisation de cœur d’UC, qui permet à l’ordinateur Hyper-V en cours d’exécution d’utiliser le plus petit nombre de cœurs de processeur pour répondre à la charge de travail.
Évaluez les fonctionnalités de déchargement TCP Chimney, de files d’attente d’ordinateurs virtuels et de trames Jumbo. Ces fonctionnalités améliorent les performances réseau et diminuent l’utilisation de l’UC, ce qui se traduit par une augmentation de la capacité globale du système.
Évaluez la prise en charge des trames Jumbo en vue d’accélérer les performances réseau lors du transfert de quantités de données volumineuses. Toutefois, vous devez tester cette option avec précaution, car la fonctionnalité de trames Jumbo ne fonctionne pas dans tous les environnements.
Évaluez la fonctionnalité d’association de cartes réseau. Cette fonctionnalité peut améliorer les performances réseau et offrir une possibilité de basculement vers les cartes réseau physiques.

Important

L’association de cartes réseau est une solution tierce et est uniquement prise en charge par le fournisseur. Pour plus d’informations, voir Stratégie de support technique Microsoft pour l’association de cartes réseau avec Hyper-V (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=194749&clcid=0x40C).

Pour garantir une haute disponibilité pour un environnement virtuel, envisagez l’implémentation du clustering de basculement Windows Server 2008 R2 et de la migration dynamique Hyper-V, comme suit :

L’étendue de clustering de basculement peut inclure les hôtes de virtualisation et les ordinateurs virtuels que chacun héberge. Si un hôte de virtualisation échoue de manière inattendue, les ordinateurs virtuels basculent automatiquement vers un autre hôte de virtualisation.
La migration dynamique est une solution adaptée aux temps mort planifiés. Vous pouvez migrer des ordinateurs virtuels en cours d’exécution vers un autre serveur (sans temps mort), arrêter le serveur physique et effectuer la maintenance. Lorsque vous avez terminé la maintenance sur le serveur, utilisez la migration dynamique pour déplacer les ordinateurs virtuels vers le serveur physique d’origine.

Pour plus d’informations, voir Hyper-V : Utilisation de Hyper-V et du clustering de basculement (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=187967&clcid=0x40C) et Hyper-V : Utilisation de la migration dynamique avec des volumes partagés de cluster dans Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?linkid=188009&clcid=0x40C).

Partager via