Planification de la capacité pour SharePoint Server 2013

S’APPLIQUE À :  yes-img-13 2013  no-img-16 2016  no-img-19 2019  no-img-se Subscription Edition  no-img-sop SharePoint in Microsoft 365

Cet article décrit la planification de la capacité d'une batterie de serveurs SharePoint Server 2013. Si vous possédez de bonnes connaissances et compréhension de la gestion et de la planification de la capacité, vous pouvez les mettre à profit pour le dimensionnement du système. Le terme « dimensionnement » est utilisé pour décrire la sélection et la configuration d'une architecture de données, d'une topologie physique et logique, et du matériel appropriés pour une plateforme de solution. Il existe une variété d'éléments d'utilisation et de gestion de la capacité qui ont une incidence sur la façon de déterminer les options de configuration et matérielles les plus appropriées.

Avant de lire cet article, vous devez consulter Vue d'ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2013.

Important

Certaines informations et valeurs de cet article reposent sur des résultats de tests et autres informations relatives aux Produits SharePoint 2010 et peuvent ne pas être fidèles aux valeurs finales de SharePoint Server 2013.

Dans cet article, nous décrivons les étapes que vous devez suivre pour mettre en place une gestion de la capacité efficace pour votre environnement. Chaque étape nécessite certaines informations pour permettre une exécution réussie, et présente un ensemble de livrables que vous utiliserez à l'étape suivante. Pour chaque étape, ces exigences et livrables sont décrits dans les tableaux.

Étape 1 : Modélisation

La modélisation de votre environnement basé sur SharePoint Server 2013 commence par l'analyse de vos solutions existantes et l'estimation des objectifs et de la demande attendus pour le déploiement que vous envisagez de définir. Commencez par collecter des informations sur votre base d’utilisateurs, les besoins en données, les objectifs de latence et de débit, et documentez les fonctionnalités SharePoint Server 2013 que vous souhaitez déployer. Utilisez cette section afin de comprendre les données que vous devez collecter, comment les collecter et comment elles peuvent être utilisées aux étapes suivantes.

Comprendre la charge de travail et le jeu de données attendus

Le dimensionnement correct d'une implémentation SharePoint Server 2013 nécessite l'étude et la compréhension des caractéristiques de la demande que votre solution doit gérer. Pour comprendre la demande, vous devez être en mesure de décrire les caractéristiques de la charge de travail, telles que le nombre d’utilisateurs et les opérations les plus fréquemment utilisées, ainsi que les caractéristiques des ensembles de données, telles que la taille et la distribution du contenu.

Cette section peut vous aider à comprendre certains des paramètres et mesures spécifiques que vous devez collecter et les mécanismes par lesquels ils peuvent être collectés.

Charge de travail

La charge de travail décrit la demande que le système devra supporter, les caractéristiques d’utilisation et la base d’utilisateurs. Le tableau suivant fournit des mesures clés qui sont utiles dans la détermination de votre charge de travail. Vous pouvez l’utiliser pour enregistrer ces mesures en même temps que vous les collectez.

Caractéristiques de la charge de travail Valeur
RPS quotidiennes moyennes
RPS moyennes aux heures de pointe
Nombre total d'utilisateurs uniques par jour
Nombre moyen d'utilisateurs simultanés quotidiens
Nombre maximal d'utilisateurs simultanés aux heures de pointe
Nombre total de demandes par jour
Distribution de la charge de travail attendue
Nombre de demandes par jour
%
Navigateur web - Analyse de recherche
Navigateur web - Interaction de collaboration générale
Navigateur web - Interaction sociale
Navigateur web - Interaction générale
Navigateur web - Office Web Apps
Clients Office
Client OneNote
SharePoint Workspace
Synchronisation RSS d'Outlook
Outlook Social Connector
Autres interactions (applications personnalisées/services web)
  • Utilisateurs simultanés - Il est très courant de mesurer la simultanéité des opérations exécutées sur la batterie de serveurs comme le nombre d'utilisateurs distincts générant des requêtes dans un délai donné. Les mesures clés sont la moyenne journalière et les utilisateurs simultanés en charge maximale.

  • Requêtes par seconde (RPS) - Les RPS sont un indicateur couramment utilisé pour décrire la demande sur la batterie de serveurs exprimée en nombre de requêtes traitées par la batterie par seconde, mais sans différencier le type ou la taille des requêtes. Chaque base d'utilisateurs d'une organisation génère une charge du système à un taux dépendant des caractéristiques d'utilisation uniques de l'organisation. Pour plus d’informations, voir Glossaire.

  • Nombre total de requêtes quotidiennes - Le nombre total de requêtes quotidiennes est un bon indicateur de la charge globale que le système devra gérer. Il est plus courant de mesurer toutes les demandes à l’exception des demandes de protocole d’authentification (état HTTP 401) sur une période de 24 heures.

  • Nombre total d'utilisateurs quotidiens - Le nombre total d'utilisateurs quotidiens est un autre indicateur clé de la charge globale que le système devra gérer. Cette mesure est le nombre réel d’utilisateurs uniques sur une période de 24 heures, et non le nombre total d’employés dans l’organisation.

    Notes

    Le nombre total d'utilisateurs quotidiens peut indiquer le potentiel de croissance de la charge sur la batterie. Par exemple, si le nombre d'utilisateurs potentiels correspond à 100 000 employés, un nombre de 15 000 utilisateurs quotidiens indique que la charge est susceptible d'augmenter considérablement dans le temps au fur et à mesure que le nombre d'utilisateurs adoptant le système augmente.

  • Distribution de la charge de travail : comprendre la distribution des demandes en fonction des applications du client qui interagissent avec la batterie de serveurs peut vous aider à prévoir la tendance attendue et les modifications de charge après la migration vers SharePoint Server 2013. À mesure que les utilisateurs passeront à des versions clientes plus récentes telles que Office 2013, et commenceront à utiliser les nouvelles fonctionnalités, les nouveaux modèles de charge, les demandes par seconde et le nombre total de demandes devraient augmenter. Pour chaque client, nous pouvons décrire le nombre d’utilisateurs distincts qui l’utilisent dans une période d’une journée et le nombre total de demandes générées par le client ou la fonctionnalité sur le serveur.

    Par exemple, le graphique ci-dessous présente un instantané d'un environnement Microsoft interne en ligne traitant une solution sociale standard. Dans cet exemple, vous pouvez voir que la majeure partie de la charge est générée par le robot de recherche et la navigation web classique de l’utilisateur final. Vous pouvez également observer qu'une charge considérable a été introduite par la fonctionnalité Outlook Social Connector (6,2 % des requêtes).

    Répartition de la charge quotidienne typique des demandes

Estimation de votre charge de travail de production

Lors de l’estimation du débit requis que votre batterie doit être capable de supporter, commencez par estimer la combinaison de transactions qui sera utilisée dans votre batterie. Concentrez-vous sur l’analyse des transactions les plus fréquemment utilisées que le système traitera, et tâchez de comprendre la fréquence à laquelle elles seront utilisées et par combien d’utilisateurs. Ceci vous permettra de valider plus tard la capacité de la batterie à supporter une telle charge dans les tests de pré-production.

Le diagramme suivant décrit la relation entre la charge de travail et la charge sur le système :

Capacité : diagramme de charge de travail

Pour évaluer votre charge de travail attendue, collectez les informations suivantes :

  • Identifiez les interactions utilisateur telles que les navigations de page web classiques, les téléchargements et téléchargements de fichiers, les vues et les modifications de l’application web Office dans le navigateur, les interactions de co-édition, les synchronisations de sites d’espace de travail SharePoint, les connexions sociales Outlook, la synchronisation RSS (dans Outlook ou d’autres visionneuses), les diffusions PowerPoint, OneNote blocs-notes partagés, Excel de travail partagés service, applications partagées Access Service, etc. Pour plus d’informations, voir Services et fonctionnalités. Concentrez-vous sur l’identification des interactions qui peuvent être propres à votre déploiement et identifiez l’impact attendu d’une telle charge. Par exemple, vous pouvez utiliser les formulaires InfoPath, les calculs du service Excel et des solutions dédiées similaires.

  • Identifiez les opérations du système, telles que les analyses incrémentielles de recherche, les sauvegardes quotidiennes, les travaux du minuteur de synchronisation de profil, le traitement des analyses web, les travaux du minuteur de journalisation et autres.

  • Estimons le nombre total d’utilisateurs par jour devant utiliser chaque fonctionnalité, dérivez les utilisateurs simultanés estimés et les demandes de haut niveau par seconde, il existe certaines hypothèses que vous effectuerez, telles que la simultanéité actuelle et le facteur de rps par utilisateur simultané qui est différent d’une fonctionnalité à l’autre, vous devez utiliser le tableau de charges de travail plus haut dans cette section pour vos estimations. Il est important de se concentrer sur les heures de pointe plutôt que sur le débit moyen. La planification de l’activité maximale vous permet de dimension SharePoint solution basée sur Server 2013.

Si vous avez une solution Office SharePoint Server 2007 existante, vous pouvez utiliser les fichiers journaux IIS ou consulter d’autres outils d’analyse Web pour mieux comprendre certains des comportements attendus de la solution existante ou consulter les instructions de la section ci-dessous pour plus d’informations. Si vous ne migrez pas à partir d’une solution existante, vous devez remplir le tableau à l’aide d’estimations approximatives. Dans les étapes ultérieures, vous devrez valider vos hypothèses et régler le système.

Analyse de vos journaux IIS SharePoint Server 2013

Afin de découvrir des mesures clés concernant un déploiement SharePoint Server 2013 existant, comme le nombre d'utilisateurs actifs, l'intensité d'utilisation du système, le type de requêtes entrantes et le type de clients dont elles proviennent, il est nécessaire d'extraire les données des journaux ULS et IIS. L'une des manières les plus simples d'acquérir ces données consiste à utiliser Log Parser, un outil puissant disponible en téléchargement gratuit via Microsoft. Cet outil peut lire et écrire dans différents formats binaires et textuels, notamment tous les formats ISS.

Vous pouvez télécharger Log Parser 2.2 à l'adresse suivante : https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en.

Jeu de données

Le jeu de données décrit le volume du contenu stocké dans le système et la façon dont il peut être distribué dans le magasin de données. Le tableau suivant fournit des mesures clés qui sont utiles dans la détermination de votre jeu de données. Vous pouvez utiliser ce tableau pour enregistrer ces mesures en même temps que vous les collectez.

Objet Valeur
Taille de base de données (en Go)
Nombre de bases de données de contenu
Nombre de collections de sites
Nombre d'applications web
Nombre de sites
Taille de l'index de recherche (nombre d'éléments)
Nombre de documents
Nombre de listes
Taille moyenne des sites
Taille du plus grand site
Nombre de profils utilisateur
  • Taille du contenu - La compréhension de la taille du contenu que vous pensez stocker dans le système SharePoint Server 2013 est importante pour la planification et l'architecture du stockage du système, ainsi que pour le dimensionnement correct de la solution de recherche qui analysera et indexera ce contenu. La taille du contenu est décrite en espace disque total. Si vous migrez du contenu à partir d’un déploiement existant, il peut s’agir d’une simple identification de la taille totale que vous allez déplacer . lors de la planification, vous devez laisser de l’espace pour la croissance au fil du temps en fonction de la tendance prévue.

  • Nombre total de documents - En plus de la taille du corpus de données, il est important de suivre le nombre global d'éléments. Le système réagit différemment si 100 Go de données sont composés de 50 fichiers de 2 Go chacun contre 100 000 fichiers de 1 Ko chacun. Dans les déploiements de grande taille, moins il y a de contraintes sur un élément, un document ou une zone de documents unique, plus les performances seront bonnes. Le contenu largement distribué comme plusieurs fichiers plus petits sur de nombreux sites et collections de sites est plus facile à servir qu’une seule bibliothèque de documents de grande taille avec des fichiers de grande taille.

  • Taille maximale de collection de sites - Il est important d'identifier la plus grande unité de contenu que vous stockerez dans SharePoint Server 2013 ; habituellement, un besoin organisationnel vous empêche de fractionner cette unité de contenu. La taille moyenne de toutes les collections de sites et le nombre total estimé de collections de sites sont des indicateurs supplémentaires qui vous aideront à identifier l'architecture de données que vous préférez.

  • Caractéristiques des données des applications de service : outre l’analyse des besoins en stockage pour le magasin de contenu, vous devez analyser et estimer la taille des autres magasins SharePoint Server 2013, notamment :

  • Taille totale de l'index de recherche

  • Taille totale de la base de données de profils en fonction du nombre d’utilisateurs dans le magasin de profils

  • Taille totale de la base de données sociale en fonction du nombre attendu de balises, de collègues et d’activités

  • Taille du magasin de métadonnées

  • Taille de la base de données d'utilisation

  • Taille de la base de données Web Analytics

Définition des objectifs de fiabilité et de performances de la batterie de serveurs

L’un des impératifs de l’étape 1 : Modélisation réside dans la bonne compréhension des objectifs de fiabilité et de performances qui correspondent au mieux aux besoins de votre organisation. Une solution SharePoint Server 2013 correctement conçue doit pouvoir atteindre « quatre neufs » (99,99 %) de temps de fonctionnement avec une réactivité de serveur de moins de seconde.

Les indicateurs utilisés pour décrire les performances et la fiabilité de la batterie de serveurs peuvent être les suivants :

  • Disponibilité du serveur - Généralement décrite par le pourcentage du temps de fonctionnement global du système. Vous devez suivre tout temps mort inattendu et comparer la disponibilité globale à l'objectif organisationnel que vous avez défini. Les cibles sont généralement décrites par un nombre de neufs (c’est-à-dire, 99 %, 99,9 %, 99,99 %).

  • Réactivité du serveur - Le temps nécessaire à la batterie pour traiter des requêtes est également un bon indicateur pour suivre l'intégrité de la batterie. Cet indicateur est nommé latence côté serveur et il est courant d’utiliser la latence moyenne ou médiane (50e centile) des demandes quotidiennes reçues. Les objectifs sont généralement décrits en sous-secondes ou secondes. Si votre organisation a pour objectif de servir des pages à partir de SharePoint Server 2013 en moins de deux secondes, l’objectif côté serveur doit être inférieur à quelques secondes pour que la page atteigne le client sur le réseau et le temps de rendu dans le navigateur. En règle générale, des temps de réponse de serveur plus longs indiquent une batterie défectueuse, car ceci a généralement un impact sur le débit, et que les RPS peuvent rarement suivre si vous passez plus d'une seconde sur le serveur sur la plupart des requêtes.

  • Problème de serveur : un autre indicateur de latence côté serveur intéressant le suivi est le comportement des 5 % de demandes les plus lentes. Les demandes plus lentes sont généralement les demandes qui touchent le système lorsqu’elle est sous charge plus élevée ou encore plus fréquemment, les demandes qui sont touchées par une activité moins fréquente qui se produit pendant que les utilisateurs interagissent avec le système ; Un système sain est également celui qui a les demandes les plus lentes sous contrôle. La cible ici est similaire à la réactivité du serveur, mais pour obtenir une réponse en moins de secondes sur le spikiness du serveur, vous devrez créer le système avec de nombreuses ressources de rechange pour gérer les pics de charge.

  • Utilisation des ressources système : d’autres indicateurs courants utilisés pour suivre l’état du système sont une collection de compteurs système qui indiquent l’état de chaque serveur dans la topologie de la batterie de serveurs. Les indicateurs les plus fréquemment utilisés pour le suivi sont l’utilisation du processeur % et la mémoire disponible . Toutefois, il existe plusieurs autres compteurs qui peuvent aider à identifier un système non sain ; Vous pouvez trouver plus d’informations à l’étape 5 : Surveiller et gérer.

Étape 2 : Conception

Maintenant que vous avez terminé de collecter des faits et des estimations sur la solution que vous devez livrer, vous êtes prêt à passer à l'étape suivante de conception d'une proposition d'architecture qui, d'après vous, sera capable de supporter la demande attendue.

À la fin de cette étape, vous devez posséder une conception pour votre topologie physique et une disposition pour votre topologie logique ; vous devez donc être capable de traiter n'importe quel bon de commande nécessaire.

Les spécifications matérielles et le nombre de machines disposées sont étroitement liés. Pour gérer une charge spécifique, il existe plusieurs solutions que vous pouvez choisir de déployer. Il est courant d'utiliser un petit ensemble de machines puissantes (montée en puissance) ou un plus grand ensemble de machines plus petites (mise à l'échelle) : chaque solution a des avantages et des inconvénients lorsqu'il est question de capacité, de redondance, de puissance, de coûts, d'espace et d'autres considérations.

Nous vous conseillons de commencer cette étape en déterminant votre architecture et votre topologie. Définissez la façon dont vous envisagez de disposer les différentes batteries et les différents services dans chaque batterie, puis choisissez les spécifications matérielles pour chacun des serveurs individuels de votre conception. Vous pouvez également exécuter ce processus en identifiant les spécifications matérielles que vous voulez déployer (la liberté de nombreuses organisations est limitée par une norme d'entreprise), puis définir votre architecture et votre topologie.

Utilisez le tableau suivant pour enregistrer vos paramètres de conception. Les données incluses sont des exemples de données et ne sont pas utilisés pour dimensioner votre batterie de serveurs. Elles sont destinées à montrer comment utiliser ce tableau pour vos propres données.

Rôle Type (standard ou virtuel) Nombre de machines Processeur Mémoire RAM Besoins en opérations d'E/S par seconde Taille sur le disque, système d'exploitation + journal Lecteur de données
Serveurs web
Virtuel
4
4 cœurs
8
N/D
400 Go
N/D
Serveur de base de données de contenu
Standard
1 cluster
4 quadruples cœurs 2,33 (GHz)
48
2k
400 Go
20 disques de 300 Go
@ 15 000 TPM
Serveurs d’applications
Virtuel
4
4 cœurs
16
N/D
400 Go
N/D
Serveur web cible d'analyse de recherche
Virtuel
1
4 cœurs
8
N/D
400 Go
N/D
Serveur de requête de recherche
Standard
2
2 quadruples cœurs 2,33 (GHz)
32
N/D
400 Go
500 Go
Serveur de robot de recherche
Standard
2
2 quadruples cœurs 2,33 (GHz)
16
400
400 Go
N/D
Serveur de base de données d'analyse de recherche
Standard
1 cluster
4 quadruples cœurs 2,33 (GHz)
48
4 000 (réglé pour la lecture)
100 Go
16 disques de 150 Go @ 15 000 TPM
Base de données de banque de propriétés de recherche + serveur de base de données d'administration
Standard
1 cluster
4 quadruples cœurs 2,33 (GHz)
48
2 000 (réglé pour l'écriture)
100 Go
16 disques de 150 Go @ 15 000 TPM

Déterminer votre architecture de départ

Cette section explique comment sélectionner une architecture de départ.

Lorsque vous déployez SharePoint Server 2013, vous pouvez choisir parmi une gamme de topologies pour implémenter votre solution ; vous pouvez déployer un serveur unique ou mettre à l’échelle de nombreux serveurs vers une batterie de serveurs SharePoint Server 2013 avec des serveurs de base de données en cluster ou en miroir et des serveurs d’applications discrets pour différents services. Ensuite, vous sélectionnez les configurations matérielles en fonction des exigences de chacun des rôles, en fonction de vos besoins en capacité, disponibilité et redondance.

Commencez par examiner les différentes architectures de référence et identifier la structure de votre batterie ; déterminez si vous devez fractionner votre solution dans plusieurs batteries ou fédérer certains services, comme la recherche, sur une batterie dédiée. Pour plus d’informations, voir Architectures de référence.

Études de cas techniques sur SharePoint Server 2010

Les instructions de gestion de la capacité pour SharePoint Server 2013 incluent de nombreuses études de cas techniques d’environnements de production existants qui présentent une description détaillée des environnements de production SharePoint Server 2013 existants. Les études de cas techniques spécifiques à SharePoint Server 2013 seront publiées dès qu’elles seront disponibles ; les études de cas SharePoint Server 2010 existantes peuvent servir de référence sur la conception d’un environnement SharePoint Server 2013 à des fins spécifiques.

Vous pouvez utiliser ces études de cas comme référence lors de la conception de l’architecture de vos solutions SharePoint Server 2013, en particulier si vous trouvez la description de ces différenciateurs clés spécifiques de déploiement semblables aux demandes et cibles de la solution que vous créez.

Ces documents fournissent les informations suivantes pour chaque étude de cas documentée :

  • spécifications, telles que le matériel, la topologie de batterie de serveurs et la configuration ;

  • Charge de travail: base d'utilisateurs et caractéristiques d'utilisation

  • Jeu de données, y compris tailles de contenu, caractéristiques de contenu et distribution de contenu

  • Intégrité et performances: ensemble d'indicateurs enregistrés décrivant les caractéristiques de fiabilité et de performances de la batterie

Pour plus d'informations, téléchargez les documents appropriés à partir de la page sur les études de cas techniques sur la performance et la capacité (SharePoint Server 2010).

Sélectionner votre matériel

La sélection des spécifications correctes pour les machines de votre batterie est une étape cruciale pour garantir la fiabilité et les performances de votre déploiement. L’un des concepts clés à garder à l’esprit est que vous devez planifier la charge et les heures de pointe. En d’autres termes, lorsque votre batterie fonctionne sous des conditions de charge moyenne, il doit y avoir suffisamment de ressources disponibles pour gérer la plus grande demande attendue tout en atteignant les objectifs de débit et de latence.

Les fonctionnalités matérielles de performances et de capacité principales des serveurs s'apparentent à quatre grandes catégories : la puissance de traitement, les performances du disque, la capacité réseau et les capacités de mémoire d'un système.

Vous devez également prendre en compte l'utilisation de machines virtuelles. Une batterie SharePoint Server 2013 peut être déployée à l’aide de machines virtuelles. Même si la virtualisation n'est pas obligatoirement source d'amélioration des performances, elle facilite la gestion. La virtualisation SQL Server ordinateurs basés sur un ordinateur n’est pas recommandée, mais la virtualisation des niveaux serveur Web et serveur d’applications peut avoir certains avantages. Pour plus d’informations, voir Planification de la virtualisation (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)).

Pour plus d’informations sur la configuration matérielle requise, voir Configuration matérielle et logicielle requise pour SharePoint Server 2016.

Instructions pour la sélection du matériel

Choix des processeurs

SharePoint Server 2013 est uniquement disponible pour les processeurs 64 bits. En règle générale, un nombre plus élevé de processeurs vous permettra de traiter une demande plus conséquente.

Dans SharePoint Server 2013, les serveurs web individuels évolueront à mesure que vous ajoutez des cœurs. Plus le serveur dispose d'un grand nombre de cœurs, plus il peut supporter de charge, le reste étant équivalent. Dans les déploiements SharePoint Server 2013 de grande taille, nous vous recommandons d’allouer plusieurs serveurs web 4 cœurs (qui peuvent être virtualisés) ou moins de serveurs web plus puissants (8-/16-/24 cœurs).

Les besoins en capacité de processeur des serveurs d'applications diffèrent en fonction du rôle du serveur et des services qu'il exécute. Certaines SharePoint Server 2013 exigent une puissance de traitement plus élevée que d’autres. Par exemple, le service de recherche SharePoint dépend grandement de la puissance de traitement du serveur d'applications.

Les besoins en capacité de processeur pour SQL Server dépendent également des bases de données de service qu'un ordinateur basé sur SQL Server héberge.

Choix de la mémoire

Vos serveurs nécessiteront des quantités variables de mémoire, selon la fonction et le rôle du serveur. Par exemple, les serveurs qui exécutent des composants d'analyse de recherche traiteront les données plus rapidement s'ils disposent d'une quantité élevée de mémoire car les documents sont lus dans la mémoire pour le traitement. Les serveurs web qui profitent des nombreuses fonctionnalités de mise en cache de SharePoint Server 2013 peuvent également nécessiter plus de mémoire.

En règle générale, les besoins en mémoire de serveur web dépendent grandement du nombre de pools d'applications activés dans la batterie et du nombre de requêtes simultanées en cours de traitement. Dans la plupart des déploiements SharePoint Server 2013 de production, nous vous recommandons d’allouer au moins 8 Go de RAM sur chaque serveur web, avec 16 Go recommandés pour les serveurs dont le trafic ou les déploiements avec plusieurs pools d’applications sont mis en place pour l’isolation.

Les besoins en mémoire des serveurs d’applications diffèrent également . Certaines SharePoint server 2013 ont plus de besoins en mémoire au niveau de l’application que d’autres. Dans la plupart des déploiements SharePoint Server 2013 de production, nous vous recommandons d’allouer au moins 8 Go de RAM sur chaque serveur d’applications ; 16 Go, 32 Go et 64 Go de serveurs d’applications sont courants lorsque de nombreux services d’application sont activés sur le même serveur ou lorsque des services très dépendants de la mémoire, tels que le service de calcul Excel et le service de recherche SharePoint Server 2013, sont activés.

Les besoins en mémoire des serveurs de base de données dépendent étroitement de la taille de la base de données. Pour plus d’informations sur le choix de la mémoire pour vos ordinateurs SQL Server, voir Stockage and SQL Server capacity planning and configuration (SharePoint Server).

Choix des réseaux

Outre les avantages offerts aux utilisateurs, si les clients ont un accès rapide aux données via le réseau, une batterie de serveurs distribuée doit avoir un accès rapide pour la communication entre serveurs. Ceci est particulièrement vrai lorsque vous distribuez des services sur plusieurs serveurs ou que vous fédérez certains services vers d'autres batteries. Il existe un trafic important dans une batterie de serveurs au niveau du serveur web, du serveur d’applications et du serveur de base de données, et le réseau peut facilement devenir un goulot d’étranglement dans certaines conditions, telles que le traitement de fichiers de grande taille ou des charges élevées.

Les serveurs web et les serveurs d'applications doivent être configurés pour utiliser au moins deux cartes d'interface réseau : une pour gérer le trafic de l'utilisateur final et l'autre pour gérer les communications inter-serveurs. La latence du réseau entre les serveurs peut avoir un impact considérable sur les performances. Par conséquent, il est important de maintenir moins d'1 milliseconde de latence du réseau entre le serveur web et les ordinateurs basés sur SQL Server hébergeant les bases de données de contenu. Les ordinateurs basés sur SQL Server qui hébergent chaque base de données d'application de service doivent également être aussi proches que possible du serveur d'applications consommateur. Le réseau entre les serveurs de la batterie doit présenter au moins 1 Gbits/s de bande passante.

Choix des disques et du stockage

La gestion des disques n’est pas simplement une fonction permettant de fournir suffisamment d’espace pour vos données. Vous devez évaluer la demande et la croissance en cours et vous assurer que l’architecture de stockage ne ralentit pas le système. Vous devez toujours vous assurer que vous avez une capacité supplémentaire d’au moins 30 % sur chaque disque, supérieure à votre estimation de besoins en données la plus élevée, afin de laisser de l’espace pour une croissance future. En outre, dans la plupart des environnements de production, la vitesse du disque (opérations d'E/S par seconde) est essentielle en vue de fournir un débit suffisant pour satisfaire les demandes de stockage des serveurs. Vous devez estimer la quantité du trafic (opérations d'E/S par seconde) dont les bases de données principales auront besoin dans votre déploiement et allouer assez de disques pour ce trafic.

Pour plus d’informations sur le choix des disques pour les serveurs de base de données, voir Stockage and SQL Server capacity planning and configuration (SharePoint Server).

Les serveurs web et d'applications ont également des besoins de stockage. Dans la plupart des environnements de production, nous vous recommandons d'allouer au moins 200 Go d'espace disque pour le système d'exploitation et le dossier temp, et 150 Go d'espace disque pour les journaux.

Étape 3 : pilote, test et optimisation

La phase de test et d’optimisation est un composant important de la gestion efficace de la capacité. Vous devez tester les nouvelles architectures avant de les déployer dans la production et vous devez conduire des tests d'acceptation tout en suivant les meilleures pratiques de surveillance afin de garantir que les architectures que vous concevez atteignent les objectifs de capacité et de performances. Ceci vous permet d'identifier et d'optimiser les goulots d'étranglement potentiels avant qu'ils aient une incidence sur les utilisateurs dans un déploiement en direct. Si vous effectuerez une mise à niveau à partir d’un environnement Office SharePoint Server 2007 et prévoyez d’apporter des modifications architecturales, ou si vous estez en mesure d’estimer la charge utilisateur des nouvelles fonctionnalités SharePoint Server 2013, il est important de tester votre nouvel environnement SharePoint Server 2013 pour atteindre les objectifs de performances et de capacité.

Après avoir testé votre environnement, vous pouvez analyser les résultats des tests pour déterminer les modifications qui doivent être apportées afin d'atteindre les objectifs de capacité et de performances que vous avez établis à l'Étape 1 : Modélisation.

Les sous-étapes de pré-production sont les suivantes :

  • Créez l'environnement de test imitant l'architecture initiale que vous avez conçue à l'Étape 2 : Conception.

  • Remplissez l'espace de stockage avec une partie ou l'ensemble du jeu de données que vous avez identifié à l'Étape 1 : Modélisation.

  • Imposez une charge synthétique au système, représentant la charge de travail que vous avez identifiée à l'Étape 1 : Modélisation.

  • Exécutez les tests, analysez les résultats et optimisez votre architecture.

  • Déployez votre architecture optimisée dans votre centre de données et lancez un pilote avec un ensemble d'utilisateurs plus restreint.

  • Analysez les résultats du pilote, identifiez les goulots d'étranglement potentiels et optimisez l'architecture. Effectuez de nouveaux tests si nécessaire.

  • Exécutez le déploiement dans l’environnement de production.

Tester

Le test est un facteur essentiel pour établir la capacité de votre conception système à prendre en charge vos caractéristiques d’utilisation et de charge de travail. Voir Test des performances de SharePoint Server 2013 pour plus d'informations concernant le test de votre déploiement SharePoint Server 2013.

  • Créer un plan de test

  • Créer l'environnement de test

  • Créer des tests et des outils

Déployer l’environnement pilote

Avant de déployer SharePoint Server 2013 dans un environnement de production, il est important que vous déployiez d’abord un environnement pilote et que vous testiez minutieusement la batterie de serveurs pour vous assurer qu’elle peut atteindre les objectifs de capacité et de performances pour la charge maximale attendue. Nous vous recommandons de tester l'environnement pilote d'abord avec une charge synthétique, surtout pour les déploiements de grande envergure, puis d'effectuer des tests de contrainte avec un petit ensemble d'utilisateurs et de contenu en direct. L’analyse de l’environnement pilote à l’aide d’un petit ensemble d’utilisateurs permet de valider certaines de vos hypothèses concernant les caractéristiques d’utilisation et la croissance du contenu avant de passer complètement en production.

Optimiser

Si vous ne pouvez pas atteindre vos objectifs de capacité et de performances en mettant le matériel de votre batterie à l’échelle ou en apportant des modifications à la topologie, vous devez peut-être envisager de revoir votre solution. Par exemple, si les exigences initiales impliquaient une batterie unique pour la collaboration, la recherche et l’aspect social, vous devrez peut-être fédérer certains services, tels que la recherche, vers une batterie de services dédiée, ou fractionner la charge de travail sur plus de batteries. Une autre solution consiste à déployer une batterie de serveurs dédiée à l’aspect social et une autre pour la collaboration en équipe.

Étape 4 : Déploiement

Une fois que vous avez exécuté votre série finale de tests et confirmé que l’architecture, vous avez sélectionné peut atteindre les objectifs de performances et de capacité que vous avez établis à l’étape 1: Modèle , vous pouvez déployer votre environnement SharePoint Server 2013 en production.

La stratégie de lancement appropriée variera en fonction de l'environnement et de la situation. Bien SharePoint déploiement de Server 2013 n’entre généralement pas dans le cadre de ce document, certaines activités suggérées peuvent sortir de l’exercice de planification de la capacité. Voici quelques exemples :

  • Déploiement d’une nouvelle batterie de serveurs SharePoint Server 2013 : l’exercice de planification de la capacité doit avoir des plans guidés et confirmés pour la conception et le déploiement de SharePoint Server 2016. Dans ce cas, le lancement sera le premier déploiement étendu de SharePoint Server 2013. Les serveurs et les services utilisés lors des exercices de planification de la capacité devront être déplacés et reconstruits dans la production. Il s'agit du scénario le plus direct car aucune mise à niveau ou modification n'est nécessaire pour une batterie existante.

  • Mise à niveau d’une batterie de serveurs Office SharePoint Server 2007 vers SharePoint Server 2013 : l’exercice de planification de la capacité doit avoir validé la conception d’une batterie de serveurs qui peut répondre aux demandes existantes et s’accroître pour répondre à la demande et à l’utilisation accrues d’une batterie de serveurs SharePoint Server 2013. Une partie de l’exercice de planification de la capacité doit avoir inclus des migrations de test pour valider la durée du processus de mise à niveau, si un code personnalisé doit être modifié ou remplacé, si des outils tiers doivent être mis à jour, etc. À la fin de la planification de la capacité, vous devez avoir une conception validée, une compréhension du temps qu’il faudra pour la mise à niveau et un plan pour la meilleure utilisation du processus de mise à niveau (par exemple, une mise à niveau sur place ou la migration des bases de données de contenu vers une nouvelle batterie de serveurs). Si vous faites une mise à niveau sur place, lors de la planification de la capacité, vous avez peut-être constaté que du matériel supplémentaire ou mis à niveau sera nécessaire et des éléments à prendre en compte pour les temps d’arrêt. Une partie de la sortie de l’exercice de planification doit être une liste des modifications matérielles nécessaires et un plan détaillé de déploiement des modifications matérielles sur la batterie de serveurs en premier. Une fois la plateforme matérielle validée lors de la planification de la capacité, vous pouvez passer au processus de mise à niveau vers SharePoint Server 2013.

  • Amélioration des performances d’une batterie de serveurs SharePoint Server 2013 existante : l’exercice de planification de la capacité doit vous aider à identifier les goulots d’étranglement dans votre implémentation actuelle, à planifier les moyens de réduire ou d’éliminer ces goulots d’étranglement et à valider une implémentation améliorée qui répond aux besoins de votre entreprise pour les services SharePoint Server 2013. Il existe différentes façons de résoudre les problèmes de performances, à partir d’une solution aussi simple que la réaffectation des services sur le matériel existant, la mise à niveau du matériel existant ou l’ajout de matériel et l’ajout de services. Les différentes approches doivent être testées et validées lors de l'exercice de planification de la capacité, puis un plan de déploiement doit être conçu en fonction des résultats de ces tests.

Étape 5 : Surveillance et maintenance

Pour maintenir les performances du système, vous devez surveiller votre serveur afin d'identifier les goulots d'étranglement potentiels. Avant de parvenir à une surveillance efficace, vous devez comprendre les indicateurs clés qui vous signaleront si vous devez porter votre attention sur une partie spécifique de votre batterie, et comment interpréter ces indicateurs. Si vous vous rendez compte que votre batterie fonctionne de façon non conforme aux objectifs que vous avez définis, vous pouvez l'ajuster en ajoutant ou en enlevant des ressources matérielles, en modifiant votre topologie ou en modifiant le stockage des données.

Voir Analyse et maintenance de SharePoint Server 2013 pour obtenir la liste des paramètres que vous pouvez modifier afin de surveiller votre environnement à ses débuts, ce qui vous aidera à déterminer si des modifications sont nécessaires. Gardez à l'esprit que l'augmentation de vos capacités de surveillance aura une incidence sur la quantité d'espace disque qui sera nécessaire à votre base de données d'utilisation. Une fois que l'environnement est stable et que cette surveillance détaillée n'est plus nécessaire, vous pouvez inverser les paramètres et les passer en-dessous de leurs paramètres par défaut.

Pour plus d’informations sur la surveillance et la résolution des problèmes d’état à l’aide des outils d’analyse d’état intégrés à l’interface d’administration centrale de SharePoint Server 2013, voir :

Surveillance et création de rapports dans SharePoint Server 2016

Résolution des problèmes et dépannage

Voir aussi

Concepts

Test des performances de SharePoint Server 2013

Analyse et maintenance de SharePoint Server 2013

Limitations et frontières logicielles pour SharePoint Server 2016

Résultats des tests de performances et de capacité, avec recommandations (SharePoint Server 2013)

Autres ressources

Capacity management and sizing overview for SharePoint Server 2013

Études de cas techniques sur la performance et la capacité (SharePoint Server 2010)