Planification de la récupération d’urgence (SharePoint Server 2010)
S’applique à : SharePoint Foundation 2010, SharePoint Server 2010
Dernière rubrique modifiée : 2016-11-30
Cet article décrit les décisions importantes dans le choix des stratégies de récupération d’urgence pour un environnement Microsoft SharePoint Server 2010.
Dans cet article :
Présentation de la récupération d'urgence
Choix d'une stratégie de récupération d'urgence
Planification de centres de données de type serveur de secours secondaire
Planification de centres de données de type secours semi-automatique
Planification de centres de données de type serveur de secours
Configuration système requise pour la récupération d'urgence
Présentation de la récupération d’urgence
Pour les besoins de cet article, nous définissons la récupération d’urgence comme étant la possibilité de récupérer d’une situation dans laquelle un centre de données hébergeant SharePoint Server devient indisponible.
La stratégie de récupération d’urgence que vous utilisez pour SharePoint Server doit être coordonnée avec la stratégie de récupération d’urgence pour l’infrastructure associée, y compris les domaines Active Directory, Exchange Server et Microsoft SQL Server. Travaillez avec les administrateurs de l’infrastructure dont vous dépendez pour concevoir une stratégie et un plan de récupération d’urgence coordonné.
Le temps et le travail immédiat nécessaire pour obtenir une autre batterie de serveurs opérationnelle à un autre emplacement est souvent appelé serveur de secours, secours semi-automatique ou serveur de secours secondaire. Nos définitions pour ces termes sont les suivantes :
Serveur de secours Un second centre de données qui peut offrir une disponibilité dans les secondes ou les minutes qui suivent.
Secours semi-automatique Un second centre de données qui peut offrir une disponibilité dans les minutes ou les heures qui suivent.
Serveur de secours secondaire Un second centre de données qui peut offrir une disponibilité dans les heures ou les jours qui suivent.
La récupération d’urgence peut être une des conditions requises les plus onéreuses pour un système. Plus l’intervalle entre la défaillance et la disponibilité est court et plus vous protégez de systèmes, plus la solution de récupération d’urgence a de chances d’être complexe et coûteuse. Lorsque vous investissez dans des centres de données de type serveur de secours ou de secours semi-automatique, les coûts portent sur les éléments suivants :
Matériels et logiciels supplémentaires, qui accroissent souvent la complexité des opérations entre les applications logicielles, telles que des scripts personnalisés pour le basculement et la récupération.
Complexité supplémentaire des opérations.
Les coûts nécessaires pour maintenir des centres de données de type serveur de secours ou de secours semi-automatique doivent être évalués sur la base des besoins de votre entreprise. Toutes les solutions déployées au sein d’une organisation ne requièrent probablement pas le même niveau de disponibilité après un sinistre. Vous pouvez offrir différents niveaux de récupération d’urgence pour les différents contenus, services ou batteries de serveurs, par exemple du contenu qui un impact fort sur votre activité, des services de recherche ou une batterie de serveurs de publication.
La récupération d’urgence est un domaine essentiel où les groupes informatiques offrent des contrats de niveau de service permettant de définir les attentes avec les groupes clients. De nombreuses organisations du secteur informatique offrent différents contrats de niveau de service qui sont associés à différents niveaux de facturation.
Lorsque vous implémentez un basculement entre des serveurs de batteries, il est recommandé de d’abord déployer et affiner la solution principale au sein d’une batterie, puis d’implémenter et de tester la récupération d’urgence.
Choix d’une stratégie de récupération d’urgence
Vous pouvez choisir parmi de nombreuses approches différentes pour mettre en œuvre la récupération d’urgence pour un environnement SharePoint Server, selon les besoins de votre entreprise. Les exemples suivants montrent dans quelle mesure des sociétés doivent choisir des stratégies de récupération d’urgence de type serveur de secours secondaire, secours semi-automatique ou serveur de secours.
Stratégie de récupération d’urgence de type serveur de secours secondaire : une entreprise envoie de façon régulière des sauvegardes pour la prise en charge d’une récupération complète dans un lieu de stockage local et régional hors site, et elle a conclu des contrats pour la location de serveurs en urgence dans une autre région.
Pour :
Souvent l’option la moins coûteuse à maintenir du point de vue du fonctionnement.
Souvent une option coûteuse quant à la récupération car elle requiert que les serveurs physiques soient configurés correctement après la survenue du sinistre.
Contre : L’option la plus lente pour la récupération.
Stratégie de récupération d’urgence de type secours semi-automatique : une entreprise envoie de façon régulière des images de serveur virtuel à des batteries de serveurs de récupération d’urgence locaux et régionaux.
Pour : Souvent relativement peu coûteux en termes de récupération car une batterie de serveurs virtuels peut requérir peu de configuration pour la récupération.
Contre : Peut être très coûteux et consommateur de temps quant à la maintenance.
Stratégie de récupération d’urgence de type serveur de secours : une entreprise fait fonctionner plusieurs centres de données, mais ne délivre du contenu et des services que depuis un seul de ces centres de données.
Pour : Souvent relativement rapide en termes de récupération.
Contre : Peut être assez coûteux en termes de configuration et de maintenance.
Important
Quelle que soit la solution de récupération d’urgence que vous décidez d’implémenter pour votre environnement, vous risquez de perdre certaines données.
Planification de centres de données de type serveur de secours secondaire
Dans un scénario de récupération d’urgence de type serveur de secours secondaire, vous pouvez effectuer la récupération en configurant une nouvelle batterie de serveurs à un nouvel emplacement (de préférence à l’aide d’un déploiement par script) et en restaurant les sauvegardes. Vous pouvez aussi effectuer la récupération en restaurant une batterie de serveurs à partir d’une solution de sauvegarde, telle que Microsoft System Center Data Protection Manager 2007, qui protège vos données au niveau de l’ordinateur et qui vous laisse restaurer chaque serveur individuellement. Cet article ne contient pas d’instructions détaillées quant à la façon de créer et de récupérer dans des scénarios de type serveur de secours secondaire. Pour plus d’informations, voir :
Planification de centres de données de type secours semi-automatique
Dans un scénario de récupération d’urgence de type secours semi-automatique, vous pouvez créer une solution de secours semi-automatique en vous assurant de créer de façon cohérente et fréquente des images de serveur virtuel des serveurs de votre batterie, que vous envoyez à un emplacement secondaire. À cet emplacement secondaire, vous devez disposer d’un environnement disponible où vous pouvez facilement configurer et connecter les images pour recréer votre environnement de batterie de serveurs.
Cet article ne contient pas d’instructions détaillées pour la création de solutions de type secours semi-automatique. Pour plus d’informations sur la façon de planifier le déploiement de batteries de serveurs à l’aide de solutions virtuelles, voir Planifier la virtualisation (SharePoint Server 2010).
Planification de centres de données de type serveur de secours
Dans un scénario de récupération d’urgence de type serveur de secours, vous pouvez configurer une batterie de serveurs de basculement de façon à fournir une récupération d’urgence dans un centre de données distinct de la batterie de serveurs principale. Un environnement qui a 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 distincte doivent être gérées sur la batterie de serveurs de basculement.
Toutes les personnalisations doivent être déployées sur les deux batteries.
Notes
Il est recommandé d’utiliser un déploiement par script pour créer la batterie principale et la batterie de basculement à l’aide des mêmes paramètres et des mêmes personnalisations de configuration. Pour plus d’informations, voir Installer SharePoint Server 2010 à l’aide de Windows PowerShell.
Les mises à jour doivent être appliquées aux deux batteries individuellement.
Les bases de données de contenu de SharePoint Server peuvent être mises en miroir ou copiées via des journaux des transactions vers la batterie de serveurs de basculement.
Notes
La mise en miroir de SQL Server peut être utilisée seulement pour copier des bases de données sur un même serveur miroir, mais vous pouvez utiliser la copie via des journaux des transactions vers plusieurs serveurs secondaires.
Les applications de service peuvent ou non être copiée via des journaux des transactions vers une batterie de serveurs. Pour plus d’informations, voir Redondance des applications de service à travers des centres de données plus loin dans cet article.
Cette topologie peut être répétée à travers de nombreux centres de données si vous configurez la copie de SQL Server via des journaux des transactions vers un ou plusieurs centres de données supplémentaires.
Consultez votre fournisseur de système SAN pour déterminer si vous pouvez utiliser la réplication SAN ou un autre mécanisme pris en charge pour offrir de la disponibilité à travers des centres de données.
L’illustration suivante montre des batteries de serveurs principales et de basculement avant basculement.
Batteries de serveurs principales et de basculement avant basculement
.gif "Batteries de serveurs principale et de basculement avant le basculement")
Redondance des applications de service entre des centres de données
Pour pouvoir fournir une disponibilité à travers les centres de données pour les applications de service, il est recommandé, pour les services qui peuvent être exécutés à travers des batteries de serveurs, de faire fonctionner une batterie de services distincte auquel il est possible d’accéder à la fois depuis le centre de données principal et depuis le centre de données secondaire.
Pour les services qui ne peuvent pas être exécutés à travers des batteries de serveurs et pour fournir une disponibilité pour la batterie de serveurs de services elle-même, la stratégie pour fournit une redondance à travers des centres de données pour une application de service varie. La stratégie employée dépend des éléments suivants :
Il y a ou non une valeur ajoutée à exécuter l’application de service dans la batterie de récupération d’urgence lorsqu’elle n’est pas utilisée.
Les bases de données associées à l’application de service peuvent ou non être copiées via les journaux des transactions ou mises en miroir de façon asynchrone.
L’application de service peut ou non s’exécuter avec des bases de données en lecture seule.
Les sections suivantes décrivent les stratégies de récupération d’urgence qui sont recommandées pour chaque application de service. Les applications de service sont regroupées par stratégie.
Bases de données pouvant être copiées via les journaux des transactions ou mises en miroir de façon asynchrone
Après qu’une application de service a été déployée initialement sur une batterie secondaire, les bases de données prenant en charge les applications de service suivantes peuvent être copiées via les journaux des transactions ou mises en miroir de façon asynchrone entre des batteries :
Application de service de métadonnées gérées
Bases de données : Service de métadonnées gérées
Notes
Si le marquage est utilisé, pour utiliser correctement l’application de service de métadonnées gérées dans la batterie de récupération d’urgence, vous devez exécuter le Moteur de réplication de profil utilisateur inclus dans la Boîte à outils d’administration SharePoint. Pour plus d’informations, voir Vue d’ensemble du moteur de réplication des profils utilisateur (SharePoint Server 2010).
PerformancePoint Services
Bases de données : Application de service PerformancePoint
Application de service Project Server
Bases de données : Brouillon, Publiée, Archivage, Création de rapports
Project Server 2010 requiert une synchronisation entre ses bases de données. Project Server peut être répliqué entre des batteries de serveurs à l’aide d’un mécanisme de réplication asynchrone (mise en miroir de base de données asynchrone, copie via les journaux des transactions ou réplication SAN asynchrone) mais pour la récupération, vous devez vous assurer que les journaux de la base de données Project sont synchronisés lors de la restauration.
Notes
Même si nous recommandons de copier via les journaux des transactions ou mettre en miroir les bases de données Project Server vers la batterie de récupération d’urgence, l’application de service Project Server ne peut pas s’exécuter avec des bases de données en lecture seule. Par conséquent, il est recommandé de ne pas exécuter l’application de service Project Server sur la batterie de service de récupération d’urgence jusqu’à la fin du basculement. Pour synchroniser correctement les bases de données Project Server sur la batterie de récupération d’urgence, vous devez configurer les horodatages ou le marquage des journaux pour les bases de données.
Application de service Banque d’informations sécurisé
Bases de données : Banque d’informations sécurisée
Application de service de collecte de données relatives à l’état et à l’utilisation
Bases de données : Journalisation
Notes
Il est possible de copier via les journaux des transactions ou de mettre en miroir la base de données Journalisation. Cependant, il est recommandé de ne pas exécuter le service de collecte de données relatives à l’état et à l’utilisation sur la batterie de récupération d’urgence, et de ne pas mettre en miroir ni de copier via les journaux des transactions la base de données Journalisation.
Application de service Web Analytics
Bases de données : Zone de transit, Création de rapports
Notes
Il est recommandé de copier via les journaux des transactions ou de mettre en miroir les bases de données Web Analytics de la zone de transit et de création de rapports. Cependant, il est recommandé de ne pas exécuter l’application de service Web Analytics sur la batterie de service de récupération d’urgence jusqu’à la fin du basculement.
Applications de service et bases de données ne pouvant pas être copiées via les journaux des transactions ou mises en miroir de façon asynchrone
Les applications de service suivantes doivent être déployées à la fois sur la batterie principale et sur la batterie de basculement, et elles ne peuvent pas être copiées via les journaux des transactions ou mises en miroir de façon asynchrone. Pour la plupart de ces applications de service, il est recommandé de les déployer puis de vérifier que la batterie de basculement a les mêmes paramètres de configuration que la batterie principale. Si des modifications de configuration affectant le service sont apportées à la batterie principale, vous devez mettre à jour le batterie de basculement.
Application de service Registre d’application
Bases de données : Service Registre d’application
La copie de la base de données du service Registre d’application via les journaux des transactions n’est pas prise en charge.
Application de service Connexion de données métiers
Bases de données : Connexion de données métiers
Application de service de profil utilisateur
Bases de données : Profils, Synchronisation, Liaison de mise en réseau
Les bases de données de profils, de synchronisation et de liaison de mise en réseau ne peuvent pas être copiées via les journaux des transactions.
Pour fournir la redondance pour l’application de service de profil utilisateur, vous devez d’abord déployer l’application de service à la fois sur le centre de données primaire et sur le centre de données secondaire.
Pour configurer les bases de données de profils et de synchronisation, il est recommandé de récupérer une sauvegarde des bases de données pour le centre de données secondaire et de les attacher à l’application de service de profil utilisateur dans ce centre de données.
Pour conserver les profils synchronisés, vous devez exécuter le moteur de réplication des profils utilisateur qui se trouve dans SharePoint Administration Toolkit, après que les données de profils ont été mises à jour sur la batterie principale. Pour plus d’informations, voir Vue d’ensemble du moteur de réplication des profils utilisateur (SharePoint Server 2010).
Application de service de paramètres d’abonnement Microsoft SharePoint Foundation
Base de données : Abonnement
Notes
La copie de la base de données de paramètres d’abonnement via les journaux des transactions n’est pas prise en charge.
Access Services
Bases de données : Aucune
Excel Services
Bases de données : Aucune
Recherche
Bases de données : Analyse, Propriétés, Administration de recherche
L’application de service de recherche requiert une synchronisation complète entre ses bases de données et ses index. En raison de cette condition requise, la recherche ne peut pas être répliquée entre des batteries à l’aide d’un mécanisme de réplication asynchrone (mise en miroir de base de données asynchrone, copie via les journaux des transactions ou réplication SAN asynchrone).
Pour fournir une recherche à jour sur une batterie de basculement, vous devez exécuter la recherche sur la batterie secondaire.
Important
L’application de service de recherche sur la batterie de basculement doit être définie de façon à analyser activement la batterie secondaire. Lors du basculement, vous devez configurer l’association de l’application Web pour qu’elle utilise l’application de service de recherche de la batterie de basculement.
Service d’état
Bases de données : État
Notes
La copie de la base de données d’état via les journaux des transactions n’est pas prise en charge.
Visio Services
Bases de données : Aucune
Word Automation Services
Bases de données : Word Automation Services
La copie de la base de données Word Automation Services via les journaux des transactions n’est pas prise en charge.
Configuration système requise pour la récupération d’urgence
Dans un scénario idéal, les composants et les systèmes de basculement correspondent en tout aux composants et aux systèmes principaux : plateforme, matériel et nombre de serveurs. Au minimum, l’environnement de basculement doit être capable de gérer le trafic que vous attendez lors d’un basculement. Rappelez-vous que le site de basculement ne peut prendre en charge qu’un sous-ensemble des utilisateurs. Les systèmes doivent correspondre au moins pour les éléments suivants :
Versions et toutes les mises à jour des systèmes d’exploitation
Versions et toutes les mises à jour de SQL Server
Versions et toutes les mises à jour de Produits SharePoint 2010
Bien que cet article traite principalement de la disponibilité de Produits SharePoint 2010, le temps nécessaire pour que le système soit opérationnel sera également affecté par les autres composants du système. En particulier, vérifiez bien les points suivants :
Vérifiez que les dépendances de l’infrastructure telles que l’alimentation, le refroidissement, le réseau, l’annuaire et SMTP sont entièrement redondants.
Choisissez un mécanisme de commutation, comme DNS ou l’équilibrage de charge matériel, qui correspond à vos besoins.