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

 

Sapplique à :SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

Dernière rubrique modifiée :2016-12-16

Résumé :Découvrez comment utiliser les données de performances pour planifier et gérer la capacité d’un environnement SharePoint Server 2013.

Cet article fournit une vue d’ensemble sur la façon de planifier et de gérer efficacement la capacité des environnements SharePoint Server 2013. Il explique également comment assurer une bonne assimilation des besoins et des possibilités de capacité de votre déploiement, par l’analyse des performances et du volume. Enfin, il étudie les répercutions des principales applications sur la capacité, y compris les caractéristiques et l’utilisation du contenu.

ImportantImportant :
Certaines valeurs de cet article reposent sur des résultats de tests et autres informations relatives aux Produits SharePoint 2010 et peuvent ne pas être fidèles aux valeurs finales de SharePoint Server 2013. Cet article sera mis à jour avec les valeurs, liens vers du contenu connexe et autres informations appropriés, puis sera publié de nouveau lorsque les données associées à SharePoint Server 2013 deviendront disponibles.

La gestion de la capacité est un processus continu, puisque 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 2013 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 2013. Le modèle de gestion de la capacité inclut des étapes supplémentaires 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.

Contenu de cet article :

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

  • 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 finaux. 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 laboratoire 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 baisse 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.

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

ImportantImportant :
Certains liens dans cette section peuvent faire référence à SharePoint Server 2010 et d’autres versions de produits antérieures, et seront mis à jour quand les versions SharePoint Server 2013 de ce contenu seront disponibles.

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

Pour savoir comment faire évoluer SharePoint Server 2013 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 :

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

J’utilise actuellement SharePoint Server 2010. Quelles sont les modifications apportées dans SharePoint Server 2013 et que dois-je prendre en compte avant d’effectuer une mise à niveau ? Quelle conséquences la mise à niveau aura-t-elle sur les performances et l’échelle de ma topologie ?

Pour plus d’informations concernant les considérations générales de mise à niveau et des conseils sur la façon de planifier et d’exécuter une mise à niveau dans Office SharePoint Server 2007, consultez l’article suivant :

J’ai déployé SharePoint Server 2013 et je veux m’assurer que je dispose de la topologie et du matériel appropriés en place. Comment valider mon architecture et en assurer correctement la maintenance ?

Pour plus d’informations sur les compteurs de performances et la surveillance pour les batteries de serveurs SharePoint Server 2013, consultez l’article suivant :

Pour plus d’informations sur l’utilisation des outils de suivi d’intégrité intégrés à l’interface d’administration centrale, consultez l’article suivant :

J’ai déployé SharePoint Server 2013 et je rencontre des problèmes de performances. Comment résoudre les problèmes et optimiser mon environnement ?

Pour plus d’informations sur les compteurs de performances et la surveillance pour les batteries de serveurs SharePoint Server 2013, consultez les articles suivants :

Pour plus d’informations sur les outils et les techniques d’optimisation des batteries de serveurs SharePoint Server 2013, consultez l’article suivant :

Pour plus d’informations sur la résolution des problèmes à l’aide des outils de suivi d’intégrité intégrés à l’interface d’administration centrale, consultez l’article suivant :

Pour obtenir la liste des articles traitant de la gestion de la capacité disponibles pour des services et des fonctionnalités SharePoint Server 2010 spécifiques (d’autres articles seront ajoutés dès qu’ils seront disponibles), consultez l’article suivant :

Pour plus d’informations sur les performances et le redimensionnement de la base de données, consultez l’article suivant :

Pour plus d’informations sur le stockage BLOB distant, consultez l’article suivant :

Je souhaite tout savoir concernant la gestion de la capacité SharePoint Server 2013. Par où commencer ?

Pour obtenir plus d’informations sur les concepts généraux concernant la gestion de la capacité et des liens vers une documentation et des ressources supplémentaires, consultez l’article suivant :

Pour plus d’informations sur la gestion de la capacité, consultez les articles qui accompagnent cet article d’aperçu :

Vous devriez maintenant maîtriser les concepts. Pour plus d’informations concernant les limites et frontières de SharePoint Server 2013, consultez l’article suivant :

Une fois prêt à identifier la topologie de départ pour votre environnement basé sur SharePoint Server 2013, vous pouvez consulter les études de cas techniques disponibles dans la bibliothèque et trouver celle qui correspond le mieux à vos besoins. Pour obtenir la liste des études de cas pour SharePoint Server 2010 (études de cas pour SharePoint Server 2013 publiées dès qu’elles seront disponibles), consultez l’article suivant :

Pour plus d’informations sur le suivi d’intégrité et la résolution des problèmes à l’aide des outils de suivi d’intégrité intégrés à l’interface d’administration centrale, consultez les articles suivants :

Pour plus d’informations sur la virtualisation des serveurs basés sur SharePoint Server 2013, consultez l’article suivant :

Pour plus d’informations sur la haute disponibilité et la récupération d’urgence, consultez l’article suivant :

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é.

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 nécessitent 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 pas optimisés peuvent retarder le traitement des demandes et avoir un impact sur la latence pour les clients distants aussi bien 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 minimal 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 lieu d’ajouter du JavaScript incorporé.

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 peut constamment satisfaire la demande, il faut estimer la charge prévue et tester l’architecture sous charge pour vérifier que la latence ne tombe pas en dessous du seuil quand 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 des 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 base de données sont exempts de goulots d’étranglement. Si le nombre maximal 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 des disques ou redistribuez les bases de données sur les disques sous-utilisés. Pour plus d’informations, consultez la section relative à l’élimination des goulots d’étranglement dans Analyse et maintenance de SharePoint Server 2013.

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

  • 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 allers-retours 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 2013 peuvent activer le tableau de bord du développeur pour identifier le code personnalisé qui nécessite 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 base de données tout en limitant le nombre d’allers-retours 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 2013 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.

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 due à 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 bases 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 2013, 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 sur la planification d’une échelle de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2013).

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 quand 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 finaux 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 bases 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.

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 2013 est en permanence surveillée et optimisée en fonction de l’évolution des conditions et des besoins.

SharePoint Server 2013 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. Ainsi, les concepteurs et les administrateurs système doivent appréhender les exigences de leur environnement spécifique.

Modèle de gestion de la capacité
  • É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 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 SharePoint Server 2013Services Internet (IIS).

  • É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 : Piloter, 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ésultats 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 tous les transferts de contenu et d’utilisateurs. Le résultat pour une batterie de serveurs existante est 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.

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 2013 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 2013 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 remontées, 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 peut 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 pire période de demande 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 aucune réponse 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 quand 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.

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 dues à 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 peut constamment supporter une charge de zone rouge sans défaillance du service et avec une latence et un débit acceptables.

Dans SharePoint Server 2013, 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 pour 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 2013 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 vous devez 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. Cette taille limite est toujours 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 toujours définis 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 prise en charge est le nombre de collections de sites par application web. La limite prise en charge est 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. Ainsi, le dépassement de certaines limites, telles que le nombre de collections de sites par application web, peut ne causer qu’une faible baisse 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 en matière de seuils et de 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 2013 peuvent être modifiées, mais vous devez 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 pour SharePoint 2013, le support sera limité tant que le système n’est pas mis à niveau vers la configuration requise.

Dans SharePoint Server 2013, 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 quand 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 acceptables. Ainsi, la valeur maximale affectée au nombre de collections de sites n’est pas absolue, mais elle est 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 Limitations et frontières logicielles pour SharePoint 2013.

Chaque déploiement de SharePoint Server 2013 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.

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 à la 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.

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 2013 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 SharePoint Server 2013 est la combinaison du nombre total d’utilisateurs et de leur répartition géographique. Par ailleurs, dans la base globale d’utilisateurs, des sous-groupes d’utilisateurs peuvent utiliser certaines fonctionnalités ou certains services 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).

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 2013, 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 maximale des collections de sites.

L’intégrité d’une batterie SharePoint Server 2013 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 Analyse et maintenance de SharePoint Server 2013 et Planifier la surveillance dans SharePoint 2013. 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.

SharePoint Server 2013 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 2013 est unique et défini par les caractéristiques de l’utilisation et des données. Chaque organisation doit effectuer un processus approfondi de gestion de la capacité et tirer efficacement avantage de la souplesse que le système SharePoint Server 2013 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 d’illustrer les principales catégories de déploiements SharePoint Server 2013, 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 2013 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.

L’architecture du déploiement sur un seul serveur est constituée d’un serveur unique qui exécute SharePoint Server 2013 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

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 2013. Cette architecture se caractérise principalement par la redondance et le basculement limités et par un ensemble minimal de fonctionnalités SharePoint Server 2013 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 une batterie de serveurs de petite taille

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 une batterie de serveurs de taille moyenne

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 2013 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 une grande batterie de serveurs

Afficher: