Planification de la capacité pour SharePoint Server 2013

S’APPLIQUE À :2013 2016 2019 Édition d’abonnement SharePoint dans 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. Diverses considérations relatives à la gestion et à l’utilisation de la capacité affectent la façon dont vous devez déterminer les options matérielles et de configuration les plus appropriées.

Avant de lire cet article, nous conseillons de lire la page Vue d'ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2013.

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 une exécution réussie et comporte 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 SharePoint Server 2013 commence par l’analyse de vos solutions existantes et l’estimation de la demande et des cibles attendues pour le déploiement que vous envisagez de configurer. Vous commencez par collecter des informations sur votre base d’utilisateurs, les exigences en matière de données, les cibles de latence et de débit, puis vous 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 à la fois 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 du jeu de données telles que la taille du contenu 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.

• 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, consultez 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 le plus courant de mesurer toutes les demandes, à l’exception des demandes de négociation 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 correspond au nombre réel d’utilisateurs uniques sur une période de 24 heures, et non au nombre total d’employés dans l’organisation.

  Remarque

  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 des charges de travail : comprendre la distribution des demandes en fonction des applications du client qui interagissent avec la batterie de serveurs peut aider à prédire la tendance attendue et les changements de charge après la migration vers SharePoint Server 2013. À mesure que les utilisateurs passent à des versions clientes plus récentes telles qu’Office 2013, et commencent à utiliser les nouvelles fonctionnalités, les nouveaux modèles de charge, rpS et le nombre total de demandes devraient augmenter. Pour chaque client, nous pouvons décrire le nombre d’utilisateurs distincts qui l’utilisent dans un laps de temps d’une journée, ainsi que 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 importante est introduite par la fonctionnalité Outlook Social Connector (6,2 % des requêtes).

  

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 servira et comprenez à quelle fréquence elles seront utilisées et par combien d’utilisateurs. Cette compréhension vous aidera ultérieurement lorsque vous vérifierez si la batterie peut supporter de telles charges 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 :

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

• Identifier les interactions utilisateur. Par exemple :

  • La page web est parcourue.
  • Téléchargements et chargements de fichiers.
  • Affichages et modifications de l’application web Office dans le navigateur.
  • Interactions de co-création.
  • Synchronisations de site de l’espace de travail SharePoint.
  • Outlook Social Connections.
  • Synchronisation RSS (dans Outlook ou d’autres visionneuses).
  • Diffusions PowerPoint.
  • Blocs-notes partagés OneNote.
  • Classeurs partagés Excel Service.
  • Accéder aux applications partagées du service

  Pour plus d’informations, consultez Services et fonctionnalités. Concentrez-vous sur l’identification des interactions qui peuvent être propres à votre déploiement. Reconnaître l’impact attendu de ces charges. Par exemple, une utilisation significative des formulaires InfoPath, des calculs Excel Service 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.

• Estimez les éléments suivants :

  • Nombre total d’utilisateurs par jour qui sont censés utiliser chaque fonctionnalité.
  • Dérivez les utilisateurs simultanés estimés et les requêtes de haut niveau par seconde.

  Vous allez faire quelques hypothèses. Par exemple :

  • Présenter l’accès concurrentiel.
  • Le facteur rps par utilisateur simultané qui est différent d’une capacité à l’autre

  Utilisez la table de charge 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 des pics d’activité vous permet de dimensionner correctement votre solution SharePoint Server 2013.

Si vous disposez d’une solution Office SharePoint Server 2007 existante, vous pouvez extraire les fichiers journaux IIS ou consulter d’autres outils de supervision web dont vous avez besoin pour mieux comprendre certains des comportements attendus de la solution existante. Sinon, consultez les instructions de la section ci-dessous pour plus d’informations. Si vous ne migrez pas à partir d’une solution existante, vous devez remplir la table à l’aide d’estimations approximatives. Dans les étapes ultérieures, vous devrez valider vos hypothèses et paramétrer le système.

Analyse de vos journaux IIS SharePoint Server 2013

Vous devez extraire des données des journaux ULS et IIS pour découvrir les métriques clés relatives à un déploiement SharePoint Server 2013 existant. Par exemple :

• Nombre d’utilisateurs actifs.
• À quel point ils utilisent le système.
• Quels sont les types de demandes qui arrivent.
• De quel type de clients proviennent les demandes.

L’un des moyens les plus simples de trouver ces données consiste à utiliser Log Parser, un outil puissant disponible gratuitement en téléchargement à partir de Microsoft. Log Parser peut lire et écrire dans de nombreux formats texte et binaire, y compris tous les formats IIS.

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

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.

• 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 être facile d’identifier la taille totale du contenu à déplacer. Pendant la planification, vous devez laisser de l’espace pour la croissance au fil du temps.

• Nombre total de documents : outre la taille du corpus de données, il est important de suivre le nombre total 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 grands déploiements, moins il y a de contrainte sur un élément, un document ou une zone de documents, plus les performances seront meilleures. 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 volumineuse avec des fichiers volumineux.

• Taille maximale de la collection de sites : il est important d’identifier la plus grande unité de contenu que vous allez stocker dans SharePoint Server 2013. il s’agit généralement d’un besoin organisationnel qui 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 : en plus d’analyser les besoins de 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 d’étiquettes, 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 être en mesure d’atteindre « quatre neuf » (99,99 %) de temps d’activité avec une réactivité du serveur inférieure à la 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 de temps d’activité 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 neuf (soit 99 %, 99,9 %, 99,99 %)

• Réactivité du serveur : le temps nécessaire à la batterie de serveurs pour traiter les demandes est un bon indicateur pour suivre l’intégrité de la batterie de serveurs. Cet indicateur est nommé latence côté serveur. Tt utilise couramment la latence moyenne ou médiane (50e centile) des requêtes quotidiennes traitées. Les cibles sont généralement décrites en secondes ou fractions de secondes. Si la cible est de servir des pages en moins de deux secondes, l’objectif côté serveur doit être en fractions de seconde. Cette amélioration des performances permet à la page d’atteindre le client et de s’afficher dans le navigateur. En outre, des temps de réponse de serveur plus longs sont généralement une indication d’une batterie de serveurs non saine. RpS peut rarement suivre si vous passez plus d’une seconde sur le serveur pour la plupart des demandes.

• Spikiness du serveur : un autre bon indicateur de latence côté serveur qui mérite d’être suivi est le comportement des 5 % les plus lents de toutes les requêtes. Les requêtes les plus lentes sont généralement les requêtes qui touchent le système lorsqu’il est soumis à une charge plus élevée, ou même plus souvent, les requêtes qui sont affectées par une activité moins fréquente qui se produit lorsque les utilisateurs interagissent avec le système . un système sain est également celui qui contrôle les requêtes les plus lentes. La cible ici est similaire à la réactivité du serveur, mais pour obtenir une réponse en moins de seconde sur la spikiness du serveur, vous devez 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’intégrité du système sont une collection de compteurs système qui indiquent l’intégrité de chaque serveur dans la topologie de la batterie de serveurs. Les indicateurs les plus fréquemment utilisés pour effectuer le suivi sont le pourcentage d’utilisation du processeur et la mémoire disponible. toutefois, il existe plusieurs autres compteurs qui peuvent aider à identifier un système non sain; Pour plus d’informations, consultez Étape 5 : Surveiller et gérer.

Étape 2 : Conception

Maintenant que vous avez terminé la collecte de faits ou d’estimations sur la solution que vous devez fournir, vous êtes prêt à commencer l’étape suivante de la conception d’une architecture proposée qui, selon vous, sera en mesure de répondre à 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 que vous dispositionz sont étroitement liés. Pour gérer une charge spécifique, vous pouvez choisir de déployer plusieurs solutions. Il est courant d’utiliser un petit ensemble de machines fortes (scale-up) ou un plus grand ensemble de machines plus petites (scale-out) ; Chaque solution présente ses avantages et ses inconvénients en matière de capacité, de redondance, de puissance, de coût, 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 êtes censé déployer (de nombreuses organisations sont limitées à une certaine norme de l’entreprise), puis en définissant 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ées pour dimensionner votre batterie de serveurs. Il est destiné à montrer comment utiliser cette table pour vos propres données.

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 seul serveur ou effectuer un scale-out de nombreux serveurs sur une batterie de serveurs SharePoint Server 2013 avec des serveurs de base de données en cluster ou mis 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 matière de capacité, de disponibilité et de 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, consultez Architectures de référence.

Études de cas techniques sur SharePoint Server 2010

Les conseils 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 éléments de différenciation clés spécifiques au déploiement similaire aux exigences et aux cibles de la solution que vous concevez.

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 les tailles de contenu, les caractéristiques du contenu et la distribution du 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 de serveurs 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 des ordinateurs SQL Server n’est pas recommandée, mais la virtualisation des niveaux serveur web et serveur d’applications peut présenter certains avantages. Pour plus d’informations, consultez 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 volumineux, nous vous recommandons d’allouer plusieurs serveurs web 4 cœurs (qui peuvent être virtualisés) ou moins de serveurs web plus forts (8-/16-/24-cores).

Les besoins en capacité de processeur des serveurs d’applications varient en fonction du rôle du serveur et des services qu’il exécute. Certaines fonctionnalités de SharePoint Server 2013 nécessitent une plus grande puissance de traitement 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 qui ont un trafic plus élevé ou les déploiements avec plusieurs pools d’applications configurés pour l’isolation.

Les besoins en mémoire des serveurs d’applications diffèrent également ; Certaines fonctionnalités de SharePoint Server 2013 ont des besoins en mémoire plus importants sur la couche 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. Les serveurs d’applications de 16 Go, 32 Go et 64 Go sont courants lorsque de nombreux services d’application sont activés sur le même serveur ou lorsque des services qui dépendent fortement 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 Planification et configuration de la capacité de stockage et de SQL Server (SharePoint Server).

Choix des réseaux

En plus de l’avantage offert aux utilisateurs, si les clients disposent d’un accès rapide aux données via le réseau, une batterie distribuée doit disposer d’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 y a un trafic important dans une batterie de serveurs entre le niveau serveur web, le niveau serveur d’applications et le niveau serveur de base de données, et le réseau peut facilement devenir un goulot d’étranglement dans certaines conditions, comme la gestion de fichiers volumineux ou de 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 une latence réseau inférieure à 1 milliseconde entre le serveur web et les ordinateurs 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 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 disposez d’au moins 30 % de capacité supplémentaire sur chaque disque, au-delà de votre estimation des besoins de données les plus élevés, pour laisser de la place à 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, consultez Planification et configuration de la capacité de stockage et d’SQL Server (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 : Piloter, tester et optimiser

L’étape 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 effectuez une mise à niveau à partir d’un environnement Office SharePoint Server 2007 et que vous envisagez d’apporter des modifications architecturales, ou si vous estimez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server 2013, test important pour vous assurer que votre nouvel environnement SharePoint Server 2013 répond aux 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.

Voici les sous-étapes pour la préproduction :

• 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 l'architecture optimisée dans votre centre de données et déployez un pilote avec un ensemble d'utilisateurs plus petit.

• Analysez les résultats du pilote, identifiez les éventuels goulots d'étranglement et optimisez l'architecture. Effectuez un nouveau test si c’est nécessaire.

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

Tester

Les tests sont un facteur essentiel pour établir la capacité de votre conception système à prendre en charge vos caractéristiques de charge de travail et d’utilisation. 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 de déployer d’abord un environnement pilote et de tester 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 recommandons que l’environnement pilote soit d’abord testé avec une charge synthétique, en particulier pour les déploiements volumineux, puis mis en évidence par un petit ensemble d’utilisateurs en direct 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 dernière série de tests et confirmé que l’architecture que vous avez sélectionnée 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 que le déploiement de SharePoint Server 2013 soit généralement en dehors du 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 effectuer un scale-up 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 inclure 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 disposer d’une conception validée, d’une compréhension du temps nécessaire à la mise à niveau et d’un plan pour la meilleure façon de procéder au processus de mise à niveau, par exemple, une mise à niveau sur place ou la migration de bases de données de contenu vers une nouvelle batterie de serveurs. Si vous effectuez une mise à niveau sur place, pendant la planification de la capacité, vous avez peut-être constaté que du matériel supplémentaire ou mis à niveau sera nécessaire, ainsi que des considérations relatives aux 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é pour déployer d’abord les modifications matérielles dans la batterie de serveurs. Une fois que la plateforme matérielle qui a été validée lors de la planification de la capacité est en place, 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é devrait vous avoir aidé à identifier les goulots d’étranglement dans votre implémentation actuelle, à planifier des moyens de réduire ou d’éliminer ces goulots d’étranglement et à valider une implémentation améliorée qui répond à vos besoins métier pour les services SharePoint Server 2013. Les problèmes de performances ont pu être résolus de différentes façons, par exemple la réaffectation de services sur le matériel existant, la mise à niveau du matériel existant ou l’ajout de matériel supplémentaire 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 ci-dessous sur leurs paramètres par défaut.

Pour plus d’informations sur la surveillance et la résolution des problèmes d’intégrité à l’aide des outils de surveillance de l’intégrité intégrés à l’interface de SharePoint Server 2013 Central Administration, consultez :

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)