Recommandations pour la topologie physique (Office SharePoint Server)

Mise à jour : 2009-11-05

La topologie de la couche base de données du système, mais également le réseau, le stockage physique et la mise en cache peuvent affecter considérablement les performances du système. Lorsque vous planifiez votre matériel, n’oubliez pas que Microsoft Office SharePoint Server 2007 est la dernière version d’Office SharePoint Server qui s’exécute sur les systèmes d’exploitation et les bases de données 32 bits. Cet article décrit essentiellement les améliorations que vous pouvez apporter lorsque le système s’exécute sur Microsoft SQL Server 2008.

Important :
Si vous utilisez la méthode de la mise à niveau progressive, pour conserver des temps de réponse acceptables de la part du serveur exécutant SQL Server 2008, il peut s’avérer nécessaire de multiplier au moins par deux les ressources SQL Server qui prennent en charge Office SharePoint Server 2007.

Les sections suivantes fournissent des conseils basés sur les meilleures pratiques que nous avons déterminées pour les bases de données SQL Server 2005 hébergeant Office SharePoint Server 2007.

Démarrer avec un serveur dédié exécutant SQL Server 2008

Les recommandations suivantes s’appliquent à la couche base de données de votre topologie :

• Placez toujours SQL Server 2008 sur un serveur dédié qui n’exécute aucun autre rôle de batterie de serveurs ou qui n’héberge de bases de données pour aucune autre application, sauf si vous déployez votre système sur un serveur autonome.

• Nous vous recommandons vivement d’installer la version 64 bits de SQL Server 2005 sur un système d’exploitation 64 bits, à moins qu’une raison professionnelle importante vous amène à ne pas le faire.

• Pour obtenir des performances optimales, utilisez Office SharePoint Server 2007 avec SQL Server 2008 et le Service Pack le plus récent, à moins que votre activité justifie l’utilisation d’une version antérieure.

• Utilisez des alias de connexion SQL Server lorsque vous configurez votre batterie de serveurs. Un alias de connexion est un nom de substitution qui permet d’établir une connexion à une instance SQL Server. Si un serveur de bases de données échoue, vous pouvez ajuster l’alias sur le serveur Web frontal afin qu’il pointe vers un autre serveur. Pour plus d’informations, voir Procédure : définir un alias SQL Server (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=132064&clcid=0x40C).

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

Envisager une montée en puissance parallèle en plus de l’ajout de ressources

Il est important de suivre les trois composants de ressources suivants d’un serveur exécutant SQL Server 2008 : le processeur, la mémoire et le sous-système d’E/S. Lorsqu’un ou plusieurs des composants semblent utilisés au maximum, analysez le mode d’action approprié en fonction de la charge de travail actuelle et prévisionnelle. Ensuite, déterminez s’il faut ajouter des ressources ou procéder à une montée en puissance parallèle vers un nouveau serveur exécutant SQL Server 2008. En règle générale, il est recommandé d’envisager une montée en puissance parallèle en plus d’ajouter des ressources. Pour plus d’informations, voir Résolution des problèmes liés aux performances dans SQL Server 2008 (en anglais) (https://go.microsoft.com/fwlink/?linkid=168448&clcid=0x40C) (en anglais).

Nous vous recommandons de déployer un serveur supplémentaire exécutant SQL Server 2008 lorsque plus de quatre serveurs Web fonctionnent à leur capacité maximale.

Suivre les instructions SQL Server lors du choix du matériel

Les sections suivantes contiennent des recommandations de l’équipe de développement de SQL Server 2008 au sujet de la configuration matérielle susceptible d’optimiser les performances d’Office SharePoint Server 2007.

Mémoire

Pour déterminer la quantité de mémoire requise pour les ordinateurs exécutant SQL Server 2008, évaluez d’abord la taille du déploiement planifié (petit, moyen ou grand) en termes de consommation de mémoire.

Déterminez la taille du déploiement à l’aide du tableau suivant :

• Si vos paramètres de déploiement sont généralement inférieurs aux valeurs répertoriées, le déploiement peut être considéré petit.

• Si vos paramètres de déploiement sont plus ou moins équivalents aux valeurs répertoriées, le déploiement peut être considéré moyen.

• Si vos paramètres de déploiement sont généralement supérieurs aux limites supérieures de la plupart des valeurs répertoriées, le déploiement peut être considéré grand.

Pour SQL Server 2008, la mémoire requise minimale est de 4 gigaoctets (Go), tandis que les quantités recommandées sont respectivement de 8 Go et d’au moins 16 Go pour les déploiements de taille moyenne et les déploiements de grande taille.

D’autres facteurs pouvant influer sur les besoins en termes de mémoire sont les suivants :

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

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

Cache processeur

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.

Bande passante du bus

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.

La liste suivante fournit une série de meilleures pratiques et de recommandations permettant d’optimiser la bande passante du bus.

• Pour les serveurs de taille moyenne à grande, plus la bande passante du bus est grande, meilleure est la fiabilité du système, en particulier avec un logiciel de gestion multivoie supplémentaire. À l’inverse, une plus grande bande passante du bus ne renforce pas de manière significative la fiabilité des systèmes plus petits. La fiabilité de la bande passante du bus est améliorée grâce à l’utilisation de voies redondantes dans le système et d’une configuration évitant les points de défaillance uniques dans les périphériques matériels.

• Plus la bande passante du bus est élevée, meilleures sont les performances des systèmes qui utilisent des transferts de blocs volumineux et effectuent des opérations d’E/S séquentielles fréquemment.

• Dans les serveurs plus petits qui effectuent principalement des opérations d’E/S séquentielles, la configuration PCI devient un goulet d’étranglement avec trois disques. Dans le cas d’un petit serveur possédant huit disques qui effectuent essentiellement des opérations d’E/S aléatoires, la configuration PCI est suffisante. Toutefois, il est plus courant de recourir à une configuration PCI-X sur les serveurs de taille petite à très volumineuse.

• Il est nécessaire d’utiliser une bande passante du bus élevée pour prendre en charge un grand nombre de disques.

• La capacité de la bande passante du bus peut être limitée par la topologie du système. Si le système utilise des disques directement connectés, le nombre d’emplacements limite la capacité de la bande passante du bus. Toutefois, dans le cas des systèmes de réseau de stockage (SAN, Storage Area Network), il n’existe aucun facteur de limite physique.

• Les serveurs plus onéreux offrent généralement des bus plus larges et plus rapides. Il est souvent impossible d’augmenter la capacité de la bande passante des bus sans remplacer les serveurs. Toutefois, il est plus facile de configurer les serveurs de plus grande taille. Pour connaître les spécifications, contactez les fournisseurs de serveurs.

Interfaces de disque et SAN

Les interfaces que vous utilisez dans votre système peuvent affecter la fiabilité et les performances. À configuration égale, plus les lecteurs sont grands, plus le temps d’accès est long. Utilisez les informations du tableau suivant pour choisir l’interface.

Redondance de base de données dans un centre de données

Vous devez fournir la redondance, quel que soit le type de stockage dans un centre de données.

• Pour un réseau SAN ou pour les disques partagés, le clustering est la technologie la plus courante et la plus économique. Les produits et technologies SharePoint prennent en charge en mode natif l’utilisation de clusters, qui sont disponibles dans SQL Server 2008 édition Standard. Les équipes en charge des opérations peuvent constater que le clustering offre une solution de disponibilité familière. Pour plus d’informations, voir Configurer la disponibilité dans une seule batterie de serveurs à l’aide du clustering de SQL Server (https://go.microsoft.com/fwlink/?linkid=168606&clcid=0x40C).

• Pour les disques dédiés ou le support de stockage à connexion directe (DAS), vous pouvez utiliser la mise en miroir de base de données SQL Server 2008. Par défaut, SharePoint ne prend pas en charge la mise en miroir de base de données. Pour modifier les connexions en cas de basculement d’un miroir, il est recommandé d’utiliser un alias client SQL Server et de gérer manuellement le processus de basculement en modifiant l’alias afin qu’il pointe vers le partenaire de basculement. Pour plus d’informations, voir Utilisation de la mise en miroir avec Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=83725&clcid=0x40C) (en anglais).

Redondance de base de données entre plusieurs centres de données

Les données stockées selon la technologie SAN ou DAS peuvent être mises en miroir ou répliquées de manière à répondre aux exigences de continuité de l’activité, mais la technique de mise en miroir diffère comme suit :

• La plupart des fournisseurs SAN fournissent la mise en miroir des données entre plusieurs sites.

• Dans la plupart des scénarios reposant sur la technologie DAS, une méthode de réplication logicielle est requise ; cette méthode est mise à disposition par le fournisseur ou activée par le biais de technologies telles que la mise en miroir de base de données ou la copie des journaux de transaction.

  Si vous choisissez d’utiliser la mise en miroir asynchrone, SharePoint peut tirer parti de la fonctionnalité de compression de flux de journal SQL Server 2008 et, si vous exécutez SQL Server 2008 édition Enterprise, peut également tirer parti de la possibilité d’utiliser un thread de restauration supplémentaire par base de données pour chaque groupe de quatre cœurs dans le système. Pour plus d’informations, voir :

  • Planifier la disponibilité (Office SharePoint Server)

  • Configurer la récupération d’urgence dans les batteries de serveurs SharePoint à l’aide de la copie des journaux de transaction SQL Server

  • Intégration de SQL Server 2008 et d’Office SharePoint Server 2007

Remarque :

Certaines technologies SQL Server 2008, telles que la réplication transactionnelle, ne peuvent pas être utilisées avec les produits et technologies SharePoint, car la technologie de réplication suppose qu’une base de données possède une colonne de clé primaire sur toutes les tables. Avant d’implémenter une technologie de réplication, assurez-vous qu’elle est prise en charge pour SQL Server 2008 et Office SharePoint Server 2007.

Les technologies de capture instantanée permettent de prendre des captures instantanées dans le temps des données hébergées sur un réseau SAN. La technologie DAS, dans la plupart des cas, n’offre pas les logiciels et services supplémentaires permettant la prise en charge des captures.

La prise en charge des technologies telles que Microsoft System Center Data Protection Manager 2007 permet de fournir une protection supplémentaire pour Microsoft SQL Server et les produits et technologies SharePoint Microsoft Office. Microsoft System Center Data Protection Manager 2007 permet la protection des données basées sur le disque et sur bande et la récupération des serveurs dans et entre les domaines Active Directory®. Pour plus d’informations sur Microsoft System Center Data Protection Manager 2007, voir le site Web Microsoft System Center Data Protection Manager 2007 (en anglais) (https://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx) (en anglais).

Performances

Pour les technologies DAS et SAN, les catégories de performances suivantes doivent être mesurées :

• E/S par seconde

• Mégaoctets par seconde

• Latence

Étant donné que de nombreux facteurs influent sur les performances des environnements DAS et SAN, il est impossible de proposer de simples recommandations. Parmi ces facteurs citons les pilotes, la configuration, les technologies sous-jacentes et de prise en charge, ainsi que les adaptateurs de bus hôte.

L’utilisation d’un commutateur de type Fibre Channel peut s’avérer bénéfique pour les environnements SAN, car la technologie Fibre Channel peut fournir plusieurs liaisons par le biais de l’ensemble fibre optique et, par conséquent, activer le parallélisme des chemins d’E/S afin que le réseau SAN puisse traiter les demandes d’E/S plus efficacement.

Il est très important que la latence soit minimale sur le sous-système d’E/S au service du serveur exécutant SQL Server. Une réponse lente de la part du sous-système d’E/S ne peut pas être compensée par l’ajout d’autres types de ressources, telles qu’une UC ou de la mémoire, mais peut avoir un impact sur l’ensemble de la batterie de serveurs et engendrer des problèmes dans celle-ci. Planifiez une latence minimale avant le déploiement et surveillez vos systèmes existants comme indiqué dans Surveiller les performances de stockage et résoudre les problèmes liés à celles-ci.

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 2008 (latence inférieure ou égale à 1 milliseconde (ms)).

• Il n’est pas recommandé d’utiliser une topologie de réseau étendu (WAN) dans laquelle un serveur exécutant SQL Server 2008 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 2008 ou la copie des journaux de transaction SQL Server 2008 pour maintenir un site distant à jour.

• Envisagez d’utiliser la fonctionnalité de compression de sauvegarde de SQL Server 2008 édition Enterprise. En définissant l’option de compression dans votre script de sauvegarde ou en configurant le serveur d’applications exécutant SQL Server 2008 édition Enterprise de manière à ce qu’il comprime par défaut, vous pouvez diminuer sensiblement la taille des sauvegardes de base de données et des journaux de transaction copiés. Pour plus d’informations, voir Compression de sauvegardes (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x40C).

  Remarque :
  La compression de base de données n’est pas prise en charge pour les produits et technologies SharePoint.

Topologie de disque

La topologie de disque que vous utilisez dans votre système peut affecter la fiabilité et les performances.

Vous devez réduire au minimum la latence du sous-système d’E/S au service du serveur exécutant SQL Server 2008. Il est impossible de compenser une réponse lente du sous-système d’E/S en ajoutant des types de ressources (par exemple, 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.

Utilisez les informations du tableau suivant pour choisir la topologie.

Télécharger ce livre

Cette rubrique est incluse dans le livre téléchargeable suivant pour une lecture et une impression plus faciles :

• Planification et architecture d’Office SharePoint Server 2007 – Seconde partie

Vous trouverez la liste complète des livres disponibles sur Contenu téléchargeable pour Office SharePoint Server 2007.