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

S’APPLIQUE À :2013 2016 2019 Édition d’abonnement SharePoint dans Microsoft 365

La haute disponibilité et la récupération d’urgence constituent la priorité la plus élevée lorsque vous créez un plan et des spécifications système pour une batterie de serveurs SharePoint Server. D’autres aspects du plan, tels que les hautes performances et la capacité, sont réduits à néant si les serveurs de la batterie ne sont pas hautement disponibles ou si une batterie de serveurs ne peut pas être récupérée.

Pour concevoir et implémenter une stratégie efficace qui permet de garantir un fonctionnement optimal et continu, vous devez comprendre les concepts de base liés à la haute disponibilité et à la récupération d’urgence. Ces concepts sont également importants pour évaluer et choisir les meilleures solutions techniques pour votre environnement SharePoint.

Introduction à la gestion de la continuité des opérations

La gestion de la continuité d’activité est un processus ou un programme de gestion qui définit, évalue et aide à gérer les risques liés au fonctionnement continu d’une organisation. La gestion de la continuité d’activité se concentre sur la création et la maintenance d’un plan de continuité d’activité, qui est une feuille de route pour la poursuite des opérations lorsque les opérations normales sont interrompues par des conditions défavorables. Ces conditions peuvent être naturelles, faites par l’homme ou une combinaison des deux. Un plan de continuité est dérivé des analyses et entrées suivantes :

• Analyse d’impact sur les opérations

• Analyse des menaces et des risques

• Définition des scénarios d’impact

• Ensemble d’exigences de récupération documentées

Il en résulte une conception de solution ou une identification des options disponibles, un plan d’implémentation, un plan de test et d’acceptation par l’organisation, ainsi qu’un plan ou une planification de maintenance.

Un exemple de gestion de la continuité des opérations figure ici . Vous y trouverez une présentation du programme de continuité des opérations de Microsoft.

De toute évidence, les technologies de l’information représentent un aspect important de la planification de la continuité des opérations pour de nombreuses organisations. Toutefois, la continuité des opérations englobe d’autres aspects : elle inclut toutes les opérations qui sont nécessaires pour s’assurer qu’une organisation peut rester opérationnelle pendant et immédiatement après un incident majeur. Un plan de continuité des opérations comprend, mais sans s’y limiter, les éléments suivants :

• stratégies, processus et procédures ;

• options possibles et responsabilité de la prise de décision ;

• ressources humaines et installations ;

• technologies de l’information.

Bien que la haute disponibilité et la récupération d’urgence soient souvent assimilées à la gestion de la continuité des opérations, ils sont en fait des sous-ensembles de la gestion de la continuité des opérations.

Description de la haute disponibilité

Pour une application ou un service logiciel donné, la haute disponibilité est finalement mesurée en termes d’expérience et d’attentes de l’utilisateur final. L’impact concret et perceptible du temps mort peut être exprimé en termes de perte d’informations, de dégâts matériels, de baisse de la productivité, de coûts d’opportunité, de préjudices contractuels ou de perte de clientèle.

L’objectif principal d’une solution de haute disponibilité est de minimiser ou d’atténuer l’impact du temps mort. Une bonne stratégie consiste à équilibrer de manière optimale les processus d’entreprise et les contrats SLA par rapport aux capacités techniques et aux coûts d’infrastructure.

Une plateforme est considérée comme hautement disponible conformément à l’accord et aux attentes des clients et des parties prenantes. La disponibilité d’un système peut être exprimée sous la forme du calcul suivant :

Temps de fonctionnement réel/temps de fonctionnement attendu X 100 %

La valeur résultante est souvent exprimée en nombre de 9 fournis par la solution. Cela permet d'indiquer un nombre annuel de minutes de temps de fonctionnement possible, ou à l'inverse, un nombre de minutes de temps mort.

Temps mort planifié et temps mort non planifié

Soit les indisponibilités du système sont anticipées ou planifiées, soit elles sont le résultat d’une défaillance imprévue. Le temps mort ne doit pas être considéré comme un aspect négatif, s’il est convenablement géré. Il existe deux principaux types de temps mort prévisibles :

• Maintenance planifiée. Une fenêtre de temps est annoncée à l’avance et coordonnée pour les tâches de maintenance planifiée telles que l’application de correctifs logiciels, les mises à niveau matérielles, les mises à jour de mots de passe, la réindexation hors connexion, le chargement des données ou le test des procédures de récupération d’urgence. Ces procédures opérationnelles bien gérées et intentionnelles doivent en principe permettre de minimiser les temps morts et d’éviter les pertes de données. Les activités de maintenance planifiée peuvent être considérées comme des investissements nécessaires pour anticiper ou atténuer d’autres scénarios d’indisponibilité non planifiée potentiellement plus graves.

• Indisponibilité non planifiée. Des défaillances au niveau du système, de l’infrastructure ou d’un processus peuvent se produire de manière non planifiée ou non contrôlée, ou de manière prévisible mais avec un taux de probabilité très faible ou un impact acceptable. Une solution de haute disponibilité robuste détecte ces types de défaillance, résout automatiquement le problème lié à l’indisponibilité, puis rétablit la tolérance de panne.

Lors de l’établissement des contrats SLA pour la haute disponibilité, calculez des indicateurs de performance clés distincts pour les activités de maintenance planifiée et les temps mort non planifiés. Cette approche vous permet de mesurer les avantages d’un investissement dans les activités de maintenance planifiée par rapport aux temps morts non planifiés qui sont évités.

Disponibilité dégradée

La haute disponibilité ne doit pas être considérée comme une proposition de type tout ou rien. Afin d’éviter une indisponibilité complète, il est souvent acceptable pour l’utilisateur final d’avoir accès à un système partiellement disponible, dont les fonctionnalités sont limitées ou dont les performances sont réduites. Voici les différents degrés de disponibilité :

• Opérations en lecture seule et différées. Durant une période de maintenance ou durant une récupération d’urgence progressive, la récupération des données est toujours possible, mais les nouveaux flux de travail et le traitement en arrière-plan peuvent être temporairement arrêtés ou mis en file d’attente.

• Latence des données et réactivité des applications. En raison d’une charge de travail importante, d’un backlog de traitement ou d’une défaillance partielle de la plateforme, les ressources matérielles limitées peuvent être sur-validées ou sous-dimensionnées. L’expérience utilisateur peut en souffrir, mais le travail peut toujours être effectué de manière moins productive.

• Défaillances partielles, passagères ou imminentes. La robustesse de la logique d’application ou de la pile matérielle permet l’exécution de nouvelles tentatives ou de corrections automatiques quand une erreur est détectée. Ces types de problème peuvent donner à l’utilisateur final une impression de latence des données ou de manque de réactivité de l’application.

• Défaillance partielle de bout en bout. Les indisponibilités planifiées ou non planifiées peuvent se produire de manière fluide, soit dans les couches verticales de la pile de la solution (infrastructure, plateforme et application), soit horizontalement entre les différents composants fonctionnels. Les utilisateurs peuvent constater une amélioration ou une dégradation partielle, selon les fonctionnalités ou les composants affectés.

L’acceptabilité de ces scénarios sous-optimaux doit être considérée dans le cadre d’une dégradation de la disponibilité menant à une indisponibilité complète, mais également en tant qu’étapes intermédiaires d’une récupération d’urgence progressive.

Quantification du temps mort

Quand un temps mort se produit, qu’il soit planifié ou non planifié, l’objectif principal de l’entreprise consiste à remettre le système en ligne et à minimiser la perte des données. Chaque minute de temps mort a des coûts directs et indirects. Avec un temps mort non planifié, vous devez équilibrer le temps et les efforts nécessaires afin de déterminer les raisons de l’indisponibilité, l’état actuel du système, ainsi que les mesures à entreprendre pour revenir à une situation normale.

À un moment prédéterminé durant une indisponibilité, vous devez prendre la décision d’arrêter de rechercher les causes de l’indisponibilité ou d’effectuer des tâches de maintenance. Vous devez revenir à une situation normale en remettant le système en ligne et, si nécessaire, rétablir la tolérance de panne.

Objectifs de récupération

La redondance des données est un composant clé d’une solution de base de données haute disponibilité. L’activité transactionnelle sur votre instance SQL Server principale est appliquée de manière synchrone ou asynchrone à une ou plusieurs instances secondaires. En cas d’indisponibilité, il est possible que les transactions qui étaient en cours d’exécution soient annulées, ou qu’elles soient perdues sur les instances secondaires en raison de retards de propagation des données.

Vous pouvez à la fois mesurer l’impact et fixer des objectifs en termes de délai de retour à la normale et de latence de la dernière transaction récupérée :

• Objectif de temps de récupération (RTO, Recovery Time Objective). Il s’agit de la durée de l’indisponibilité. L’objectif initial est de remettre le système en ligne au moins pour un accès en lecture seule afin de faciliter la recherche des causes du problème. Toutefois, l’objectif principal est de restaurer le service en totalité pour permettre aux nouvelles transactions d’avoir lieu.

• Objectif de point de récupération (RPO, Recovery Point Objective). Cet objectif est souvent désigné comme une mesure des pertes de données acceptables. Il représente l’intervalle ou le temps de latence entre la validation de la dernière transaction de données avant la défaillance et la récupération des données les plus récentes après la défaillance. La perte de données effective peut varier selon la charge de travail du système au moment de la défaillance, le type de défaillance et le type de solution de haute disponibilité utilisée.

  Notes

  L’objectif de niveau de récupération (RLO, Recovery Level Objective) est un objectif connexe. Cet objectif définit la granularité avec laquelle vous devez pouvoir récupérer des données, c’est-à-dire si vous devez pouvoir récupérer l’intégralité de la batterie de serveurs, de l’application web, de la collection de sites, du site, de la liste ou de la bibliothèque, ou encore de l’élément. Pour plus d'informations, voir Planifier la sauvegarde et la récupération dans SharePoint Server.

Utilisez les valeurs de l’objectif de temps de récupération et de l’objectif de point de récupération comme indicateurs pour la tolérance des temps morts et des pertes de données acceptables, ainsi que pour la surveillance de l’état de disponibilité.

Justification du retour sur investissement ou du coût d’opportunité

Les coûts liés au temps mort peuvent se traduire par une perte financière ou une perte de clientèle. Ces coûts peuvent s’accumuler avec le temps ou augmenter à un moment donné de la fenêtre d’indisponibilité. Outre la prévision du coût d’une indisponibilité avec un temps de récupération et un point de récupération des données spécifiques, vous pouvez également calculer les investissements nécessaires en matière d’infrastructure et de processus d’entreprise pour atteindre votre objectif de temps de récupération et votre objectif de point de récupération, ou pour éviter une indisponibilité complète. Ces investissements doivent inclure les aspects suivants :

• Éviter les temps morts. Les coûts de récupération des pannes sont évités ensemble si une panne ne se produit pas en premier lieu. Les investissements incluent le coût de l’infrastructure ou du matériel redondant à tolérance de panne, la distribution des charges de travail sur des points de défaillance isolés, ainsi que la planification des temps morts à des fins de maintenance préventive.

• Automatisation de la récupération. Si une défaillance système se produit, vous pouvez considérablement réduire l’impact du temps mort sur l’expérience utilisateur grâce à une récupération automatique et transparente.

• Utilisation des ressources. Une infrastructure secondaire ou de secours est prête, dans l’attente d’une indisponibilité. Elle peut également être mise à profit pour les charges de travail en lecture seule ou pour l’amélioration des performances système globales via la répartition des charges de travail sur l’ensemble du matériel disponible.

Pour des objectifs de temps de récupération et de point de récupération donnés, les investissements nécessaires en matière de disponibilité et de récupération, combinés aux coûts prévus pour les temps morts, peuvent être exprimés et justifiés en fonction du temps. Durant une indisponibilité réelle, cela vous permet de prendre des décisions relatives aux coûts en fonction du temps mort écoulé.

Surveillance de l’état de disponibilité

D’un point de vue opérationnel, lors d’une indisponibilité réelle, vous ne devriez pas essayer de prendre en compte toutes les variables pertinentes afin de calculer le retour sur investissement ou les coûts d’opportunité en temps réel. En revanche, vous devriez plutôt surveiller la latence des données sur vos instances de secours comme solution intermédiaire pour atteindre un objectif de point de récupération attendu.

En cas d’indisponibilité, vous devriez également limiter le temps initial consacré à la recherche de l’origine du problème et vous concentrer plutôt sur la validation de l’intégrité de votre environnement de récupération. Appuyez-vous ensuite sur les détails des journaux système et les copies secondaires des données pour mener une analyse plus conséquente.

Planification de la récupération d’urgence

Les efforts en matière de haute disponibilité incluent ce que vous entreprenez pour éviter une indisponibilité, alors que les efforts en matière de récupération d’urgence incluent ce qui permet de rétablir la haute disponibilité après une indisponibilité.

Dans la mesure du possible, les procédures et responsabilités en matière de récupération d’urgence devraient être formulées avant toute indisponibilité effective. En fonction d’une surveillance active et des alertes, la décision d’entreprendre un basculement et une récupération automatiques ou manuels devrait être liée à des seuils préétablis en termes d’objectif de temps de récupération et d’objectif de point de récupération. Voici ce que devrait inclure un plan de récupération d’urgence cohérent :

• Granularité de la défaillance et de la récupération. Selon l’emplacement et le type de l’indisponibilité, vous pouvez prendre des mesures correctives à différents niveaux : centre de données, infrastructure, plateforme, application ou charge de travail.

• Matériel source d’investigation. Un historique de surveillance récent et de référence, des alertes système, des journaux des événements et des requêtes de diagnostic doivent être facilement accessibles pour les parties concernées.

• Coordination des dépendances. Dans la pile de l’application et entre les parties prenantes, quelles sont les dépendances aux niveaux du système et de l’entreprise ?

• Arbre de décision. Arbre de décision validé, prédéterminé et reproductible, qui inclut les responsabilités des rôles, le triage des erreurs, les critères de basculement en termes d’objectif de point de récupération et d’objectif de temps de récupération, ainsi que les étapes de récupération prescrites.

• Validation. Après avoir entrepris les mesures nécessaires pour résoudre le problème d’indisponibilité, que faut-il faire pour s’assurer que le système est revenu à la normale ?

• Documentation. Compilez tous les éléments ci-dessus dans un ensemble de documents, avec suffisamment de détails et de clarté pour permettre à une équipe tierce d’exécuter le plan de récupération avec une assistance minimale. Ce type de documentation est communément appelé « livre de série » ou « livre de cuisine ».

• Répétitions de récupération. Exercez régulièrement le plan de récupération d’urgence pour établir des attentes de base pour les objectifs de RTO et envisagez une rotation régulière de l’hébergement du site de production principal sur le site principal et chacun des sites de récupération d’urgence.

Voir aussi

Concepts

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

Autres ressources

Quelles charges de travail pouvez-vous protéger avec Azure Site Recovery ?

Répliquer une application SharePoint multiniveau pour la récupération d’urgence à l’aide d’Azure Site Recovery