Planifier des architectures virtuelles (SharePoint Server 2010)

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2017-01-17

Cet article présente une série de points dont vous devez tenir compte pour planifier des architectures virtuelles à l’aide de rôles de serveur Microsoft SharePoint Server 2010. Cet article ne comporte pas de données ou de recommandations sur la planification des performances ou de la capacité. Il constitue une aide générale pour la planification d’environnements virtuels et comprend des exemples d’architectures pour des batteries de serveurs de taille petite, moyenne et grande.

Dans cet article :

• Architectures virtuelles et architectures physiques

• Exemple d’architectures virtuelles pour des batteries de serveurs de taille petite à moyenne

• Exemple d’architectures virtuelles pour des batteries de serveurs de taille moyenne à grande

Architectures virtuelles et architectures physiques

En règle générale, une organisation envisage une transition vers des architectures virtuelles pour réduire le nombre de serveurs nécessaires à l’hébergement d’une solution, pour utiliser plus efficacement le matériel existant ou pour économiser de l’énergie et de l’espace. La possibilité d’automatiser le déploiement de serveurs est également un facteur déterminant en faveur du déploiement d’un environnement serveur virtuel.

Virtualisation des serveurs Web et des serveurs d’applications

Les rôles de serveur Web et de serveur d’applications se prêtent aisément à la virtualisation. Lorsque vous planifiez un environnement virtuel, une approche raisonnable consiste à appliquer une méthodologie de topologie, de performances et de capacité pour planifier l’environnement physique, puis à utiliser le nombre obtenu de serveurs Web et de serveurs d’applications, y compris les rôles de serveur propres aux applications, comme point de départ pour l’environnement virtuel.

Toutefois, dans un environnement virtuel, il est possible qu’un nombre plus élevé de serveurs virtuels soit requis pour obtenir le même niveau de service et de performances pendant les heures de pointe que celui offert par des serveurs physiques. Le résultat dépend des services spécifiques et des modèles d’utilisation de ces services.

Cela mis à part, un environnement virtuel permet de réallouer les ressources entre les ordinateurs virtuels en fonction des besoins et en toute souplesse pour affiner les performances. Vous pouvez également ajouter et supprimer plus facilement des serveurs virtuels pour faire face aux pics d’utilisation de services spécifiques qui se produisent à des moments prévisibles tout au long de l’année.

Virtualisation de SQL Server

La question de savoir s’il convient de virtualiser Microsoft SQL Server n’a pas de réponse définitive et dépend des objectifs globaux d’un déploiement. En règle générale, un environnement SQL Server virtuel est un peu plus lent qu’un environnement physique, bien que les performances s’améliorent au fil des versions. Lorsque la version la plus récente du rôle Hyper-V (inclus dans Windows Server 2008 R2) est utilisée, les tests de performances de SQL Server indiquent que le même débit (par rapport à un serveur physique) peut être atteint dans un ordinateur virtuel invité au prix d’une utilisation légèrement supérieure de l’UC.

Vous devez prendre d’autres facteurs en compte avant d’envisager de virtualiser SQL Server, tels que le nombre de cœurs de processeurs requis par SQL Server, le plan de basculement et de disponibilité et les options d’optimisation du stockage. Indépendamment de ces points, les avantages procurés par le déploiement de SQL Server dans un environnement virtuel peuvent l’emporter sur le coût en termes de performances.

Les organisations qui hébergent des batteries de serveurs SharePoint et qui envisagent de déployer et de reconstruire des batteries de serveurs fréquemment, telles que les sociétés d’hébergement, ont tout intérêt à ajouter SQL Server à l’environnement virtuel. En outre, la virtualisation de SQL Server peut être utile dans une solution temporaire ou transitoire, par exemple lors de la combinaison de plusieurs batteries de serveurs en une batterie de serveurs d’entreprise et du retrait de matériel. Les organisations qui tirent le meilleur parti d’une configuration matérielle limitée profiteront au mieux du déploiement de SQL Server sur des serveurs physiques. Les exemples dans cet article font référence à des environnements qui utilisent les deux approches.

Pour plus d’informations, voir Exécution de SQL Server 2008 dans un environnement Hyper-V : meilleures pratiques et recommandations pour les performances (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=134106&clcid=0x40C). Ce livre blanc est basé sur une version antérieure de Hyper-V. Une version plus récente de ce document devrait être disponible vers la fin du printemps 2010.

Virtualisation d’autres serveurs dans l’environnement

Les solutions des Produits SharePoint 2010 reposent sur d’autres serveurs dans l’environnement. Cette section fournit une aide générale sur leur transposition dans une architecture virtuelle.

Active Directory

Il est recommandé, au minimum, que le contrôleur de domaine racine pour un environnement de services d’annuaire Active Directory soit hébergé sur un serveur physique en dehors des environnements virtuels. Au besoin, des contrôleurs de domaine supplémentaires peuvent être déployés en tant que serveurs virtuels.

Pour plus d’informations sur le déploiement d’Active Directory dans des environnements virtuels, voir les ressources suivantes :

• Blog de Sander Berkouwer : Active Directory dans les environnements Hyper-V, Partie 2 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=186927&clcid=0x40C)

• Observations sur la planification des contrôleurs de domaine virtualisés (https://go.microsoft.com/fwlink/?linkid=186928&clcid=0x40C)

Produits de passerelle

Les produits de passerelle sont les suivants :

• Microsoft Forefront Unified Access Gateway (UAG)

• Microsoft Forefront Threat Management Gateway (TMG)

Pour obtenir un haut niveau de disponibilité, il est recommandé de placer ces produits en dehors de l’environnement virtuel des Produits SharePoint 2010. Pour plus d’informations sur la configuration d’environnements virtuels pour ces produits de passerelle, voir la documentation du produit.

Test côte à côte

Si vous souhaitez savoir dans quelle mesure le déploiement de rôles de serveur pour les Produits SharePoint 2010 dans un environnement virtuel peut affecter les performances, vous pouvez tester les rôles que vous envisagez de déployer. Vous pouvez utiliser les résultats pour déterminer le nombre de serveurs virtuels à déployer pour un rôle spécifique, voire pour décider s’il est nécessaire de déployer un rôle spécifique dans l’environnement virtuel. Par exemple, si votre batterie de serveurs est appelée à analyser une quantité élevée de contenu, les résultats de vos tests peuvent vous amener à déployer le rôle d’analyse sur un serveur physique dédié.

Une façon de tester un environnement virtuel consiste à déployer un rôle spécifique à la fois virtuellement et physiquement et à comparer les données d’évaluation relatives au réseau, à la mémoire, au disque et à l’UC. L’illustration suivante fournit un exemple de test de rôles de serveur spécifiques à l’aide d’un nombre limité de serveurs.

Dans cette illustration, des rôles spécifiques sont déployés dans l’environnement virtuel. Un serveur de test physique est configuré pour tester chaque rôle, à raison d’un à la fois, afin que les données d’évaluation côte à côte puissent être collectées. Veillez à tenir des différences entre les environnements physique et virtuel susceptibles d’affecter les résultats des tests, telles que celles relatives aux spécifications matérielles.

Si vous disposez d’une batterie de serveurs, vous pouvez ajouter un hôte virtuel et intégrer des ordinateurs virtuels qui ont des rôles équivalents pour déterminer dans quelle mesure les performances virtuelles de chaque rôle sont affectées. Vous pouvez également évaluer l’impact de différentes combinaisons de rôles sur les performances globales de la batterie de serveurs. L’exemple suivant illustre cette idée.

Exemple d’architectures virtuelles pour des batteries de serveurs de taille petite à moyenne

Le point de départ du remplacement d’une batterie de serveurs physique à l’aide d’une batterie de serveurs virtuelle consiste à utiliser entre deux et quatre serveurs hôtes physiques. Pour chaque hôte, le nombre de serveurs pouvant être déployés est déterminé par les ressources en mémoire, UC, disque et réseau disponibles.

Les deux illustrations suivantes fournissent des exemples de déploiements dans lesquels les rôles de serveur Web et de serveur d’applications sont déployés dans un environnement virtuel.

Dans cet exemple, gardez à l’esprit les éléments suivants :

• Les ressources minimales pour les UC et la mémoire RAM représentent des points de départ pour la batterie de serveurs. Étant donné que seuls deux processeurs sont réservés pour chaque image virtuelle, cet exemple est uniquement approprié pour des environnements preuve de concept ou de développement dans lesquels les performances ne revêtent pas une importance particulière. Réservez suffisamment de ressources disponibles qui pourront être réallouées si la surveillance des performances l’exige.

• SQL Server est déployé sur des serveurs physiques, non sur des serveurs virtuels.

• Les serveurs Web et les serveurs d’applications sont redondants dans les deux serveurs hôtes.

• Trois serveurs Web sont déployés dans l’environnement virtuel afin que le niveau de disponibilité soit élevé.

• Les contrôleurs de domaine Active Directory sont déployés sur des serveurs physiques.

Dans le cas des environnements de production et de test pilote, au minimum quatre processeurs sont initialement recommandés pour les ordinateurs virtuels. L’environnement virtuel suivant utilise moins d’ordinateurs virtuels pour atteindre cet objectif.

Cet exemple représente un environnement de départ. Vous pouvez être amené à ajouter des ressources, suivant le modèle d’utilisation de la batterie de serveurs.

Exemple d’architectures virtuelles pour des batteries de serveurs de taille moyenne à grande

En utilisant des serveurs hôtes plus grands, vous pouvez allouer davantage de ressources aux images virtuelles. L’illustration suivante fournit un exemple d’implémentation qui utilise davantage d’UC et de mémoire RAM.

Si les avantages de la virtualisation de SQL Server l’emportent sur le coût en termes de performances, SQL Server peut également être déployé en tant qu’invité, comme le montre l’illustration suivante.

Dans cet exemple, gardez à l’esprit les éléments suivants :

• Une seule instance de SQL Server est déployée sur chaque hôte. Dans les environnements virtuels de taille petite ou moyenne, il est recommandé de ne pas déployer plus d’un invité SQL Server par hôte.

• Les deux serveurs hôtes possèdent davantage de mémoire afin que tous les serveurs virtuels soient pris en charge, SQL Server compris.

Si un rôle de serveur spécifique consomme tellement de ressources que cela affecte les performances globales de l’environnement virtuel, envisagez de dédier un serveur physique à ce rôle. Suivant les modèles d’utilisation d’une organisation, ces rôles peuvent inclure des serveurs d’analyse, le serveur qui importe les profils, l’application Excel Services ou d’autres services utilisés de façon intensive. L’illustration suivante fournit un exemple.

Dans cet exemple :

• SQL Server est déployé sur des serveurs physiques. Supprimez SQL Server de l’environnement virtuel avant de supprimer les rôles de serveur d’applications.

• Le rôle d’analyse est déployé sur un serveur physique. Dans certains environnements, un rôle différent peut convenir pour le déploiement sur un serveur physique, suivant le modèle d’utilisation.