Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010

Mis à jour: juin 2012

 

S’applique à : SharePoint Server 2010

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

Cet article donne une vue d’ensemble sur la façon de gérer et planifier de façon efficace la capacité des environnements Microsoft SharePoint Server 2010. Il explique également comment maintenir une bonne compréhension des besoins et des possibilités de capacité de votre déploiement, par l’analyse des performances et du volume. Il passe également en revue les impacts des applications majeures sur la capacité, y compris les caractéristiques et l’utilisation du contenu.

La gestion de la capacité est un processus continu, puisqu’aucune implémentation ne demeure statique en ce qui concerne son contenu et son utilisation. Vous devez planifier la croissance et le changement afin que votre environnement SharePoint Server 2010 puisse continuer à offrir une solution métier efficace.

La planification de la capacité n’est qu’une partie du cycle de gestion de la capacité. C’est l’ensemble d’activités initiales que l’architecte-concepteur effectue pour bâtir l’architecture initiale la plus adaptée d’après lui au déploiement de SharePoint Server 2010. Le modèle de gestion de la capacité inclut des étapes supplémentaires pour pour valider et mettre au point l’architecture initiale, et fournit une boucle de rétroaction pour replanifier et optimiser l’environnement de production afin qu’il puisse prendre en charge les objectifs de la conception avec les meilleurs choix en matière de matériel, de topologie et de configuration.

Dans cet article :

  • Glossaire

  • À qui s’adressent les articles sur la gestion de la capacité ?

  • Les quatre concepts de base des performances

  • Gestion de la capacité et planification de la capacité

  • Surdimensionnement et sous-dimensionnement

  • Limitations et frontières logicielles

  • Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007

  • Différenciateurs clés d’un déploiement SharePoint Server 2010

  • Architectures de référence

Glossaire

Les termes spécialisés suivants sont utilisés dans la documentation sur la gestion de la capacité de SharePoint Server 2010.

  • RPS   (Requests per second) Demandes par seconde. Nombre de requêtes reçues par une batterie de serveurs ou un serveur par seconde. C’est une mesure courante de la charge d’un serveur ou d’une batterie de serveurs. Le nombre de requêtes traitées par une batterie de serveurs est supérieur au nombre de chargements de pages et d’interactions des utilisateurs finals. En effet, chaque page contient plusieurs composants, qui créent chacun une ou plusieurs requêtes au chargement de la page. Certaines requêtes sont plus légères que d’autres en termes de coût de transaction. Dans nos tests de labo et documents d’étude de cas, nous éliminons 401 requêtes et réponses (établissements de liaison d’authentification) sur les requêtes utilisées pour calculer RPS car elles ont un impact négligeable sur les ressources de la batterie de serveurs.

  • Heures de pointe   Heures de la journée durant lesquelles la charge de la batterie de serveurs est maximale.

  • Charge maximale   Charge quotidienne maximale moyenne de la batterie de serveurs, mesurée en RPS.

  • Pic de charge   Pics de charge temporaires qui se produisent en dehors des heures de pointe habituelles. Ils peuvent être causés par des accroissements non planifiés du trafic utilisateur, une diminution du débit de la batterie de serveurs à cause d’opérations d’administration, ou par une combinaison de ces facteurs.

  • Augmenter en puissance   Ajouter des ressources comme processeurs ou mémoire à un serveur.

  • Étendre   Ajouter des serveurs à une batterie de serveurs.

À qui s’adressent les articles sur la gestion de la capacité ?

Considérez les questions suivantes pour savoir si ce contenu vous concerne.

Évaluation de SharePoint Server 2010

Je suis informaticien ou décideur d’entreprise et je recherche une solution pour des problèmes métiers spécifiques. SharePoint Server 2010 est une option pour mon déploiement. Offre-t-il les fonctionnalités et l’évolutivité qui répondent à mes exigences particulières ?

Pour savoir comment faire évoluer SharePoint Server 2010 pour satisfaire les exigences de solutions spécifiques et comment déterminer le matériel requis pour prendre en charge vos besoins, voir les sections suivantes de cet article :

  • Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007

  • Limitations et frontières logicielles

Pour savoir comment évaluer SharePoint Server 2010 pour vos besoins métiers spécifiques, voir les articles suivants :

Mise à niveau à partir d’Office SharePoint Server 2007

J’utilise actuellement Office SharePoint Server 2007. Qu’est-ce qui a changé dans SharePoint Server 2010 et que faut-il prendre en compte pour la mise à niveau ? Quel impact aura la mise à niveau sur les performances et l’évolutivité de ma topologie ?

Pour savoir en quoi les facteurs de performances et de capacité diffèrent pour Office SharePoint Server 2007 et SharePoint Server 2010, voir la section suivante plus loin dans cet article :

  • Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007

Pour des considérations plus générales sur la mise à niveau et pour savoir comment planifier et exécuter une mise à niveau à partir d’Office SharePoint Server 2007, voir l’article suivant :

Réglage et optimisation d’un environnement SharePoint actif

J’ai déployé SharePoint Server 2010 et je veux m’assurer que j’ai le matériel et la topologie appropriés en place. Comment valider mon architecture et la maintenir correctement ?

Pour des informations sur le suivi et les compteurs de performances sur les batteries de serveurs Microsoft SharePoint Server 2010, voir l’article suivant :

Pour savoir comment utiliser les outils d’analyse d’intégrité intégrés à l’interface Administration centrale, voir l’article suivant :

J’ai déployé SharePoint Server 2010 et je rencontre des problèmes de performances. Comment dépanner et optimiser mon environnement ?

Pour des informations sur le suivi et les compteurs de performances sur les batteries de serveurs Microsoft SharePoint Server 2010, voir l’article suivant :

Pour des informations sur le dépannage à l’aide des outils d’analyse d’intégrité intégrés à l’interface Administration centrale, voir l’article suivant :

Pour la liste des articles sur la gestion de la capacité disponibles sur de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d’autres articles seront ajoutés au fur et à mesure), voir l’article suivant :

Pour des informations sur le dimensionnement et les performances des bases de données, voir l’article suivant :

Pour des informations sur le stockage BLOB distant (RBS), voir l’article suivant :

De bout en bout

Je veux tout savoir sur la gestion de la capacité de SharePoint Server 2010. Par où commencer ?

Pour des informations sur les concepts généraux de gestion de la capacité et des liens vers de la documentation et des ressources supplémentaires, voir l’article suivant :

Pour des informations supplémentaires sur la gestion de la capacité, voir les articles connexes suivants :

Vous avez maintenant acquis une bonne compréhension des concepts. Pour des informations sur les limitations et frontières de SharePoint Server 2010, voir l’article suivant :

Lorsque vous êtes prêt à identifier une topologie de départ pour votre environnement SharePoint Server 2010, vous pouvez consulter la bibliothèque des études de cas techniques pour rechercher celui qui correspond le plus à vos besoins. Pour la liste des études de cas (d’autres études de cas seront ajoutées au fur et à mesure), voir l’article suivant :

Pour la liste des articles sur la gestion de la capacité disponibles pour de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d’autres articles seront ajoutés au fur et à mesure), voir l’article suivant :

Pour des informations sur le dimensionnement et les performances des bases de données, voir l’article suivant :

Pour des informations sur le stockage BLOB distant (RBS), voir l’article suivant :

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

Pour des instructions générales sur le réglage des performances et des informations sur divers sujets relatifs à des performances et des capacités spécifiques (d’autres articles seront ajoutés au fur et à mesure), voir l’article suivant :

Pour savoir comment virtualiser les serveurs SharePoint Server 2010, voir l’article suivant :

Les quatre concepts de base des performances

La gestion de la capacité est axée sur les quatre aspects majeurs du dimensionnement de votre solution suivants :

  • Latence   Pour les besoins de la gestion de la capacité, la latence est la durée entre le moment où un utilisateur lance une action, comme cliquer sur un lien hypertexte, et le moment où le dernier octet est transmis à l’application cliente ou au navigateur Web.

  • Débit   Le débit est le nombre de requêtes simultanées qu’un serveur ou une batterie de serveurs peut traiter.

  • Échelle de données   L’échelle de données est la taille et le corpus de données du contenu que le système peut héberger. La structure et la répartition des bases de données de contenu ont un impact significatif sur le temps nécessaire pour le traitement des requêtes (latence) par le système et sur le nombre de requêtes simultanées que le système peut traiter (débit).

  • Fiabilité   La fiabilité est une mesure de la capacité du système à atteindre les objectifs de latence et de débit définis au fil du temps.

Le but principal de la gestion de la capacité de votre environnement est d’établir et maintenir un système qui satisfait les objectifs de votre organisation en termes de latence, débit, échelle des données et fiabilité.

Latence

La latence, également appelée latence perçue par l’utilisateur final, est constituée des trois composants majeurs suivants :

  • Le temps nécessaire au serveur pour recevoir et traiter la demande.

  • Le temps nécessaire au transfert via le réseau de la demande et de la réponse du serveur.

  • Le temps nécessaire pour restituer la réponse dans l’application cliente.

Différentes organisations définissent différents objectifs de latence en fonction de leurs exigences et des attentes des utilisateurs. Certaines organisations peuvent se permettre une latence de quelques secondes, tandis que d’autres requièrent des transactions très rapides. L’optimisation en vue de transactions très rapides est généralement plus coûteuse, et nécessite souvent des clients et des serveurs plus puissants, des versions de navigateur et d’application cliente plus récentes, des solutions de réseau à haut débit, et éventuellement des investissements de développement et l’adaptation des pages.

Certains des facteurs principaux qui contribuent à augmenter la latence perçue par l’utilisateur final, et des exemples de problèmes courants, sont décrits dans la liste suivante. Ces facteurs sont surtout pertinents dans les scénarios où les clients sont géographiquement distants de la batterie de serveurs ou accèdent à celle-ci par une connexion réseau à faible bande passante.

  • Les fonctionnalités, les services ou les paramètres de configuration qui ne sont optimisés peuvent retarder le traitement des demandes et avoir un impact sur la latence aussi bien pour les clients distants que locaux. Pour plus d’informations, voir Débit et Fiabilité plus loin dans cet article.

  • Les pages Web qui génèrent des requêtes inutiles auprès du serveur pour télécharger les données et ressources requises. L’optimisation doit inclure le téléchargement du nombre minimum de ressources pour dessiner la page, en réduisant la taille des images, le stockage des ressources statiques dans des dossiers qui autorisent l’accès anonyme, le clustering des requêtes et l’activation de l’interactivité des pages pendant le téléchargement asynchrone des ressources à partir du serveur. Ces optimisations sont importantes pour obtenir une expérience de navigation acceptable à la première visite.

  • Le volume excessif de données transmises via le réseau contribue à la dégradation de la latence et du débit. Par exemple, les images et autres objets binaires figurant sur une page doivent utiliser un format compressé tel que .png ou .jpg au lieu de bitmap, autant que possible.

  • Les pages Web qui ne sont pas optimisées pour le chargement en second accès. Le temps de chargement de page (PLT, Page Load Time) améliore le chargement en second accès car certaines ressources de la page sont mises en cache sur le client et le navigateur ne doit télécharger que le contenu dynamique non mis en cache. Les latences de chargement de page en second accès inacceptables sont souvent dues à une configuration incorrecte de cache des objets BLOB ou à une mise en cache du navigateur local désactivée sur les ordinateurs clients. Les optimisations doivent inclure la mise en cache correcte des ressources sur le client.

  • Les pages Web qui contiennent du code JavaScript personnalisé non optimisé. Cela peut ralentir l’affichage de la page sur le client. L’optimisation doit différer le traitement JavaScript sur le client tant que le reste de la page n’est pas chargé, et de préférence appeler des scripts au lien d’ajouter du JavaScript incorporé.

Débit

Le débit est le nombre de requêtes qu’une batterie de serveurs peut traiter dans une unité de temps ; il est souvent utilisé pour mesurer l’échelle des opérations que le système doit pouvoir soutenir en fonction de la taille de l’organisation et de ses caractéristiques d’utilisation. Chaque opération a un coût spécifique en termes de ressources de batterie de serveurs. Pour comprendre la demande et déployer une architecture de batterie de serveurs qui puisse constamment satisfaire la demande, il faut estimer la charge prévue et tester l’architecture sous charge afin de vérifier que la latence ne tombe pas en dessous du seuil lorsque la simultanéité est élevée et que le système est chargé.

Voici des exemples courants de conditions de faible débit :

  • Ressources matérielles inadéquates   Lorsque la batterie de serveurs reçoit plus de requêtes que ce qu’elle peut traiter simultanément, des requêtes sont mises en file d’attente, ce qui retarde de façon cumulée le traitement des requêtes suivantes tant que la demande est trop forte pour permettre une file d’attente vide. Voici quelques exemples d’optimisation d’une batterie de serveurs pour soutenir un débit plus élevé :

    • Assurez-vous que les processeurs des batteries de serveurs ne sont pas surutilisés. Par exemple, si l’utilisation de l’UC durant les heures de pointe ou les pics de charge dépasse constamment 80 %, ajoutez d’autres serveurs ou redistribuez les services sur d’autres serveurs de la batterie de serveurs.

    • Assurez-vous que la mémoire sur les serveurs d’applications et les serveurs Web est suffisante pour contenir le cache complet. Cela permet d’éviter des appels à la base de données pour traiter les requêtes de contenu non mis en cache.

    • Assurez-vous que les serveurs de bases de données sont exempts de goulots d’étranglement. Si le nombre maximum d’opérations d’entrée/sortie par seconde (IOPS) sur l’espace disque total disponible est insuffisant pour supporter la demande de pointe, ajoutez d’autres disques ou redistribuez les bases de données sur les disques sous-utilisés. Voir la section Suppression des goulots d’étranglement dans l’article Suivi et maintenance des produits et technologies SharePoint Server 2010 pour plus d’informations.

    • Si l’ajout de ressources sur les ordinateurs existants ne suffit pas à résoudre les problèmes de débit, ajoutez des serveurs et redistribuez les fonctionnalités et services affectés sur ces nouveaux serveurs.

  • Pages Web personnalisées non optimisées   L’ajout de code personnalisé à des pages fréquemment utilisées dans un environnement de production est une cause courante des problèmes de débit. L’ajout de code personnalisé peut générer des aller-retour supplémentaires vers les serveurs de bases de données ou les services Web pour traiter les requêtes de données. La personnalisation des pages non fréquemment utilisées n’a pas forcément un impact significatif sur le débit, mais du code même bien optimisé peut diminuer le débit de la batterie de serveurs s’il est appelé des milliers de fois par jour. Les administrateurs de SharePoint Server peuvent activer le tableau de bord du développeur pour identifier le code personnalisé qui requiert une optimisation. Voici quelques exemples d’optimisation du code personnalisé :

    • Réduisez le nombre de demandes de service Web et de requêtes SQL.

    • Extrayez les données minimum requises à chaque accès au serveur de bases de données tout en réduisant le nombre d’aller-retour nécessaires.

    • Évitez l’ajout de code personnalisé sur les pages fréquemment utilisées.

    • Utilisez les index pour extraire un volume de données filtré.

  • Solutions non approuvées   Le déploiement de code personnalisé dans des dossiers binaires peut nuire aux performances du serveur. Chaque fois qu’une page contenant du code non approuvé est demandée, SharePoint Server 2010 doit effectuer des contrôles de sécurité avant de charger la page. Sauf s’il existe un raison particulière de déployer du code non approuvé, vous devez installer des assemblys personnalisés dans le GAC pour éviter les contrôles de sécurité inutiles.

Échelle de données

L’échelle de données est le volume de données que le serveur ou la batterie de serveurs peut stocker tout en atteignant les objectifs de latence et de débit. En règle générale, plus le volume de données sur la batterie de serveurs est élevé, plus l’impact sur le débit global et sur l’expérience utilisateur est important. La méthode utilisée pour distribuer les données sur les disques et les serveurs de bases de données peut également affecter la latence et le débit de la batterie de serveurs.

Le dimensionnement des bases de données, l’architecture des données et un matériel suffisant pour les serveurs de bases de données sont tous très importants dans une solution de bases de données optimale. Dans un déploiement idéal, les bases de données de contenu sont dimensionnées selon les consignes de limites et sont distribuées sur les disques physiques pour éviter la mise en file d’attente des requêtes à cause de l’utilisation excessive des disques et permettre aux serveurs de bases de données de supporter les charges maximales et les pointes imprévues sans dépasser les seuils d’utilisation des ressources.

D’autre part, certaines opérations peuvent verrouiller des tables pendant leur exécution, par exemple la suppression d’un site volumineux, qui peut causer le verrouillage des tables associées de la base de données de contenu où le site réside tant que la suppression n’est pas terminée.

Voici quelques exemples d’optimisation d’une batterie de serveurs pour des performances de données et de stockage :

  • Assurez-vous que les bases de données sont correctement réparties sur les serveurs de bases de données et que les ressources de ces serveurs sont suffisantes pour supporter le volume et la distribution des données.

  • Séparez les volumes de base de données en unités logiques (LUN) uniques, constituées de piles de disques physiques uniques. Utilisez plusieurs disques ayant un faible temps d’accès et des configurations RAID appropriées pour satisfaire les demandes de stockage des serveurs de bases de données.

  • Vous pouvez utiliser le stockage BLOB distant (RBS) si votre corpus contient beaucoup d’objets BLOB (Binary Large Object). RBS présente les avantages suivants :

    • Les données BLOB peuvent être stockées sur des dispositifs de stockage moins onéreux configurés pour gérer le stockage simple.

    • L’administration du stockage BLOB est contrôlée par un système spécifiquement conçu pour exploiter des données BLOB.

    • Les ressources des serveurs de base de données sont libérées pour les opérations de base de données.

    Ces avantages ne sont pas gratuits. Avant d’implémenter RBS avec SharePoint Server 2010, vous devez déterminer si ces avantages potentiels compensent les coûts et les limitations de l’implémentation et de la gestion de RBS.

    Pour plus d’informations, voir Planifier le stockage BLOB distant (RBS) (SharePoint Server 2010).

Pour plus d’informations sur la planification de l’échelle de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Fiabilité

La fiabilité est la mesure consolidée de la capacité de la batterie de serveurs à atteindre les objectifs de latence, de débit et de capacité de données établis, au fil du temps. Une batterie de serveurs fiable est une batterie pour laquelle le temps de fonctionnement, la réactivité, le taux de défaillances, et la fréquence et l’amplitude des pointes de latence respectent les objectifs et les exigences opérationnelles établis. Une batterie de serveurs fiable est capable également de constamment soutenir les objectifs de latence et de débit durant les heures de pointe ou de charge maximale, ou lorsque des opérations système telles que l’analyse ou les sauvegardes quotidiennes se déroulent.

Un facteur majeur de maintien de la fiabilité est l’impact des opérations d’administration courantes sur les objectifs de performance. Lors de certaines opérations, comme la reconstruction des index de base de données, les travaux de maintenance du minuteur, ou la suppression de plusieurs sites ayant un volume important de contenu, le système risque de ne pas pouvoir traiter les demandes des utilisateurs aussi rapidement. Dans ce cas, la latence et le débit des demandes des utilisateurs finals peuvent être affectés. L’impact sur la batterie de serveurs dépend de la fréquence et du coût de transaction de telles opérations moins courantes, ainsi que du moment de leur exécution durant ou non les heures d’exploitation normales.

Voici quelques exemples de maintien d’un système plus fiable :

  • Planifiez les travaux de minuteur et les tâches administratives gourmands en ressources pendant les heures creuses.

  • Augmentez la puissance matérielle des serveurs existants de la batterie, ou étendez la batterie en ajoutant des serveurs Web, des serveurs d’applications ou des serveurs de base de données supplémentaires.

  • Répartissez les services et les fonctionnalités gourmands en ressources sur des serveurs dédiés. Vous pouvez également utiliser un équilibreur de charge matériel pour diriger le trafic spécifique à des fonctionnalités vers un serveur Web dédié à des fonctionnalités ou des services particuliers.

Gestion de la capacité et planification de la capacité

La gestion de la capacité étend le concept de planification de la capacité de manière à exprimer une approche cyclique dans laquelle la capacité d’un déploiement de SharePoint Server 2010 est en permanence surveillée et optimisée en fonction de l’évolution des conditions et des besoins.

SharePoint Server 2010 offre une souplesse accrue et peut être configuré pour soutenir des scénarios d’utilisation dans un large éventail d’échelles différentes. Il n’y a pas une architecture de déploiement unique. Par conséquent, les concepteurs et les administrateurs système doivent appréhender les exigences de leur environnement spécifique.

Modèle de gestion de la capacité de SharePoint Server 2010

Modèle de gestion de la capacité SharePoint

  • Étape 1 : Modéliser   La modélisation est le processus au cours duquel vous déterminez les solutions essentielles que votre environnement doit prendre en charge, et vous établissez tous les paramètres et mesures importants. Le résultat de cette étape est la liste de toutes les données fondamentales nécessaires pour concevoir votre environnement.

    • Appréhendez la charge de travail et l’ensemble de données attendus.

    • Définissez les objectifs de performances et de fiabilité de la batterie de serveurs.

    • Analysez les journaux IIS de SharePoint Server 2010.

  • Étape 2 : Conception   Après avoir rassemblé les données de l’étape 1, vous pouvez concevoir la batterie de serveurs. Le résultat de cette étape est l’architecture détaillée des données ainsi que les topologies physique et logique.

    • Déterminez votre architecture de départ.

    • Sélectionnez votre matériel.

  • Étape 3 : Pilote, tester et optimiser    Si vous avez conçu un nouveau déploiement, vous devez déployer un environnement pilote pour effectuer des tests avec la charge de travail et les caractéristiques d’utilisation prévues. Pour une batterie de serveurs existante, les tests sont conseillés si des changements majeurs sont apportés à l’infrastructure, mais une optimisation standard basée sur les résultats de l’analyse peut s’avérer nécessaire pour maintenir les objectifs de performances. Le résultat de cette phase est l’analyse des résultat des tests par rapport aux objectifs et une architecture optimisée capable de soutenir les objectifs de performances et de capacité établis.

    • Pilote   Déployez un environnement pilote.

    • Tester   Testez par rapport aux objectifs de latence et de débit.

    • Optimiser   Rassemblez les résultats des tests et apportez les changements nécessaires aux ressources et à la topologie de la batterie de serveurs.

  • Étape 4 : Déployer   Cette étape décrit l’implémentation de la batterie de serveurs ou le déploiement des modifications sur une batterie de serveurs existante. Le résultat pour une nouvelle conception est le déploiement terminé vers une production en ligne, y compris toutes les migrations de contenu et d’utilisateurs. Le résultat pour une batterie de serveurs existante sont des configurations révisées et des mises à jour des plans de maintenance.

  • Étape 5 : Surveiller et maintenir   Cette étape décrit comment configurer le suivi, comment prévoir et identifier les goulots d’étranglement, effectuer la maintenance régulière et les activités de limitation des goulots d’étranglement.

Surdimensionnement et sous-dimensionnement

Le surdimensionnement désigne une approche dans la conception d’une batterie de serveurs où les objectifs sont atteints sans une pleine utilisation du matériel, et où les ressources de la batterie de serveurs SharePoint Server sont considérablement et constamment sous-utilisées. Dans un déploiement surdimensionné, la mémoire, l’UC et d’autres indicateurs sur les ressources de la batterie de serveurs montrent que la batterie peut correctement traiter la demande avec moins de ressources. L’inconvénient du surdimensionnement : des frais de matériel et de maintenance accrus et des besoins plus importants en énergie et en espace qui peuvent en découler.

Le sous-dimensionnement désigne une approche dans la conception d’une batterie de serveurs où les objectifs de performances et de capacité sont inatteignables car les ressources matérielles de la batterie de serveurs SharePoint Server sont sur-utilisées. Le sous-dimensionnement d’une batterie de serveurs est parfois dû à une volonté de réduire les coûts de matériel, mais produit généralement une latence élevée causant une expérience utilisateur médiocre, une faible satisfaction, de fréquentes escalades, des coûts d’assistance élevés et des dépenses inutiles de dépannage et d’adaptation de l’environnement.

Lorsque vous concevez votre batterie de serveurs, assurez-vous qu’elle puisse soutenir les objectifs de performances et de capacité établis, aussi bien lors des charges maximales régulières que pendant les pointes imprévues. La conception, les tests et l’optimisation vous permettront de vérifier si la batterie dispose du matériel adéquat.

Pour maintenir les objectifs de performances et s’adapter à la croissance, il est toujours préférable de disposer de plus de ressources que nécessaire pour atteindre les objectifs. Le coût du surinvestissement en matériel est généralement bien inférieur aux dépenses cumulées pour résoudre les problèmes dus au sous-dimensionnement.

Vous devez systématiquement dimensionner le système pour répondre de façon adéquate à la demande de pointe, qui peut être différente pour des services spécifiques à différentes heures. Pour estimer effectivement les besoins en capacité, vous devez identifier la période de demande la pire pour toutes les ressources. Il peut y avoir des charges accrues pour certains services et fonctionnalités à certaines heures de la journée, par exemple en début de matinée ou après le déjeuner.

La batterie de serveurs doit également pouvoir supporter les pics non planifiés, par exemple lors d’annonces à l’échelle de l’organisation où un nombre exceptionnellement élevé d’utilisateurs accèdent à un site en même temps. Durant de telles périodes de forte demande, les utilisateurs subissent une latence élevée ou n’obtiennent pas de réponse du tout de la batterie de serveurs si les ressources disponibles sont insuffisantes pour satisfaire la charge accrue sur la batterie de serveurs.

Il faut également revoir la capacité de la batterie de serveurs lorsque des utilisateurs supplémentaires sont mis en service dans l’entreprise. Des situations comme une fusion ou une acquisition, caractérisées par de nouveaux employés ou membres qui accèdent à la batterie de serveurs, peuvent avoir des effets défavorables sur les performances si elles ne sont pas planifiées et estimées à l’avance.

États opérationnels : zone verte et zone rouge

Pour décrire la charge d’un système de production, nous faisons référence à deux états opérationnels : la zone verte qui correspond aux situations durant lesquelles le système fonctionne avec une charge normale et prévue, et la zone rouge qui correspond aux situations durant lesquelles la batterie de serveurs subit une demande temporaire très élevée de ressources qui ne peut être soutenue que sur de courtes périodes avant que des pannes ou d’autres problèmes de performances ou de fiabilité ne se produisent.

Zone verte   Correspond aux situations où le serveur ou la batterie de serveurs fonctionne dans des conditions de charge normale ou de charge maximale quotidienne prévue. Une batterie de serveurs dans cette plage doit pouvoir soutenir des temps de réponse et une latence acceptables.

Zone rouge   Plage opérationnelle où la charge est supérieure à la charge maximale normale, mais où les demandes peuvent être encore traitées sur une période limitée. Cet état se caractérise par une latence supérieure à la normale et par des défaillances possibles à cause de la saturation des goulots d’étranglement du système.

Le but ultime de la conception d’une batterie de serveurs est de déployer un environnement qui puisse constamment supporter une charge de zone rouge sans défaillance du service et avec une latence et un débit acceptables.

Limitations et frontières logicielles

Dans SharePoint Server 2010, il existe certaines limites qui ne sont absolument pas franchissables et d’autres qui sont définies sur des valeurs par défaut et qui peuvent être modifiées par l’administrateur de la batterie de serveurs. Il existe également certaines limites qui ne sont pas représentées par une valeur configurable, telles que le nombre de collections de sites par application Web.

Les frontières sont des limites absolues qui ne sont absolument pas franchissables. Il est important de comprendre ces limites afin de ne pas concevoir votre batterie de serveurs sur des hypothèses erronées.

Un exemple de frontière est la taille limite de 2 Go pour les documents ; vous ne pouvez pas configurer SharePoint Server 2010 de manière à stocker des documents qui dépassent 2 Go. Il s’agit d’une valeur prédéfinie qui ne peut absolument pas être dépassée.

Les seuils possèdent une valeur par défaut qui ne peut pas être dépassée, à moins de la modifier. Dans certaines circonstances, les seuils peuvent être dépassés si l’évolution de la conception de votre batterie de serveurs le nécessite, mais il est important de comprendre que cela risque d’avoir une incidence sur les performances de la batterie de serveurs et sur la valeur effective des autres limites.

La valeur par défaut de certains seuils peut être dépassée, mais dans la limite d’une valeur maximum absolue. La taille limite des documents en est un bon exemple. Par défaut, cette taille limite est définie sur 50 Mo, mais peut être remplacée par la valeur maximum de 2 Go.

Les limites supportées définissent la valeur testée pour un paramètre donné. Les valeurs par défaut de ces limites ont été définies à l’aide de tests et représentent les limitations connues du produit. Le dépassement des limites supportées risque de produire des résultats inattendus, une dégradation significative des performances ou d’autres effets nuisibles.

Certaines limites supportées sont des paramètres configurables qui sont définis par défaut sur la valeur recommandée, tandis que d’autres limites concernent des paramètres qui ne sont pas représentés par une valeur configurable.

Un exemple de limite supportée est le nombre de collections de sites par application Web. Cette limite est 500 000, qui constitue le nombre le plus élevé de collections de sites par application Web ayant satisfait aux tests d’évaluation des performances.

Il est important de noter que de nombreuses valeurs limites fournies dans ce document représentent un point dans une courbe qui décrit une charge croissante sur les ressources et une dégradation concomitante des performances à mesure que la valeur augmente. Par conséquent, le dépassement de certaines limites, telles que le nombre de collections de sites par application Web, peut ne causer qu’une faible diminution des performances de la batterie de serveurs. Toutefois, dans la plupart des cas, le fonctionnement sur une limite établie ou une valeur approchante n’est pas une meilleure pratique, car les cibles de performances et de fiabilité acceptables sont d’autant plus facilement atteintes que la conception d’une batterie de serveurs prévoit un compromis raisonnable entre les valeurs limites.

Les recommandations sur les seuils et les limites supportées sont déterminées par les performances. En d’autres termes, vous pouvez dépasser les valeurs par défaut des limites, mais l’augmentation d’une valeur limite peut avoir une incidence sur les performances de la batterie de serveurs et sur la valeur effective des autres limites. De nombreuses limites dans SharePoint Server 2010 peuvent être modifiées, mais il est important de comprendre l’impact que peut avoir la modification d’une limite donnée sur les autres parties de la batterie de serveurs.

Si vous contactez les services de support technique Microsoft à propos d’un système de production qui ne satisfait pas la configuration matérielle minimale décrite dans Configuration matérielle et logicielle requise (SharePoint Server 2010), le support sera limité tant que le système n’est pas mis à niveau vers la configuration requise.

Mode d’établissement des limites

Dans SharePoint Server 2010, les seuils et les limites supportées sont établis par les tests et l’observation du comportement de la batterie de serveurs en fonction de charges croissantes jusqu’au point où les opérations et les services de la batterie atteignent leurs limites de fonctionnement effectives. Étant donné que certains services et composants de la batterie de serveurs peuvent accepter plus de charge que d’autres, dans certains cas, vous devez affecter une valeur limite basée sur une moyenne de plusieurs facteurs.

Par exemple, les observations du comportement de la batterie de serveurs testée lorsque des collections de sites sont ajoutées indiquent que certaines fonctionnalités présentent une latence anormalement élevée tandis que d’autres affichent des paramètres de fonctionnement encore acceptables. Par conséquent, la valeur maximum affectée au nombre de collections de sites n’est pas absolue, mais calculée en fonction d’un ensemble attendu de caractéristiques d’utilisation dans lequel les performances globales de la batterie de serveurs sont acceptables pour la limite donnée dans certaines circonstances.

Si d’autres services fonctionnent avec des paramètres plus élevés que ceux utilisés pour les tests des limites, les limites effectives maximales des autres services seront réduites. Il est donc important d’effectuer des tests d’échelle et de gestion de capacité rigoureux pour des déploiements spécifiques afin d’établir des limites effectives pour l’environnement considéré.

Pour plus d’informations sur les limitations et frontières et sur leur impact sur la gestion de la capacité, voir Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles.

Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007

SharePoint Server 2010 offre un ensemble plus riche de fonctionnalités et un modèle topologique plus souple que les versions antérieures. Avant d’utiliser cette architecture plus complexe pour fournir aux utilisateurs des fonctionnalités et des possibilités de traitement plus puissantes, vous devez étudier avec soin leur impact sur les performances et la capacité de la batterie de serveurs.

Dans Office SharePoint Server 2007, il y avait quatre services majeurs que vous pouviez activer dans des fournisseurs de services partagés (SSP) : le service de recherche, le service de calcul Excel, le service de profil utilisateur et le service de catalogue de données métiers. En outre, un ensemble relativement plus petit de clients pouvait s’interfacer directement avec Office SharePoint Server 2007.

Dans SharePoint Server 2010, il y a plus de services disponibles, appelés SSA (SharePoint Service Application), et SharePoint Server 2010 offre une gamme plus large d’applications clientes pouvant interagir avec la batterie de serveurs, y compris plusieurs nouvelles applications Office, des appareils mobiles, des outils de conception et des navigateurs. Voici quelques exemples de l’impact des interactions clientes étendues sur les considérations en matière de capacité :

  • SharePoint Server 2010 inclut des applications de mise en réseau qui s’intègrent avec Outlook, ce qui permet aux clients Outlook 2010 d’afficher des informations sur les destinataires du courrier électronique qui sont extraites de la batterie de serveurs SharePoint Server lorsque les messages électroniques sont affichés dans le client Outlook. Cela introduit un nouvel ensemble de schémas de trafic et une charge sur le serveur qu’il faut prendre en compte.

  • Certaines nouvelles fonctionnalités de clients Microsoft Office 2010 actualisent automatiquement les données par rapport à la batterie de serveurs SharePoint Server, même si les applications clientes sont ouvertes sans être utilisées activement. De tels clients, comme SharePoint Workspace et OneNote, introduisent également des nouveaux schémas de trafic et une charge sur le serveur qu’il faut prendre en compte.

  • Les nouvelles possibilités d’interactivité Web de SharePoint Server 2010, comme Office Web Apps, qui permettent d’éditer des fichiers Office directement depuis le navigateur, utilisent des appels AJAX qui introduisent de nouveaux schémas de trafic et une charge sur le serveur qu’il faut prendre en compte.

Dans Office SharePoint Server 2007, le client principal utilisé pour interagir avec le serveur était le navigateur Web. Étant donné l’ensemble de fonctionnalités enrichi de SharePoint Server 2010, le nombre global de demandes par seconde (RPS) est censé croître. De plus, le pourcentage de demandes émanant du navigateur est censé être inférieur à celui dans Office SharePoint Server 2007, ce qui libère de la place pour le pourcentage croissant de nouveau trafic émanant d’autres clients du fait de leur adoption élargie à toute l’organisation.

Par ailleurs, SharePoint Server 2010 introduit de nouvelles fonctionnalités comme la prise en charge des vidéos incorporées natives qui peuvent ajouter une charge supplémentaire à la batterie de serveurs. Certaines fonctionnalités ont été également étendues pour supporter une échelle plus grande que les versions précédentes.

La section suivante décrit ces interactions, services et fonctionnalités des clients et leur impact sur les performances et la capacité globales du système que vous devez prendre en compte lors de la conception de votre solution.

Pour plus d’informations sur la mise à niveau vers SharePoint Server 2010, voir Mise à niveau vers SharePoint Server 2010.

Services et fonctionnalités

Le tableau suivant donne un aperçu simplifié des besoins en ressources des différents services à chaque niveau. Les cellules vides signalent que le service ne s’exécute pas ou n’a pas d’impact à ce niveau.

X – Indique un coût minime ou négligeable sur la ressource. Le service peut partager cette ressource avec d’autres services.

XX – Indique un coût moyen sur la ressource. Le service peut partager cette ressource avec d’autres services ayant un impact minime.

XX – Indique un coût élevé sur la ressource. Le service ne doit normalement pas partager cette ressource avec d’autres services.

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

Pour la liste des articles sur la gestion de la capacité disponibles pour de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d’autres articles seront ajoutés au fur et à mesure), voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010).

Application de service UC de serveur Web RAM de serveur Web UC de serveur d’applications RAM de serveur d’applications UC de serveur SQL IOPS de serveur SQL Stockage de serveur SQL

Service SharePoint Foundation

XXX

XXX

 

 

XX

XXX

XXX

Service Administration centrale

   

XX

XX

X

X

X

Service de journalisation*

XX

XX

 

 

XX

XXX

XXX

Service de recherche SharePoint

XXX

XXX

XXX

XXX

XXX

XXX

XXX

Application de service d’affichage Word*

X

X

XXX

XX

     

Service PowerPoint*

XX

XX

XXX

XX

     

Service de calcul Excel

XX

X

XX

XXX

     

Service Visio*

X

X

XXX

XXX

X

X

X

Service Access*

X

X

XXX

XX

X

X

X

Service de profil utilisateur

X

XX

XX

XX

XXX

XXX

XX

Service de métadonnées gérées*

X

XX

XX

XX

X

X

XX

Service Web Analytics*

X

X

 

 

XXX

XXX

XXX

Business Connection Service*

XX

XX

XXX

XXX

     

InfoPath Forms Service

XX

XX

XX

XX

X

X

X

Service de conversion Word

X

X

XXX

XX

X

X

X

Application de service PerformancePoint*

XX

XX

XXX

XXX

X

X

X

Service Project*

X

X

X

X

XXX

XXX

XX

Solutions en bac à sable*

X

X

XXX

XXX

     

Fonctionnalités de flux de travail*

XXX

XXX

 

       

Service minuteur

XX

XX

XX

XX

     

PowerPivot*

X

X

XXX

XXX

XX

XX

XXX

Notes

Un astérisque (*) signale un nouveau service dans SharePoint Server 2010.

  • Service SharePoint Foundation   Service SharePoint central pour la collaboration de contenu. Dans les grands déploiements SharePoint Server, il est recommandé d’allouer des serveurs Web redondants en fonction de la charge de trafic prévue, de dimensionner correctement les ordinateurs SQL Server qui servent les bases de données de contenu, et d’allouer correctement le stockage en fonction de la taille de la batterie de serveurs.

  • Service Administration centrale   Le service d’administration. Les besoins en capacité de ce service sont relativement faibles. Il est recommandé d’activer ce service sur plusieurs serveurs de la batterie pour assurer la redondance.

  • Service de journalisation   Service qui enregistre les indicateurs d’utilisation et d’intégrité à des fins de suivi. Ce service fait des accès en écriture intensifs et peut nécessiter un espace disque relativement important selon le nombre d’indicateurs et leur fréquence de journalisation. Dans les grands déploiements SharePoint Server 2010, il est recommandé d’isoler la base de données d’utilisation des bases de données de contenu sur des ordinateurs SQL Server différents.

  • Application de service de recherche SharePoint   L’application de service partagé qui fournit les capacités d’indexation et d’interrogation. Généralement, ce service est relativement gourmand en ressources, puisqu’il peut servir des déploiements de contenu très volumineux. Dans les grands déploiements SharePoint Server où la recherche d’entreprise est très importante, il est recommandé d’utiliser une batterie de serveurs distincte pour héberger les applications de service de recherche, avec des ressources dédiées aux bases de données, d’utiliser plusieurs serveurs d’applications pour traiter les fonctions spécifiques de recherche (analyse ou interrogation), et des serveurs Web cibles dédiés sur les batteries de serveurs de contenu pour assurer un débit acceptable pour l’analyse ou l’interrogation. Vous pouvez également activer l’application FAST Service comme étant votre application de service de recherche. Créez un ou plusieurs connecteurs FAST Search pour indexer le contenu avec FAST Search Server 2010 for SharePoint et créez un autre service FAST Search Query (SSA) pour interroger le contenu analysé par les connecteurs FAST Search.

  • Application de service d’affichage Word   L’activation de ce service vous permet d’afficher des documents Word directement à partir du navigateur. Ce service est ajouté lorsque vous installez Office Web Apps en complément de SharePoint Server 2010. Ce service requiert un serveur d’applications pour préparer les fichiers d’origine en vue de l’affichage dans le navigateur. Dans les grands déploiements SharePoint Server, il est recommandé d’étendre le service à plusieurs serveurs d’applications à des fins de redondance et de débit.

    Notes

    L’édition dans le navigateur pour Word et OneNote est activée si vous installez Office Web Apps sur la batterie de serveurs SharePoint Server 2010. Cependant, cette fonctionnalité s’exécute sur les serveurs Web de la batterie et n’utilise aucune application de service.

  • Application de service PowerPoint   Ce service permet d’afficher et de modifier des fichiers PowerPoint directement dans le navigateur, et de diffuser et partager des présentations PowerPoint en direct. Ce service est ajouté lorsque vous installez Office Web Apps sur SharePoint Server 2010. Ce service requiert un serveur d’applications pour préparer les fichiers d’origine en vue de l’affichage dans le navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de déployer plusieurs serveurs d’applications pour assurer une redondance et un débit acceptables, et d’ajouter des serveurs Web supplémentaires si la diffusion PowerPoint est également fréquemment utilisée.

  • Application de service de calcul Excel   Ce service affiche les feuilles de calcul Excel directement dans le navigateur et effectue les calculs Excel sur le serveur. Il permet également de modifier les feuilles de calcul directement à partir du navigateur si vous installez Office Web Apps sur SharePoint Server 2010. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’allouer un nombre suffisant de serveurs d’applications dotés de suffisamment de RAM pour assurer des performances et un débit acceptables.

  • PowerPivot pour SharePoint   Ce service permet d’afficher la fonction PowerPivot dans des feuilles de calcul Excel où elle est activée, directement à partir du navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’allouer un nombre suffisant de serveurs d’applications dotés suffisamment en RAM et UC pour assurer des performances et un débit acceptables. Pour plus d’informations, voir Configuration matérielle et logicielle requise (PowerPivot pour SharePoint).

  • Application de service Visio   Ce service permet d’afficher des graphiques Visio dynamiques directement dans le navigateur. Il dépend de l’application de service d’état de session, qui requiert une base de données SQL Server relativement petite. Le service Visio requiert un serveur d’applications pour préparer les fichiers Visio d’origine en vue de leur affichage dans le navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’étendre le service à plusieurs serveurs d’applications dotés suffisamment en RAM et UC pour assurer des performances et un débit acceptables.

  • Application de service Access   Ce service permet d’héberger des solutions Accès dans SharePoint Server 2010. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’étendre le service à plusieurs serveurs d’applications dotés de suffisamment de RAM pour assurer des performances et un débit acceptables. Le service Accès utilise SQL Reporting Services, qui requiert une base de données SQL Server pouvant être hébergée avec d’autres bases de données.

  • Application de service de profil utilisateur   Ce service permet de mettre en œuvre les scénarios de réseau social dans SharePoint Server 2010 et active les fonctionnalités Mes sites, Marquage, Notes, Synchronisation de profil avec les annuaires et autres fonctionnalités de réseau social. Le service de profil requiert trois bases de données relativement gourmandes en ressources : une pour la synchronisation, une pour les profils et une pour les liaisons de mise en réseau. Ce service dépend de l’application de service de métadonnées gérées. Dans les grands déploiements SharePoint Server, il est recommandé de distribuer ce service sur une batterie de serveurs dédiée aux services partagés, et de dimensionner correctement le niveau des serveurs de bases de données pour garantir des performances acceptables pour les transactions courantes et les travaux de synchronisation d’annuaires.

  • Application de service de métadonnées gérées   Ce service permet de mettre en œuvre le magasin central de métadonnées et autorise la syndication des types de contenu à travers l’entreprise. Ce service peut être fédéré sur une batterie de serveurs dédiée aux services. Il requiert une base de données qui peut être hébergée avec d’autres bases de données.

  • Application de service Web Analytics   Ce service agrège et stocke les statistiques des caractéristiques d’utilisation de la batterie de serveurs. Les besoins en stockage et ressources SQL Server de ce service sont relativement élevés. Ce service peut être fédéré sur une batterie de serveurs dédiée aux services. Dans les grands déploiements SharePoint Server, il est recommandé d’isoler les bases de données Web Analytics des autres bases de données très importantes ou gourmandes en ressources en les hébergeant sur des serveurs de bases de données différents.

  • Application Business Connection Service   Ce service permet l’intégration de diverses applications métiers organisationnelles avec SharePoint Server 2010. Il requiert un service d’application pour maintenir les connexions de données à des ressources externes. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’allouer un nombre suffisant de serveurs d’applications dotés de suffisamment de RAM pour assurer des performances acceptables.

  • Application InfoPath Forms Service   Ce service autorise les formulaires basés sur navigateur dans SharePoint Server 2010 et permet l’intégration de l’application cliente InfoPath pour la création de formulaires. Ce service requiert un serveur d’applications et dépend de l’application de service d’état de session, qui requiert une base de données relativement petite. Il peut être hébergé avec d’autres services ; ses besoins en capacité sont relativement faibles et leur croissance dépend de la fréquence d’utilisation de cette fonctionnalité.

  • Application de service d’automatisation Word   Ce service permet la conversion des fichiers Word dans un format, comme .doc, vers un autre format, comme .docx ou .pdf. Ce service requiert un serveur d’applications. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’étendre le service à plusieurs serveurs d’applications dotés de ressources UC suffisantes pour assurer un débit de conversion acceptable. Ce service requiert également une base de données relativement petite pour maintenir la file d’attente des travaux de conversion.

  • Application de service PerformancePoint   Ce service active les fonctionnalités d’aide à la décision PerformancePoint dans SharePoint Server 2010 et vous permet de créer des visualisations analytiques. Il requiert un serveur d’applications et une base de données. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’allouer suffisamment de RAM aux serveurs d’applications pour assurer des performances et un débit acceptables.

  • Application de service Project   Ce service active toutes les fonctionnalités de planification et de suivi de Microsoft Project Server 2010 en plus de SharePoint Server 2010. Ce service requiert un serveur d’applications et une base de données relativement gourmande en ressources. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de dédier un serveur de bases de données pour la base de données Project Server et éventuellement de dédier une batterie de serveurs SharePoint Server pour les solutions de gestion Project Server.

  • Service minuteur   Le processus responsable de l’exécution des diverses tâches planifiées sur les différents serveurs de la batterie. Le système exécute divers travaux du minuteur, certains s’exécutant sur tous les serveurs de la batterie et d’autres seulement sur des serveurs spécifiques en fonction du rôle du serveur. Certains travaux du minuteur sont gourmands en ressources et sont susceptibles de créer de la charge aussi bien sur le serveur local que sur les serveurs de bases de données, selon leur activité et la quantité de contenu qu’ils exploitent. Dans les grands déploiements SharePoint Server où les travaux du minuteur sont susceptibles d’avoir un impact sur la latence de l’utilisateur final, il est recommandé de dédier un serveur pour isoler l’exécution des travaux les plus gourmands en ressources.

  • Flux de travail   Cette fonctionnalité active les flux de travail intégrés dans SharePoint Server 2010 et exécute les flux de travail sur le serveur Web. L’utilisation des ressources dépend de la complexité des flux de travail et du nombre total d’événements qu’ils gèrent. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d’ajouter des serveurs Web ou d’isoler un serveur pour gérer uniquement le service du minuteur de flux de travail afin que le trafic de l’utilisateur final ne soit pas affecté et que les opérations de flux de travail ne soient pas retardées.

  • Solutions en bac à sable   Ce service permet l’isolation du code personnalisé sur des ressources dédiées de la batterie de serveurs. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de dédier des serveurs Web supplémentaires si le code personnalisé commence à avoir un impact sur les performances des serveurs.

Nouvelles interactions des applications clientes avec SharePoint Server 2010

Cette section décrit quelques unes des nouvelles interactions client-serveur prises en charge par SharePoint Server 2010 et leurs implications sur la planification de la capacité.

Le tableau suivant donne un aperçu simplifié de la charge standard que ces nouvelles fonctionnalités introduisent sur le système :

X – Indique une charge minime ou négligeable sur les ressources du système.

XX – Indique une charge moyenne sur les ressources du système.

XX – Indique une charge élevée sur les ressources du système.

Client Trafic Charge utile

Office Web Apps

XXX

XX

Diffusion PowerPoint

XXX

X

Application cliente Word et PowerPoint 2010

XX

X

Application cliente OneNote

XXX

XXX

Outlook Social Connector

XX

XX

SharePoint Workspace

XXX

XX

  • Office Web Apps   L’affichage et la modification des fichiers Word, PowerPoint, Excel et OneNote est un sous-ensemble des requêtes de navigateur, avec des caractéristiques de trafic légèrement différentes. Ce genre d’interaction introduit une charge de trafic relativement élevée pour permettre les fonctionnalités comme la co-création. Dans les grands déploiements SharePoint Server où ces fonctionnalités sont activées, une charge supplémentaire est à prévoir sur les serveurs Web.

  • Diffusion PowerPoint   L’ensemble des requêtes associées à l’affichage d’une présentation PowerPoint en direct dans le navigateur Web est un autre sous-ensemble des requêtes de navigateur. Lors des sessions de diffusion PowerPoint en direct, les clients participants demandent des changements auprès du service. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web.

  • Applications clientes Word et PowerPoint 2010   Les clients Word et PowerPoint 2010 ont de nouvelles fonctionnalités qui tirent parti de la batterie de serveurs SharePoint Server. La co-création de document en est un exemple, où toutes les applications clientes participant à une session de co-création effectuent fréquemment des opérations de chargement sur le serveur ou de téléchargement depuis ce dernier. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web.

  • Application cliente OneNote 2010   Le client OneNote 2010 interagit avec la batterie de serveurs SharePoint Server, comme dans la version précédente de OneNote, et utilise SharePoint Server 2010 pour partager et permettre la co-création de blocs-notes OneNote. Ce scénario introduit de la charge sur SharePoint Server 2010 même si le client est ouvert sans être utilisé activement. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web.

  • Application cliente Outlook 2010   Outlook 2010 a une nouvelle fonctionnalité, Outlook Social Connector, qui tire parti de la batterie SharePoint Server (ce composant peut être ajouté aux versions précédentes d’Outlook également). Cette fonctionnalité vous permet d’afficher l’activité sociale demandée à partir de la batterie SharePoint Server directement dans les messages électroniques. Dans les grands déploiements SharePoint Server où cette fonctionnalité est activée, une charge supplémentaire est à prévoir sur les serveurs Web.

  • SharePoint Workspace   Les clients SharePoint Workspace 2010 ont de nouvelles fonctionnalités qui tirent parti de la batterie SharePoint Server et vous permettent de synchroniser des sites Web, des listes et des bibliothèques de documents sur le client pour une utilisation hors connexion. SharePoint Workspace 2010 effectue une synchronisation régulière avec les objets associés du serveur lorsque le client s’exécute, qu’il soit utilisé activement ou non. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web.

Différenciateurs clés d’un déploiement SharePoint Server 2010

Chaque déploiement de SharePoint Server 2010 a un ensemble de caractéristiques clés qui le rendent unique et différent par rapport à d’autres batteries de serveurs. Ces différenciateurs clés peuvent être classés en quatre catégories principales :

  • Spécifications   Décrivent le matériel, la topologie et la configuration de la batterie de serveurs.

  • Charge de travail   Décrit la demande sur la batterie de serveurs, y compris le nombre d’utilisateurs et les caractéristiques d’utilisation.

  • Ensemble de données   Décrit les tailles et la distribution du contenu.

  • Intégrité et performances   Décrit les performances de la batterie de serveurs par rapport aux cibles de latence et de débit.

Spécifications

Matériel

Le matériel comprend les ressources physiques de l’ordinateur comme les processeurs, la mémoire et les disques durs. Il inclut également des composants réseau physiques comme les cartes réseau, les câbles, les commutateurs, les routeurs et les équilibreurs de charge matériels. De nombreux problèmes de performances et de capacité peuvent être résolus en s’assurant que le matériel correct est utilisé. À l’inverse, une seule mauvaise application de ressource matérielle, par exemple une mémoire insuffisante sur un serveur, peut nuire aux performances de toute la batterie de serveurs.

Topologie

La topologie est la distribution et les relations mutuelles du matériel et des composants de la batterie de serveurs. Il y a deux sortes de topologie :

  • Topologie logique   La carte des composants logiciels tels que les services et les fonctionnalités dans une batterie de serveurs.

  • Topologie physique   La carte des serveurs et des ressources physiques.

En règle générale, le nombre d’utilisateurs et les caractéristiques d’utilisation déterminent la topologie physique d’une batterie de serveurs, et les besoins de l’entreprise tels que la prise en charge de fonctionnalités spécifiques dans la charge prévue déterminent la topologie logique.

Configuration

Nous utilisons le terme configuration pour décrire les paramètres du logiciel et leur définition. La configuration fait également référence à la mise en cache, à RBS et à définition des limites configurables, ainsi qu’à toute partie de l’environnement logiciel pouvant être définie ou modifiée pour satisfaire des exigences particulières.

Charge de travail

La charge de travail définit les caractéristiques opérationnelles clés de la batterie de serveurs, notamment la base d’utilisateurs, la simultanéité, les fonctionnalités utilisées et les agents ou les applications clientes de l’utilisateur qui sont utilisés pour se connecter à la batterie de serveurs.

Les différentes fonctionnalités SharePoint Server ont différents coûts associés sur les ressources de la batterie de serveurs. La popularité des fonctionnalités les plus coûteuses peut avoir un impact considérable sur les performances et l’intégrité du système. Identifier la demande et les caractéristiques d’utilisation prévisibles vous permettra de dimensionner correctement votre implémentation et de réduire le risque de constamment exécuter le système dans un état non fiable.

Base d’utilisateurs

La base d’utilisateurs d’une application basée sur SharePoint Server est la combinaison du nombre total d’utilisateurs et de leur répartition géographique. Par ailleurs, dans la base globale d’utilisateurs, il y a des sous-groupes d’utilisateurs qui peuvent utiliser des fonctionnalités ou des services donnés de façon plus intensive que d’autres groupes. La simultanéité des utilisateurs est le pourcentage total d’utilisateurs utilisant activement le système à un moment donné. Les indicateurs qui définissent la base d’utilisateurs incluent le nombre total d’utilisateurs uniques et le nombre d’utilisateurs simultanés.

Caractéristiques d’utilisation

Les performances d’une batterie de serveurs peuvent être affectées non seulement par le nombre d’utilisateurs en interaction avec le système, mais aussi par leurs caractéristiques d’utilisation. Deux organisations ayant le même nombre d’utilisateurs peuvent avoir des besoins sensiblement différents en fonction de la fréquence d’accès des utilisateurs aux ressources de la batterie, et de l’activation ou non de fonctionnalités et de services gourmands en ressources sur la batterie de serveurs. Les indicateurs qui décrivent les caractéristiques d’utilisation incluent la fréquence des opérations uniques, le rapport opérationnel global (ratio des opérations de lecture et d’écriture et des opérations administratives), ainsi que les schémas d’utilisation et la charge pour les nouvelles fonctionnalités qui sont activées sur la batterie de serveurs (comme Mes sites, la recherche, les flux de travail et Office Web Apps).

Ensemble de données

Le volume de contenu stocké sur le système et les caractéristiques de l’architecture de stockage du contenu peuvent avoir un impact significatif sur les performances et l’intégrité globales du système. L’identification de la taille, de la fréquence d’accès et de la distribution des données vous permettra de dimensionner correctement le stockage sur le système pour éviter qu’il ne devienne un goulot d’étranglement qui ralentit les interactions des utilisateurs avec les services de la batterie de serveurs et affecte l’expérience de l’utilisateur final.

Pour correctement estimer et concevoir l’architecture de stockage d’une solution basée sur SharePoint Server, vous devez connaître le volume de données à stocker sur le système et le nombre d’utilisateurs interrogeant des données provenant de différentes sources de données. Le volume du contenu est un élément important pour dimensionner la capacité des disques, car il peut avoir une influence sur les performances d’autres fonctionnalités et est également susceptible d’affecter la latence et bande passante disponible du réseau. Les indicateurs qui définissent l’ensemble de données incluent le volume total du contenu, le nombre total de documents, le nombre total de collections de sites et les tailles moyenne et maximum des collections de sites.

Intégrité et performances

L’intégrité d’une batterie SharePoint Server est fondamentalement une mesure ou un score simplifié qui reflète la fiabilité, la stabilité et les performances du système. Le niveau de performances de la batterie par rapport aux objectifs dépend fondamentalement des trois premiers différenciateurs. L’intégrité et le score des performances peuvent être suivis au moyen de la consolidation d’un ensemble d’indicateurs. Pour plus d’informations, voir Surveillance et gestion de SharePoint Server 2010. Ces indicateurs incluent le temps de fonctionnement du système, la latence perçue par l’utilisateur final, le taux d’échecs de page et les indicateurs d’utilisation des ressources (UC, RAM).

Tout changement significatif apporté au matériel, à la topologie, à la configuration, à la charge de travail ou à l’ensemble de données peut considérablement affecter la fiabilité et la réactivité du système. Le score d’intégrité permet de faire le suivi des performances au fil du temps et d’évaluer l’impact du changement des conditions de fonctionnement ou des modifications du système sur la fiabilité de la batterie de serveurs.

Architectures de référence

SharePoint Server 2010 est un produit complexe et puissant et il n’existe pas une solution d’architecture adaptée à toutes les situations. Chaque déploiement SharePoint Server est unique et défini par les caractéristiques de l’utilisation et des données. Chaque organisation doit effectuer un un processus approfondi de gestion de la capacité et tirer efficacement avantage de la souplesse que le système SharePoint Server 2010 offre pour personnaliser une solution dimensionnée correctement qui remplit au mieux les besoins organisationnels.

Le concept des architectures de référence est de décrire et illustrer les principales catégories de déploiements SharePoint Server, mais pas de fournir une recette que les architectes puissent utiliser pour concevoir leurs solutions. Cette section s’attache à décrire les vecteurs à partir desquels les déploiements SharePoint Server sont généralement mis à l’échelle.

Les architectures répertoriées ici permettent de comprendre aisément les différences générales entre ces catégories génériques, et de les distinguer en fonction des facteurs généraux de coût et de niveau d’effort.

Déploiement sur un seul serveur

L’architecture du déploiement sur un seul serveur est constituée d’un serveur unique qui exécute SharePoint Server 2010 et une version de SQL Server prise en charge. Cette architecture peut convenir à des fins d’évaluation, pour des développeurs ou pour une implémentation isolée non critique dans un service n’ayant que quelques utilisateurs. Cependant, elle n’est pas recommandée pour un environnement de production.

Modèle de déploiement sur un seul serveur

Déploiement sur une petite batterie de serveurs

Un déploiement sur une petite batterie de serveurs est constitué d’un serveur ou d’un cluster de bases de données unique et d’un ou deux ordinateurs équipés de SharePoint Server 2010. Cette architecture se caractérise principalement par la redondance et le basculement limités et un ensemble minimal de fonctionnalités SharePoint Server activées.

Une petite batterie de serveurs est utile seulement pour les déploiements limités, avec un ensemble minimal d’applications de service activées, une base d’utilisateurs relativement petite, une charge d’utilisation relativement faible (de quelques demandes par minute à très peu de demandes par seconde), et un volume de données relativement petit (de l’ordre de 10 gigaoctets).

Modèle de déploiement sur petite batterie de serveurs

Déploiement sur une batterie de serveurs moyenne

Cette architecture introduit la répartition de la topologie sur trois niveaux : les serveurs Web dédiés, les serveurs d’applications dédiés, et un ou plusieurs serveurs ou clusters de bases de données. La séparation du niveau des serveurs frontaux et du niveau des serveurs d’applications permet une plus grande souplesse pour l’isolation des services et l’équilibrage de la charge sur le système.

Cette architecture, qui est la plus courante, inclut un large spectre de topologies de services et de tailles de batterie de serveurs. Un déploiement sur batterie de serveurs moyenne convient dans les environnements caractérisés par :

  • Plusieurs applications de service réparties sur plusieurs serveurs. Un ensemble standard de fonctionnalités pouvant inclure le service Office Web Apps, le service de profil utilisateur, le service de métadonnées gérées et le service de calcul Excel.

  • Une base d’utilisateurs contenant des dizaines de milliers d’utilisateurs et une charge de 10 à 50 demandes par seconde.

  • Un magasin de données de 1 à 2 téraoctets.

Capacité - Modèle de déploiement sur batterie de serveurs moyenne

Déploiement sur une grande batterie de serveurs

Les déploiements sur de grandes batteries de serveurs introduisent la répartition des services et des solutions sur plusieurs batteries de serveurs, et une extension supplémentaire des niveaux sur une batterie de serveurs unique. Plusieurs services SharePoint Server peuvent être déployés sur une batterie de serveurs dédiée aux services qui traite les demandes provenant de plusieurs batteries de serveurs consommatrices. Dans ces grandes architectures, il y a généralement des serveurs Web, de multiples serveurs d’applications, en fonction des caractéristiques d’utilisation de chacun des services locaux (non partagés), et de multiples serveurs SQL Server ou clusters SQL Server, en fonction du volume de contenu et des bases de données des services d’application activées sur la batterie de serveurs. Ces architectures sont conçues pour les environnements caractérisés par :

  • Plusieurs applications de service fédérées et utilisées par une batterie de serveurs dédiée aux services, généralement le service de profil utilisateur, le service de recherche, le service de métadonnées gérées et le service Web Analytics.

  • La plupart des autres applications de service sont activées localement.

  • Une base d’utilisateurs constituée de centaines de milliers d’utilisateurs.

  • Une charge d’utilisation de l’ordre de centaines de demandes par seconde.

  • Un ensemble de données de l’ordre de 10 téraoctets ou plus.

Capacité - Modèle de déploiement sur grande batterie de serveurs

See Also

Concepts

Planification de la capacité pour SharePoint Server 2010
Test de performances pour SharePoint Server 2010
Surveillance et gestion de SharePoint Server 2010
Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles
Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010)
Performance and capacity technical case studies (SharePoint Server 2010)
Configuration matérielle et logicielle requise (SharePoint Server 2010)

Other Resources

Centre de ressources : Gestion de la capacité pour SharePoint Server 2010