Planification de la disponibilité (Windows SharePoint Services)

Article
05/17/2012

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.

Pourcentage de temps d’activité acceptable	Temps quotidien d'immobilisation	Temps mensuel d'immobilisation	Temps annuel d'immobilisation
95	72 minutes	36 heures	18,26 jours
99	14,4 minutes	7 heures	3,65 jours
99.9	86,4 secondes	43 minutes	8,77 heures
99.99	8,64 secondes	4 minutes	52,6 minutes
99.999	0,86 seconde	26 secondes	5,26 minutes

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

Disponibilité d’une batterie de serveurs 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.

Services sur le serveur	Stratégie préférable de redondance de base dans une batterie de serveurs
SQL Server	Gestion de clusters ou mise en miroir synchrone. La méthode de clustering est plus facile à implémenter mais peut être plus coûteuse. Pour plus d'informations sur l'utilisation la mise en miroir synchrone, reportez-vous à la section White paper: Using database mirroring.
Serveurs Web	Déploiement sur plusieurs serveurs et équilibrage de la charge à l'aide de logiciels ou de matériel d'équilibrage de la charge.
Serveur Web pour les batteries de serveurs de taille moyenne (application Web Application et services de recherche de requêtes)	Déploiement sur plusieurs serveurs.
Indexation de la recherche	Impossibilité du déploiement sur plusieurs serveurs et de la redondance redondante. Vous devez utiliser une stratégie de disponibilité différente. Pour plus d'informations, reportez-vous à la section Disponibilité de la recherche après le basculement.
Calculs Excel	Déployez sur plusieurs serveurs.
Application de projet	Déployez sur plusieurs 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é.

Gestion de clusters SQL Server de basculement	Mise en miroir SQL Server haute disponibilité
Le serveur miroir entre en service immédiatement après la panne.	Le serveur miroir entre en service immédiatement après la panne.
Cohérence des transactions.	Cohérence des transactions.
Transactions simultanées	Transactions simultanées
Tempe de récupération le plus court (quelques secondes à quelques minutes).	Temps de récupération légèrement plus long (quelques secondes à quelques minutes).
La panne est automatiquement détectée par les nœuds de la base de données. Les produits et technologies SharePoint font référence au cluster : le basculement du point de vue des produits et technologies SharePoint est donc transparent et automatique.	Nécessite des scripts pour le basculement des produits et technologies SharePoint.
Ne protège pas contre un échec de stockage, car le stockage est partagé entre les nœuds du cluster.	Protège contre les échecs de stockage, car les serveurs des bases de données principale et miroir écrivent sur des disques locaux.
Nécessite un stockage partagé plus coûteux.	Utilise le stockage à connexion directe le moins coûteux stockage (DAS).
Même sous-réseau.	Jusqu'à 1 ms de latence entre SQL Server et les serveurs Web.
Utilise le mode de récupération simple SQL Server, bien que le seul point de récupération disponible, si le cluster est perdu, soit la dernière sauvegarde complète.	Nécessite le mode de récupération complète SQL Server.
Aucune surcharge de performances.	Présente la latence transactionnelle. Ajoute la surcharge de la mémoire et du processeur.
Charge opérationnelle minimale.	Charge opérationnelle supplémentaire, y compris les scripts et la configuration d'alias SQL Server.

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 »

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

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.

Serveur ou rôle de serveur	Stratégie préférable de redondance de base entre des batteries de serveurs
SQL Server	Mise en miroir asynchrone des bases de données SQL Server, envoi de journaux SQL Server ou autre mécanisme de réplication asynchrone. Notes N'est pas utilisable pour les bases de données SSP qui contiennent des informations de recherche.
Serveurs Web frontaux	Déploiement sur les deux batteries de serveurs, y compris les personnalisations.
Serveur Web pour les batteries de serveurs de taille moyenne (application Web Application et services de recherche de requêtes)	Déploiement sur les deux batteries de serveurs.
Indexation de la recherche	Déploiement sur les deux batteries de serveurs. Récupérer la sauvegarde à partir de la batterie de serveurs d'origine pour la déplacer vers une batterie de basculement.
Calculs Excel	Déployer sur les deux batteries de serveurs. Si le fournisseur SSP n'héberge pas de recherche, peut utiliser la mise en miroir asynchrone, l'envoi de journaux SQL Server ou un autre mécanisme de réplication asynchrone pour déplacer des données sur une batterie de basculement. Si le fournisseur SSP héberge également la recherche, doit récupérer la sauvegarde de batterie de serveurs d'origine à déplacer.
Application de projet	Déployer sur les deux batteries de serveurs. Récupérer la sauvegarde à partir de la batterie de serveurs d'origine à déplacer vers une batterie de basculement.

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

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

Batterie de serveurs avec deux SSP

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

Batteries de serveurs avec basculement SSP