Choisir une stratégie de récupération d’urgence pour SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
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.
SharePoint Server 2019, 2016, 2013 et les serveurs SQL Server qui les prennent en charge fournissent des options de configuration et de récupération de contenu qui peuvent répondre à l’objectif de temps de récupération (RTO) et à l’objectif de point de récupération (RPO) requis 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.
Importante
Nous vous recommandons d'identifier et de quantifier clairement l'objectif de délai de récupération et l'objectif de point de récupération de votre organisation avant de développer une stratégie de récupération et de mettre en œuvre une solution technique. Concentrez-vous sur ce qui doit être fait, et non la façon de le faire.
Les coûts des temps d’arrêt varient considérablement d’un secteur à l’autre, en particulier en raison des différents effets des temps d’arrêt. La taille de l’entreprise est le facteur le plus évident. Cependant, ce n’est pas le seul. Définir une mesure signifie établir la nature et les implications de l’échec. Réduit au niveau le plus simple, un échec d’une application critique peut entraîner les types de pertes 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.
La plupart des organisations entraînent un coût de temps d’arrêt des deux types de perte précédents, mais la nature de l’entreprise détermine quel type de perte a le plus d’effet. L’article suivant, écrit par Chris Preimesberger à eWEEK, met en évidence l’impact financier du temps d’arrêt du centre de données. Un temps d’arrêt informatique non planifié peut coûter 5 000 $ par minute : Rapport.
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. Pour cette raison, nous n’avons pas inclus d’informations sur la planification de la récupération d’urgence, mais nous nous concentrons sur les options permettant de vous assurer que vous pouvez récupérer votre batterie de serveurs SharePoint Server à un autre emplacement.
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 :
Veille à froid. Un centre de données secondaire qui peut fournir une disponibilité en quelques heures ou jours.
Secours à chaud. Un centre de données secondaire qui peut fournir une disponibilité en quelques minutes ou heures.
Secours à chaud. Un centre de données secondaire qui peut fournir une disponibilité en quelques secondes ou 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.
Pros: 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 avec Azure Site Recovery.
Pros: Récupération plutôt économique, car une batterie de serveurs virtuels requiert une configuration minimale au moment de la récupération.
Cons: 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.
Pros: Récupération généralement rapide.
Cons: Configuration et maintenance susceptibles d'être très onéreuses.
Importante
Quelle que soit la solution de récupération d’urgence ci-dessus que vous décidez d’appliquer, certaines données seront très probablement perdues.
Récupération d’urgence à reprise progressive
Dans un scénario de récupération d’urgence de secours à froid, vous récupérez en configurant une nouvelle batterie de serveurs dans un nouvel emplacement (de préférence à l’aide d’un déploiement scripté) et en restaurant les sauvegardes. Vous pouvez également récupérer en restaurant la batterie à l’aide d’une solution de sauvegarde telle que System Center - Data Protection Manager (DPM). DPM protège vos données au niveau du système d’exploitation de l’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. Pour plus d’informations, consultez Déploiement de SharePoint Server avec des groupes de disponibilité Sql Server Always On 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 d’utiliser cette fonctionnalité dans les nouveaux déploiements. Pensez à modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez plutôt des groupes de disponibilité Always On.
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 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.
Importante
La disponibilité de la bande passante et de la latence du réseau est un facteur important à prendre en compte quand vous utilisez une approche de basculement pour la récupération d'urgence. Nous vous recommandons de consulter votre fournisseur SAN pour déterminer si vous pouvez utiliser la réplication SAN pour les bases de données SQL ou un autre mécanisme pris en charge pour fournir le niveau de disponibilité de secours à chaud dans les centres de données. Notez que l’utilisation de la réplication SAN pour les serveurs SharePoint n’est pas prise en charge.
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.
Voir aussi
Concepts
Concepts relatifs à la haute disponibilité et à la récupération d’urgence dans SharePoint Server
Autres ressources
Quelles charges de travail pouvez-vous protéger avec Azure Site Recovery ?