Planification de la capacité pour SharePoint Server 2010

Article
03/04/2017

S’applique à : SharePoint Server 2010

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

Cet article explique comment planifier la capacité d’une batterie de serveurs Microsoft SharePoint Server 2010. Lorsque vous avez une bonne appréciation et une bonne compréhension de la planification et de la gestion de capacité, vous pouvez appliquer vos connaissances au dimensionnement du système. Le dimensionnement est le terme employé pour décrire la sélection et la configuration de l’architecture de données appropriée, la topologie physique et logique, ainsi que le matériel d'une plateforme de solution. Il existe de nombreuses considérations relatives à l’utilisation et à la gestion de capacité qui affectent la façon dont vous devez déterminer les options de configuration et de matériel les plus appropriées.

Avant de lire cet article, vous devez lire l’article intitulé Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Dans cet article, nous décrivons les étapes à suivre pour effectuer une gestion de capacité efficace pour votre environnement. Chaque étape nécessite de disposer de certaines informations et génère un ensemble de résultats que vous utiliserez lors de l’étape suivante. Pour chaque étape, ces exigences et informations générées sont décrites dans des tableaux.

Dans cet article :

Étape 1: modéliser
Étape 2: concevoir
Étape 3: piloter, tester et optimiser
Étape 4: déployer
Étape 5: analyser et assurer la maintenance

Étape 1: modéliser

La modélisation de votre environnement SharePoint Server 2010 débute par l’analyse de vos solutions existantes et l’évaluation de la demande attendue et des cibles pour le déploiement que vous envisagez de configurer. Vous devez commencer par recueillir des informations sur votre base d’utilisateurs, les exigences en matière de données, la latence et les cibles de débit, et documenter les fonctionnalités SharePoint Server que vous souhaitez déployer. Utilisez cette section pour identifier les données que vous devez recueillir, comprendre comment les recueillir et comment elle peuvent être utilisées lors des étapes suivantes.

Comprendre votre charge de travail attendue et le groupe de données

Le dimensionnement correct d’une implémentation de SharePoint Server 2010 nécessite d’étudier et de comprendre les caractéristiques de demande que votre solution est censée gérer. Comprendre cette demande implique de pouvoir décrire les caractéristiques de charge de travail (telles que le nombre d’utilisateurs et les opérations les plus fréquemment utilisées) et les caractéristiques de groupe de données (telles que la taille et la distribution du contenu).

Cette section peut vous aider à comprendre certains paramètres et métriques spécifiques que vous devez recueillir, ainsi que les mécanismes de collecte à votre disposition.

Charge de travail

La charge de travail décrit la demande que le système devra prendre en charge, la base d’utilisateurs et les caractéristiques d’utilisation. Le tableau suivant propose quelques métriques clés utiles pour déterminer votre charge de travail. Vous pouvez l’utiliser pour enregistrer ces métriques à mesure que vous les recueillez.

Caractéristiques de charge de travail	Valeur
Moyenne quotidienne de demandes par secondes
Moyenne de demandes par secondes aux heures de pointe
Nombre total d’utilisateurs uniques par jour
Nombre moyen d’utilisateurs simultanés quotidien
Nombre maximal d’utilisateurs simultanés aux heures de pointe
Nombre total de demandes par jour
Distribution de 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 des flux RSS Outlook
Outlook Social Connector
Autres interactions (applications personnalisées/services Web)

Utilisateurs simultanés – Il est plus courant de mesurer la simultanéité des opérations exécutées sur la batterie de serveurs que le nombre d’utilisateurs distincts générant des requêtes dans un laps de temps donné. Les métriques clés sont la moyenne quotidienne et les utilisateurs simultanés au pic de charge.
Demandes par seconde – Le nombre de demandes par seconde est un indicateur courant permettant de décrire la demande sur la batterie de serveurs, exprimée en nombre de demandes traitées par la batterie de serveurs par seconde, mais sans aucune différenciation quant au type ou à la taille des demandes. La base d’utilisateurs de chaque organisation génère une charge système à un taux qui dépend des caractéristiques d’utilisation unique de l’organisation. Pour plus d’informations sur ce terme, voir le Glossaire dans Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.
Nombre total de demandes par jour – Le nombre total de demandes par jour est un bon indicateur quant à la charge globale que le système devra gérer. Il est 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 est un autre indicateur clé quant à la charge globale que le système devra gérer. Cette mesure correspond au nombre réel d’utilisateurs uniques durant une période de 24 heures, et non au 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 de serveurs. Par exemple, si le nombre d’utilisateurs potentiels est de 100 000 employés, une valeur de 15 000 utilisateurs quotidiens indique que la charge est susceptible de croître sensiblement à mesure que l’adoption par les utilisateurs augmente.
Distribution de la charge de travail – Comprendre la distribution des demandes en fonction des applications clientes qui interagissent avec la batterie de serveurs peut aider à prévoir la tendance et les modifications de charge après la migration vers SharePoint Server 2010. À mesure que les utilisateurs passent à des versions plus récentes de clients telles qu’Office 2010 et commencent à utiliser les nouvelles fonctionnalités et de nouveaux modèles de charge, il est prévu que le nombre de demandes par seconde et le nombre total de demandes augmentent. Pour chaque client, nous pouvons décrire le nombre d’utilisateurs distincts utilisant ce client dans un laps de temps 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 tableau ci-dessous présente un instantané d’un environnement Microsoft interne actif servant une solution sociale standard. Dans cet exemple, on peut constater que la majeure partie de la charge est générée par le robot de recherche et la navigation Web standard des utilisateurs finaux. On peut également remarquer qu’il existe une charge importante introduite par la nouvelle fonctionnalité Outlook Social Connector (6,2 % des demandes).

Répartition moyenne des demandes

Évaluation de la charge de travail de production

Lors de l’évaluation du débit que votre batterie de serveurs doit être en mesure de prendre en charge, commencez par évaluer la combinaison de transactions qui seront utilisées dans votre batterie. Axez votre travail sur l’analyse des transactions les plus fréquemment utilisées, sur leur fréquence d’utilisation et sur le nombre d’utilisateurs. Cela vous aidera à vérifier ultérieurement si la batterie de serveurs peut supporter cette charge lors des 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 la charge de travail attendue, recueillez les informations suivantes :

Identifiez les interactions utilisateur telles que les consultations de pages Web classiques, les chargements et téléchargements de fichiers, les affichages et modifications Office Web Application dans le navigateur, les interactions de co-création, les synchronisations de sites SharePoint Workspace, les connexions sociales Outlook, la synchronisation de flux RSS (dans Outlook ou autres visionneuses), les diffusions PowerPoint, les bloc-notes partagés OneNote, les classeurs partagés Excel Services, les applications partagées Excel Services et autres. Pour plus d’informations, voir la section Services et fonctionnalités de l’article Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010. Concentrez-vous sur l’identification des interactions qui peuvent être propres à votre déploiement et recherchez l’impact attendu d’une telle charge (par exemple, utilisation significative de formulaires InfoPath, calculs Excel Services et solutions dédiées similaires).
Identifiez les opérations système telles que les analyses de recherche incrémentielles, les sauvegardes quotidiennes, les travaux du minuteur de synchronisation des profils, le traitement des analyses Web, les travaux du minuteur de journalisation et autres.
Évaluez le nombre total d’utilisateurs par jour qui utiliseront chaque fonctionnalité, dérivez une estimation du nombre d’utilisateurs simultanés et du niveau élevé de demandes par seconde. Vous prendrez comme base certaines hypothèses telles que la concurrence d’accès existante et le facteur de demandes par seconde par utilisateur simultané qui diffère d’une fonctionnalité à l’autre. Pour vos estimations, utilisez le tableau de charge de travail proposé plus haut dans cette section. Il est important de se concentrer sur les heures de pointe plutôt que sur le débit moyen. La planification de l’activité de pointe vous permettra de dimensionner correctement votre solution SharePoint Server 2010.

Si vous avez une solution Office SharePoint Server 2007 existante, vous pouvez analyser les fichiers journaux des services Internet (IIS) ou tirer parti d’autres outils d’analyse Web à votre disposition afin de mieux comprendre certains des comportements attendus de la solution existante. Vous pouvez également consulter les instructions fournies dans la section ci-dessous pour plus d’informations. Si vous ne migrez pas à partir d’une solution existante, remplissez le tableau à l’aide d’estimations. Lors des étapes suivantes, vous devrez valider vos hypothèses et affiner le système.

Analyse de vos journaux IIS SharePoint Server 2010

Pour découvrir les métriques clés concernant un déploiement SharePoint Server 2010 existant, telles que le nombre d’utilisateurs actifs, l’intensité de l’utilisation du système, les types de demandes entrantes et le type de clients desquelles ces demandes proviennent, il est nécessaire d’extraire les données des journaux ULS et IIS. L’une des méthodes les plus simples pour obtenir ces données consiste à utiliser Log Parser, un outil puissant disponible gratuitement en téléchargement auprès de Microsoft. Log Parser peut lire et écrire dans plusieurs formats textuels et binaires, y compris tous les formats IIS.

Pour plus d’informations sur la façon d’analyser l’utilisation de SharePoint Server 2010 à l’aide de Log Parser, voir Analyse de l’utilisation des Produits et technologies Microsoft SharePoint (éventuellement en anglais) (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=fr-fr).

Vous pouvez télécharger Log Parser 2.2 à l’adresse https://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=fr-fr (éventuellement en anglais).

Groupe de données

Le terme « groupe de données » décrit le volume de contenu stocké dans le système et comment il peut être distribué dans le magasin de données. Le tableau suivant propose quelques métriques clés utiles pour déterminer votre groupe de données. Vous pouvez utiliser ce tableau pour enregistrer ces métriques à mesure que vous les recueillez.

Objet	Valeur
Taille de la 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 d’index de recherche (nombre d’articles)
Nombre de documents
Nombre de listes
Taille moyenne des sites
Taille de site maximale
Nombre de profils utilisateur

Taille du contenu – Comprendre la taille du contenu que vous comptez stocker dans le système SharePoint Server 2010 est important pour la planification et l’architecture du stockage système et pour le dimensionnement correct de la solution de recherche qui analysera et indexera ce contenu. La taille du contenu est décrite en terme d’espace disque total. Si vous migrez du contenu à partir d’un déploiement existant, il peut être plus simple d’identifier la taille totale que vous déplacerez ; lors de la planification, vous devez prendre en compte la croissance ultérieure en fonction de la tendance prévue.
Nombre total de documents – Outre la taille du corpus de données, il est important d’effectuer le suivi du nombre total d’éléments. Le système réagit différemment si 100 Go de données sont composées de 50 fichiers de 2 Go plutôt que de 100 000 fichiers de 1 Ko. Dans les déploiements à grande échelle, moins il y a de contrainte sur un élément, un document ou une zone de documents, meilleures sont les performances. Un contenu largement distribué, tel que plusieurs petits fichiers sur de nombreux sites et collections de sites, est plus facile à servir qu’une bibliothèque de documents unique de grande taille contenant de très gros fichiers.
Taille maximale de la collection de sites – Il est important d’identifier la plus grande unité de contenu que vous stockerez dans SharePoint Server 2010 ; en règle générale, il existe une exigence organisationnelle qui vous empêche de fractionner cette unité de contenu. La taille moyenne de toutes les collections de sites et l’estimation du nombre total de collections de sites sont des indicateurs supplémentaires qui vous aideront à identifier votre architecture de données optimale.
Caractéristiques des données des applications de service – Outre les besoins en stockage du magasin de contenu, vous devez analyser et évaluer la taille d’autres magasins SharePoint Server 2010, entre autres :
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 sociales en fonction du nombre prévu de liens de mise en réseau, 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

Pour plus d’informations sur la façon d’évaluer les tailles des bases de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

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

L’un des livrables de l’Étape 1 : modéliser est une bonne compréhension des cibles de performances et de fiabilité adaptées aux besoins de votre organisation. Une solution SharePoint Server à la conception correcte doit être en mesure d’atteindre 99,99 % de disponibilité avec un temps de réponse serveur inférieur à une seconde.

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

Disponibilité du serveur – Généralement décrite en terme de pourcentage du temps de fonctionnement global du système. Vous devez effectuer le suivi des temps d’arrêt inattendus et comparer la disponibilité globale à l’objectif organisationnel défini. Les cibles sont généralement décrites par un certain nombre de neuf (par exemple, 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 de suivi de l’intégrité de la batterie de serveurs. Cet indicateur est généralement appelé « latence côté serveur » et il est courant d’utiliser la valeur de latence moyenne ou médiane (50ème percentile) des demandes quotidiennes prises en charge. Les cibles sont généralement décrites en termes de secondes ou de valeurs inférieures à une seconde. Notez que si votre organisation a comme objectif de servir les pages de SharePoint Server 2010 en moins de deux secondes, l’objectif côté serveur doit être inférieur à une seconde, afin de laisser à la page le temps d’atteindre le client sur le réseau et de s’afficher dans le navigateur. De plus, des temps de réponse serveur plus longs sont des signes qui traduisent une mauvaise intégrité de la batterie, ceci ayant généralement un impact sur le débit et le nombre de demandes par seconde pouvant rarement suivre si vous passez plus d’une seconde sur le serveur sur la plupart des demandes.
Pointes de serveur – L’un des autres indicateurs de latence côté serveur qu’il est préférable d’analyser est le comportement des 5 % de demandes les plus lentes. Les demandes les plus lentes sont généralement celles qui impactent le système lorsqu’il est soumis à une charge élevée ou, ce qui est encore plus fréquent, celles affectées par une activité moins fréquente qui se produit pendant que des utilisateurs interagissent avec le système ; un système avec une bonne intégrité est un système dont vous contrôlez également les demandes les plus lentes. Ici, la cible est semblable à la réactivité du serveur, mais pour obtenir une réponse inférieure à une seconde vous devrez créer un système disposant de nombreuses ressources de secours afin de gérer les pics de charge.
Utilisation des ressources système – Parmi les autres indicateurs courants utilisés pour effectuer le suivi de l’intégrité du système figurent un ensemble de compteurs système qui indiquent l’intégrité de chaque serveur dans la topologie de batterie. Les indicateurs les plus fréquemment utilisés dont il faut 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 à l’intégrité douteuse ; vous trouverez davantage de détails lors de l’Étape 5 : analyser et assurer la maintenance.

Étape 2: concevoir

Maintenant que vous avez terminé la collecte des faits ou des estimations quant à la solution que vous avez besoin de fournir, vous êtes prêt pour l’étape suivante : la conception d’une architecture qui, selon vous, pourra prendre en charge la demande attendue.

À la fin de cette étape, vous devriez avoir une conception pour votre topologie physique et une disposition pour votre topologie logique, ce qui devrait vous permettre de procéder aux achats nécessaires.

Les spécifications matérielles et le nombre d’ordinateurs utilisés sont étroitement liés. Pour gérer une charge spécifique, il existe plusieurs solutions. Il est courant d’utiliser un petit ensemble d’ordinateurs puissants (montée en puissance par unité) ou un plus grand ensemble de petits ordinateurs (montée en puissance parallèle) ; chaque solution a ses avantages et ses inconvénients en termes de capacité, de redondance, d’alimentation, de coût, d’espace et autres considérations.

Nous vous recommandons de commencer par déterminer votre architecture et votre topologie. Définissez comment vous envisagez de disposer les différentes batteries de serveurs et les différents services de chaque batterie, puis choisissez les spécifications matérielles de chacun des serveurs de votre conception. Vous pouvez également identifier les spécifications matérielles que vous êtes censé déployer (de nombreuses organisations sont contraintes de respecter certaines normes 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 doivent pas être utilisées pour dimensionner votre batterie de serveurs. Elles ont pour but de montrer comment utiliser ce tableau pour vos propres données.

Rôle	Type (standard ou virtuel)	Nombre d’ordinateurs	Processeurs	RAM	Besoin IOPS	Taille de disque système d’exploitation + journal	Lecteur de données
Serveurs Web	Virtuel	4	4 cœurs	8	S/O	400 Go	S/O
Serveur de bases de données de contenu	Standard	1 cluster	4 quad-core 2,33 (GHz)	48	2 k	400 Go	20 disques de 300 Go @ 15 K TPM
Serveurs d’applications	Virtuel	4	4 cœurs	16	S/O	400 Go	S/O
Serveur Web cible d’analyse de recherche	Virtuel	1	4 cœurs	8	S/O	400 Go	S/O
Serveur de requête de recherche	Standard	2	2 quad-core 2,33 (GHz)	32	S/O	400 Go	500 Go
Serveur de robot de recherche	Standard	2	2 quad-core 2,33 (GHz)	16	400	400 Go	S/O
Serveur de bases de données d’analyse de recherche	Standard	1 cluster	4 quad-core 2,33 (GHz)	48	4 k (réglé pour la lecture)	100 Go	16 disques de 150 Go @ 15 K TPM
Base de données de magasin de propriétés de recherche + serveur de bases de données d’administration	Standard	1 cluster	4 quad-core 2,33 (GHz)	48	2 k (réglé pour l’écriture)	100 Go	16 disques de 150 Go @ 15 K TPM

Déterminer votre architecture de point de départ

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

Lorsque vous déployez SharePoint Server 2010, vous pouvez choisir parmi une gamme de topologies pour implémenter votre solution ; vous pouvez déployer un seul serveur ou de nombreux serveurs dans une batterie SharePoint Server avec des serveurs de bases de données en cluster ou en miroir et des serveurs d’applications distincts pour divers services. Ultérieurement, vous sélectionnerez les configurations matérielles en fonction des exigences de chacun des rôles et 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 déterminer la structure de votre batterie de serveurs, puis décidez si vous devez fractionner votre solution sur plusieurs batteries ou fédérer certains services, tels que la recherche, sur une batterie de serveurs dédiée. Pour plus d’informations, voir la section Architectures de référence dans Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Études de cas techniques SharePoint Server 2010

Les instructions d’aide à la gestion de capacité pour SharePoint Server 2010 comprennent un certain nombre d’études de cas techniques d’environnements de production existants qui présentent une description détaillée d’environnements de production SharePoint Server existants. D’autres études de cas techniques seront publiées au fil du temps ; elles pourront servir de référence quant à la conception d’un environnement SharePoint Server à des fins spécifiques.

Vous pouvez utiliser ces études de cas en guise de référence lors de la conception de l’architecture de vos solutions SharePoint Server, en particulier si vous constatez que la description de ces caractéristiques de différentiation clés spécifiques au déploiement est semblable aux demandes et aux cibles de la solution dont vous concevez l’architecture.

Ces documents décrivent 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, y compris la base d’utilisateurs et les caractéristiques d’utilisation
Groupe de données, y compris les tailles de contenu, les caractéristiques de contenu et la distribution du contenu
Intégrité et performances, y compris un ensemble d’indicateurs enregistrés décrivant les caractéristiques de fiabilité et de performances de la batterie de serveurs

Pour plus d’informations, téléchargez les documents pertinents à partir de la page Web Études de cas techniques de performances et de capacité (https://technet.microsoft.com/fr-fr/library/cc261716.aspx).

Sélectionner votre matériel

La sélection des spécifications correctes pour les ordinateurs de votre batterie de serveurs est une étape cruciale pour garantir une fiabilité et des performances correctes pour votre déploiement. L’un des concepts essentiels à retenir est que vous devez prévoir les pics de charge et les heures de pointe ; autrement dit, si votre batterie de serveurs fonctionne dans des conditions de charge moyenne, il doit y avoir suffisamment de ressources disponibles pour gérer la demande la plus élevée attendue tout en atteignant les objectifs de débit et latence.

Les principales fonctionnalités matérielles de capacité et de performances des serveurs reflètent les quatre catégories principales suivantes : puissance de traitement, performances des disques, capacité réseau et capacité mémoire d’un système.

Il convient également d’évaluer l’utilisation d’ordinateurs virtuels. Une batterie de serveurs SharePoint Server peut être déployée à l’aide d’ordinateurs virtuels. Bien qu’il n’ait pas été prouvé que cela augmente les performances, cela procure des avantages en matière de facilité de gestion. La virtualisation des ordinateurs SQL Server n’est généralement pas recommandée, mais il peut y avoir certains avantages à virtualiser les couches de serveurs Web et de serveurs d’applications. Pour plus d’informations, voir Planification de la virtualisation(https://technet.microsoft.com/fr-fr/library/ff607968(Office.14.aspx).

Conseils relatifs à la sélection du matériel

Choix des processeurs

SharePoint Server 2010 est disponible uniquement pour les processeurs 64 bits. En règle générale, une quantité plus élevée de processeurs vous permettra de répondre à une demande plus élevée.

Dans SharePoint Server 2010, les serveurs Web évoluent à mesure que vous ajoutez des cœurs (nous avons testé jusqu’à 24 cœurs) ; plus le serveur possède de cœurs, plus la charge qu’il peut soutenir est élevée (tous les autres paramètres étant égaux). Dans les grands déploiements de SharePoint Server, il est recommandé d’allouer plusieurs serveurs Web à quatre cœurs (qui peuvent être virtualisés) ou moins de serveurs Web plus puissants (8, 16 ou 24 cœurs).

Les besoins en capacité de traitement des serveurs d’applications varient selon le rôle du serveur et les services qu’il exécute. Certaines fonctionnalités de SharePoint Server exigent une puissance de traitement supérieure à d’autres. Par exemple, le service de recherche de SharePoint dépend fortement de la puissance de traitement du serveur d’applications. Pour plus d’informations sur les besoins en ressources des fonctionnalités et services de SharePoint Server, voir la section Services et fonctionnalités de l’article Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Les besoins en capacité de traitement pour SQL Server dépendent également des bases de données de service hébergées par un ordinateur SQL Server. Pour plus d’informations sur le comportement et les exigences par défaut de chaque base de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Choix de la mémoire

Vos serveurs nécessiteront une quantité variable de mémoire, selon leur fonction et leur rôle. Par exemple, les serveurs exécutant les composants d’analyse de recherche traiteront les données plus rapidement s’ils disposent d’une grande quantité de mémoire car les documents sont lus en mémoire pour le traitement. Les serveurs Web qui tirent parti des nombreuses fonctionnalités de mise en cache de SharePoint Server 2010 peuvent également nécessiter davantage de mémoire.

En règle générale, les besoins en mémoire des serveurs Web dépendent fortement du nombre de pools d’applications activés dans la batterie de serveurs et du nombre de requêtes simultanées satisfaites. Dans la plupart des déploiements de production SharePoint Server, il est recommandé d’allouer au moins 8 Go de RAM sur chaque serveur Web, 16 Go étant la valeur recommandée pour les serveurs avec davantage de trafic ou pour les déploiements pour lesquels plusieurs pools d’applications sont configurés pour l’isolation.

Les besoins en mémoire des serveurs d’applications diffèrent également ; certaines fonctionnalités de SharePoint Server exigent davantage de mémoire sur la couche Application que d’autres. Dans la plupart des déploiements de production SharePoint Server, il est recommandé 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’applications 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, sont activés.

Les besoins en mémoire des serveurs de bases de données dépendent étroitement de la taille des bases 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 SQL Server et du stockage (SharePoint Server 2010).

Choix des réseaux

Outre les avantages offerts aux utilisateurs si les clients disposent d’un accès rapide aux données par le biais du réseau, une batterie de serveurs distribuée doit disposer d’un accès rapide pour la communication entre les serveurs. Ceci est particulièrement vrai lorsque vous distribuez des services sur plusieurs serveurs ou lorsque vous fédérez certains des services à d’autres batteries. Il existe un trafic important dans une batterie de serveurs sur la couche serveur Web, la couche serveur d’applications et la couche serveur de bases de données ; le réseau peut donc facilement devenir un goulet d’étranglement dans certaines conditions, par exemple en présence de gros fichiers ou de charges très élevées.

Les serveurs Web et les serveurs d’applications doivent être configurés avec au moins deux cartes d’interface réseau (NIC) : une pour gérer le trafic des utilisateurs finaux et l’autre pour gérer la communication entre les serveurs. La latence du réseau entre les serveurs peut avoir un impact significatif sur les performances ; il est donc important de conserver moins de 1 milliseconde de latence réseau entre le serveur Web et les ordinateurs SQL Server qui hébergent les bases de données de contenu. Les ordinateurs SQL Server qui hébergent chaque base de données d’application de service doivent se trouver le plus proche possible du serveur d’applications consommateur. Le réseau entre les serveurs de la batterie doit avoir au moins 1 Gbps de bande passante.

Choix des disques et du stockage

La gestion des disques ne consiste pas simplement à fournir suffisamment d’espace pour vos données. Vous devez évaluer la demande en cours et la croissance et vous assurer que l’architecture de stockage ne ralentit pas le système. Vous devez toujours vous assurer de disposer d’au moins 30 pour cent de capacité supplémentaire sur chaque disque, au-delà de votre estimation en besoin de données la plus élevée, afin de pouvoir satisfaire la croissance future. En outre, dans la plupart des environnements de production, la vitesse de disque (IOps) est essentielle pour fournir un débit suffisant afin de répondre aux exigences de stockage des serveurs. Vous devez évaluer la quantité de trafic (IOps) qui sera requise par les principales bases de données dans votre déploiement et allouer suffisamment de disques pour satisfaire ce trafic.

Pour plus d’informations sur le choix des disques pour les serveurs de bases de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Les serveurs Web et serveurs d’applications ont également des besoins en matière de stockage. Dans la plupart des environnements de production, il est recommandé d’allouer au moins 200 Go d’espace disque pour le système d’exploitation et les fichiers temporaires et 150 Go d’espace disque pour les journaux.

Étape 3: piloter, tester et optimiser

La phase de test et d’optimisation est un élément critique pour l’efficacité de la gestion de la capacité. Vous devez tester les nouvelles architectures avant de les déployer en production et mener des tests d’acceptation en plus de respecter les meilleures pratiques d’analyse suivantes, afin de vous assurer que les architectures que vous concevez répondent aux objectifs en matière de performances et de capacité. Cela vous permet d’identifier et d’optimiser les goulets d’étranglement potentiels avant qu’ils n’affectent les utilisateurs dans un déploiement actif. Si vous effectuez une mise à niveau à partir d’un environnement Office SharePoint Server 2007 et que vous prévoyez d’apporter des modifications architecturales, ou si vous évaluez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server, les tests revêtent une importance toute particulière si vous souhaitez vous assurer que votre environnement SharePoint Server répond aux objectifs de performances et de capacité.

Une fois que vous avez testé votre environnement, vous pouvez analyser les résultats des tests pour déterminer quelles modifications doivent être apportées afin d’atteindre les objectifs de performances et de capacité définis à l’Étape 1 : modéliser.

Voici la liste des sous-étapes recommandées pour la pré-production :

Créer l’environnement de test qui simule l’architecture initiale que vous avez conçue à l’Étape 2 : concevoir.
Remplir le stockage avec le groupe de données ou la partie de groupe de données que vous avez identifié à l’Étape 1 : modéliser.
Appliquer une contrainte sur le système avec une charge synthétique qui représente la charge de travail identifiée à l’Étape 1 : modéliser.
Exécuter les tests, analyser les résultats et optimiser votre architecture.
Déployer votre architecture optimisée dans votre centre de données et déployer un projet pilote avec un ensemble d’utilisateurs de taille réduite.
Analyser les résultats du pilote, identifier les goulets d’étranglement potentiels et optimiser l’architecture. Tester de nouveau si nécessaire.
Déployer dans l’environnement de production.

Tester

Les tests constituent un facteur critique en vue d’établir la faculté de la conception de votre système à supporter votre charge de travail et les caractéristiques d’utilisation. Pour plus d’informations sur les tests de votre déploiement SharePoint Server 2010, voir Test de performances pour SharePoint Server 2010.

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 2010 dans un environnement de production, il convient tout d’abord de déployer un environnement pilote et de tester soigneusement la batterie de serveurs pour vous assurer qu’elle peut satisfaire les objectifs de capacité et de performances pour votre charge maximale attendue. Nous vous recommandons de tester au préalable l’environnement pilote avec une charge synthétique, en particulier pour les déploiements à grande échelle, puis d’appliquer une contrainte à l’aide d’un petit ensemble d’utilisateurs et de contenu actifs. L’analyse d’un environnement pilote avec un petit ensemble d’utilisateurs actifs offre l’avantage de pouvoir valider certaines des hypothèses que vous avez mises en avant concernant les caractéristiques d’utilisation et la croissance du contenu avant de basculer totalement en production.

Optimiser

Si vous ne pouvez pas atteindre vos objectifs de capacité et de performances en faisant monter votre matériel de batterie de serveurs en puissance ou en apportant des modifications à la topologie, il peut s’avérer nécessaire de modifier votre solution. Par exemple, si vos exigences initiales concernaient une seule batterie de serveurs pour la collaboration, la recherche et les fonctionnalités sociales, vous devrez peut-être fédérer certains des services (tels que la recherche) sur une batterie de serveurs de services dédiée ou répartir la charge de travail sur plusieurs batteries de serveurs. Une alternative consiste à déployer une batterie de serveurs dédiée pour les fonctionnalités sociales et une autre pour la collaboration d’équipe.

Étape 4: déployer

Une fois que vous avez exécuté votre série de tests finale et confirmé que l’architecture que vous avez sélectionnée peut répondre aux objectifs de performances et de capacité définis à l’Étape 1 : modéliser, vous pouvez déployer votre environnement SharePoint Server 2010 en production.

La stratégie de déploiement appropriée varie en fonction de l’environnement et de la situation. Bien que le déploiement général de SharePoint Serverdépasse la portée de ce document, certaines activités peuvent être suggérées suite à l’exercice de planification de capacité. Voici quelques exemples :

Déploiement d’une nouvelle batterie de serveurs SharePoint Server : l’exercice de planification de la capacité doit avoir orienté et confirmé les plans pour une conception et un déploiement de SharePoint Server 2010. Dans ce cas, le déploiement sera le premier déploiement à grande échelle de SharePoint Server 2010. Il nécessitera le déplacement ou la reconstruction des serveurs et services qui ont été utilisés lors des exercices de planification de capacité vers l’environnement de production. Il s’agit du scénario le plus simple, car aucune modification ou mise à niveau de batterie existante n’est nécessaire.
Mise à niveau d’une batterie de serveurs Office SharePoint Server 2007 vers SharePoint Server 2010: l’exercice de planification de capacité doit avoir validé la conception d’une batterie qui répond à la demande actuelle et peut monter en puissance de façon à satisfaire toute augmentation de demande et d’utilisation d’une batterie SharePoint Server 2010. Une partie de l’exercice de planification de capacité doit avoir inclus des migrations tests afin de vérifier la durée nécessaire au processus de mise à niveau, de déterminer si aucun code personnalisé ne doit être modifié ou remplacé, si des outils tiers doivent être mis à jour, et ainsi de suite. À l’issue de la phase de planification de capacité, vous devez disposer d’une conception validée, connaître la durée nécessaire à la mise à niveau et posséder un plan détaillant le processus de mise à niveau le plus adéquat, par exemple une mise à niveau sur place ou une migration des bases de données de contenu dans une nouvelle batterie de serveurs. Si vous effectuez une mise à niveau sur place lors de la planification de capacité, vous aurez peut-être identifié des considérations relatives aux temps d’arrêt et constaté que du matériel supplémentaire ou mis à niveau est nécessaire. L’exercice de planification doit avoir généré une liste des modifications matérielles nécessaires et un plan détaillé concernant le déploiement préalable des modifications matérielles dans la batterie de serveurs. Une fois que la plateforme matérielle validée lors de la planification de capacité est en place, vous pouvez passer au processus de mise à niveau vers SharePoint Server 2010.
Amélioration des performances d’une batterie de serveurs SharePoint Server 2010 existante : l’exercice de planification de capacité doit vous avoir aidé à identifier les goulets d’étranglement dans votre implémentation actuelle, à trouver des moyens de réduire ou d’éliminer les goulets d’étranglement et à valider une implémentation améliorée qui répond à vos besoins professionnels pour les services SharePoint Server. Il existe différentes façons par lesquelles les problèmes de performances peuvent avoir été résolus : de la simple réaffectation des services sur un matériel existant à la mise à niveau du matériel existant, en passant par l’ajout de matériel supplémentaire et l’ajout de services supplémentaires sur ce matériel. Les différentes approches doivent être testées et validées lors de l’exercice de planification de capacité, puis un plan de déploiement doit être formulé en fonction des résultats de ces tests.

Étape 5: analyser et assurer la maintenance

Pour maintenir les performances du système, vous devez analyser votre serveur afin d’identifier les goulets d’étranglement potentiels. Une analyse efficace nécessite de bien comprendre les indicateurs clés qui vous indiqueront si une partie spécifique de votre batterie de serveurs nécessite une attention particulière et de savoir comment faire pour interpréter ces indicateurs. Si vous constatez que votre batterie de serveurs fonctionne en dehors des objectifs que vous avez définis, vous pouvez l’ajuster en ajoutant ou en supprimant des ressources matérielles, en modifiant votre topologie ou en modifiant le mode de stockage des données.

Pour obtenir la liste des paramètres que vous pouvez modifier pour analyser votre environnement lors des phases initiales, ce qui peut vous aider à déterminer si des modifications sont nécessaires, voir Surveillance et gestion de SharePoint Server 2010. Gardez à l’esprit que l’augmentation de vos capacités d’analyse affecte la quantité d’espace disque requis par votre base de données d’utilisation. Une fois que l’environnement est stable et que ce suivi détaillé n’est plus nécessaire, vous souhaiterez peut-être rétablir les valeurs par défaut des paramètres ci-dessous.

Pour plus d’informations sur l’analyse de l’intégrité et sur le dépannage à l’aide des outils d’analyse d’intégrité intégrés à l’interface d’Administration centrale de SharePoint Server, voir les articles suivants :

Surveillance de l’intégrité (SharePoint Server 2010)

Résolution des problèmes et dépannage (https://technet.microsoft.com/fr-fr/library/ee748639(office.14).aspx)