Planifier la disponibilité (Office SharePoint Server)

  • Article

Mise à jour : 2009-04-23

Cet article décrit la disponibilité en général, les coûts et les défis en termes de disponibilité dans un environnement des produits et technologies SharePoint, ainsi que les stratégies et les solutions que vous pouvez utiliser dans l’environnement. Vous devez lire ce document si votre batterie de serveurs exécute Microsoft Office SharePoint Server 2007. Vous pouvez télécharger et imprimer le modèle de disponibilité Office SharePoint Server 2007 (en anglais) (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x40C) qui accompagne cet article. Il fournit un résumé, de la taille d’une affiche, du contenu de cet article.

Vue d’ensemble de la disponibilité

La disponibilité exprime dans quelle mesure un environnement des produits et technologies SharePoint est perçu par les utilisateurs comme étant disponible. Garantir la disponibilité signifie garantir qu’un système est robuste, de telle sorte que les incidents qui affectent les services se produisent rarement et qu’une action efficace soit effectuée en temps opportun. Les stratégies de disponibilité réduisent au minimum la perception de l’utilisateur des temps morts planifiés et non planifiés.

L’une des mesures les plus courantes de la disponibilité est le pourcentage de temps d’activité exprimé en nombre de neuf, c’est-à-dire le pourcentage de temps pendant lequel un système donné est actif et en cours de fonctionnement. Par exemple, un système qui affiche un pourcentage de temps d’activité de 99,999 est réputé avoir cinq neuf de disponibilité.

Le tableau suivant établit une correspondance entre le nombre de neuf et les équivalents en durées calendaires.

Pourcentage acceptable de disponibilité Temps mort par jour Temps mort par mois Temps mort par an

95

72,00 minutes

36 heures

18,26 jours

99

14,40 minutes

7 heures

3,65 jours

99,9

86,40 secondes

43 minutes

8,77 heures

99,99

8,64 secondes

4 minutes

52,60 minutes

99,999

0,86 seconde

26 secondes

5,26 minutes

Si vous pouvez évaluer objectivement le nombre total d’heures de temps mort éventuel, vous pouvez utiliser les formules suivantes pour calculer le pourcentage de temps d’activité pour une année, un mois ou une semaine :

% 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é n’est pas

La disponibilité n’est pas un système de protection et de récupération de données, ni de récupération d’urgence, bien que ces concepts soient liés, et vous devez mettre en place des plans de protection de données et de récupération d’urgence dans n’importe quel système à haut niveau de disponibilité. La protection et la récupération de données constituent le besoin d’entreprise qui sous-tend les besoins d’entreprise spécifiques suivants :

  • conservation et possibilité de passer en revue plusieurs versions d’un élément ou d’un site ;

  • récupération des éléments ou des sites supprimés accidentellement ;

  • archivage des données pour des raisons légales, réglementaires ou d’entreprise ;

  • restauration des systèmes en cas de défaillance matérielle ou logicielle inattendue.

En outre, la disponibilité n’est pas la gestion de la continuité des affaires. La gestion de la continuité des affaires se caractérise par des décisions, des processus et des outils d’entreprise que vous mettez en place à l’avance afin de gérer les crises. Une crise peut être un événement local, régional ou national, ou bien être liée uniquement à votre entreprise.

La disponibilité des produits et technologies SharePoint et les stratégies de gestion de protection des données peuvent faire partie de votre plan technique de la gestion de la continuité des affaires, mais votre plan global de la gestion de la continuité des affaires doit être beaucoup plus complet, en intégrant notamment les éléments suivants :

  • procédures clairement documentées ;

  • stockage hors site des enregistrements d’entreprise clés ;

  • contacts clairement désignés ;

  • formation constante du personnel ;

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

Coûts de la disponibilité

La disponibilité est l’une des contraintes les plus onéreuses pour un système. Plus le niveau de disponibilité et le nombre de systèmes que vous protégez sont élevés, plus une solution de disponibilité est susceptible d’être complexe et coûteuse. Les coûts inhérents à la disponibilité sont les suivants :

  • matériel et 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 ;

  • complexité opérationnelle accrue.

Les coûts inhérents à la disponibilité doivent être évalués en fonction de vos besoins métiers ; les solutions au sein d’une organisation peuvent impliquer des niveaux de disponibilité différents. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, différents services (tels que la recherche et l’analyse décisionnelle) ou différentes batteries de serveurs.

La disponibilité constitue une zone clé dans laquelle les groupes de technologie de l’information proposent des contrats de niveau de service pour définir les attentes avec les groupes de clients. De nombreuses organisations informatiques offrent une variété de contrats de niveau de service, qui sont associés à des niveaux de facturation différents.

NoteRemarque :

Lors du calcul de la disponibilité, la plupart des organisations exemptent ou ajoutent de façon spécifique des heures pour les activités de maintenance planifiée.

Défis pour la disponibilité des produits et technologies SharePoint

Un déploiement des produits et technologies SharePoint présente les défis suivants en termes de disponibilité :

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

  • Vous ne pouvez pas obtenir la redondance des serveurs d’index en installant le rôle d’index sur plusieurs serveurs. Pour faire face à la perte d’un serveur d’index, vous devez réinstaller le serveur, puis effectuer une restauration à partir d’une sauvegarde ou vous baser sur des résultats légèrement périmés lorsque la recherche réanalyse le contenu. Ou bien, vous pouvez utiliser l’une des techniques décrites dans la section Disponibilité de recherche dans une batterie de serveurs et Recherche disponibilité entre des batteries afin de réduire le temps nécessaire à la récupération de la recherche.

  • Les produits et technologies SharePoint ne reconnaissent pas la mise en miroir de Microsoft SQL Server 2005. Bien que nous vous recommandions d’envisager l’utilisation de la mise en miroir SQL Server comme technique de disponibilité pour SharePoint, cette solution implique une automatisation supplémentaire.

Quand envisager la disponibilité ?

Nous vous recommandons de prendre en compte les besoins en matière de disponibilité dans le cadre de la conception de la solution SharePoint de base. Vous pouvez également renforcer la disponibilité une fois la solution déployée. D’un point de vue opérationnel, nous vous recommandons de déployer et d’ajuster la solution de base dans une batterie de serveurs, puis de tester les solutions de disponibilité.

Déterminer les exigences de disponibilité

Pour mesurer la tolérance de l’organisation en termes de temps mort pour un site, un service ou une batterie de serveurs, répondez aux questions suivantes pour le site, le service ou la batterie de serveurs.

  • Si le site, le service ou la batterie de serveurs devient indisponible, les employés de l’organisation pourront-ils remplir normalement leurs tâches ?

  • Si le site, le service ou la batterie de serveurs devient indisponible, les transactions de l’entreprise et des clients seront-elles interrompues, provoquant 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é.

Choisir une stratégie de disponibilité

Vous pouvez choisir parmi plusieurs approches différentes pour améliorer la disponibilité, notamment celles-ci :

  • tolérance de panne des composants ;

  • redondance et basculement entre les bases de données et les rôles de serveur d’une batterie ;

  • redondance et basculement entre les batteries de serveurs.

Configuration système requise pour la disponibilité

Dans un scénario idéal, les systèmes et les composants de basculement correspondent aux système et composants principaux en tous points : plateforme, matériel et nombre de serveurs. Au minimum, l’environnement de basculement doit être en mesure de gérer le trafic attendu pendant un basculement. Gardez à l’esprit que seul un sous-ensemble d’utilisateurs peut être fourni par le site de basculement. Les systèmes doivent correspondre au moins dans les aspects suivants :

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

  • versions de SQL Server et toutes les mises à jour ;

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

Bien que cet article traite principalement de la disponibilité des produits et technologies SharePoint, le temps d’activité système est également affecté par les autres composants du système. En particulier, prenez en compte les éléments suivants :

Disponibilité dans une batterie de serveurs

Pour prendre en charge la disponibilité dans une batterie de serveurs, envisagez l’utilisation de composants à tolérance de pannes, de rôles de serveurs redondants, ainsi que la prise en charge de la disponibilité des bases de données, par le biais du clustering et/ou de la mise en miroir de base de données.

Tolérance de panne des composants

Quel que soit le système, il est recommandé de collaborer avec les fabricants de matériel afin de disposer d’un matériel tolérant aux pannes adéquat, notamment de baies RAID (Redundant Array of Independent Disks). Pour obtenir des recommandations, voir Planifier les performances et la capacité (Office SharePoint Server).

Lorsque vous planifiez la tolérance de panne des composants, prenez en compte les éléments suivants :

  • La redondance complète de chaque composant au sein d’un serveur peut s’avérer impossible ou difficile à mettre en place. Utilisez des serveurs supplémentaires pour accroître la redondance.

  • Envisagez la redondance des composants pour le rôle de serveur d’index, car celui-ci ne peut pas être rendu redondant.

  • Assurez-vous que les serveurs disposent de plusieurs branchements à différentes sources d’alimentation afin que la redondance soit maximale.

Redondance et basculement entre les rôles de serveurs dans une batterie de serveurs

Les produits et technologies SharePoint prennent en charge les rôles de serveurs en cours d’exécution sur des ordinateurs redondants (c’est-à-dire la montée en puissance parallèle) 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, il est possible d’ajouter des serveurs pour augmenter la disponibilité globale du service.

Redondance dans une batterie à serveur unique

Disponibilité d’une batterie de serveurs unique

Le tableau suivant décrit les rôles de serveurs et les services dans un environnement des produits et technologies SharePoint, tels que répertoriés dans la page Services sur le serveur du site Web Administration centrale de SharePoint, et les stratégies de redondance de base utilisables pour chacun d’eux dans une batterie de serveurs.

Services sur le serveur Stratégie de redondance de base par défaut dans une batterie de serveurs

Serveurs Web

Déploiement sur plusieurs serveurs et équilibrage de la charge à l’aide d’un mécanisme logiciel ou matériel.

Serveur Web pour les batteries de serveurs de taille moyenne (application Web et services de requête de recherche)

Déploiement sur plusieurs serveurs.

Indexation de la recherche

Ne peut pas être déployée sur plusieurs serveurs et être redondante. Vous devez utiliser une stratégie de disponibilité différente. Pour plus d’informations, voir Disponibilité de recherche dans une batterie de serveurs.

Calcul Excel

Déploiement sur plusieurs serveurs.

Application de projet

Déploiement sur plusieurs serveurs.

Pour plus d’informations, voir Planifier la redondance (Office SharePoint Server).

Stratégies de disponibilité des bases de données pour une batterie de serveurs unique

La disponibilité des bases de données dans une batterie de serveurs peut être assurée par le biais du clustering SQL Server ou de la mise en miroir SQL Server à haut niveau de disponibilité (mise en miroir synchrone).

Clustering Le clustering avec basculement assure la prise en charge de la disponibilité d’une instance entière de SQL Server. Un cluster avec basculement combine un ou plusieurs nœuds ou serveurs et deux ou plusieurs disques partagés. Une instance de cluster avec basculement apparaît sous la forme d’un seul ordinateur, mais dispose des fonctionnalités permettant de basculer d’un nœud vers un autre en cas d’indisponibilité du nœud actuel.

Office SharePoint Server 2007 fait référence au cluster dans sa globalité, de sorte que le basculement est automatique et transparent du point de vue des produits et technologies SharePoint.

Mise en miroir de base de données synchrone La mise en miroir de base de données prend en charge la disponibilité en envoyant les transactions depuis une base de données et un serveur principaux directement à une base de données et un serveur miroirs chaque fois que le tampon du journal des transactions de la base de données principale est écrit sur le disque. Nous vous recommandons d’utiliser la mise en miroir, également appelée mode de haute sécurité avec le basculement automatique. La mise en miroir de base de données à haut niveau de disponibilité implique trois instances de serveur : un serveur principal, un serveur miroir et un serveur témoin. Le serveur témoin permet à SQL Server de basculer automatiquement du serveur principal vers le serveur miroir. Le basculement de la base de données principale vers la base de données miroir prend généralement plusieurs secondes.

Chaque technologie présente des avantages et des inconvénients. La méthode de clustering est plus facile à implémenter mais peut être plus coûteuse. La mise en miroir SQL Server n’est pas prise en charge pour les bases de données Microsoft Office Project Server 2007.

Le tableau suivant compare le clustering avec basculement à la mise en miroir SQL Server à haut niveau de disponibilité.

Clustering avec basculement SQL Server Mise en miroir SQL Server à haut niveau de disponibilité

Le miroir prend immédiatement le relais en cas de panne.

Le miroir prend immédiatement le relais en cas de panne.

Cohérent du point de vue des transactions.

Cohérente du point de vue des transactions.

Prend en charge les transactions simultanées.

Prend en charge les transactions simultanées.

Délai plus court pour la récupération (secondes ou minutes).

Délai légèrement plus long pour la récupération (secondes ou minutes).

La défaillance est automatiquement détectée par les nœuds de la base de données ; les produits et technologies SharePoint référencent le cluster, de sorte que le basculement du point de vue des produits et technologies SharePoint est transparent et automatique.

Requiert des scripts pour assurer le basculement des produits et technologies SharePoint.

Ne protège pas contre l’échec d’un stockage, car le stockage est partagé entre les nœuds du cluster.

Assure une protection contre l’échec d’un stockage, car les serveurs de bases de données principal et miroir écrivent sur les disques locaux.

Requiert un stockage partagé plus coûteux.

Peut utiliser un stockage à connexion directe (DAS) moins onéreux.

Même sous-réseau.

Jusqu’à 1 milliseconde (ms) de latence entre SQL Server et les serveurs Web.

Peut utiliser le mode de récupération simple de SQL Server, bien que le seul point de récupération disponible en cas de perte du cluster soit la dernière sauvegarde complète.

Requiert le mode de restauration complète de SQL Server.

Aucune surcharge pour les performances.

Présente une latence transactionnelle. Ajoute une surcharge pour la mémoire et le processeur.

Charge opérationnelle minimale.

Charge opérationnelle supplémentaire, liée notamment aux scripts et à la configuration des alias SQL Server.

Pour plus d’informations sur l’utilisation du clustering, voir Configurer la disponibilité dans une seule batterie de serveurs à l’aide du clustering de SQL Server.

Pour plus d’informations sur l’utilisation de la mise en miroir synchrone, voir Configurer la disponibilité dans une seule batterie de serveurs à l’aide de la mise en miroir de bases de données SQL Server et Utilisation de la mise en miroir de base de données (Office SharePoint Server) (livre blanc).

Redondance et basculement entre des centres de données proches configurés en tant que batterie de serveurs unique (batterie de serveurs étendue)

Certaines entreprises possèdent des centres de données proches reliés par des connexions à bande passante élevée, ce qui permet de les configurer en tant que batterie de serveurs unique. Celle-ci est alors appelée batterie de serveurs étendue. Pour qu’une batterie de serveurs étendue fonctionne, il est nécessaire que la latence soit inférieure à 1 milliseconde entre SQL Server et les serveurs Web dans un sens et que la bande passante offre un débit d’au moins 1 gigabit par seconde.

  • Dans ce scénario, vous pouvez assurer la redondance des bases de données en utilisant la mise en miroir synchrone. Dans une batterie de serveurs étendue, 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 sur la façon dont une entreprise peut utiliser une batterie de serveurs étendue, voir Étude de cas d’une disponibilité élevée pour SharePoint à l’aide de la mise en miroir de base de données (livre blanc).

  • Consultez votre fournisseur de réseau SAN pour déterminer si vous pouvez utiliser la réplication SAN ou un autre mécanisme pris en charge pour assurer la disponibilité des centres de données, tel que l’exécution de SQL Server sur des clusters de serveurs disséminés. Assurez-vous que la solution de réplication SAN offre un niveau suffisant de simultanéité et de cohérence transactionnelle.

Dans une batterie de serveurs étendue, vous pouvez assurer la tolérance de panne pour les serveurs d’applications qui exécutent des fournisseurs de services partagés (SSP) en recourant à :

  • 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 simultanéité de la recherche lors de récupération est essentielle, utiliser une batterie de serveurs SSP. Pour plus d’informations, voir Disponibilité de recherche dans une batterie de serveurs.

Project Server constitue un autre point unique de défaillance dans ce scénario. Prévoyez de sauvegarder et de restaurer vos bases de données Project Server.

Batterie de serveurs étendue

Batterie de serveurs « étirée »

Disponibilité de la recherche dans une batterie de serveurs

Le rôle de serveur d’index ne peut pas être redondant dans une batterie de serveurs. Les besoins de l’entreprise en termes de simultanéité de la recherche après le basculement permettent de déterminer l’architecture logique de la solution.

Si l’entreprise ne requiert pas une simultanéité de la recherche et une disponibilité immédiate après le basculement, vous pouvez sauvegarder et restaurer le fournisseur de services partagés de recherche sur le site de basculement.

Si l’entreprise nécessite une disponibilité et une simultanéité de la recherche rapide, vous pouvez utiliser une des méthodes suivantes :

  • architecture composée d’une seule batterie de serveurs avec deux fournisseurs de services partagés identiques ;

    NoteRemarque :

    Si l’entreprise nécessite la simultanéité et la disponibilité de la recherche rapide, et si vous utilisez des profils, les profils sur les fournisseurs de services partagés de basculement ne sont pas synchronisés avec les profils sur les fournisseurs de services partagés principaux. Ils seront dans l’état où ils étaient importés à l’origine. 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 le kit de ressources d’administration SharePoint 32 bits (en englais) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x40C) ou dans le kit de ressources d’administration SharePoint 64 bits (en anglais) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x40C). Pour en savoir plus, voir Outil User Profile Replication Engine (Office SharePoint Server).

  • une batterie de serveurs parent centralisée qui héberge la recherche et d’autres fournisseurs de services partagés. Le service de recherche situé dans la batterie de serveurs centrale analyse le contenu stocké dans toutes les autres batteries de serveurs. Cette architecture permet de prendre en charge une ou plusieurs batteries de serveurs.

Batterie de serveurs unique avec deux fournisseurs de services partagés

L’architecture suivante offre une protection contre la défaillance d’un serveur d’index. Dans cette topologie, les deux fournisseurs de services partagés analysent le même contenu, à l’aide des mêmes règles. Le fournisseur de services partagés de basculement n’est associé au site Web principal qu’en cas de basculement.

Batterie de serveurs unique avec deux fournisseurs de services partagés

Batterie de serveurs avec deux SSP

Cette topologie présente les limites suivantes :

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

Dans un environnement offrant une bande passante limitée, cette topologie peut réduire considérablement les performances. La double analyse du contenu exerce une charge supplémentaire sur les référentiels de contenu en cours d’analyse, ce qui peut affecter leurs performances. La capacité de la recherche à maintenir l’index à jour peut également être affectée.

Batteries de serveurs SSP centralisées

Dans l’architecture suivante, l’utilisation d’une batterie de serveurs SSP parente offre une protection contre les pannes d’un serveur d’index. Bien que cette solution puisse être gourmande en ressources matérielles, des batteries de serveurs SSP distinctes peuvent partager une ressource matérielle telle qu’un serveur de bases de données en cluster ou en miroir, sous réserve que les serveurs d’index résident sur des serveurs distincts. Pour plus d’informations sur la planification et la configuration des batteries de serveurs SSP, voir Planifier l'architecture SSP.

Cette topologie présente les avantages suivants :

  • La gestion SSP est centralisée.

  • Aucune réanalyse n’est nécessaire en cas de défaillance d’une batterie de serveurs.

Batteries de serveurs SSP centralisées

Batteries de serveurs avec basculement SSP

Cette topologie présente les limites suivantes :

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

Vous pouvez configurer une batterie de serveurs de basculement pour assurer la disponibilité dans un centre de données distinct à partir de la batterie de serveurs principale. 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.

    NoteRemarque :

    Si vous avez configuré le mappage des accès de substitution pour la batterie de serveurs principale, il est très important de le configurer de la même manière 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 aux deux batteries de serveurs, séparément.

  • Seules les bases de données de contenu peuvent être correctement mises en miroir de manière asynchrone ou copiées dans les journaux des transactions sur la batterie de serveurs de basculement.

  • Les bases de données mises en miroir ou copiées dans les journaux des transactions doivent être configurées de manière à utiliser le mode de restauration complète.

  • Les bases de données SSP, y compris les bases de données de Office Project 2007, peuvent être sauvegardées et restaurées sur la batterie de serveurs de basculement.

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

Cette topologie peut être répétée dans différents centres de données si vous configurez la copie des journaux des transactions SQL Server sur un ou plusieurs centres de données supplémentaires.

NoteRemarque :

La mise en miroir SQL Server ne peut être utilisée qu’avec un seul serveur miroir, mais vous pouvez copier les journaux des transactions 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 suivant répertorie les rôles de serveurs et les services dans un environnement des produits et technologies SharePoint, ainsi que les stratégies de redondance de base utilisables entre les batteries de serveurs.

Serveur ou rôle de serveur Stratégie de redondance de base par défaut entre les batteries de serveurs

SQL Server

Mise en miroir asynchrone de la base de données SQL Server, copie des journaux de transaction SQL Server ou autre mécanisme de réplication asynchrone.

Notes

Stratégie inutilisable pour les bases de données SSP qui hébergent des informations de recherche, ni pour les bases de données Project Server.

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 et services de requête de recherche)

Déploiement sur les deux batteries de serveurs.

Indexation de la recherche

Déploiement sur les deux batteries de serveurs. Récupération de la sauvegarde à partir de la batterie de serveurs d’origine, vers une batterie de basculement.

Calcul Excel

Déploiement sur les deux batteries de serveurs. Si le fournisseur de services partagés n’héberge pas la recherche, peut utiliser la mise en miroir de base de données asynchrone, la copie des journaux de transaction SQL Server ou un autre mécanisme de réplication asynchrone pour déplacer les données vers une batterie de basculement.

Si le fournisseur de services partagés héberge également la recherche, doit récupérer la sauvegarde à partir de la batterie de serveurs d’origine pour effectuer le déplacement.

Application de projet

Déploiement sur les deux batteries de serveurs. Récupération de la sauvegarde à partir de la batterie de serveurs d’origine, vers une batterie de basculement.

Disponibilité de la recherche entre batteries de serveurs

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

NoteRemarque :

Si vous exécutez un fournisseur de services partagés sans recherche ou projet, vous pouvez utiliser un mécanisme de réplication asynchrone pour déplacer les données.

Pour fournir la recherche sur une batterie de serveurs de basculement, vous devez utiliser l’une des méthodes suivantes :

  • récupérer une sauvegarde du fournisseur SSP de recherche sur la batterie de serveurs de basculement.

  • Utiliser une 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 de toutes les autres batteries de serveurs.

Synthèse

Passez soigneusement en revue vos besoins en matière de disponibilité. Plus le niveau de disponibilité et le nombre de systèmes que vous protégez sont élevés, plus une solution de disponibilité est susceptible d’être complexe et coûteuse.

Les coûts inhérents à la disponibilité doivent être évalués en fonction des besoins de l’entreprise ; les solutions au sein d’une organisation peuvent impliquer des niveaux de disponibilité différents. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, différents services (tels que la recherche et l’analyse décisionnelle) ou différentes batteries de serveurs.

Remerciements

L’équipe de publication de contenu Microsoft Office SharePoint Server remercie les réviseurs techniques suivants qui ont travaillé sur ce document :

  • Bill Baer, Services Microsoft Online, SharePoint hébergé, Architecte des technologies

  • James Petrosky, Services de conseil Microsoft, Consultant principal

  • Steve Peschka, Services de conseil Microsoft, Architecte principal IW

  • Dan Winter, Support technique Microsoft, Ingénieur d’escalade

  • Sean Livingston, Produits et technologies Microsoft SharePoint, Chef de projet

  • Mike Watson, Architecte des technologies

  • Todd Carter, Ingénierie de maintenance Microsoft Premier, Ingénieur de maintenance Premier principal

  • Mike Plumley, Microsoft Office Project Server, Rédacteur technique

  • Christophe Fiessinger, Microsoft Office Project, Chef de produit technique principal

  • Sid Shah, Microsoft Search, Chef de projet

  • Luca Bandinelli, Produits et technologies Microsoft SharePoint, Chef de projet

Télécharger ce livre

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

Voir aussi

Concepts

Configurer la disponibilité élevée (Office SharePoint Server)