Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010)

 

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

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

Cet article explique comment planifier et configurer la couche de stockage et de base de données Microsoft SQL Server dans un environnement Microsoft SharePoint Server 2010.

Les informations de planification de capacité qui y figurent sont exploitables dans votre planification. Elles s’appuient sur des tests effectués par Microsoft sur des propriétés activées. Les résultats obtenus peuvent toutefois varier en fonction de l’équipement utilisé et des fonctionnalités implémentées pour vos sites.

Étant donné que SharePoint Server s’exécute souvent dans des environnements dans lesquels les bases de données sont gérées par plusieurs administrateurs de bases de données SQL Server, ce document s’adresse à la fois aux personnes chargées de l’implémentation des batteries de serveurs SharePoint Server et aux administrateurs de base de données SQL Server. Il implique une bonne connaissance de SharePoint Server et de SQL Server.

Cet article suppose que vous maîtrisiez les concepts présentés dans Capacity management and sizing for SharePoint Server 2010.

Processus de conception et de configuration du niveau de stockage et de base de données des produits SharePoint 2010

Nous vous recommandons de décliner le processus de création du niveau de stockage et de base de données en étapes distinctes, décrites ci-après. Chaque section fournit des informations détaillées sur chaque étape de conception, en insistant notamment sur les besoins de stockage et les meilleures pratiques :

• Collecter les besoins d’E/S, d’espace SQL Server et de stockage

• Choisir l'édition et la version de SQL Server

• Concevoir l'architecture de stockage basée sur les besoins de capacité et d'E/S

• Estimer les besoins de mémoire

• Comprendre les besoins de topologie réseau

• Configurer SQL Server

• Valider les performances et la fiabilité de stockage

Collecter les besoins d’E/S, d’espace SQL Server et de stockage

Plusieurs facteurs d’architecture de SharePoint Server 2010 influent sur la conception du stockage, notamment la quantité de contenu, les fonctionnalités et applications de service utilisées, le nombre de batteries de serveurs et les besoins de disponibilité.

Avant de commencer la planification du stockage, vous devez connaître les bases de données utilisables par SharePoint Server 2010.

Dans cette section :

• Bases de données utilisées par les produits SharePoint 2010

• Comprendre SQL Server et les E/S par seconde

• Estimer les besoins du stockage principal et des E/S par seconde

• Déterminer les besoins de stockage des applications de service et des E/S par seconde

• Déterminer les besoins de disponibilité

Bases de données utilisées par les produits SharePoint 2010

Les bases de données installées avec SharePoint Server 2010 dépendent des fonctionnalités utilisées dans l’environnement. Tous les environnements Produits SharePoint 2010 reposent sur les bases de données système SQL Server. Cette section récapitule les bases de données installées avec SharePoint Server 2010. Pour plus d’informations, voir Types et descriptions des bases de données (SharePoint Server 2010) et Modèle de base de données (https://go.microsoft.com/fwlink/p/?LinkId=187968).

Version et édition du produit	Bases de données
SharePoint Foundation 2010	Configuration Contenu de l’Administration centrale Contenu (une ou plusieurs) Collection des données d’utilisation et d’intégrité Business Data Connectivity Service de registre d’application (si la mise à niveau est effectuée à partir du catalogue de données métiers Microsoft Office SharePoint Server 2007) Service des paramètres d’abonnement (s’il est activé par le biais de Windows PowerShell)
Bases de données supplémentaires pour SharePoint Server 2010 Édition standard	Application de service de recherche : Administration de la recherche Analyse (un ou plusieurs) Propriété (une ou plusieurs) Application du service de profil utilisateur : Profil Synchronisation Liaison de mise en réseau Application de service Web Analytics Zone de transit Création de rapports Banque d’informations sécurisée État Métadonnées gérées Services d’automatisation Word
Bases de données supplémentaires pour SharePoint Server 2010 Édition Enterprise	PerformancePoint
Bases de données supplémentaires pour Project Server 2010	Provisoires Publiées Archivées Création de rapports
Base de données supplémentaire pour FAST Search Server	Administration de la recherche

Si vous effectuez une intégration plus poussée avec SQL Server, votre environnement peut inclure des bases de données supplémentaires, comme dans les scénarios suivants :

• Microsoft SQL Server 2008 R2 PowerPivot pour Microsoft SharePoint 2010 peut être utilisé dans un environnement SharePoint Server 2010 comprenant SQL Server 2008 R2 Enterprise Edition et SQL Server Analysis Services. Si vous l’utilisez, envisagez également de prendre en charge la base de données de l’application PowerPivot et la charge supplémentaire qu’elle impose au système. Pour plus d’informations, voir Planifier un déploiement PowerPivot dans une batterie de serveurs SharePoint (https://go.microsoft.com/fwlink/p/?LinkID=186698).

• Le plug-in Microsoft SQL Server 2008 Reporting Services (SSRS) peut être utilisé avec tout environnement des produits SharePoint 2010. Si vous l’utilisez, pensez à prendre en charge les deux bases de données SQL Server 2008 Reporting Services et la charge supplémentaire requise pour SQL Server 2008 Reporting Services.

Comprendre SQL Server et les E/S par seconde

Il est très important que les serveurs hébergeant SQL Server obtiennent les meilleurs temps de réponse possibles du sous-système d’E/S.

Des disques ou des matrices plus rapides et plus nombreux fournissent des opérations d’entrées/sorties par seconde (IOPS) suffisantes tout en conservant une faible latence et une file d’attente courte sur tous les disques.

Il est impossible de compenser une réponse lente du sous-système d’E/S en ajoutant d’autres types de ressources, tels qu’un processeur ou de la mémoire. En outre, cette lenteur peut influer sur le fonctionnement de la batterie de serveurs et entraîner des problèmes dans celle-ci. Planifiez donc une latence minimale avant le déploiement et surveillez vos systèmes existants.

Avant de déployer une nouvelle batterie de serveurs, nous recommandons l’évaluation du sous-système d’E/S à l’aide de l’outil d’évaluation du sous-système de disque SQLIO. Pour plus d’informations, voir Outil d’évaluation du sous-système de disque SQLIO (https://go.microsoft.com/fwlink/p/?LinkID=105586).

Pour plus d’informations sur l’analyse des besoins d’E/S par seconde dans une perspective SQL Server, voir Analyse des caractéristiques d’E/S et dimensionnement des systèmes de stockage pour les applications de bases de données SQL Server (https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

Estimer les besoins du stockage principal et des E/S par seconde

Le stockage du contenu et de la configuration, ainsi que les E/S par seconde, constituent le niveau de base que vous devez planifier pour chaque déploiement SharePoint Server 2010.

Stockage de la configuration et E/S par seconde

Les besoins de stockage de la base de données de configuration et de la base de données de contenu de l’Administration centrale sont modestes. Nous recommandons d’allouer 2 Go à la base de données de configuration et 1 Go à la base de données de contenu de l’Administration centrale. Au fil du temps, la base de données de configuration peut dépasser 1 Go mais sa croissance est lente, se montant à environ 40 Mo pour 50 000 collections de sites.

Les journaux de transactions de la base de données de configuration pouvant être volumineux, nous recommandons de changer le modèle de récupération de la base de données complet par le modèle simple.

Les besoins d’E/S par seconde pour la base de données de configuration et la base de données de contenu de l’Administration centrale sont minimaux.

Stockage de contenu et E/S par seconde

L’estimation des besoins de stockage et d’E/S par seconde pour les bases de données de contenu n’est pas une science exacte. Dans les tests et les explications qui suivent, notre but est de vous aider à déduire les estimations qui vous permettront de déterminer la taille initiale de votre déploiement. Néanmoins, vous serez certainement amené à revoir vos prévisions de capacité en fonction des données de votre environnement d’exécution réel.

Pour plus d’informations sur la méthodologie de planification de la capacité globale, voir Capacity management and sizing for SharePoint Server 2010.

Estimer le stockage de la base de données de contenu

Le processus suivant décrit comment estimer approximativement le stockage requis pour les bases de données de contenu, sans tenir compte des fichiers journaux :

1. Calculez le nombre de documents prévu. La valeur est représentée par D dans la formule.

   Le mode de calcul du nombre de documents est déterminé par les fonctionnalités que vous utilisez. Par exemple, pour les sites de collaboration ou les sites Mon site, nous recommandons de calculer le nombre de documents prévu par utilisateur et de le multiplier par le nombre d’utilisateurs. Pour les sites de publication de contenu ou de gestion d’enregistrements, vous pouvez calculer le nombre de documents gérés et générés par le biais d’un processus.

   Si vous migrez à partir d’un système actuel, il est peut-être plus simple d’extrapoler votre taux de croissance et d’utilisation actuels. Si vous créez un système, examinez vos partages de fichiers existants ou autres référentiels et faites une estimation en fonction de ce taux d’utilisation.

2. Estimez la taille moyenne des documents devant être stockés. Cette valeur est représentée par S dans la formule. Il peut être judicieux d’estimer des moyennes pour plusieurs types ou groupes de sites. La taille moyenne des fichiers pour les sites Mon site, les référentiels de médias et les portails de services peuvent varier considérablement.

3. Estimez le nombre d’éléments de liste dans l’environnement. Cette valeur est représentée par la lettre L dans la formule.

   Les éléments de liste sont plus difficiles à estimer que les documents. Nous nous basons généralement sur une estimation correspondant au nombre de documents multiplié par trois (D), mais cette estimation peut changer selon ce que vous comptez faire de vos sites.

4. Déterminez le nombre approximatif de versions. Estimez le nombre moyen de versions de chaque document d’une bibliothèque (cette valeur sera généralement beaucoup plus faible que le nombre de versions maximal autorisé). Cette valeur est représentée par la lettre V dans la formule.

   La valeur de V doit être supérieure à zéro.

5. Utilisez la formule suivante pour estimer la taille de vos bases de données de contenu :

   Taille de la base de données = ((D × V) × S) + (10 Ko × (L + (V × D)))

   La valeur de 10 Ko dans la formule est une constante qui estime approximatement la quantité de métadonnées requise par SharePoint Server 2010. Si votre système utilise les métadonnées de façon intensive, augmentez cette constante.

Par exemple, si vous deviez utiliser la formule pour estimer la quantité d’espace de stockage requise pour les fichiers de données d’une base de données de contenu dans un environnement de collaboration présentant les caractéristiques suivantes, il vous faudrait environ 105 Go.

Entrée	Valeur
Nombre de documents (D)	200 000 Postulat : 10 000 utilisateurs multiplié par 20 documents
Taille moyenne des documents (S)	250 Ko
Éléments de liste (L)	600 000
Nombre de versions non actuelles (V)	2 Postulat : nombre maximal de versions autorisée égal à 10

Taille de la base de données = (((200 000 x 2)) × 250) + ((10 Ko × (600 000 + (200 000 x 2))) = 110 000 000 Ko ou 105 Go

Fonctionnalités ayant une incidence sur la taille des bases de données de contenu

L’utilisation des fonctionnalités SharePoint Server 2010 suivantes peut avoir des répercussions significatives sur la taille des bases de données de contenu :

• Corbeilles   Tant qu’un document n’a pas été définitivement supprimé des Corbeilles principale et secondaire, il occupe de l’espace dans une base de données de contenu. Calculez le nombre de documents supprimés tous les mois afin de déterminer l’incidence des Corbeilles sur la taille des bases de données de contenu. Pour plus d’informations, voir Configurer les paramètres de la Corbeille (SharePoint Server 2010).

• Audit   Les données d’audit peuvent rapidement s’agréger et utiliser énormément d’espace dans une base de données de contenu, notamment si l’audit des vues est activé. Plutôt que de laisser les données d’audit grossir sans limitation, nous recommandons de n’activer l’audit que pour les événements importants, par exemple la conformité par rapport à des réglementations ou des contrôles internes. Les conseils suivants devraient vous permettre d’estimer l’espace à réserver pour les données d’audit :

  • Estimez le nombre de nouvelles entrées d’audit pour un site et multipliez-le par 2 Ko (les entrées sont généralement limitées à 4 Ko, la taille moyenne étant d’1 Ko).

  • Selon l’espace que vous souhaitez allouer, déterminez le nombre de jours de conservation des journaux d’audit.

• Office Web Apps. Si Office Web Apps sont utilisés, le cache d’Office Web Apps peut affecter la taille d’une base de données de contenu de manière significative. Par défaut, le cache d’Office Web Apps est configuré pour atteindre une taille de 100 Go. Pour plus d’informations sur la taille du cache d’Office Web Apps, voir Gérer le cache Office Web Apps.

Estimer les besoins d’E/S par seconde des bases de données de contenu

Les besoins d’E/S par seconde des bases de données de contenu varient considérablement en fonction de l’utilisation de votre environnement ainsi que de l’espace disque et du nombre de serveurs dont vous disposez. En règle générale, nous recommandons de comparer la charge de travail prévue dans un environnement avec l’une des solutions que nous avons testées. Pour plus d’informations, voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010).

Estimer les besoins de stockage des applications de service et des E/S par seconde

Après avoir estimé les besoins de stockage de contenu et des E/S par seconde, vous devez déterminer ceux des applications de service utilisées dans votre environnement.

Besoins de stockage des applications de service SharePoint Server 2010 et d’E/S par seconde

Pour estimer les besoins de stockage des applications de service du système, vous devez tout d’abord connaître les applications de service et l’usage que vous souhaitez en faire. Les applications de service disponibles dans SharePoint Server 2010 possédant des bases de données sont répertoriées dans le tableau suivant.

Application de service	Taille estimée recommandée
Recherche	La recherche nécessite trois bases de données. Votre environnement peut inclure plusieurs bases de données de propriétés et d’analyse. La base de données d’administration de la recherche est généralement petite : allouez 10 Go. Pour estimer le stockage nécessaire pour vos bases de données de propriétés et d’analyse, utilisez les multiplicateurs suivants : Analyse : 0,046 × (somme des bases de données de contenu) Propriétés : 0,015 × (somme des bases de données de contenu) Les besoins d’E/S par seconde de la recherche sont conséquents. Pour la base de données d’analyse, la recherche nécessite entre 3 500 et 7 000 E/S par seconde. Pour la base de données de propriétés, la recherche nécessite 2 000 E/S par seconde. Pour plus d’informations sur l’estimation de la capacité requise pour la recherche, voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010). FAST Search Server 2010 for SharePoint possède une architecture différente. La base de données d’analyse a les mêmes exigences d’opérations d’E/S, mais la base de données de propriétés est utilisée uniquement pour la recherche de personnes et il existe une base de données d’administration de la recherche supplémentaire. Pour obtenir des informations détaillées sur FAST Search Server 2010 for SharePoint, voir Planifier la topologie de la batterie de serveurs (FAST Search Server 2010 for SharePoint) (traduction automatique) et Performance and capacity management (FAST Search Server 2010 for SharePoint).
profil utilisateur	L’application de service Profil utilisateur est associée à trois bases de données : profils, synchronisation et liaison de mise en réseau. Pour estimer le stockage nécessaire pour les bases de données, utilisez les informations suivantes : Profils. Dans un environnement configuré pour utiliser Active Directory et avec les paramètres par défaut, la base de données de profils nécessite environ 1 Mo par profil utilisateur. Synchronisation. Dans un environnement disposant de quelques groupes par utilisateur et avec les paramètres par défaut, la base de données de synchronisation nécessite environ 630 Ko par profil utilisateur. 90 % de l’espace sera utilisé par le fichier de données. Liaison de mise en réseau. Avec les paramètres par défaut, la base de données de liaison de mise en réseau nécessite environ 0,009 Mo par balise, commentaire ou évaluation. Pour estimer le nombre de balises et de notes créées par les utilisateurs, tenez compte des informations suivantes sur le site del.icio.us : Environ 10 % des utilisateurs sont considérés actifs. Les utilisateurs actifs créent 4,5 balises et 1,8 commentaires par mois. Dans un environnement de collaboration comprenant 160 000 profils utilisateurs, 5 groupes, 79 000 balises, commentaires et évaluations (2 500 commentaires, 76 000 balises et 800 évaluations) et des paramètres par défaut, nous avons constaté les tailles de bases de données suivantes :   Nom de la base de données Taille de la base de données Profil 155 Go Synchronisation 96 Go Liaison de mise en réseau 0,66 Go
Métadonnées gérées	L’application de service Métadonnées gérées possède une seule base de données. La taille de la base de données dépend du nombre de types de contenus et de mots clés utilisés dans le système. De nombreux environnements incluront plusieurs instances de l’application de service Métadonnées gérées.
Web Analytics	L’application de service Web Analytics possède deux bases de données : zone de transit et création de rapports. De nombreux facteurs influent sur la taille des bases de données, notamment la période de conservation, le volume quotidien des données suivies ainsi que le nombre de collections de site, sites et sous-sites de l’application Web analysée. Pour plus d’informations sur l’estimation de leur taille et de leurs besoins d’E/S par seconde, voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010).
Banque d’informations sécurisée	La taille de la base de données de l’application Service Banque d’informations sécurisé est déterminée par le nombre d’informations d’identification de la banque et le nombre d’entrées de la table d’audit. Nous vous recommandons de lui allouer 5 Mo pour 1 000 informations d’identification. Les besoins d’E/S par seconde sont minimaux.
État	L’application de service État possède une seule base de données. Nous recommandons de lui allouer 1 Go. Les besoins d’E/S par seconde sont minimaux.
Word Automation Services	L’application Word Automation Services possède une seule base de données. Nous recommandons de lui allouer 1 Go. Les besoins d’E/S par seconde sont minimaux.
PerformancePoint	L’application de service PerformancePoint possède une seule base de données. Nous recommandons de lui allouer 1 Go. Les besoins d’E/S par seconde sont minimaux.

Déterminer les besoins de disponibilité

La disponibilité est le degré de perception de la disponibilité par les utilisateurs d’un environnement SharePoint Server 2010. Un système disponible est fiable, c’est-à-dire que les incidents affectant le service se produisent rarement et qu’une action immédiate et efficace est effectuée lorsqu’ils se produisent.

Les besoins de disponibilité peuvent augmenter considérablement vos besoins de stockage. Pour plus d’informations, voir Planifier la disponibilité (SharePoint Server 2010).

Choisir la version et l’édition de SQL Server

Même si Produits SharePoint 2010 peut s’exécuter sur Microsoft SQL Server 2008 R2, SQL Server 2008 ou SQL Server 2005, nous vous recommandons fortement d’exécuter votre environnement sur SQL Server 2008 ou SQL Server 2008 R2 Enterprise Edition afin de tirer parti des fonctions de performance, disponibilité, sécurité et gestion complémentaires proposées. Pour plus d’informations sur les avantages liés à l’utilisation de SQL Server 2008 R2 Enterprise Edition, voir SQL Server 2008 R2 et les produits SharePoint 2010 : une association efficace (livre blanc) (SharePoint Server 2010).

Vous devez notamment prendre en compte vos besoins pour les fonctionnalités suivantes :

• Compression de sauvegarde   La compression de sauvegarde permet d’accélérer les sauvegardes dans SharePoint. Elle est disponible dans SQL Server 2008 Enterprise Edition ou SQL Server 2008 R2 Standard Edition. Si vous définissez l’option de compression dans votre script de sauvegarde ou configurez le serveur exécutant SQL Server pour effectuer une compression par défaut, vous pouvez réduire considérablement la taille de vos sauvegardes de bases de données et de vos journaux copiés. Pour plus d’informations, voir Compression de sauvegardes (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkId=129381).

  Notes

  La compression de données SQL Server n’est pas prise en charge pour Produits SharePoint 2010, sauf pour les bases de données d’application de service de recherche.

• Chiffrement transparent des données   Si vos besoins de sécurité incluent le chiffrement transparent des données, vous devez utiliser SQL Server Enterprise Edition.

• Application de service Web Analytics   Si vous envisagez d’utiliser l’application de service Web Analytics pour effectuer des analyses significatives, pensez à SQL Server Enterprise Edition qui permet au système de tirer parti du partitionnement table.

• Déploiement de contenu   Si vous prévoyez d’utiliser la fonction Déploiement de contenu, pensez à SQL Server Enterprise Edition qui permet au système de tirer parti des captures instantanées de base de données SQL Server.

• Stockage BLOB distant   Si vous souhaitez tirer parti du stockage BLOB distant sur une base de données ou un emplacement situé en dehors des fichiers associés à chaque base de données de contenu, vous devez utiliser SQL Server 2008 ou SQL Server 2008 R2 Enterprise Edition.

• Gouverneur de ressources   Le gouverneur de ressources est une technologie introduite par SQL Server 2008 qui permet de gérer les charges de travail et les ressources SQL Server en spécifiant des limites concernant la consommation de ressources par les requêtes entrantes. Le gouverneur de ressources permet de différencier ces charges de travail et d’allouer des ressources (processeur et mémoire) en fonction de la demande, selon les limites que vous spécifiez. Il est disponible uniquement dans SQL Server 2008 ou SQL Server 2008 R2 Enterprise Edition. Pour plus d’informations sur l’utilisation du gouverneur de ressources, voir Gestion des charges de travail SQL Server à l’aide du gouverneur de ressources.

  Nous recommandons d’utiliser le gouverneur de ressources avec SharePoint Server 2010 pour effectuer les opérations suivantes :

  • Limiter la quantité de ressources SQL Server que consomment les serveurs Web ciblés par le composant d’analyse de recherche. La meilleure pratique consiste à limiter le composant d’analyse à 10 % de l’UC lorsque le système est surchargé.

  • Surveiller le nombre de ressources consommées par chaque base de données du système. Vous pouvez ainsi utiliser le gouverneur de ressources pour déterminer le meilleur positionnement des bases de données parmi les ordinateurs exécutant SQL Server.

• PowerPivot pour SharePoint 2010   Permet aux utilisateurs de partager des modèles de données générés par l’utilisateur et des analyses dans Excel et dans le navigateur, et d’y collaborer, tout en actualisant ces analyses automatiquement. Ce composant fait partie de SQL Server 2008 R2 Enterprise Edition Analysis Services.

Concevoir l’architecture de stockage en fonction des besoins de capacité et d’E/S

L’architecture de stockage et les types de disques que vous sélectionnez pour votre environnement peuvent affecter les performances du système.

Dans cette section :

• Choisir une architecture de stockage

• Choisir les types de disques

• Choisir les types RAID

Choisir une architecture de stockage

Les architectures de stockage DAS (Direct Attached Storage), SAN (Storage Area Network) et NAS (Network Attached Storage) sont prises en charge avec SharePoint Server 2010, même si NAS n’est pris en charge que pour les bases de données de contenu configurées pour utiliser le stockage BLOB distant. Votre choix est lié à des facteurs intrinsèques à votre solution métier et à votre infrastructure existante.

Une architecture de stockage doit prendre en charge vos besoins de disponibilité et se comporter de façon appropriée au niveau des E/S par seconde et de la latence. Pour être prises en charge, le système doit renvoyer régulièrement le premier octet de données en 20 millisecondes (ms).

DAS (Direct Attached Storage, stockage à connexion directe)

Système de stockage numérique qui n’utilise pas les ressources d’un réseau, mais qui est directement relié à un serveur ou une station de travail. Les types de disques physiques DAS incluent SAS et SATA.

En général, nous recommandons une architecture DAS lorsqu’une plateforme de stockage partagée ne peut pas garantir un temps de réponse de 20 ms et une capacité suffisante pour les E/S par seconde moyennes et de pointe.

SAN (Storage Area Network, réseau de stockage SAN)

Architecture conçue pour relier des périphériques de stockage des ordinateurs distants (comme des baies de disques et des bibliothèques de bandes) à des serveurs, si bien que les périphériques semblent reliés localement au système d’exploitation (par exemple, le stockage de blocs).

Nous recommandons généralement l’architecture SAN lorsque le stockage partagé est bénéfique pour votre organisation.

Les avantages du stockage partagé sont les suivants :

• Permet de réallouer plus facilement le stockage sur disque entre les serveurs.

• Peut être au service de plusieurs serveurs.

• Ne présente aucune limitation quant au nombre de disques accessibles.

Network Attached Storage (NAS, stockage connecté au réseau)

Une unité NAS est un ordinateur autonome, relié à un réseau, dont la principale fonction est de fournir des services de stockage de données à base de fichiers aux autres périphériques du réseau. Le système d’exploitation et les autres logiciels installés sur l’unité NAS fournissent des fonctionnalités de stockage de données, de systèmes de fichiers et d’accès aux fichiers, ainsi que la gestion de ces fonctionnalités (par exemple, le stockage de fichiers).

Choisir les types de disques

Les types de disques utilisés dans le système peuvent affecter la fiabilité et les performances. À configuration égale, plus les lecteurs sont grands, plus le temps d’accès est long. SharePoint Server 2010 prend en charge les types de lecteurs suivants :

• SCSI (Small Computer System Interface)

• SATA (Serial Advanced Technology Attachment)

• SAS (Serial-Attached SCSI)

• FC (Fibre Channel)

• IDE (Integrated Device Electronics)

• SSD (Solid State Drive) ou disque Flash

Choisir les types RAID

Les types RAID (Redundant Array of Independent Disks) contribuent généralement à améliorer les caractéristiques de performance des disques individuels (en distribuant les données sur plusieurs disques) et à fournir une protection contre les échecs des disques individuels.

Tous les types RAID sont pris en charge pour SharePoint Server 2010 ; nous recommandons cependant l’utilisation du type RAID 10 ou d’une solution RAID fournisseur offrant des performances équivalentes.

Lorsque vous configurez une matrice RAID, veillez à bien aligner le système de fichiers au décalage indiqué par le fournisseur. En l’absence de consignes de celui-ci, voir Méthodes recommandées pour l’E/S d’avant déploiement de SQL Server (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Pour plus d’informations sur la mise en service de RAID et du sous-système d’E/S SQL Server, voir Meilleures pratiques SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=168612).

Estimation de la mémoire requise

La mémoire requise pour SharePoint Server 2010 est directement liée à la taille des bases de données de contenu que vous hébergez sur un serveur exécutant SQL Server.

Il est probable que vos besoins augmenteront à mesure que vous ajouterez des applications de service et des fonctionnalités. Le tableau suivant répertorie les recommandations associées à la quantité de mémoire requise.

Taille combinée des bases de données de contenu	Mémoire RAM recommandée pour l’ordinateur exécutant SQL Server
Taille minimale pour les déploiements à petite échelle	8 Go
Taille minimale pour les déploiements à moyenne échelle	16 Go
Recommandation jusqu’à 2 téraoctets	32 Go
Recommandation pour une taille comprise entre 2 et 5 téraoctets	64 Go
Recommandation pour plus de 5 téraoctets	Au-delà de 64 Go, la RAM supplémentaire permet d’améliorer la vitesse de mise en cache de SQL Server.

D’autres facteurs peuvent influer sur la mémoire requise :

• l’utilisation de la mise en miroir SQL Server ;

• l’utilisation fréquente de fichiers supérieurs à 15 mégaoctets (Mo).

Recommandations pour la topologie du réseau

Planifiez les connexions réseau au sein des batteries de serveurs et entre celles-ci. Il est recommandé d’utiliser un réseau présentant une latence faible.

La liste suivante indique certaines meilleures pratiques et recommandations.

• Tous les serveurs de la batterie de serveurs doivent disposer d’une latence et d’une bande passante LAN sur le serveur exécutant SQL Server (la latence ne doit pas dépasser 1 milliseconde).

• Il n’est pas recommandé d’utiliser une topologie de réseau étendu (WAN) dans laquelle un serveur exécutant SQL Server est déployé à distance à partir d’autres composants de la batterie de serveurs et dont la latence de réseau est supérieure à 1 ms. Cette topologie n’a pas été testée.

• Planifiez un réseau WAN adéquat si vous envisagez d’utiliser la mise en miroir SQL Server ou la copie des journaux de transaction pour maintenir un site distant à jour.

• Nous recommandons l’installation de deux cartes réseau sur les serveurs Web et les serveurs d’applications : une carte réseau pour gérer le trafic des utilisateurs et une autre pour gérer les communications entre les serveurs exécutant SQL Server.

Configurer SQL Server

Les sections suivantes décrivent comment planifier la configuration de SQL Server pour SharePoint Server 2010.

Dans cette section :

• Déterminer le nombre d'instances ou de serveurs requis

• Configurer le stockage et la mémoire

• Définir les options SQL Server

• Configurer les bases de données

Estimer le nombre de serveurs requis

En général, SharePoint Server 2010 a été conçu pour tirer parti de la montée en charge de SQL Server. Autrement dit, il est possible que SharePoint Server 2010 se comporte mieux avec un grand nombre de serveurs de taille moyenne exécutant SQL Server qu’avec seulement quelques gros serveurs.

Installez toujours SQL Server sur un serveur dédié qui n’exécute aucun autre rôle de batterie de serveurs ou n’héberge aucune base de données pour d’autres applications, sauf si vous déployez le système sur un serveur autonome.

Les recommandations suivantes devraient vous aider à déterminer le moment le plus apportun pour déployer un serveur supplémentaire exécutant SQL Server :

• Ajouter un serveur de bases de données supplémentaire lorsque plus de quatre serveurs Web fonctionnent à leur capacité maximale.

• Ajoutez un serveur de base de données supplémentaire si votre serveur actuel a atteint ses limites effectives en matière de ressources de RAM, de processeur, de débit d’E/S de disque, de capacité de disque ou de débit de réseau.

Pour promouvoir le stockage des informations d’identification sécurisé lors de l’exécution de l’application de service Banque d’informations sécurisé, nous recommandons l’hébergement de la base de données de stockage sécurisé sur une instance de base de données distincte dont l’accès est limité à un administrateur unique.

Configurer le stockage et la mémoire

Sur le serveur exécutant SQL Server 2008, il est recommandé que le cache L2 dispose d’au moins 2 Mo par processeur afin d’optimiser les performances de la mémoire.

Suivre les recommandations du fournisseur pour la configuration de stockage

Pour obtenir des performances optimales lors de la configuration d’une matrice de stockage physique, suivez les recommandations du fournisseur de la solution de stockage pour la configuration matérielle au lieu de conserver les valeurs par défaut du système d’exploitation.

Si vous ne disposez d’aucune instruction fournisseur, nous vous recommandons d’utiliser l’utilitaire de configuration de disque DiskPart.exe pour configurer le stockage de SQL Server 2008. Pour plus d’informations, voir Meilleures pratiques relatives aux E/S avant le déploiement (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Fournir autant de ressources que possible

Assurez-vous que les canaux d’entrée/sortie (E/S) SQL Server vers les disques ne sont pas partagés par d’autres applications, comme le fichier de pagination et les journaux IIS (Internet Information Services).

Fournir autant de bande passante du bus que possible. Plus la bande passante est élevée, meilleures sont la fiabilité et les performances. N’oubliez pas que le disque n’est pas le seul utilisateur de la bande passante du bus. Par exemple, vous devez également tenir compte de l’accès au réseau.

Définir les options SQL Server

Vous devez configurer les options et paramètres SQL Server suivants préalablement au déploiement de SharePoint Server.

• N’activez pas la création automatique de statistiques sur un serveur SQL Server prenant en charge SharePoint Server. SharePoint Server configure les paramètres requis au moment de la mise en service et de la mise à niveau. La création automatique de statistiques peut modifier considérablement le plan d’exécution d’une requête d’une instance de SQL Server vers une autre instance de SQL Server. Par conséquent, pour apporter une assistance technique cohérente à tous les utilisateurs, SharePoint Server fournit au besoin des indications codées pour les requêtes afin d’offrir les meilleures performances possible dans tous les scénarios.

• Pour garantir des performances optimales, nous vous recommandons vivement de définir le degré maximal de parallélisme (MAXDOP) sur 1 sur les instances SQL Server hébergeant des bases de données SharePoint Server 2010. Pour plus d’informations sur la définition du degré maximal de parallélisme, voir Option Degré maximal de parallélisme (https://go.microsoft.com/fwlink/p/?LinkId=189030).

• Dans le but de faciliter la maintenance, configurez des alias de connexion SQL Server pour chaque serveur de bases de données de votre batterie de serveurs. Un alias de connexion est un nom de substitution qui permet d’établir une connexion à une instance de SQL Server. Pour plus d’informations, voir Définir un alias SQL Server (SQL Server Management Studio) (https://go.microsoft.com/fwlink/p/?LinkId=132064).

Configurer des bases de données

La section suivante décrit les meilleures pratiques de planification lorsque vous configurez chaque base de données dans votre environnement.

Répartir les données sur les disques et définir leur priorité

De préférence, vous devez placer la base de données tempdb, les bases de données de contenu, la base de données d’utilisation, les bases de données de recherche et les journaux des transactions SQL Server 2008 sur des disques durs physiques distincts.

La liste suivante indique les meilleures pratiques et fournit des recommandations pour hiérarchiser les données.

• Lors de la définition de la priorité des données parmi des disques plus rapides, utilisez le classement suivant :

  1. Fichiers de données tempdb et journaux des transactions

  2. Fichiers journaux des transactions de base de données

  3. Bases de données de recherche, sauf pour la base de données d’administration de la recherche

  4. Fichiers de données de la base de données

  Dans un site portail principalement utilisé en lecture, privilégiez les données aux journaux.

• Les informations recueillies auprès des clients et à l’issue des tests montrent que les performances des batteries de serveurs SharePoint Server 2010 peuvent être considérablement ralenties par des E/S disques insuffisantes pour la base de données tempdb. Pour éviter cela, allouez des disques dédiés à tempdb. Pour une forte charge de travail prévue ou surveillée, autrement dit lorsque les opérations de lecture ou d’écriture nécessitent en moyenne plus de 20 millisecondes, il peut être nécessaire de limiter le goulot d’étranglement soit en répartissant les fichiers sur les disques, soit en remplaçant les disques par des disques plus rapides.

• Pour de meilleures performances, placez tempdb sur une matrice RAID 10. Le nombre de fichiers de données tempdb doit être égal au nombre de processeurs et les fichiers de données tempdb doivent être définis sur une taille équivalente. À cet effet, comptez chaque processeur double cœur comme deux processeurs et chaque processeur prenant en charge l’hyperthreading comme un seul processeur. Pour plus d’informations, voir Optimisation des performances de la base de données tempdb (https://go.microsoft.com/fwlink/p/?LinkID=148537).

• Répartissez les données de base de données et les journaux des transactions sur différents disques. Si des fichiers doivent se trouver sur le même disque parce qu’ils sont trop petits pour bénéficier d’une bande ou d’un disque complet ou si vous manquez d’espace disque disponible, placez les fichiers ayant des utilisations différentes sur le même disque pour réduire les demandes d’accès simultanées.

• Contactez votre fournisseur de matériel de stockage pour en savoir davantage sur la configuration de l’optimisation de l’écriture dans tous les journaux et les bases de données de recherche pour votre solution de stockage particulière.

Utiliser plusieurs fichiers de données pour les bases de données de contenu

Suivez les recommandations suivantes pour optimiser les performances :

• Ne créez des fichiers que dans le groupe de fichiers primaire de la base de données.

• Répartissez les fichiers sur plusieurs disques.

• Le nombre de fichiers de données doit être inférieur ou égal au nombre de processeurs principaux. À cette fin, comptez les processeurs à double cœur comme deux processeurs. Comptez chaque processeur qui prend en charge la technologie HyperThreading comme un seul processeur.

• Créez des fichiers de données de taille équivalente.

Pour plus d’informations sur la création et la gestion des groupes de fichiers, voir Architecture des fichiers et des groupes de fichiers (https://go.microsoft.com/fwlink/p/?LinkId=117909).

Limiter la taille de la base de données de contenu pour en améliorer la gestion

Planifiez la taille de la base de données de façon à améliorer la gestion, les performances et faciliter la mise à niveau de votre environnement.

Pour garantir les performances du système, nous vous recommandons de limiter la taille des bases de données de contenu à 200 Go, sauf dans le cas de scénarios et de conditions d’utilisation spécifiques prenant en charge des tailles plus importantes. Pour plus d’informations sur la taille maximale des bases de données de contenu, voir la section Limites des bases de données de contenu dans Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles.

Nous recommandons généralement qu’une collection de sites ne dépasse pas 100 Go, sauf s’il s’agit de la seule collection de sites dans la base de données, afin que vous puissiez utiliser les outils de sauvegarde précise SharePoint Server 2010 pour la déplacer vers une autre base de données si nécessaire.

Pour plus d’informations sur les référentiels de documents à grande échelle, voir « Évaluer les exigences en matière de performances et de capacité pour les référentiels de documents à grande échelle » dans Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010).

Gérer proactivement la croissance des données et des fichiers journaux

Nous vous recommandons de gérer proactivement la croissance des données et des fichiers journaux en suivant les recommandations ci-dessous :

• Autant que possible, pré-augmentez la taille de l’ensemble des données et des fichiers journaux en leur allouant la taille finale supposée.

• Nous recommandons l’activation de la croissance automatique pour des raisons de sécurité. Ne vous fiez pas aux paramètres de croissance automatique par défaut et prenez plutôt en considération les recommandations ci-dessous :

  • Lorsque vous planifiez des bases de données de contenu dont la taille est supérieure à la taille recommandée (200 Go), définissez la valeur de la croissance automatique des bases de données à une valeur fixe de mégaoctets au lieu d’un pourcentage, et ce, afin de diminuer la fréquence à laquelle SQL Server augmente la taille d’un fichier. L’augmentation de la taille des fichiers est une opération de blocage qui nécessite de remplir le nouvel espace à l’aide de pages vides.

  • Attribuez 10 % à la valeur de la croissance automatique pour la base de données Banque de propriétés de l’application de service Recherche.

  • Si la taille calculée de la base de données de contenu n’est pas censée atteindre le pic recommandé de 200 Go l’année suivante, définissez la taille maximale que vous avez prévue dans une année,  — avec une marge d’erreur supplémentaire de 20 % — à l’aide de la propriété ALTER DATABASE MAXSIZE. Examinez régulièrement ce paramètre pour vous assurer que la base de calcul par rapport aux taux de croissance passés est toujours pertinente.

• Maintenez un niveau d’au moins 25 % d’espace libre sur les disques afin de prendre en charge des modèles de croissance et d’utilisation en période de forte activité. Si vous gérez la croissance en ajoutant des disques à une matrice RAID ou en allouant plus d’espace de stockage, analysez la taille de disque soigneusement afin d’éviter de manquer d’espace.

Valider et surveiller les performances de stockage et de SQL Server

Vérifiez que les performances et la solution de sauvegarde sur votre équipement vous permet de répondre aux exigences de votre contrat de niveau de service. Plus précisément, testez le sous-système d’E/S de l’ordinateur exécutant SQL Server pour vérifier que les performances sont satisfaisantes.

Testez la solution de sauvegarde en vigueur pour vous assurer qu’elle est capable de sauvegarder le système dans la fenêtre de maintenance disponible. Si les exigences de votre contrat de niveau de service ne sont pas satisfaites, pensez à utiliser une solution de sauvegarde incrémentielle telle que System Center Data Protection Manager (DPM) 2010.

Il est important de suivre les composants de ressources suivants sur les serveurs exécutant SQL Server : processeur, mémoire, taux d’accès au cache et sous-système d’E/S. Si des composants semblent lents ou surchargés, analysez la stratégie à adopter en fonction de la charge de travail actuelle et à venir. Pour plus d’informations, voir Résolution des problèmes de performances dans SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkID=168448).

La section suivante répertorie les compteurs de performances que nous recommandons pour analyser les performances des bases de données SQL Server exécutées dans votre environnement SharePoint Server 2010. Des valeurs intègres sont également indiquées pour chaque compteur.

Pour plus d’informations sur l’analyse des performances et l’utilisation des compteurs de performances, voir Guide de prise en main de l’analyse des performances (https://go.microsoft.com/fwlink/p/?LinkId=189032).

Compteurs SQL Server à surveiller

Surveillez les compteurs SQL Server suivants pour vous assurer de l’intégrité de vos serveurs :

• Statistiques générales   Cet objet fournit les compteurs permettant d’analyser l’activité générale au niveau du serveur, notamment le nombre de connexions actuelles et le nombre d’utilisateurs se connectant et se déconnectant par seconde d’ordinateurs exécutant une instance de SQL Server. Pensez à surveiller le compteur suivant :

  • Connexions utilisateur   Cet compteur indique le volume de connexions utilisateur sur votre ordinateur exécutant SQL Server. Si vous constatez que ce nombre a augmenté de 500 % par rapport à votre ligne de base, une baisse des performances pourrait se faire ressentir.

• Bases de données   Cet objet fournit des compteurs pour analyser les opérations de copie en bloc, le débit des sauvegardes et des restaurations, ainsi que l’activité des journaux des transactions. Surveillez les transactions et le journal des transactions pour déterminer l’intensité de l’activité de l’utilisateur dans la base de données et le taux de remplissage du journal des transactions. Le volume d’activité de l’utilisateur peut déterminer les performances de la base de données et affecter la taille du journal, le verrouillage et la réplication. La surveillance de l’activité du journal de bas niveau afin de mesurer l’activité de l’utilisateur et l’exploitation des ressources peut permettre d’identifier les goulots d’étranglement des performances. Pensez à surveiller le compteur suivant :

  • Transactions/s   Ce compteur indique le volume de transactions effectuées sur une base de données spécifique ou sur le serveur entier par seconde. Ce nombre est surtout utile à titre de référence et dans le cadre de la résolution des problèmes.

• Verrous   Cet objet fournit des informations sur les verrous SQL Server sur des types de ressources individuels. Pensez à contrôler les compteurs suivants :

  • Temps d’attente moyen (ms)   Ce compteur affiche le temps d’attente moyen pour chaque demande de verrouillage qui a provoqué une attente.

  • Temps d’attente des verrous (ms)   Ce compteur affiche le temps d’attente des verrous au cours de la dernière seconde.

  • Attentes de verrous/s   Ce compteur affiche le nombre de verrous par seconde ne pouvant pas être satisfaits immédiatement et devant attendre des ressources.

  • Nombre d’interblocages/s   Ce compteur affiche le nombre d’interblocages sur l’ordinateur exécutant SQL Server par seconde. Ce nombre ne doit pas être supérieur à 0.

• Verrous internes   Cet objet fournit les compteurs permettant de surveiller les verrous de ressources SQL Server internes appelés verrous. L’analyse des verrous pour déterminer l’activité des utilisateurs et l’utilisation des ressources peut vous aider à identifier les goulots d’étranglement de performance. Pensez à analyser les comptes suivants :

  • Temps d’attente moyen d’un verrou interne (ms)   Ce compteur affiche le temps d’attente moyen d’un verrou pour les demandes en attente.

  • Attentes de verrous internes/s   Ce compteur affiche le nombre de demandes de verrous ne pouvant pas être satisfaites immédiatement.

• Statistiques SQL   Cet objet fournit les compteurs pour l’analyse de la compilation et du type de demandes envoyées à une instance de SQL Server. L’analyse du nombre de compilations et recompilations des requêtes ainsi que le nombre de lots reçus par une instance de SQL Server vous donne une indication de la vitesse à laquelle SQL Server traite les requêtes et de l’efficacité avec laquelle l’optimiseur de requêtes traite les requêtes. Pensez à analyser les compteurs suivants :

  • Compilations SQL/s   Ce compteur indique le nombre de saisies du chemin d’accès du code de compilation par seconde.

  • Recompilations SQL/s   Ce compteur indique le nombre de recompilations des instructions par seconde.

• Gestionnaire de tampons   Cet objet fournit des compteurs permettant de surveiller l’utilisation de la mémoire par SQL Server pour stocker des pages de données, des structures de données internes et le cache de procédures, ainsi que des compteurs permettant de surveiller les E/S physiques lorsque SQL Server lit et écrit des pages de bases de données. Pensez à surveiller le compteur suivant :

  • Taux d’accès au cache des tampons

  • Ce compteur affiche le pourcentage de pages trouvées dans le cache des tampons sans avoir eu à lire sur le disque. Le ratio correspond au nombre total d’accès au cache divisé par le nombre total de recherches dans le cache lors des mille derniers accès aux pages. Étant donné que la lecture dans le cache est beaucoup moins coûteuse que la lecture sur le disque, vous souhaitez que ce rapport soit élevé. En règle générale, vous pouvez augmenter le taux d’accès au cache des tampons en augmentant la quantité de mémoire disponible pour SQL Server.

• Plan Cache   Cet objet fournit des compteurs qui permettent de surveiller l’utilisation de la mémoire par SQL Server pour stocker des objets tels que des procédures stockées, des instructions Transact-SQL ad hoc et préparées ainsi que des déclencheurs. Pensez à surveilleur le compteur suivant :

  • Taux d’accès au cache

  • Ce compteur indique le rapport entre les accès au cache et les recherches de plans.

Compteurs de serveur physique à surveiller

Surveillez les compteurs suivants pour vous assurer de l’intégrité de vos ordinateurs exécutant SQL Server:

• Processeur : Pourcentage de temps processeur : _Total   Ce compteur indique le pourcentage de temps que le processeur consacre à l’exécution de processus d’application ou de système d’exploitation, à l’exclusion des processus inactifs. Sur l’ordinateur qui exécute SQL Server, ce compteur doit être maintenu entre 50 et 75 %. En cas de surcharge constante, déterminez s’il existe une activité de processus anormale ou si le serveur a besoin d’UC supplémentaires.

• Système : Longueur de la file du processeur   Ce compteur indique le nombre de threads dans la file du processeur. Surveillez ce compteur afin que sa valeur demeure inférieure à deux fois le nombre d’UC principales.

• Mémoire : Mégaoctets disponibles   Ce compteur indique la quantité de mémoire physique, en mégaoctets, disponible pour les processus en cours d’exécution sur l’ordinateur. Surveillez ce compteur de manière à ce que le niveau de mémoire RAM physique disponible soit au moins égal à 20 %.

• Mémoire : Pages/s   Ce compteur indique le taux auquel les pages sont lues à partir du disque et écrites sur celui-ci pour faciliter la résolution des défauts des pages matérielles. Surveillez ce compteur de manière à ce que sa valeur demeure inférieure à 100.

Pour plus d’informations et des méthodes de résolution des problèmes liés à la mémoire, voir Surveillance de l’utilisation de la mémoire SQL Server 2005 (https://go.microsoft.com/fwlink/p/?LinkID=105585).

Compteurs de disques à surveiller

Surveillez les compteurs suivants pour vous assurer de l’intégrité des disques. Notez que les valeurs suivantes représentent des valeurs mesurées dans le temps et non des valeurs correspondant à des pics d’activité soudains ou à des valeurs basées sur une seule mesure.

• Disque physique : Pourcentage du temps disque : lecteur de données   Ce compteur indique le pourcentage de temps écoulé que le lecteur de disque sélectionné consacre à traiter les demandes de lecture ou d’écriture. C’est un indicateur général de l’occupation du disque. Si le compteur Disque physique : Pourcentage du temps disque est élevé (plus de 90 %), vérifiez le compteur Disque physique : Longueur actuelle de la file d’attente du disque pour afficher le nombre de demandes système en attente de l’accès au disque. Le nombre de demandes d’E/S en attente doit demeurer inférieur à 1,5 ou 2 fois le nombre de piles constituant le disque physique.

• Disque logique : Transferts disque/s   Ce compteur indique le taux auquel les opérations de lecture et d’écriture sont réalisées sur le disque. Utilisez ce compteur pour surveiller les tendances de croissance et effectuer des prévisions en conséquence.

• Disque logique : Lectures disque, octets/s et Disque logique : Écritures disque, octets/s   Ces compteurs indiquent le taux de transfert des octets à partir du disque pendant les opérations de lecture ou d’écriture.

• Disque logique : Moyenne disque, octets/lecture   Ce compteur indique le nombre moyen d’octets transférés à partir du disque pendant les opérations de lecture. Cette valeur peut refléter la latence de disque : plus les opérations de lecture sont importantes, plus la latence est susceptible d’augmenter légèrement.

• Disque logique : Moyenne disque, octets/écriture   Ce compteur indique le nombre moyen d’octets transférés vers le disque pendant les opérations d’écriture. Cette valeur peut refléter la latence de disque : plus les opérations d’écriture sont importantes, plus la latence est susceptible d’augmenter légèrement.

• Disque logique : Taille de file d’attente du disque actuelle   Ce compteur indique le nombre de demandes qui sont en attente sur le disque au moment où les données de performances sont collectées. Pour ce compteur, plus les valeurs sont petites, plus la situation est convenable. Les valeurs supérieures à 2 par disque peuvent indiquer un goulot d’étranglement et doivent être analysées. Cela signifie qu’une valeur inférieure à égale à 8 peut être acceptable pour un LUN composé de 4 disques. Les goulots d’étranglement peuvent créer un journal des travaux en souffrance qui peut s’étendre au-delà du serveur qui accède actuellement au disque et se traduire par de longs temps d’attente pour les utilisateurs. Pour résoudre un goulot d’étranglement, vous pouvez ajouter des disques à la matrice RAID, remplacer les disques existants par des disques plus rapides ou déplacer une partie des données vers d’autres disques.

• Disque logique : Longueur moyenne de file d’attente du disque   Ce compteur indique le nombre moyen de demandes de lecture et d’écriture qui ont été mises en file d’attente pour le disque sélectionné pendant l’intervalle d’échantillonnage. La règle est qu’il doit y avoir au plus deux demandes de lecture et d’écriture en attente par pile, mais cela peut s’avérer difficile à mesurer en raison de la virtualisation du stockage et des différences de niveaux RAID entre les configurations. Recherchez s’il existe à la fois des longueurs de file d’attente du disque supérieures à la moyenne et des latences de disque supérieures à la moyenne. Si tel est le cas, il est possible que le cache du groupe de stockage soit surutilisé ou que le partage des piles avec d’autres applications affecte les performances.

• Disque logique : Moyenne disque s/lecture et Disque logique : Moyenne disque s/écriture Ces compteurs indiquent le temps moyen, en secondes, d’une opération de lecture ou d’écriture sur le disque. Surveillez-les pour vérifier que leurs valeurs demeurent inférieures à 85 % de la capacité du disque. Le temps d’accès au disque augmente de manière exponentielle si les opérations de lecture ou d’écriture représentent plus de 85 % de la capacité du disque. Pour déterminer la capacité propre à votre configuration matérielle, reportez-vous à la documentation du fournisseur ou utilisez l’outil d’évaluation du sous-système de disque SQLIO, qui permet de calculer cette capacité. Pour plus d’informations, voir Outil d’évaluation du sous-système de disque SQLIO (https://go.microsoft.com/fwlink/p/?LinkID=105586).

  • Disque logique : Moyenne disque s/lecture   Ce compteur indique le temps moyen, en secondes, d’une opération de lecture à partir du disque. Sur un système correctement configuré, les valeurs idéales sont comprises entre 1 et 5 millisecondes (ms) pour les journaux (idéalement 1 ms sur une matrice mise en cache) et entre 4 et 20 ms pour les données (idéalement moins de 10 ms). Des latences élevées peuvent se produire pendant les périodes de pointe, mais si vous constatez des valeurs élevées régulièrement, vous devez en déterminer la cause.

  • Disque logique : Moyenne disque s/écriture   Ce compteur indique le temps moyen, en secondes, d’une opération d’écriture sur le disque. Sur un système correctement configuré, les valeurs idéales sont comprises entre 1 et 5 ms pour les journaux (idéalement 1 ms sur une matrice mise en cache) et entre 4 et 20 ms pour les données (idéalement moins de 10 ms). Des latences élevées peuvent se produire pendant les périodes de pointe, mais si vous constatez des valeurs élevées régulièrement, vous devez en déterminer la cause.

  Lorsque vous utilisez des configurations RAID avec les compteurs Disque logique : Moyenne disque, octets/lecture ou Disque logique : Moyenne disque, octets/écriture, utilisez les formules répertoriées dans le tableau suivant pour déterminer le taux d’entrée et de sortie sur le disque.

  Niveau RAID	Formule
  RAID 0	E/S par disque = (lectures + écritures) / nombre de disques
  RAID 1	E/S par disque = [lectures + (2 * écritures)] / 2
  RAID 5	E/S par disque = [lectures + (4 * écritures)] / nombre de disques
  RAID 10	E/S par disque = [lectures + (2 * écritures)] / nombre de disques

  Supposons que vous disposez d’un système RAID 1 doté de deux disques physiques et que vos compteurs affichent les valeurs indiquées dans le tableau suivant.

  Compteur	Valeur
  Moyenne disque s/lecture	80
  Disque logique: Moyenne disque s/écriture	70
  Longueur moyenne de file d’attente du disque	5

  La valeur d’E/S par disque peut être calculée comme suit : (80 + (2 × 70))/2 = 110

  La longueur de file d’attente du disque peut être calculée comme suit : 5/2 = 2,5

  Cette valeur indique la présence d’un goulot d’étranglement d’E/S en formation.

Autres outils d’analyse

Vous pouvez également surveiller la latence de disque et analyser les tendances à l’aide de la vue de gestion dynamique sys.dm_io_virtual_file_stats disponible dans SQL Server 2008. Pour plus d’informations, voir sys.dm_io_virtual_file_stats (Transact-SQL) (https://go.microsoft.com/fwlink/p/?LinkID=105587).

See Also

Other Resources

Centre de ressources : Gestion de la performance et de la capacité (SharePoint Server 2010)
Centre de ressources : Gestion des bases de données (SharePoint Server 2010)