Partager via

Meilleures pratiques pour SQL Server 2008 dans une batterie de serveurs SharePoint Server 2010

  • Article

 

S’applique à : SharePoint Server 2010

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

Cet article décrit les meilleures pratiques pour la configuration et la maintenance de Microsoft SQL Server 2008 dans un environnement Microsoft SharePoint Server 2010. Ces pratiques sont présentées selon l’ordre dans lequel elles seraient appliquées (installation et configuration de SQL Server 2008, déploiement de SharePoint Server, puis maintenance de la batterie de serveurs).

Cet article appartient à une série d’articles Meilleures pratiques consacrés à SharePoint Server. Pour connaître les autres articles de cette série, voir Meilleures pratiques (SharePoint Server 2010). Pour obtenir plus d’informations et de ressources relatives aux meilleures pratiques pour SharePoint Server 2010, voir le Centre de ressources des meilleures pratiques (https://go.microsoft.com/fwlink/?linkid=220280&clcid=0x40C) (éventuellement en anglais).

1. Utilisez un serveur dédié pour SQL Server 2008

Pour garantir des performances optimales pour les opérations liées aux batteries de serveurs, nous vous recommandons d’installer SQL Server 2008sur un serveur dédié qui n’exécute aucun autre rôle de batterie et n’héberge pas de bases de données pour une autre application quelconque. La seule exception est si vous déployez SharePoint Server 2010 sur un serveur autonome, ce qui est déconseillé dans des environnements de production à grande échelle.

Notes

La recommandation d’utiliser un serveur dédié pour la base de données s’applique également dans un environnement où SQL Server 2008 est virtualisé.

2. Configurez des paramètres SQL Server 2008 spécifiques avant de déployer SharePoint Server 2010

Pour garantir un déroulement et des performances homogènes, configurez les options et les paramètres suivants avant de déployer SharePoint Server 2010.

  • N’activez pas l’outil de création automatique des statistiques sur un serveur SQL Server prenant en charge SharePoint Server.

  • Définissez le degré maximal de parallélisme (MAXDOP) à 1 pour les instances SQL Server qui hébergent les bases de données SharePoint Server 2010 pour vous assurer que chaque demande est traitée par un processus SQL Server unique.

    Important

    Dans un environnement SharePoint Server, tous les autres paramètres aboutiront à la sélection d’un plan de requêtes non optimal qui sera exécuté, entraînant une diminution des performances globales.

  • Pour améliorer le confort de maintenance et faciliter le déplacement de la base de données si cela est nécessaire par la suite, configurez les alias de connexion SQL Server pour chaque serveur de base de données dans votre batterie.

Pour plus d’informations, voir Définir les options SQL Server.

3. Consolidez le serveur de base de données avant de déployer SharePoint Server 2010

Nous vous conseillons de planifier une consolidation du serveur de base de données avant de déployer SharePoint Server 2010. Cette opération implique de sécuriser le rôle serveur de base de données pour SharePoint Server et SQL Server. Pour plus d’informations, voir :

4. Configurez les serveurs de base de données pour des raisons de performance et de disponibilité

Comme pour les serveurs Web et les serveurs d’applications, la configuration des serveurs de base de données affectent le degré de performance et de fonctionnement de SharePoint Server 2010. Certaines bases de données exigent une colocalisation ou une séparation avec les autres bases de données. Pour plus d’informations, voir :

Pour les bases de données à haute disponibilité utilisant la mise en miroir, reportez-vous aux conseils de l’article Meilleures pratiques et considérations sur les performances de la mise en miroir de bases de données (https://go.microsoft.com/fwlink/?linkid=185119&clcid=0x40C) (éventuellement en anglais).

5. Concevez votre solution de stockage dans une optique de rendement optimal et de facilité de gestion

Nous vous recommandons de séparer et de définir en priorité vos données sur les disques du serveur de base de données. L’idéal est de 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 qui suit décrit certaines des meilleures pratiques et des recommandations à suivre pour donner la priorité aux données et aux journaux et les gérer. Pour plus d’informations, voir Configurer les bases de données.

  • Pour les sites de collaboration ou les sites exigeants en termes de mises à jour, respectez l’ordre suivant pour la distribution du contenu de stockage :

    1. Fichier de données et journaux des transactions tempdb sur les disques les plus rapides

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

    3. Bases de données de recherche, à l’exception de la base de données Administration de la recherche

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

  • Sur le site d’un portail fortement orienté vers l’accès en lecture, suivez cet ordre pour donner davantage la priorité aux données et à la recherche qu’aux journaux des transactions :

    1. Fichier de données et journaux des transactions tempdb sur les disques les plus rapides

    2. Fichiers de données de la base de données de contenu

    3. Bases de données de recherche, à l’exception de la base de données Administration de la recherche

    4. Fichiers journaux des transactions de la base de données de contenu

  • Des tests et des données utilisateur montrent que les performances globales des batteries de serveurs peuvent grandement être compromises par une consommation insuffisante au niveau des E/S de disque dans le cadre de la base de données tempdb. Pour éviter ce problème, allouez des disques dédiés à la base de données tempdb.

  • Pour garantir les meilleures performances, placez la base de données sur un contrôleur RAID 10. Le nombre de fichiers de données tempdb doit être égal au nombre d’UC principales et les fichiers de données tempdb eux-mêmes doivent être définis avec une taille égale.

  • Séparez les données de la base de données et les fichiers journaux des transactions sur différents disques. Si les fichiers doivent partager des disques parce qu’ils sont trop petits pour tenir sur une bande ou un disque tout entier, ou si vous être confronté à une pénurie d’espace disque, mettez les fichiers qui affichent des modèles d’utilisation différents sur le même disque afin de réduire le nombre de demandes d’accès simultanés.

  • Utilisez plusieurs fichiers de données pour des bases de données de contenu à fort taux d’utilisation, chacun sur leur propre disque.

  • Pour améliorer et faciliter la gestion, limitez la taille de la base de données de contenu à 50 Go

Une configuration en bonne et due forme des sous-systèmes d’E/S est primordiale pour garantir des performances et un fonctionnement optimaux des systèmes SQL Server. Pour plus d’informations, voir Storage Top 10 Best Practices

6. Gérez de manière proactive la croissance des données et des fichiers journaux

Nous vous recommandons de gérer de manière proactive la croissance des données et des fichiers journaux en tenant compte des recommandations suivantes :

  • Si cela est possible, augmentez au préalable l’ensemble des fichiers de données et des fichiers journaux vers leur taille finale prévue, ou augmentez-les de manière périodique à des moments définis (par exemple, tous les mois ou tous les six mois ou avant le lancement d’un nouveau site à fort volume de stockage, notamment lors de la migration des fichiers).

  • Nous vous recommandons d’activer la fonction de croissance automatique des bases de données en guise de mesure de protection pour vous assurer que vous ne manquez pas d’espace pour les fichiers de données et les journaux. Tenez compte des éléments suivants :

    Important

    Vous devez prendre en compte les problèmes de performance et opérationnels associés à l’utilisation de la croissance automatique. Pour plus d’informations, voir Éléments à prendre en compte pour les paramètres de « croissance automatique » et de « réduction automatique » dans SQL Server (https://go.microsoft.com/fwlink/?linkid=117750&clcid=0x40C)

    • Ne vous fiez pas aux paramètres par défaut de la croissance automatique ; suivez les instructions fournies dans la section Définir les options SQL Server.

    • Définissez les valeurs de croissance automatique sous forme de pourcentage et non sous la forme d’un nombre fixe de mégaoctets. Plus la base de données est volumineuse, plus la valeur d’incrément de croissance doit être importante.

      Prenons l’exemple d’un scénario dans lequel le contenu est graduellement augmenté par incréments de 100 Mo avec une croissance automatique définie à 10 Mo. Un très fort volume de stockage de données est ensuite soudainement requis pour un nouveau site de gestion des documents avec peut-être une taille de départ de 50 Go ; la capacité de croissance devrait alors se mesurer en incréments de 500 Mo et non plus de 10 Mo.

    • Pour un système de production géré, vous devez envisager la croissance automatique comme un simple plan d’urgence en cas de croissance inattendue. N’utilisez pas l’option de croissance automatique pour gérer la croissance de vos données et de vos journaux au quotidien.

  • Maintenez un niveau d’espace disque disponible de 25 % sur les disques afin d’anticiper les modèles de croissance et d’utilisation maximale. Si vous gérez votre croissance en ajoutant des disques à un contrôleur RAID ou en allouant un plus grand volume de stockage, surveillez de près la taille des disques pour éviter de manquer d’espace.

7. Surveillez en permanence le stockage et les performances de SQL Server

Nous vous recommandons de surveiller continuellement le stockage et les performances de SQL Server pour vous assurer que le serveur de base de données de production gère de manière adéquate la charge qui y est placée. De même, une surveillance continue vous permet d’établir des points de référence (benchmarks) qui peuvent vous être utiles pour la planification des ressources.

Adoptez une approche holistique de la surveillance des ressources ; ne la limitez pas aux ressources propres à SQL Server. Il est également primordial de surveiller les composants de ressources suivants d’un serveur doté de SQL Server : UC, mémoire, taux d’accès au cache, et sous-système d’E/S.

Lorsqu’un ou plusieurs des composants du serveur de base de données apparaissent ralentis ou surchargés, analysez la stratégie adéquate en vous basant sur la charge de travail actuelle et prévisionnelle. Pour plus d’informations, voir :

8. Utilisez la fonction de compression de la sauvegarde pour accélérer les sauvegardes et réduire la taille des fichiers

La compression de la sauvegarde peut accélérer toute sauvegarde dans SharePoint est est disponible dans SQL Server 2008 Enterprise Edition ou SQL Server 2008 R2 Standard Edition. En définissant l’option de compression dans votre script de sauvegarde ou en configurant le serveur qui exécute SQL Server pour une compression par défaut, vous pouvez considérablement réduire la taille des sauvegardes de vos bases de données et des journaux transmis. Pour plus d’informations, voir Compression de sauvegardes (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x40C) et Compression des données : stratégie, planification de la capacité et meilleures pratiques (https://go.microsoft.com/fwlink/?linkid=223674&clcid=0x40C) (éventuellement en anglais).

Remerciements

L’équipe de publication de contenu SharePoint Server 2010 remercie les personnes suivantes pour leur contribution à la rédaction cet article :

  • Stephen Dillon, Consultant senior

  • Gus Apostal, Responsable de programme senior, SQL Server