Estimer les performances et la capacité requises pour les environnements de collaboration de division (SharePoint Server 2013)
S’APPLIQUE À :
2013 
2016 2019 Subscription Edition SharePoint dans Microsoft 365
Cet article présente des instructions concernant la planification de capacité et de performances pour une solution de collaboration de division basée sur SharePoint Server 2013. Les informations suivantes sont incluses dans cet article :
Spécifications d'environnement de laboratoire de test, telles que le matériel, la topologie de batterie de serveurs et la configuration
Charge de travail de la batterie de serveurs test et jeu de données ayant généré la charge de test
Résultats des tests et analyse qui démontrent et expliquent les tendances du débit, de la latence et de la demande matérielle sous charge à différentes échelles
Vous pouvez utiliser les informations contenues dans cet article pour comprendre les caractéristiques du scénario de charges normale et maximale et pour évaluer la variation des tendances de performances lorsque la charge des serveurs de la batterie augmente. Cet article peut également vous aider à déterminer un point de départ approprié pour la planification de votre architecture et à comprendre les éléments à prendre en compte lorsque vous développez un plan pour maintenir des niveaux de performances acceptables en charge maximale.
Introduction
Cet article explique comment mettre à l'échelle des serveurs dans une solution de collaboration de division SharePoint Server 2013. Une solution de collaboration de division est un déploiement SharePoint Server 2013 qui comporte moins d'ordinateurs impliqués dans les activités collaboratives qu'une solution de collaboration d'entreprise. Cette article part du principe qu'une division est une organisation à l'intérieur d'une entreprise qui comporte 1 000 à 10 000 employés.
Des scénarios différents comporteront des exigences différentes. Par conséquent, complétez ces instructions avec des tests supplémentaires sur votre propre matériel et dans votre propre environnement. Si votre charge de travail et conception planifiées ressemblent à l'environnement décrit dans cet article, vous pouvez tirer des conclusions concernant les performances à attendre lorsque vous faites monter en puissance votre environnement.
Importante
Les résultats des tests de cet article ont été produits dans un laboratoire de test qui a utilisé une charge de travail, un jeu de données et une architecture pour simuler un environnement de production dans des conditions hautement contrôlées. Bien que nous ayons soigneusement conçu ces tests, les caractéristiques de performances d’un laboratoire de test ne sont jamais les mêmes que le comportement d’un environnement de production. Ces résultats de test ne représentent pas les caractéristiques de performances et de capacité d’une batterie de serveurs de production. Au lieu de cela, les résultats des tests illustrent les tendances observées en matière de débit, de latence et de demande matérielle. Utilisez l’analyse des données observées pour vous aider à planifier la capacité et à gérer votre propre batterie de serveurs.
En lisant cet article, vous découvrirez les éléments suivants :
Spécifications, ce qui comprend le matériel, la topologie et la configuration
Charge de travail, ce qui comprend une analyse de la demande sur la batterie de serveurs, le nombre d'utilisateurs et les caractéristiques d'utilisation
Jeu de données, notamment la taille des bases de données et les types de contenu
Résultats des tests et analyse pour la montée en puissance des serveurs web
Avant de lire cet article, lisez les articles suivants pour vous assurer que vous comprenez les concepts clés de la gestion de la capacité dans Limites et limites logicielles pour SharePoint 2013SharePoint Server 2013.
Glossaire
La liste suivante contient les définitions des termes clés présents dans cet article.
RPS: Demandes par seconde. RPS est le nombre de demandes qu’une batterie ou un serveur reçoit en une seconde. C'est une mesure courante de la charge d'un serveur ou d'une batterie de serveurs.
Notes
Les demandes sont différentes des chargements de page. Une page contient plusieurs composants et chacun de ces composants crée une ou plusieurs demandes lorsqu'un navigateur charge la page. Un chargement de page crée plusieurs demandes. En règle générale, les vérifications et les événements d'authentification qui utilisent très peu de ressources ne sont pas comptabilisés dans le calcul RPS.
Zone verte : la zone verte représente un ensemble défini de caractéristiques de charge dans des conditions de fonctionnement normales, jusqu'aux charges maximales journalières attendues. Une batterie de serveurs dans cette plage doit pouvoir soutenir des temps de réponse et une latence acceptables.
Il s'agit de l'état dans lequel le serveur peut respecter l'ensemble des critères suivants :
Latence côté serveur inférieure à 1 seconde pour au moins 75 % des demandes.
Utilisation moyenne du processeur inférieure à 60 % pour tous les serveurs de la batterie.
Notes
Aucune analyse de recherche active n'a été exécuté dans notre environnement de laboratoire. Par conséquent, l'utilisation du processeur du serveur de base de données a été maintenue à environ 50 % ou moins pour réserver 10 % à la charge de l'analyse de recherche. Cela signifie que le gouverneur de ressources SQL Server est utilisé en production pour que la charge de l'analyse de recherche n'utilise pas plus de 10 % du processeur.
Taux d'échec inférieur à 0,01 %.
Zone rouge (max.) : la zone rouge représente un ensemble défini de caractéristiques de charge dans les conditions de fonctionnement maximales. Lorsqu'elle est en zone rouge, la batterie de serveurs reçoit des demandes de ressources temporaires très élevées qu'elle ne peut gérer que pendant des périodes limitées avant que des défaillances ou d'autres problèmes de fiabilité surviennent.
Il s'agit de l'état dans lequel le serveur peut respecter l'ensemble des critères suivants pendant une durée limitée :
La fonctionnalité de limitation de requêtes HTTP est activée, mais aucune erreur 503 (Serveur occupé) n'a été renvoyée.
Le taux d’échec est inférieur à 0. 1%.
Latence côté serveur inférieure à 3 secondes pour au moins 75 % des demandes.
Utilisation moyenne du processeur inférieure à 90 % environ pour tous les serveurs de la batterie (hormis les serveurs de base de données).
Utilisation moyenne du processeur du serveur de base de données inférieure à 50 % environ, ce qui permet de réserver une grande charge de traitement pour l'analyse de recherche.
AxBxC (notation du graphique) : nombre de serveurs web, nombre de serveurs d'applications et nombre de serveurs de base de données dans une batterie, respectivement. Par exemple, 10x1x1 signifie que l'environnement comporte 10 serveurs web, 1 serveur d'applications et 1 serveur de base de données.
MDF et LDF : fichiers physiques SQL Server. Pour plus d’informations, consultez Architecture des fichiers et des groupes de fichiers.
Vue d’ensemble
Cette section fournit une vue d’ensemble de notre approche de montée en charge et de notre méthodologie de test.
Approche de montée en puissance
Cette section décrit l’approche que nous avons adoptée pour faire monter en puissance notre environnement de laboratoire. Cette approche va vous permettre de trouver la meilleure configuration pour votre charge de travail :
Nous avons fait monter en puissance les serveurs web jusqu'à ce que quatre serveurs web soient utilisés. Chaque serveur exécute le service de cache distribué.
Nous avons ajouté un serveur dédié exécutant ce service.
Nous avons désactivé le service de cache distribué sur les serveurs Web.
Nous avons fait monter en puissance d’autres serveurs web jusqu’au maximum pour l’étendue du test.
Remarques sur la méthodologie et les tests
Étant donné que cet article contient des résultats provenant d’un environnement de laboratoire de test, nous avons pu faire en sorte que certains facteurs affichent des aspects spécifiques des performances pour cette charge de travail. En outre, certains éléments de l'environnement de production, qui figurent dans la liste suivante, ont été écartés de l'environnement de test pour simplifier la charge de traitement des tests.
Notes
Nous vous recommandons d'intégrer ces éléments dans les environnements de production.
Entre deux séries de tests, nous avons modifié uniquement une variable à la fois pour faciliter la comparaison des résultats entre chaque série.
Les serveurs de base de données ne faisaient partie d'aucun cluster car la redondance n'était pas nécessaire pour la finalité de ces tests.
L'analyse de recherche n'était pas exécutée pendant les tests. Évidemment, il est possible qu'elle soit exécutée dans un environnement de production. Pour prendre cette variable en compte, nous avons réduit l'utilisation du processeur SQL Server dans nos définitions de « zone verte » et de « zone rouge » pour adapter les ressources qu'une analyse de recherche utiliserait habituellement pendant les tests.
Spécifications
Cette section fournit des détails sur le matériel, les logiciels, la topologie et la configuration de notre environnement de laboratoire de test.
Matériel
Les sections suivantes décrivent le matériel que nous avons utilisé dans notre environnement de laboratoire de test.
Importante
Nous avons utilisé des hôtes Hyper-V pour virtualiser tous les serveurs web et serveurs d'applications dans notre laboratoire de test. Les serveurs de base de données n'ont pas été virtualisés. Le matériel d'hôte physique et le matériel virtuel de machine virtuelle sont décrits séparément dans cette section.
Hôtes Hyper-V
Nous avons utilisé six hôtes Hyper-V configurés de manière identique pour nos tests. Chaque hôte exécute une à deux machines virtuelles.
| Matériel hôte | Valeur |
|---|---|
|
Processeurs |
2 processeurs quadruple cœur 2,49 GHz |
|
Mémoire RAM |
32 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Nombre de cartes réseau |
2 |
|
Vitesse de la carte réseau |
1 gigabit |
Serveurs web virtuels et serveurs d’applications
Notre batterie de serveurs de test utilise huit serveurs web virtuels. Nous utilisons également un serveur virtuel dédié qui exécute le service de cache distribué.
Notes
Les environnements de production déploient généralement des serveurs dédiés qui exécutent le service de cache distribué dans une configuration haute disponibilité. Dans notre environnement de laboratoire de test, nous utilisons un serveur dédié unique pour le cache distribué car la haute disponibilité n'est pas un facteur important.
| Matériel virtuel | WFE1-8 et DC1 |
|---|---|
|
Processeurs |
4 processeurs virtuels |
|
Mémoire RAM |
12 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Taille du lecteur SharePoint |
100 Go |
|
Nombre de cartes réseau |
2 |
|
Vitesse de la carte réseau |
10 gigabits (trafic entre les hôtes limité à la vitesse de la carte réseau de l'hôte) |
|
Authentification |
Windows NTLM |
|
Type d'équilibrage de la charge |
F5 Big-IP |
|
Services exécutés en local |
WFE 1-8 : services fédérés de base. Ceci comprend les suivants : service du minuteur SharePoint, service de suivi, Word Automation Services, Excel Services et Service de code en mode bac à sable Microsoft SharePoint Foundation. DC1 : service de cache distribué. |
Serveurs de base de données
Dans nos tests, nous utilisons un serveur de base de données physique et avons exécuté l'instance SQL Server par défaut qui stocke les bases de données SharePoint. Nous ne suivons pas la base de données de journalisation dans cet article.
Notes
Si vous activez les rapports d'utilisation, nous vous recommandons de stocker la base de données de journalisation sur un numéro d'unité logique (LUN) distinct. Les déploiements importants et certains déploiements intermédiaires peuvent nécessiter une base de données de journalisation dédiée pour réceptionner la demande de volume élevé d'événements de journalisation du processeur.
Dans notre environnement de laboratoire, nous avons limité la journalisation et la base de données de journalisation dans une instance SQL Server séparée.
| Serveur de base de données - Instance par défaut | SQL Server |
|---|---|
|
Processeurs |
4 processeurs quadruple cœur 2,4 GHz |
|
Mémoire RAM |
32 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Stockage et géométrie |
Stockage à connexion directe (DAS) 1 volume système (RAID0, 1 broche, 300 Go) 2 volumes de données de contenu (RAID0, 4 broches, 450 Go chacune) 2 volumes de journalisation de contenu (RAID0, 2 broches, 450 Go chacune) 1 volume de données temporaires (RAID0, 2 broches, 300 Go chacune) 1 volume de journalisation temporaire (RAID0, 2 broches, 300 Go chacune) |
|
Nombre de cartes réseau |
1 |
|
Vitesse de la carte réseau |
1 gigabit |
|
Authentification |
Windows NTLM |
|
Version logicielle requise |
SQL Server 2008 R2 |
Topologie
Le diagramme suivant illustre la topologie de notre environnement de laboratoire de test.
Configuration
Le tableau suivant indique les modifications de configuration importantes que nous avons apportées au serveur de base de données dans notre environnement de laboratoire. Ces modifications de configuration permettent d'obtenir des performances de test optimales et clarifient les relations entre les paramètres de test et les résultats. Notez que le paramètre MAXDOP est requis pour SharePoint Server 2013. Les autres modifications de configuration s'appliquent uniquement à notre environnement de laboratoire de test et n'ont peut-être pas d'impact sur votre environnement de production.
| Paramètre | Valeur | Commentaires |
|---|---|---|
|
Collection de sites |
179 (total dans l'environnement) |
Les collections de sites dans notre environnement de test utilisent les paramètres par défaut et l'authentification basée sur les revendications Windows. |
|
Mise en cache BLOB |
Activée |
La valeur par défaut est Désactivée. Si vous activez la mise en cache BLOB, vous améliorez l'efficacité du serveur en réduisant les appels du serveur de base de données pour les ressources de page statiques susceptibles d'être demandées fréquemment par les navigateurs. |
|
Degré maximal de parallélisme (MAXDOP) |
1 |
Ce paramètre est défini sur l'instance ou les instances SQL Server qui contiennent les bases de données de contenu SharePoint Server 2013. La valeur par défaut est 0, ce qui permet à SQL Server de déterminer le degré maximal de parallélisme. SharePoint Server 2013 exige que MAXDOP soit défini sur 1 pour les instances SQL Server qui contiennent des bases de données SharePoint Server 2013. Pour plus d'informations sur la configuration du paramètre MAXDOP pour SQL Server 2008 R2, voir Option Degré maximal de parallélisme. Pour plus d'informations sur la configuration du paramètre MAXDOP pour SQL Server 2012, voir Configurer l'option de configuration du serveur Degré maximal de parallélisme. |
Charge de travail
Cette section explique les tests de laboratoire que nous avons exécutés sur SharePoint Server 2013. Les détails des tests sont typiques d'un environnement de collaboration de division.
Jeu de données
Le jeu de données que nous avons utilisé pour notre environnement de laboratoire de test est typique d’un environnement de collaboration de division. Ce jeu de données contient des collections de sites, sites, listes, bibliothèques, types de fichiers et tailles de fichiers divers.
| Caractéristiques du jeu de données | Valeur |
|---|---|
|
Taille de la base de données (combinée) |
174 Go |
|
Taille MDF |
154 Go |
|
Taille LDF |
20 Go |
|
Taille BLOB |
152 Go |
|
Nombre de bases de données de contenu |
2 |
|
Nombre de collections de sites |
179 |
|
Nombre d'applications Web |
1 |
|
Nombre de sites |
1 471 |
Résultats et analyse
Les résultats suivants sont triés en fonction de l’approche de montée en puissance décrite à la section Vue d’ensemble.
Montée en puissance du serveur web
Les sections suivantes décrivent les résultats des tests obtenus lors de la montée en puissance des serveurs web présents dans notre environnement de laboratoire de test.
Méthodologie de test
Ajouter des serveurs web qui utilisent les mêmes spécifications matérielles et exécuter à nouveau le test sans modifier la batterie de serveurs ni les paramètres de test.
Mesurer le RPS, la latence et l’utilisation des ressources sur chaque serveur de la batterie de test.
Analyse
Voici ce que nos tests ont révélé :
L'environnement est monté en puissance jusqu'à dix serveurs web par serveur de base de données. L'augmentation de débit a été relativement linéaire.
Même jusqu'à la charge maximale testée de dix serveurs Web, l'ajout de serveurs de base de données supplémentaires n'a pas provoqué d'augmentation du débit. De manière générale, le goulot d'étranglement s'est limité aux ressources des serveurs Web.
La latence moyenne de zone verte a été presque constante sur l'ensemble du test. Le nombre de serveurs web et le débit n'a pas eu d'impact sur la latence de zone verte. Les données de latence de zone rouge indiquent une courbe de tendance attendue. La latence est très élevée avec un seul serveur web. Avec 2 à 8 serveurs web, la courbe reste confortablement dans les critères de la zone rouge.
Notes
La latence peut être légèrement affectée lorsque vous déplacez le service de cache distribué des serveurs web d’une batterie vers un serveur dédié au cache distribué. Cela peut se produire parce que le trafic du cache distribué, qui était auparavant interne à chaque serveur web, commence à traverser le réseau. Testez les performances de scale-out dans votre propre environnement pour déterminer si ce compromis est significatif. Notez que la latence dans notre environnement de test a légèrement augmenté lorsque le service de cache distribué a été migré vers un serveur dédié. La latence a diminué avec chaque serveur web ajouté, car la latence ajoutée nominale a été décalée par la diminution de la charge de traitement et de mémoire sur les serveurs web. > Pour plus d’informations sur la planification de la capacité du cache distribué, voir Planifier les flux et le service de cache distribué dans SharePoint Server.
Grâce aux améliorations des caractéristiques d'utilisation de la base de données et de la mise en cache dans SharePoint Server 2013, la charge moyenne sur la couche du serveur de base de données est faible. Nous avons constaté pendant nos tests qu'il n'est pas nécessaire de monter en puissance les serveurs de base de données.
Lorsque vous ajoutez des serveurs web virtuels, les gains en performances dépendent en partie des ressources matérielles des hôtes et de l'utilisation des ressources des autres ordinateurs virtuels qui sont exécutés sur le même hôte. Les serveurs virtuels requièrent des stratégies de gestion et de planification supplémentaires propres à la virtualisation.
Pour plus d’informations sur les performances et la planification de la capacité Hyper-V, voir Configuration requise pour la virtualisation Hyper-V pour SharePoint 2013 et Utiliser les configurations des meilleures pratiques pour les machines virtuelles SharePoint 2013 et l’environnement Hyper-V.
Notes
Les conclusions présentes dans cette section sont propres au matériel qui compose l'environnement. L'environnement peut avoir atteint le même débit si l'environnement a utilisé plus de serveurs hôtes Hyper-V moins puissants ou des serveurs hôtes Hyper-V moins nombreux mais plus puissants. Une augmentation des ressources matérielles sur le serveur de base de données n'aura pas d'impact significatif sur les résultats.
Résultats, graphiques et diagrammes
Dans les graphiques suivants, l’axe des X correspond à la modification du nombre de serveurs web dans la batterie de serveurs. La montée en charge commence par un serveur web virtuel et un serveur de base de données physique (1x1). Le maximum est de 8 serveurs web virtuels, d'un serveur de cache distribué virtuel dédié (ajouté lorsque quatre serveurs web sont utilisés) et d'un serveur de base de données physique (8x1x1).
Notes
Les graphiques de cette section représentent les valeurs moyennes pour chaque point de données pendant la durée du test. Tous les graphiques ont pour référence le nombre de demandes par seconde pour les zones rouge et verte afin de pouvoir indiquer la relation entre le nombre de demandes par seconde et des facteurs tels que la latence, l'utilisation des ressources serveur et l'utilisation du disque SQL Server.
1. Demandes par seconde (RPS)
Le graphique suivant représente l'impact de la montée en puissance sur la référence RPS.
2. Latence
Le graphique suivant illustre l'impact de la montée en charge sur la latence. Notez que la latence de zone verte reste quasiment plate, mais la latence de zone rouge montre des augmentations comprises dans des limites acceptables.
3. Utilisation de la mémoire et des processeurs des serveurs web
Le graphique suivant illustre l'impact de la montée en charge sur l'utilisation moyenne des processeurs et de la mémoire des serveurs web. Notez que l'utilisation moyenne de la mémoire et que l'utilisation des processeurs de zone verte reste relativement constante lors de l'augmentation du nombre de demandes par seconde.
La tendance d'utilisation des processeurs dans la zone rouge est à la baisse. Cette tendance à la baisse reflète le fait que la demande moyenne du processeur du serveur web à charge maximale décline à mesure que le nombre de serveurs augmente.
4. Opérations d'E/S SQL Server par seconde et utilisation des processeurs
Les graphiques suivants indiquent la variation du nombre moyen d'opérations d'E/S disque (à la fois les totaux et les opérations de lecture/d'écriture) et des valeurs d'utilisation des processeurs avec l'augmentation du nombre de serveurs web. Les compteurs de performances suivants ont été utilisés pour mesurer les valeurs des opérations d'E/S :
PhysicalDisk : lectures disque/s.
PhysicalDisk : écritures disque/s.
La moyenne des valeurs de chaque compteur pendant la durée du test est calculée, puis les moyennes obtenues sont cumulées pour générer le nombre total d'opérations d'E/S.
Notes
Les données relatives à l'utilisation de la mémoire SQL Server n'étaient pas disponibles au moment de nos tests, elles ne sont donc pas incluses dans ce graphique.
Importante
Ces résultats pour les tests d’E/S par seconde ne sont pas représentatifs d’un environnement de production, car notre jeu de données était beaucoup plus petit que celui d’une batterie de serveurs de production. Cela a permis de mettre en cache un pourcentage plus élevé des données sur les serveurs web que dans un environnement de production. Étant donné que nous avons mis en cache un pourcentage plus élevé des données sur le serveur web, les résultats des E/S par seconde dans cette section sont des moyennes calculées basées sur les données de test disponibles. Nous nous attendons à ce que nos résultats d’E/S par seconde soient généralement inférieurs à ceux des E/S par seconde dans un environnement de production. Les tests complets de votre propre batterie de serveurs dans un environnement pilote peuvent générer des résultats différents.
Notez que dans les graphiques de cette section, les opérations d'E/S et l'utilisation des processeurs des serveurs de base de données affichent une chute à 6 serveurs web frontaux, alors que le nombre de demandes par seconde continue d'augmenter. Cette variation est également reflétée dans l'utilisation des processeurs des serveurs web, comme indiqué dans le graphique précédent.
Cela signifie que la montée en charge de la batterie de serveurs a atteint un niveau où la pression maximale sur les ressources des serveurs de la batterie a été atteinte en utilisant la charge et le jeu de données de référence. Une utilisation moyenne moins élevée des ressources des serveurs est nécessaire pour prendre en charge la charge de la batterie de serveurs.
Il est possible de tirer les conclusions suivantes de cette tendance :
Si la charge du test avait été augmentée au sixième point de charge de serveur web, un nombre plus élevé de demandes par seconde aurait pu être obtenu tout en conservant une courbe plate de l'utilisation des ressources des serveurs.
Si le nombre de serveurs web avait été davantage augmenté tout en maintenant la même charge de test, le nombre de demandes par seconde aurait continué à augmenter alors que la pression sur les ressources des serveurs aurait continué à baisser.
Nombre total d'opérations d'E/S SQL Server
Le graphique suivant montre l'impact de la montée en charge sur le nombre total d'opérations d'E/S.
Opérations d'E/S SQL Server réparties en opérations de lecture et d'écriture
Le graphique suivant illustre l'impact de la montée en puisance sur les opérations d'E/S pour les lectures par seconde et les écritures par seconde.
Utilisation du processeur SQL Server
Le graphique suivant illustre l'impact de la montée en puissance sur l'utilisation du processeur SQL Server.
Voir aussi
Concepts
Planification des performances dans SharePoint Server 2013
Résultats des tests de performances et de capacité, avec recommandations (SharePoint Server 2013)