Serveur d'impression

Planification de la continuité des opérations et de la reprise après sinistre pour SQL Server – Bien choisir son serveur d impression

Le 18 juillet 2019 - 12 minutes de lecture

Cet article de Dave Bermingham fournit des conseils pratiques pour aider les administrateurs de systèmes et de bases de données chargés de créer des plans de continuité des activités et de reprise après sinistre.

Le général George Patton émet le conseil suivant: «Un bon plan aujourd’hui vaut mieux qu’un plan parfait au lendemain». Aucun plan de continuité des opérations ou de reprise après sinistre ne peut éventuellement traiter tous les événements ou circonstances possibles. C’est pourquoi Les plans de la Colombie-Britannique et de la République dominicaine devraient évoluer en permanence, à mesure que les leçons apprises éclairent diverses améliorations.

Fournir les conseils nécessaires pour créer un plan de continuité des activités solide remplirait un livre. Mais comme le plan de continuité des opérations constitue la base du plan de reprise après sinistre, il convient au moins d’en discuter. Ce qui suit résume sept étapes qui se sont révélées utiles pour créer et améliorer des plans de continuité des activités.

Étape 1: Préparez-vous à planifier

Cette étape consiste principalement à collecter des informations pertinentes sur le personnel clé, les clients et fournisseurs, les installations, les services publics, les mesures de sécurité, les enregistrements, les procédures et processus d'exploitation, les contrats de service et de licence, les réglementations de confidentialité en vigueur, etc.

Étape 2: Établir les objectifs du plan

Le plan de continuité des activités doit soutenir la mission principale de l’organisation, ce qui suppose la définition d’un ensemble d’objectifs reposant sur une évaluation des perturbations potentielles. Les objectifs en matière de temps de récupération et de points de récupération (décrits ci-dessous), ainsi que le budget disponible avant, pendant et après une interruption, présentent un intérêt particulier pour les services informatiques.

Étape 3: Identifiez et hiérarchisez les menaces et les impacts potentiels

Bien qu’il ne soit pas possible de prévoir de toutes les manières possibles la perturbation des activités, il existe probablement des menaces en fonction du lieu et de la situation de l’organisation. Toutes les installations peuvent perdre de la puissance, mais seules certaines peuvent subir une tornade, un ouragan ou un tremblement de terre. Utilisez les probabilités pour déterminer les priorités et estimez la durée potentielle de chaque menace.

Étape 4: Élaborer des stratégies d'atténuation et de continuité des activités

C’est l’essentiel du plan de continuité des opérations, qui doit inclure des moyens de minimiser les impacts sur les activités avant, pendant et après la reprise après une interruption. Pour l'informatique, la criticité de la mission de chaque application sera utilisée pour déterminer sa priorité dans le plan de reprise après sinistre. Pour tous les départements, la capacité de maintenir les communications sera essentielle, en particulier en cas d'échec du plan et si une urgence est nécessaire.

Étape 5: Identifiez les équipes et les tâches

Cette étape pourrait être incluse à l’étape 4, mais elle est gardée séparément ici pour communiquer son importance. Après tout, ce sont les personnes qui mettront en œuvre le plan de continuité des activités et les personnes qui prendront les mesures qui s'imposent pour compenser les carences du plan, telles que les tâches critiques ne figurant pas dans une liste de contrôle. Cette étape doit également établir une ligne de succession avec des membres suppléants ou des équipes identifiées si les membres principaux sont indisponibles.

Étape 6: Testez le plan

Le meilleur moyen de détecter les failles dans le plan et de préparer les équipes à son implémentation est de le tester – minutieusement et régulièrement – en simulant les perturbations de l'activité causées par les menaces identifiées. Les coupures de courant programmées peuvent constituer des occasions idéales pour mener ces tests, mais certaines doivent également se produire sans préavis.

Étape 7: Maintenir / améliorer le plan

Cette étape est en cours et sert de boucle de rétroaction pour l’ajustement, la mise à jour, l’amélioration et le maintien du plan sur la base des enseignements tirés des tests et des perturbations effectives. Tout ce qui est nouveau, comme une nouvelle installation, une nouvelle application ou un nouveau service, doit également passer par le processus de planification séparément ou dans le cadre de cette étape continue.

Plan de reprise après sinistre

Le plan de reprise après sinistre pour les services informatiques s’appuie sur le plan de continuité des opérations avec des stratégies spécifiques qui protègent les données de l’entreprise et garantissent que les applications critiques peuvent continuer de fonctionner avec une interruption minimale, voire nulle. Deux aspects du plan de continuité des activités sont essentiels à la planification de la reprise après sinistre: l’évaluation de la menace à l’étape 3 et l’analyse de l’impact des activités à l’étape 4. Le premier identifie les catastrophes que l'organisation est le plus susceptible de subir, tandis que le second détermine les applications critiques.

Le plan devrait reconnaître la différence entre les "défaillances" et les "catastrophes", car cette différence peut entraîner la nécessité de mettre en œuvre des dispositions différentes pour la haute disponibilité (HA) et la reprise après sinistre. Les pannes sont de courte durée et de faible ampleur, affectant un serveur, un rack, l’alimentation ou le refroidissement d’un centre de traitement de données. Les catastrophes ont des impacts durables et sont plus répandues, affectant des centres de données entiers d'une manière qui empêche un rétablissement localisé rapide. Par exemple, une tornade, un ouragan ou un tremblement de terre peut couper le courant et les réseaux, et fermer des routes, rendant le centre de données inaccessible pendant plusieurs jours.

La principale différence réside peut-être dans la réplication sur des ressources redondantes (systèmes, logiciels et données), qui peuvent être locales – sur un réseau local – pour remédier à une défaillance. En revanche, la redondance requise pour se remettre d’un sinistre doit être "longue distance" sur un réseau étendu. Pour les applications de base de données nécessitant des performances de débit transactionnelles élevées, la possibilité de répliquer les données de l'instance active de manière synchrone sur le réseau local permet à l'instance de secours d'être "à chaud" (en synchronisation avec l'instance active), prête à prendre le relais immédiatement et automatiquement en cas d'événement. d'un échec. Une réponse aussi rapide devrait être l’objectif de toutes les dispositions relatives aux AP.

Étant donné que la latence inhérente au réseau WAN aurait un impact négatif sur les performances de débit de l'instance active lors de l'utilisation de la réplication synchrone, les données sont normalement répliquées de manière asynchrone dans les configurations DR. Cela signifie que les mises à jour de l'instance en attente sont toujours en retard par rapport aux mises à jour apportées à l'instance active. Cela réchauffe l’instance de secours et entraîne un délai inévitable lors de la récupération après sinistre. Le retard dans les dispositions de reprise après sinistre est tolérable car les catastrophes sont rares et touchent généralement les utilisateurs dont la capacité de travail est également perturbée.

Ces différences entraînent des différences entre les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO) établis aux fins de la HA et de la RD. RTO est la durée maximale tolérable d'une panne. Les applications critiques ont des RTO faibles, généralement de l'ordre de quelques secondes pour les HA, et les applications de traitement de transactions en ligne à volume élevé en ont généralement les plus faibles. En RD, les RTO de plusieurs minutes, voire plusieurs heures, sont assez courants en raison du coût extraordinaire de la mise en œuvre de dispositions capables de se remettre complètement d’une catastrophe généralisée en quelques minutes à peine.

RPO est la période maximale pendant laquelle la perte de données peut être tolérée. Si aucune perte de données n'est tolérable, le RPO est égal à zéro. Parce que la plupart des données ont une grande valeur (sinon, il ne serait pas nécessaire de les capturer et de les stocker.) Les RPO faibles sont communs pour les objectifs HA et DR. Pour la haute disponibilité, la réplication synchrone des données facilite relativement la satisfaction d'un RPO faible ou nul.

La situation en ce qui concerne la reprise après sinistre est toutefois sensiblement différente, un RPO bas créant la nécessité d’un compromis possible avec RTO. Voici pourquoi: pour les applications avec un RPO égal à zéro, des processus manuels sont nécessaires pour garantir que toutes les données (provenant, par exemple, d'un journal des transactions) ont été entièrement répliquées sur l'instance de secours avant que la récupération, sous la forme d'un basculement, puisse avoir lieu. Cet effort supplémentaire a pour effet d'augmenter les temps de récupération.

Les options de DR

Reconnaissant que la reprise après sinistre est différente de la haute disponibilité et que les RTO plus longs, qui durent plusieurs minutes voire plusieurs heures, sont la norme lors de la reprise après sinistre, les administrateurs système et bases de données disposent d’une marge de manœuvre considérable pour choisir différentes dispositions de reprise après sinistre pour différentes applications.

Dans le cloud public, la plupart des fournisseurs de services disposent de ce que l’on pourrait appeler une procédure de reprise en charge à faire soi-même, guidée par des modèles, des livres de recettes et d’autres outils. Le bricolage est viable car, contrairement aux dispositions relatives à la haute disponibilité, la reprise en charge est relativement facile à mettre en œuvre en répliquant les données sur des instances en veille dans une autre zone ou région de disponibilité. Quelques fournisseurs de services cloud proposent désormais une solution DRaaS (DR-as-a-Service) gérée, qui réplique automatiquement les instances actives (logiciels et données) sur une ou plusieurs instances en veille, également dans une autre zone ou région de disponibilité, afin de permettre la reprise après sinistre généralisé. Tant pour le bricolage que pour le DRaaS, le processus de récupération est manuel.

Bien que DR soit différent de HA, il est possible (et généralement préférable) d’ajouter DR à une configuration HA existante. Ces configurations HA / DR combinées multi-nœuds, multi-sites ont l’avantage d’être implémentées avec une solution unique par rapport à l’exigence de dispositions distinctes pour HA et DR, qui peuvent également être différentes pour différentes applications.

Il existe deux options courantes pour combiner les dispositions de haute disponibilité et de reprise après sinistre pour SQL Server. L’une est la fonctionnalité de groupes de disponibilité permanente de SQL Server capable de satisfaire les RTO et les RPO les plus exigeants. Mais cette approche nécessite l'édition plus coûteuse Enterprise Edition et protège uniquement les bases de données utilisateur, et non l'instance SQL Server entière.

L'autre option combinée HA / DR est une solution de clustering de basculement tierce. Celles-ci sont spécialement conçues pour prendre en charge pratiquement toutes les applications exécutées sur Windows Server et Linux dans des clouds publics, privés et hybrides. Elles sont entièrement implémentées dans le logiciel et incluent généralement une réplication de données en temps réel, une surveillance continue pour détecter les défaillances au niveau du système et des applications, ainsi que des stratégies configurables pour le basculement et la restauration.

Les solutions de clustering avec basculement qui s'intègrent à Windows Server avec basculement en cluster permettent l'utilisation d'instances de cluster de basculement SQL Server (FCI) couvrant plusieurs centres de données ou régions de nuage. Les FCI de SQL Server sont pris en charge par les éditions Standard et Enterprise de SQL Server pour Windows. Étant donné que SQL Server 2017 pour Linux ne possède pas l'équivalent de WSFC, la solution de clustering avec basculement doit gérer directement toutes les réplications de données et autres fonctionnalités.

Quelle que soit l'option choisie, gardez à l'esprit que la seule chose qui est plus difficile que de planifier son rétablissement est d'essayer d'expliquer pourquoi vous ne l'avez pas fait!

L'auteur

David Bermingham est évangéliste technique chez SIOS Technology. Il est reconnu dans la communauté technologique comme un expert en haute disponibilité et a l'honneur d'être élu MVP Microsoft au cours des 8 dernières années: 6 ans en tant que MVP de cluster et 2 ans en tant que MVP de gestion de centres de données et de cloud. David est titulaire de nombreuses certifications techniques et compte plus de trente ans d'expérience en informatique, notamment dans les domaines de la finance, de la santé et de l'éducation.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.