Planifier la récupération d’urgence (SharePoint Foundation 2010)

 

S’applique à : SharePoint Foundation 2010

Dernière rubrique modifiée : 2016-11-30

Cet article décrit les décisions clés à prendre lorsqu’il s’agit de choisir des stratégies de récupération d’urgence pour un environnement Microsoft SharePoint Foundation 2010.

Dans cet article :

• Vue d'ensemble de la récupération d'urgence

• Choisir une stratégie de récupération d'urgence

• Planification pour un secours à froid

• Planning for warm standby data centers

• Planification pour des centres de données de secours à chaud

• Configuration requise pour la récupération d'urgence

Vue d’ensemble de la récupération d’urgence

Pour les besoins du présent article, nous définirons la récupération d’urgence comment étant la capacité à récupérer d’une situation où un centre de données qui héberge SharePoint Foundation devient indisponible.

La stratégie de récupération d’urgence que vous utilisez pour SharePoint Foundation doit être coordonnée avec celle qui s’applique à l’infrastructure associée, notamment les domaines Active Directory, Exchange Server et Microsoft SQL Server. Collaborez avec les administrateurs de l’infrastructure sur laquelle vous reposez pour concevoir une stratégie et un plan de récupération d’urgence coordonnés.

Le temps et les efforts immédiats nécessaires à la mise en service d’une autre batterie de serveurs sur un site différent ont un nom. Ils sont souvent appelés secours à chaud, secours semi-automatique ou secours à froid. Nos définitions de ces termes sont les suivantes :

Secours à chaud Second centre de données capable d’assurer une disponibilité en quelques minutes ou secondes.

Secours semi-automatique Second centre de données capable d’assurer une disponibilité en quelques minutes ou heures.

Secours à froid Second centre de données capable d’assurer une disponibilité en quelques heures ou jours.

La récupération d’urgence peut être l’une des exigences les plus coûteuses à l’échelle d’un système. Plus le délai qui s’écoule entre la panne et le rétablissement de la disponibilité est bref et plus les systèmes que vous protégez sont nombreux, plus il y a de chances pour que la solution de récupération d’urgence soit complexe et coûteuse. Lorsque vous investissez dans des centres de données de secours à chaud ou semi-automatique, les coûts englobent :

• les éléments matériels et logiciels supplémentaires, qui accentuent souvent la complexité des opérations entre les applications logicielles, telles que les scripts personnalisés pour le basculement et la récupération ;

• une complexité opérationnelle supplémentaire.

Les coûts de maintenance des centres de données de secours à chaud ou semi-automatique doivent être évalués en fonction des besoins de votre entreprise. Les solutions au sein d’une organisation ne sont pas toutes susceptibles de demander le même niveau de disponibilité après un incident. Vous pouvez proposer différents niveaux de récupération d’urgence en fonction du contenu, des services ou des batteries de serveurs (p.ex., contenu ayant le plus fort impact sur votre activité, services de recherche ou batterie de serveurs de publication sur Internet).

La récupération d’urgence est un domaine clé dans lequel les groupes informatiques proposent des contrats de niveau de service (SLA) pour fixer les attentes avec les groupes clients. De nombreuses organisations informatiques offrent différents contrats de niveau de service associés à différents niveaux de facturation.

Si vous envisagez d’implémenter le basculement entre différentes batteries de serveurs, nous vous recommandons dans un premier temps de déployer et configurer la solution de base dans une batterie de serveurs, puis d’implémenter et tester la récupération d’urgence.

Choisir une stratégie de récupération d’urgence

En matière de récupération d’urgence pour un environnement SharePoint Foundation, vous avez le choix entre diverses approches qui dépendent des besoins de votre entreprise. Les exemples suivants exposent les raisons qui peuvent amener les sociétés à opter pour des stratégies de récupération d’urgence reposant de secours à froid, à chaud ou semi-automatique.

• Stratégie de récupération d’urgence de secours à froid : une entreprise expédie régulièrement des sauvegardes pour permettre une récupération complète à des emplacements de stockage hors site locaux et régionaux, et a souscrit des contrats de location de serveurs d’urgence dans une autre région.

  Avantages :

  • Souvent la solution la plus économique sur le plan de la maintenance opérationnelle.

  • Souvent une solution coûteuse en matière de récupération, car elle exige que les serveurs physiques soient correctement configurés après un incident.

  Inconvénients : la solution de récupération la plus lente.

• Stratégie de récupération d’urgence de secours semi-automatique : une entreprise expédie des images de serveurs virtuels à destination de batteries de serveurs de récupération d’urgence locales et régionales.

  Avantages : récupération souvent relativement peu coûteuse, car une batterie de serveurs virtuels ne demande pas nécessairement une configuration importante après récupération.

  Inconvénients : maintenance potentiellement très coûteuse et fastidieuse.

• Stratégie de récupération d’urgence de secours à chaud : une entreprise utilise plusieurs centres de données, mais délivre le contenu et les services par le biais d’un seul et même centre de données.

  Avantages : récupération souvent relativement rapide.

  Inconvénients : configuration et maintenance potentiellement coûteuses.

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 des données.

Planification pour des centres de données de secours à froid

Dans un scénario de récupération d’urgence de secours à froid, vous pouvez effectuer une récupération en configurant une nouvelle batterie de serveurs sur un nouveau site (de préférence, en recourant à un déploiement à base de script), puis en restaurant les sauvegardes. Une autre solution consiste à restaurer 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 vous permet de restaurer chaque serveur séparément. Cet article ne fournit pas d’instructions de création et de récupération détaillées dans les scénarios de secours à froid. Pour plus d’informations, voir :

• Restaurer une batterie de serveurs (SharePoint Foundation 2010)

• Restaurer les personnalisations (SharePoint Foundation 2010)

Planification pour des centres de données de secours semi-automatique

Dans un scénario de récupération d’urgence de secours semi-automatique, vous pouvez créer une solution de secours semi-automatique en veillant à créer de façon systématique et fréquente des images virtuelles des serveurs de votre batterie que vous expédiez à destination d’un site secondaire. Sur ce site, vous devez disposer d’un environnement qui permette de configurer et connecter facilement les images afin de recréer votre environnement de batterie de serveurs.

Cet article ne contient pas d’instructions détaillées expliquant comment créer des solutions de secours semi-automatique. Pour plus d’informations sur la planification de déploiements de batteries de serveurs à l’aide de solutions virtuelles, voir Planifier la virtualisation (SharePoint Foundation 2010).

Planification pour des centres de données de secours à chaud

Dans un scénario de récupération d’urgence de secours à chaud, vous pouvez configurer une batterie de serveurs de basculement pour assurer une récupération d’urgence dans un centre de données distinct à partir de la batterie principale. Un environnement qui comporte une batterie de serveurs de basculement distincte présente les caractéristiques suivantes :

• une base de données de configuration et une base de données de contenu Administration centrale distinctes doivent être maintenues dans la batterie de serveurs de basculement ;

• toutes les personnalisations doivent être déployées dans les deux batteries de serveurs.

  Notes

  Il est recommandé d’utiliser un déploiement à base de script pour créer la batterie de serveurs principale et la batterie de serveurs de déploiement avec les mêmes paramètres de configuration et les mêmes personnalisations.

• Les mises à jour doivent être appliquées aux deux batteries de serveurs, séparément.

• Les bases de données de contenu SharePoint Foundation peuvent être mises en miroir de façon asynchrone ou faire l’objet d’une copie des journaux de transaction dans la batterie de serveurs de basculement.

  Notes

  La mise en miroir SQL Server peut être utilisée uniquement pour copier des bases de données sur un serveur miroir unique, mais vous pouvez copier les journaux de transaction sur plusieurs serveurs secondaires.

• Dans le cas des applications de service, la copie des journaux de transactions sur une batterie de serveurs n’est pas toujours possible. Pour plus d’informations, voir Redondance des applications de service dans les centres de données plus loin dans cet article.

Cette topologie peut être reproduite dans de nombreux centres de données si vous configurez la copie des journaux de transaction SQL Server dans un ou plusieurs centres de données supplémentaires.

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

La figure suivante illustre une batterie de serveurs principale et une batterie de serveurs de basculement avant basculement.

Batterie de serveurs principale et batterie de serveurs de basculement avant basculement

Redondance des applications de service dans les centres de données

Pour assurer la disponibilité des applications de service dans les centres de données, il est recommandé pour les services qui peuvent être exécutés sur les différents centres de données d’exécuter une batterie de services distincte qui soit accessible à partir des centres de données principal et secondaire(s).

Pour les services qui ne peuvent pas être exécutés sur les différentes batteries de serveurs, et pour fournir une disponibilité à la batterie de services proprement dite, les stratégies visant à assurer une redondance dans les centres de données pour un service varient selon que :

• il existe un intérêt économique à ce que l’application de service soit exécutée dans la batterie de serveurs 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 fait l’objet d’une copie des journaux de transaction ou d’une mise en miroir asynchrone ;

• l’application de service peut s’exécuter sur des bases de données en lecture seule.

Les sections suivantes décrivent les stratégies de récupération d’urgence que nous recommandons pour chaque application de service. Les applications de service sont regroupées par stratégie.

Bases de données pouvant faire l’objet d’une copie des journaux de transaction ou d’une mise en miroir asynchrone

Après qu’une application de service a été initialement déployée dans une batterie de serveurs secondaire, les bases de données qui prennent en charge les applications de service suivantes peuvent faire l’objet d’une mise en miroir asynchrone ou d’une copie des journaux de transaction dans les batteries de serveurs :

• Application de service Registre d’application

  Bases de données : service Registre d’application

• Application de service Business Data Connectivity

  Bases de données : Business Data Connectivity

• Application de service de collecte de données relatives à l’utilisation et à l’état

  Bases de données : journalisation

  Notes

  La base de données de journalisation peut faire l’objet d’une copie des journaux de transaction ou d’une mise en miroir. Toutefois, il est déconseillé d’exécuter le service de collecte de données relatives à l’utilisation et à l’état dans la batterie de serveurs de récupération d’urgence, de procéder à une mise en miroir ou à la copie des journaux de transaction pour la base de données de journalisation.

Applications de service et bases de données ne pouvant pas faire l’objet d’une copie des journaux de transaction ou d’une mise en miroir asynchrone

Les applications de service suivantes doivent être déployées à la fois dans la batterie de serveurs principale et dans la batterie de serveurs de basculement, et elles ne peuvent pas faire l’objet d’une copie des journaux de transaction ou d’une mise en miroir asynchrone. Pour la plupart de ces applications de service, il est recommandé de les déployer puis de vérifier que les paramètres de configuration de la batterie de serveurs de basculement sont identiques à ceux de la batterie de serveurs principale. Si la configuration de la batterie de serveurs principale est modifiée et que ces modifications affectent le service, vous devez mettre à jour la batterie de serveurs de basculement.

• Application de service de paramètres d’abonnement Microsoft SharePoint Foundation

  Base de données : paramètres d’abonnement

  Notes

  La copie des journaux de transaction n’est pas prise en charge dans le cas de la base de données des paramètres d’abonnement.

Configuration requise pour la récupération d’urgence

Dans l’idéal, les composants et les systèmes de basculement doivent correspondre en tous points aux composants et aux systèmes principaux : plateforme, matériel et nombre de serveurs. Au minimum, l’environnement de basculement doit être en mesure de gérer le trafic attendu lors d’un basculement. Ne perdez pas de vue que seul un sous-ensemble d’utilisateurs pourra être desservi par le site de basculement. Les systèmes doivent au moins correspondre sur les points suivants :

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

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

• versions de Produits SharePoint 2010 et toutes les mises à jour.

Bien que cet article porte enssentiellement sur la disponibilité de Produits SharePoint 2010, la durée active du système sera également affectée par les autres composants du système. En particulier, veillez à effectuer les opérations suivantes :

• Assurez-vous que les dépendances d’infrastructure, telles que l’alimentation, le refroidissement, le réseau, l’annuaire et le service SMTP sont entièrement redondants.

• Choisissez un mécanisme de basculement (équilibrage de charge matérielle ou DNS) qui réponde à vos besoins.