Planification de la disponibilité (Windows SharePoint Services)

Mise à jour : 2009-03-11

Cet article décrit la disponibilité en général, les coûts et les problèmes posés par la disponibilité dans un de produits et technologies SharePoint, ainsi que les stratégies et des solutions que vous pouvez utiliser dans cet environnement. Vous devez lire ce document si votre batterie de serveurs exécute Windows SharePoint Services 3.0 ou est un environnement de haute disponibilité avec Microsoft Office SharePoint Server 2007, Microsoft Office Forms Server 2007 ou Microsoft Search Server 2008. Vous pouvez télécharger et imprimer le modèle de disponibilité Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x40C (en anglais)) qui accompagne cet article. Ce modèle fournit un résumé en taille d'affichage du contenu dans cet article.

Remarque :
Cet article fait en partie référence à des fonctionnalités qui sont disponibles dans Office SharePoint Server 2007 uniquement, mais nous l'avons inclus car nous n'avons pas exclu que vous puissiez gérer un environnement dans lequel se trouvent à la fois Windows SharePoint Services 3.0 et Office SharePoint Server 2007.

Qu'est-ce que la disponibilité ?

La disponibilité est le degré de perception de la disponibilité par les utilisateurs d'un environnement des produits et technologies SharePoint. La vérification de la disponibilité consiste à vous assurer qu'un système 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 stratégies de disponibilité minimisent la perception par les utilisateurs des immobilisations prévues et imprévues.

L'une des mesures les plus courantes de la disponibilité est le pourcentage du temps de fonctionnement exprimé sous forme de nombre de neufs : il s'agit du pourcentage de temps pendant lequel un système donné est en service et fonctionne. Par exemple, un système avec un pourcentage de disponibilité égal à 99.999 est censé avoir une disponibilité de 5 neufs.

Le tableau ci-dessous établit la correspondance entre le nombre de neufs et les équivalents en durées calendaires.

Si vous pouvez établir une estimation censée du nombre total probable d'heures d'indisponibilité que vous pouvez rencontrer, vous pouvez utiliser les formules ci-dessous pour calculer le pourcentage du temps de fonctionnement annuel, mensuel et quotidien :

% Temps de fonctionnement/an = 100 \endash (8760 \endash nombre total d'heures d'indisponibilité par an) / 8760

% Temps de fonctionnement/mois = 100 \endash ((24 * nombre de jours dans le mois) \endash nombre total d'heures d'indisponibilité dans ce mois) / (24 * nombre de jours dans le mois)

% Temps de fonctionnement/semaine = 100 \endash (168 \endash nombre total d'heures d'indisponibilité dans cette semaine) / 168

Ce que la disponibilité ne signifie pas

La disponibilité n'est ni la protection et la récupération des données, ni la récupération d'urgence, même si ces concepts sont liés. Vous devez disposer de plans de récupération et de protection des données en cas d'urgence de données dans un système haute disponibilité. La protection et la récupération des données sont nécessaires dans la gestion générale sous-jacente d'une entreprise pour les cas suivants :

• conservation et possibilité d'examen de plusieurs versions d’un élément ou d’un site ;

• récupération d'éléments ou de sites supprimés accidentellement ;

• archivage des données pour des raisons légales, réglementaires ou pour les besoins de l'entreprise ;

• restauration des systèmes en cas de défaillances matérielles ou logicielles inattendues.

En outre, la disponibilité n'est pas la gestion du fonctionnement de l'entreprise (BCM). La gestion BCM se compose des prises de décision, des processus et des outils que vous mettez en place à l'avance afin de gérer des situations de crise. Une crise peut être un événement local, régional ou national ou peut concerner votre entreprise uniquement.

La disponibilité des produits et technologies SharePoint et les stratégies de protection des données peuvent faire partie de votre plan technique BCM, mais votre plan BCM global doit être beaucoup plus complet et inclure les éléments suivants :

• procédures clairement documentées

• stockage hors site des données professionnelles vitales

• contacts clairement désignés

• formation continue du personnel

• mécanismes de récupération hors site

Coûts de la disponibilité

La disponibilité est une des conditions les plus onéreuses d'un système. Plus le niveau de disponibilité est élevé et plus le nombre de systèmes que vous devez protéger est important, plus la solution de disponibilité sera probablement complexe et coûteuse. Lorsque vous investissez dans la disponibilité, les frais comprennent :

• le matériel et les logiciels supplémentaires, impliquant souvent des opérations complexes entre les logiciels, telles que des scripts personnalisés pour le basculement et la récupération ;

• la complexité opérationnelle supplémentaire.

Les coûts de la disponibilité doivent être évalués en fonction des besoins de votre entreprise : toutes les solutions au sein d'une organisation exigent probablement le même niveau de disponibilité. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, des services différents (par exemple, recherche et analyse décisionnelle) ou différentes batteries de serveurs.

La disponibilité constitue un élément essentiel pour lequel les groupes informatiques proposent des contrats de niveau de service pour définir les attentes avec les groupes de clients. De nombreuses entreprises informatiques proposent divers contrats de niveau de service correspondant à différents niveaux de facturation.

Remarque :
Lors du calcul de disponibilité, la plupart des entreprises ajoutent ou retirent des heures pour les activités de maintenance prévues.

Problèmes posés par la disponibilité pour les produits et technologies SharePoint

Un déploiement des produits et technologies SharePoint présente les problèmes de disponibilité suivants :

• Lorsque vous appliquez des correctifs ou que vous mettez à niveau la batterie de serveurs, celle-ci n'est pas disponible.

• La redondance des serveurs d'index n'est pas réalisable en installant le rôle d'index sur plusieurs serveurs. Pour résoudre la perte d'un serveur d'index, vous devrez réinstaller le serveur et le restaurer à partir d'une sauvegarde ou faire confiance à des résultats légèrement obsolètes lorsque la recherche réanalyse le contenu. Vous pouvez également utiliser l'une des techniques décrites dans la section Disponibilité de la recherche après le basculement afin de réduire le temps de recherche de la récupération.

• Les produits et technologies SharePoint ne connaissent pas la mise en miroir SQL Server. Même s'il n'est pas recommandé d'utiliser la mise en miroir SQL Server comme technique de disponibilité, cela nécessite un niveau supplémentaire d'automatisation.

Quand devez-vous envisager la disponibilité ?

Il est recommandé d'examiner les besoins de disponibilité dans le cadre de la conception de base de la solution SharePoint. Vous pouvez également améliorer la disponibilité lorsque la solution est déployée. Sur le plan opérationnel, il est recommandé de déployer et d'affiner la solution standard sur une batterie de serveurs, puis de tester les solutions de disponibilité.

Détermination des besoins de disponibilité

Pour évaluer la tolérance de l'organisation sur les temps d'immobilisation d'un site, d'un service ou d'une batterie de serveurs, répondez aux questions suivantes :

• Si le site, le service ou la batterie de serveurs n'est pas disponible, les employés de votre organisation seront-ils dans l’impossibilité d’exercer raisonnablement leurs fonctions ?

• Si le site, le service ou la batterie de serveurs n'est pas disponible, les transactions de l'entreprise et des clients seront-elles interrompues, entraînant une perte d'activité et de clients ?

Si vous avez répondu oui à l'une de ces questions, vous devez investir dans une solution de disponibilité.

Choix d'une stratégie de disponibilité

Vous pouvez choisir parmi plusieurs approches pour améliorer la disponibilité :

• tolérance aux pannes des composants ;

• redondance et basculement entre les rôles de serveur d'une batterie ;

• redondance et basculement entre des batteries de serveurs.

Configuration système indispensable pour la disponibilité

Dans un scénario idéal, les composants et les systèmes de reprise après incident correspondent à l'intégralité des composants et du système principaux : plateforme, matériel, nombre de serveurs. Au minimum, l'environnement de basculement doit pouvoir gérer le trafic attendu pendant un basculement. Gardez à l'esprit que seul un sous-ensemble d'utilisateurs peut être servi par le site de basculement. Les systèmes doivent répondre au minimum aux conditions suivantes :

• version du système d'exploitation et toutes les mises à jour ;

• versions SQL Server et toutes les mises à jour ;

• versions des produits et technologies SharePoint et toutes les mises à jour.

Même si cet article traite principalement de la disponibilité des produits et technologies SharePoint, le temps d'activité du système est également affecté par les autres composants du système. En particulier, tenez compte les éléments suivants :

• Vous devez vérifier que les dépendances d'infrastructure (par exemple, alimentation électrique, refroidissement, réseau, répertoire et protocole/serveur SMTP) sont complètement redondantes.

• Choisissez un mécanisme de commutation pour le système, DNS ou matériel d'équilibrage de la charge, répondant à vos besoins. Les articles ci-dessous indiquent les méthodes conseillées pour les serveurs Web d'équilibrage de la charge :

  • Conception au niveau de l'entreprise pour l'équilibrage de la charge (en anglais) (https://go.microsoft.com/fwlink/?linkid=122194&clcid=0x40C) (en anglais)

  • Conception DNS au niveau de l'entreprise (en anglais) (https://go.microsoft.com/fwlink/?linkid=122196&clcid=0x40C) (en anglais)

Tolérance aux pannes des composants

Dans n'importe quel système, il est recommandé de travailler avec les fabricants de matériel pour bénéficier de la tolérance aux pannes adaptée au système, y compris les piles de disques RAID (Redundant Array of Independent Disks). Pour des recommandations, reportez-vous à la section Planifier les performances et la capacité (Windows SharePoint Services).

Lors de la planification de la tolérance aux pannes des composants, tenez compte des points suivants :

• La redondance totale de chaque composant d'un serveur n'est peut-être pas possible ou peut être difficile. Utilisez des serveurs supplémentaires pour une meilleure redondance.

• Envisagez la redondance des composants pour le rôle de serveur d'index, car la redondance de ce rôle n'est pas possible.

• Vérifiez que les serveurs sont équipés de plusieurs alimentations connectées à des sources différentes pour une redondance maximale.

Redondance et basculement entre les rôles de serveur d'une batterie

Les produits et technologies SharePoint prennent en charge les rôles de serveur en cours d'exécution sur des ordinateurs redondants (c'est-à-dire l'évolution) dans une batterie de serveurs pour augmenter la capacité et améliorer les performances, et procurer une disponibilité standard. La capacité et les performances déterminent à la fois le nombre et la taille des serveurs d'une batterie. Lorsque les conditions de base sont remplies, vous voudrez peut-être ajouter des serveurs supplémentaires pour augmenter la disponibilité globale du service.

Disponibilité dans une batterie à serveur unique

Le tableau ci-dessous décrit les serveurs et les rôles de serveur dans un environnement de produits et technologies SharePoint (reportez-vous à la page Services sur le serveur) dans le le site Web Administration centrale de SharePoint) et les stratégies de redondance standard utilisables pour chacun d'entre eux dans une batterie de serveurs.

Pour plus d'informations, reportez-vous à la section Planification de la redondance (Windows SharePoint Services).

Comparaison des stratégies de disponibilité des bases de données pour une seule batterie de serveurs : gestion de clusters SQL Server de basculement/mise en miroir SQL Server haute disponibilité

Le tableau ci-dessous compare la gestion des clusters et la mise en miroir synchrone SQL Server haute disponibilité.

Redondance et basculement entre des centres de données proches configurés comme batterie de serveurs unique (batterie étirée)

Certaines entreprises ont des centres de données proches avec des connexions à bande passante élevée, de façon à les configurer comme une batterie de serveurs unique. Cette opération est baptisée une batterie de serveurs étirée. Pour qu'une batterie de serveurs étirée fonctionne, la latence entre SQL Server et les serveurs Web doit être inférieure à il doit être inférieure à 1 ms dans un sens avec une bande passante minimale égale à 1 Gbit/s.

• Dans ce scénario, vous pouvez offrir la redondance des bases de données en utilisant la mise en miroir synchrone. Dans une batterie de serveurs étirée, vous pouvez mettre en miroir la base de données de configuration et les bases de données de contenu. Pour une étude de cas de sur l'utilisation d'une batterie de serveurs étirée par une société, reportez-vous à la section White paper: Case Study of High Availability for SharePoint using Database Mirroring.

• Consultez votre fournisseur du réseau SAN afin de déterminer si vous pouvez utiliser la réplication du réseau SAN ou un autre mécanisme pris en charge pour fournir la disponibilité sur les centres de données, par exemple l'exécution de SQL Server sur des serveurs de clusters géographiquement dispersés. Vérifiez que la solution de réplication du réseau SAN offre une cohérence suffisante pour la simultanéité et les transactions.

Dans une batterie de serveurs étirée, vous pouvez offrir la tolérance aux pannes pour les serveurs d'applications qui exécutent des fournisseurs SSP (Security Support Provider) en ayant :

• plusieurs serveurs de requêtes

• plusieurs serveurs exécutant Services de calcul Excel

Le serveur d'index est un point unique de défaillance dans ce scénario. Vous pouvez sauvegarder et restaurer la recherche ou, si la devise de recherche lors de récupération est essentielle, utilisez une batterie de serveurs de basculement SSP. Pour plus d'informations, reportez-vous à la section Disponibilité de la recherche après le basculement.

Batterie de serveurs « étirée »

Redondance et basculement entre des centres de données comportant plusieurs batteries de serveurs

Vous pouvez configurer une batterie de serveurs de basculement pour offrir la disponibilité dans un centre de données distinct de la batterie de serveurs principal. Un environnement comportant une batterie de serveurs de basculement distincte présente les caractéristiques suivantes :

• Une base de données de configuration distincte et une base de données de contenu de l'Administration centrale doivent être gérées sur la batterie de serveurs de basculement.

  Remarque :
  Si vous avez configuré un autre mappage d'accès pour la batterie de serveurs principale, il est particulièrement important de le configurer de la même manière que sur la batterie de serveurs de basculement.

• Toutes les personnalisations doivent être déployées sur les deux batteries de serveurs.

• Les correctifs doivent être appliqués individuellement aux deux batteries de serveurs.

• Seules les bases de données de contenu peuvent être mises en miroir de manière asynchrone ou envoyées avec les journaux dans la batterie de serveurs de basculement.

• Les bases de données en miroir ou envoyées avec les journaux doivent être configurées pour utiliser le mode de récupération complète.

• Il est possible de sauvegarder et de restaurer les bases de données SSP dans la batterie de serveurs de basculement.

Consultez votre fournisseur du réseau SAN pour déterminer si vous pouvez utiliser la réplication du réseau SAN ou un autre mécanisme pris en charge pour assurer la disponibilité dans les centres de données.

Cette topologie peut être reproduite sur plusieurs centres de données si vous configurez l'envoi des journaux SQL Server sur un ou plusieurs centres de données supplémentaires.

Remarque :
Il n'est pas possible d'utiliser la mise en miroir SQL Server ne peut être utilisé avec serveur miroir, mais vous pouvez envoyer les journaux sur plusieurs serveurs secondaires.

Batteries de serveurs principale et de basculement avant le basculement

Le tableau ci-dessous décrit les serveurs et les rôles de serveur dans un environnement de produits et technologies SharePoint, ainsi que la stratégie de redondance de base utilisable pour chaque serveur entre les batteries de serveurs.

Réplication asynchrone et recherche

La recherche nécessite la synchronisation complète entre la base de données de recherche, la base de données SSP et les index. Du fait de cette exigence, il n'est pas possible de répliquer la recherche entre des batteries de serveurs en utilisant un mécanisme de réplication asynchrone (mise en miroir asynchrone des bases de données, envoi de journaux ou réplication du réseau SAN asynchrone). Pour offrir la recherche sur une batterie de serveurs de basculement, vous devez récupérer la base de données SSP de recherche

Remarque :
Si vous exécutez une base de données SSP sans recherche ou projet, vous pouvez utiliser un mécanisme de réplication asynchrone pour déplacer des données.

Disponibilité de la recherche après le basculement

Le rôle de serveur d'index ne peut pas être redondant dans une batterie de serveurs. Les besoins de l'entreprise pour la devise de la recherche après le basculement peuvent déterminer l'architecture logique de la solution.

• Si l'entreprise ne nécessite pas la devise de la recherche immédiate et la disponibilité après le basculement, vous pouvez sauvegarder et restaurer la base de données de recherche SSP sur le site de basculement.

• Si l'entreprise nécessite la devise de la recherche rapide et la disponibilité, vous pouvez utiliser une des solutions suivantes :

• Architecture de batterie de serveurs unique avec deux fournisseurs SSP identiques.

• Batterie de serveurs parente centralisée qui héberge la recherche et d'autres fournisseurs SSP. Le service de recherche de la batterie de serveurs centrale analyse le contenu toutes les autres batteries de serveurs. Cette architecture est utilisable pour prendre en charge une ou plusieurs batteries de serveurs.

Important :

Si vous avez besoin de simultanéité et de disponibilité de la recherche rapide et que vous utilisez des profils, les profils présents sur les fournisseurs SSP de basculement ne sont pas synchronisés avec les profils des fournisseurs SSP principaux. Ils seront dans l'état où ils étaient initialement importés. Pour que les profils sur tous les fournisseurs SSP demeurent synchronisés, vous devez utiliser le moteur de réplication de profil utilisateur inclus dans les outils d'administration SharePoint 32 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x40C) (en anglais) ou dans les outils d'administration SharePoint 64 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x40C) (en anglais) . Pour plus d'informations, voir User Profile Replication Engine (Office SharePoint Server).

Batterie de serveurs unique avec deux fournisseurs SSP

L'architecture suivante protège contre les pannes d'un serveur d'index. Dans cette topologie, les deux fournisseurs SSP analysent le même contenu, en utilisant les mêmes règles. Le fournisseur SSP de basculement n'est pas associé au site Web principal, sauf si un basculement se produit.

Batterie de serveurs unique avec deux fournisseurs services partagés

Cette topologie présente les limitations suivantes :

• Nécessite deux fois l'espace pour les index sur chaque serveur de requêtes

• Nécessite le basculement manuel d'une application Web pour utiliser le basculement SSP (peut être fait l'objet d'un script).

• Réduit de moitié la taille du corpus que vous pouvez analyser.

• Par défaut, si les profils sont activés, les profils sur le fournisseur SSP de basculement ne sont pas synchronisés avec les profils sur le fournisseur SSP principal. Au lieu de cela, ils seront dans l'état où ils étaient initialement importés. Pour que les profils sur tous les fournisseurs SSP demeurent synchronisés, vous devez utiliser le moteur de réplication de profil utilisateur inclus dans les outils d'administration SharePoint 32 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x40C) (en anglais) ou dans les outils d'administration SharePoint 64 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x40C) (en anglais) . Pour plus d'informations, voir User Profile Replication Engine (Office SharePoint Server).

La capacité à analyser de grands ensembles de données en temps voulu est affectée par plusieurs facteurs notamment la latence et la bande passante entre les serveurs d'index et les serveurs Web.

Dans un environnement ayant une bande passante limitée, cette topologie peut réduire considérablement les performances. Le contenu de l'analyse crée une charge supplémentaire deux fois plus importante sur les référentiels de contenu en cours d'analyse, ce qui peut nuire aux performances du référentiel. La capacité de la recherche à conserver l'actualisation des index peut être également affectée.

Batteries de serveurs SSP centralisées

Dans l'architecture suivante, l'utilisation d'une batterie de serveurs SSP parente protège contre les pannes de serveur d'index. Bien que cela puisse sembler une solution imposant une charge intense sur le matériel, des batteries SSP distinctes peuvent partager certains matériels (ex. serveur en cluster ou serveur de bases de données en miroir), tant que les serveurs d'index résident sur des serveurs distincts. Pour plus d'informations sur la planification et la configuration des batteries SSP, reportez-vous à la section Plan SSP architecture.

Cette topologie présente les avantages suivants :

• La gestion SSP est centralisée.

• La panne d'une batterie de serveurs ne nécessite pas une nouvelle analyse.

Batteries de serveurs SSP centralisées

Cette topologie présente les limitations suivantes :

• L'analyse du contenu sur un réseau étendu (WAN) utilise la bande passante.

• Le maintien à jour des index peut être difficile dans des environnements comportant des données volumineuses et un taux de modifications élevé.

• Les performances des requêtes peuvent être affectés par les performances des liaisons sur un réseau étendu.

• Par défaut, si les profils sont activés, les profils sur la batterie de serveurs SSP de basculement ne sont pas synchronisés avec les profils sur le fournisseur SSP principal. Au lieu de cela, ils seront dans l'état où ils étaient initialement importés. Pour que les profils sur tous les fournisseurs SSP demeurent synchronisés, vous devez utiliser le moteur de réplication de profil utilisateur inclus dans les outils d'administration SharePoint 32 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x40C) (en anglais) ou dans les outils d'administration SharePoint 64 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x40C) (en anglais) . Pour plus d'informations, voir User Profile Replication Engine (Office SharePoint Server).

Résumé

Étudiez soigneusement vos besoins en matière de disponibilité. Plus le niveau de disponibilité et les systèmes plus que vous protéger, plus complexes et coûteuses une solution de disponibilité est probablement être.

Les coûts de la disponibilité doivent être évalués en fonction des besoins de votre entreprise : toutes les solutions au sein d'une organisation exigent probablement le même niveau de disponibilité. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, des services différents (par exemple, recherche et analyse décisionnelle) ou différentes batteries de serveurs.

Remerciements

L'équipe de rédaction Microsoft Office SharePoint remercie les relecteurs techniques suivants à propos de cet article :

• Bill Baer, Microsoft Online Services, Hosted SharePoint, Technology Architect

• James Petrosky, Microsoft Consulting Services, Senior Consultant

• Steve Peschka, Microsoft Consulting Services, IW Senior Architect

• Dan Winter, Microsoft Customer Support Services, Escalation Engineer

• Sean Livingston, Microsoft SharePoint Products and Technologies, Program Manager

• Mike Watson, Technology Architect

• Todd Carter, Microsoft Premier Field Engineering, Principal Premier Field Engineer

• Mike Plumley, Microsoft Office Project Server, Writer

• Christophe Fiessinger, Microsoft Office Project, Senior Technical Product Manager

• Sid Shah, Microsoft Search, Program Manager

• Luca Bandinelli, Microsoft SharePoint Products and Technologies, Program Manager