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

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

**Dernière rubrique modifiée :**2017-08-01

Résumé : Découvrez les concepts de haute disponibilité et de récupération d’urgence dans SharePoint Server 2016 et SharePoint 2013 afin de choisir la meilleure stratégie pour votre batterie de serveurs.

La haute disponibilité et la récupération d’urgence sont des priorités quand vous créez le plan et les spécifications système d’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.

Contenu de cet article :

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

• Description de la haute disponibilité

• Quantification du temps mort

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

La gestion de la continuité des opérations est un programme ou processus de gestion qui définit, évalue et facilite la gestion des risques liés au fonctionnement en continu d’une organisation. La gestion de la continuité des opérations se concentre sur la création et la gestion d’un plan de continuité des opérations. Il s’agit d’une feuille de route visant à assurer la continuité des opérations en cas d’interruption liée à des situations défavorables. Ces situations peuvent avoir une origine naturelle et/ou artificielle. Un plan de la continuité est issu 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 un service ou une application logicielle spécifique, la haute disponibilité est mesurée en termes d’expérience et d’attente de la part 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 lourde charge de travail, d’un retard de traitement ou d’une défaillance partielle de la plateforme, les ressources matérielles limitées peuvent être validées de manière excessive ou sous-dimensionnées. L’expérience utilisateur peut en être affectée. Toutefois, le travail peut tout de même être effectué malgré une baisse de productivité.

• 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 de votre instance principale de SQL Server 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 d’un retour à la normale après une indisponibilité sont inexistants quand il n’y a pas d’indisponibilité tout simplement. 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é « manuel ».

• Exercices de récupération. Testez régulièrement le plan de récupération d’urgence pour établir les attentes de référence en matière d’objectif de temps de récupération. Par ailleurs, 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.

See also

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