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

**Sapplique à :**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2018-02-15

Résumé : Familiarisez-vous avec les options de récupération d’urgence et les technologies prises en charge pour la récupération d’une batterie de serveurs SharePoint Server 2016 et SharePoint 2013 en cas de sinistre.

Nous définissons la récupération d’urgence comme la capacité à remédier à une situation dans laquelle le centre de données principal qui héberge une batterie de serveurs SharePoint Server n’est pas en mesure de continuer à fonctionner. Quelle que soit la nature de l’événement et sa cause, une panne du centre de données suffit pour mettre en œuvre les actions définies dans le plan de récupération d’urgence de votre organisation. Cela implique de mettre en production une batterie de serveurs totalement opérationnelle à l’aide de ressources informatiques situées dans un centre de données qui n’est pas touché par l’événement.

Contenu de cet article :

• Introduction

• Options de récupération du centre de données de secours

• Configuration système requise pour la récupération

SharePoint Server 2016 et SQL Server 2014 avec Service Pack 1 (SP1) ou SQL Server 2016, et SharePoint 2013 et SQL Server 2008 R2 avec Service Pack 1 (SP1) ou SQL Server 2012 fournissent des options de récupération de configuration et de contenu qui peuvent satisfaire aux objectifs de délai de récupération et de point de récupération, lesquels sont essentiels pour votre entreprise en cas de sinistre. Pour plus d’informations au sujet de ces concepts de récupération d’urgence, reportez-vous à Concepts relatifs à la haute disponibilité et à la récupération d’urgence dans SharePoint Server.

Introduction

Pour être efficace, la stratégie de récupération d’urgence d’une batterie de serveurs SharePoint Server doit satisfaire de manière suffisante aux exigences de votre organisation, lesquelles sont généralement exprimées à l’aide de deux mesures : l’objectif de délai de récupération et l’objectif de point de récupération. Ces deux exigences sont déterminées en évaluant le coût du temps mort pour l’organisation impliqué par un sinistre.

Les coûts des temps morts varient considérablement en fonction des secteurs et au sein de chaque secteur, en particulier en raison de la différence des effets des temps morts. La taille de l’entreprise est le facteur le plus évident, mais ce n’est pas le seul. La définition d’une mesure implique l’établissement de la nature et des conséquences de la défaillance. Pour faire simple, la défaillance d’une application essentielle pourrait conduire aux types de dommages suivants :

• Perte de service de l’application. L’effet des temps morts varie en fonction de l’application et de l’entreprise.

• Perte de données. La perte potentielle de données due à une panne système peut avoir un impact juridique et financier important.

Pour la plupart des organisations, les deux types de pertes ci-dessus engendreront des frais, mais la nature de l’activité exercée par l’entreprise déterminera le type de perte ayant l’impact le plus important. L’article suivant, rédigé par Chris Preimesberger sur eWEEK, souligne l’impact financier des temps morts d’un centre de données : Unplanned IT Downtime Can Cost $5K Per Minute: Report (Rapport : le coût des temps morts informatiques non planifiés peut s’élever à 5 000 $ par minute).

Dans la plupart des scénarios, les Produits SharePoint font partie des nombreuses applications devant être récupérées en cas d’arrêt d’urgence du centre de données. C’est pour cette raison que nous n’avons pas inclus d’informations sur la planification de la récupération d’urgence, pour nous concentrer sur les options permettant de s’assurer que vous pourrez récupérer votre batterie de serveurs SharePoint Server 2016 à un autre endroit.

Quel que soit le type et l’ampleur du sinistre, la récupération implique l’utilisation d’un centre de données de secours vers lequel vous pouvez récupérer la batterie.

Options de récupération du centre de données de secours

Les centres de données de secours sont nécessaires lorsque les systèmes redondants locaux et les sauvegardes ne peuvent pas être utilisés pour la récupération suite à une panne du centre de données principal. Le temps et les efforts immédiats nécessaires pour obtenir une batterie de remplacement fonctionnelle à un autre emplacement correspondent généralement à trois catégories : automatique, semi-automatique et à reprise progressive. Voici nos définitions de ces types de centres de données de récupération de batterie de serveurs :

• À reprise progressive : centre de données secondaire pouvant être disponible en plusieurs heures ou en quelques jours.

• Semi-automatique : centre de données secondaire pouvant être disponible en plusieurs minutes ou en quelques heures.

• Automatique : centre de données secondaire pouvant être disponible en plusieurs secondes ou en quelques minutes.

Chacun de ces centres de données de secours a des caractéristiques et des exigences spécifiques, ainsi qu’un coût d’exploitation et de maintenance.

• Stratégie de récupération d’urgence à reprise progressive : l’entreprise envoie des sauvegardes pour assurer la récupération complète du système vers un emplacement de stockage hors site local et régional régulièrement et a passé des contrats de location de serveur d’urgence dans une autre région.

  Avantages :

  • Maintenance opérationnelle la plus économique des trois options.

  • Récupération généralement onéreuse, car les serveurs physiques doivent être configurés correctement après un sinistre.

  Inconvénients : Récupération la plus lente parmi les trois options.

• Stratégie de récupération d’urgence semi-automatique : l’entreprise envoie des sauvegardes ou des images d’ordinateur virtuel vers des batteries de serveurs de récupération d’urgence locales et régionales.

  Avantages : Récupération plutôt économique, car une batterie de serveurs virtuels ne requiert qu’une configuration minimale lors de la récupération.

  Inconvénients : Maintenance susceptible d’être très onéreuse et longue.

• Stratégie de récupération d’urgence automatique : l’entreprise exécute plusieurs centres de données, mais n’envoie du contenu et des services qu’à un seul centre de données.

  Avantages : Récupération généralement rapide.

  Inconvénients : Configuration et maintenance susceptibles d’être très onéreuses.

Récupération d’urgence à reprise progressive

Dans un scénario de récupération d’urgence à reprise progressive, vous effectuez la récupération en configurant une nouvelle batterie de serveurs à un nouvel emplacement (de préférence en utilisant des scripts de déploiement) et en restaurant les sauvegardes. Sinon, vous pouvez effectuer la récupération en restaurant la batterie de serveurs à l’aide d’une solution de sauvegarde telle que System Center 2016 - Data Protection Manager (DPM) ou System Center 2012 - Data Protection Manager (DPM). System Center Data Protection Manager protège vos données au niveau du système d’exploitation de votre ordinateur et vous permet de restaurer chaque serveur individuellement. Cet article ne contient pas d’instructions détaillées sur la façon de créer et d’effectuer des récupérations dans les scénarios de récupération d’urgence à reprise progressive. Pour plus d’informations, voir :

• Vue d’ensemble de la sauvegarde et de la récupération dans SharePoint Server

• Planifier la sauvegarde et la récupération dans SharePoint Server

Récupération d’urgence semi-automatique

Dans un scénario de récupération d’urgence semi-automatique, vous créez un environnement de secours semi-automatique en dupliquant une batterie de serveurs sur le centre de données de remplacement et vous vous assurez qu’il est régulièrement mis à jour à l’aide de sauvegardes complètes et incrémentielles de la batterie principale.

Environnements virtuels de secours semi-automatique

La virtualisation est une option viable et économique pour une solution de récupération de secours semi-automatique. Vous pouvez utiliser Hyper-V comme solution interne ou Azure en tant que solution hébergée pour assurer la fourniture de l’infrastructure nécessaire à la récupération.

Vous pouvez créer des images virtuelles des serveurs de production et envoyer ces images vers le centre de données de secours. Si vous choisissez cette solution de secours virtuelle, assurez-vous que les images virtuelles sont créées assez souvent afin de fournir le niveau de configuration de batterie et d’actualisation du contenu nécessaire pour la récupération de la batterie. À l’emplacement secondaire, vous devez disposer d’un environnement disponible dans lequel vous pouvez facilement configurer et connecter les images pour recréer votre environnement de batterie. Pour plus d’informations, consultez la rubrique Déploiement de SharePoint Server 2016 avec des groupes de disponibilité AlwaysOn SQL Server dans Azure

Récupération de secours automatique

Dans un scénario de récupération de secours automatique d’urgence, vous configurez une batterie de basculement dans le centre de données de secours afin qu’elle puisse assumer les opérations de production presque immédiatement après la déconnexion de la batterie principale. Un environnement qui possède une batterie de basculement distincte présente les caractéristiques suivantes :

• Une base de données de configuration distincte et la base de données de contenu pour le site Web Administration centrale de SharePoint doivent être maintenues sur la batterie de basculement.

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

  Conseil

  Il existe une certaine cohérence entre les deux batteries de serveurs et, afin de réduire le risque d’erreur, nous vous recommandons d’utiliser des scripts de déploiement pour créer la batterie principale et la batterie de basculement en utilisant les mêmes paramètres de configuration et les mêmes personnalisations.

• Les mises à jour logicielles du système d’exploitation, de SQL Server et des SharePoint Server doivent être appliquées aux deux batteries, afin de maintenir la cohérence de la configuration entre les deux batteries.

• Vous pouvez copier les bases de données de contenu des SharePoint Server sur la batterie de basculement en utilisant la mise en miroir asynchrone, la validation asynchrone sur un réplica de groupe de disponibilité ou la copie des journaux de transaction.

  Notes

  La mise en miroir de SQL Server ne peut être utilisée que pour copier des bases de données sur un serveur miroir unique, mais vous pouvez copier des journaux de transaction vers plusieurs serveurs secondaires.
  La fonctionnalité de mise en miroir de bases de données SQL Server sera supprimée dans les prochaines versions. Nous vous recommandons d’éviter de l’utiliser dans tout nouveau développement. Pensez à modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez plutôt les groupes de disponibilité AlwaysOn.

• Les applications de service différent selon que leurs journaux de transactions peuvent être copiés vers une batterie de serveurs ou non. Pour plus d’informations, voir Redondance des applications de service entre centres de données plus loin dans cet article.

La topologie de la batterie de serveurs de secours automatique peut être répliquée dans plusieurs centres de données, tant que vous configurez la copie des journaux de transaction SQL Server vers un ou plusieurs centres de données supplémentaires.

Redondance des applications de service

Pour assurer la disponibilité dans tous les centres de données pour les applications de service, nous recommandons, pour les services qui peuvent être exécutées sur différentes batteries, d’exécuter une batterie de services distincte accessible à la fois depuis le centre de données principal et secondaire.

Pour les services qui ne peuvent être exécutés sur différentes batteries, et afin d’assurer la disponibilité de la batterie de service, la stratégie de fourniture de redondance entre les centres de données pour une application de service varie. La stratégie employée dépend des éléments suivants :

• Il est intéressant pour l’entreprise d’exécuter l’application de service dans la batterie de serveurs de récupération lorsqu’elle n’est pas utilisée.

• Les bases de données associées à l’application de service peuvent être mises en miroir de manière asynchrone, répliquées à l’aide de la validation asynchrone ou leurs journaux de transaction peuvent être copiés.

• L’application de service peut être exécutée sur des bases de données en lecture seule.

Consultez l’article Options de haute disponibilité et de récupération d’urgence prises en charge pour les bases de données SharePoint avant de concevoir une solution de récupération d’urgence qui utilise un centre de données de secours automatique ou semi-automatique.

Configuration système requise pour la récupération

Dans un scénario idéal, les composants et les systèmes de basculement correspondent aux principaux composants et systèmes en tous points : plateforme, matériel et nombre de serveurs. Au minimum, l’environnement de basculement doit être capable de gérer le trafic que vous attendez pendant un basculement. Gardez à l’esprit que seul un sous-ensemble d’utilisateurs ne pourra bénéficier du site de basculement. Les systèmes doivent correspondre au minimum sur les éléments suivants :

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

• Les versions SQL Server et toutes les mises à jour

• Les versions SharePoint Server et toutes les mises à jour

En plus des exigences précédentes, le délai de récupération de la batterie sera également fonction de la disponibilité des installations et des composants de l’infrastructure. Assurez-vous que les conditions suivantes sont remplies :

• L’alimentation, le refroidissement, le réseau, le répertoire et le protocole SMTP sont totalement redondants

• Choisissez un mécanisme de commutation que répond à vos besoins, que ce soit l’équilibrage de charge matérielle ou DNS.

See also

Concepts relatifs à la haute disponibilité et à la récupération d’urgence dans SharePoint Server