Architecturer la reprise d’activité après sinistre pour SQL Server sur AWS : Partie 1

Dans le monde d’aujourd’hui, ce n’est qu’une question de temps avant qu’un sinistre ne se produise, et quand il arrive, il est essentiel de récupérer, par exemple, vos bases de données SQL Server et de remettre le système en ligne avec un minimum de perte de données et de temps d’indisponibilité. Pour sécuriser et rétablir l’accès à vos bases de données SQL Server après une interruption de service, des solutions de haute disponibilité et de reprise après sinistre peuvent être utilisées. Les mécanismes de haute disponibilité visent à définir ce qu’il est nécessaire de faire pour prévenir les sinistres, tandis que la reprise après sinistre a pour objectif de définir quoi faire pour rétablir la haute disponibilité après un sinistre. AWS peut vous aider à réduire le coût et la complexité des solutions de haute disponibilité et de reprise après sinistre pour vos infrastructures SQL Server.

De nombreux clients nous demandent conseil afin de choisir la bonne solution de haute disponibilité et de reprise après sinistre pour SQL Server sur AWS, mais il n’existe pas de solution unique. Il y a des compromis à faire concernant la potentielle perte de données, le temps de rétablissement du service, la complexité opérationnelle et le coût d’exploitation. Dans certains cas, il est possible de combiner ces technologies pour implémenter une solution qui réponde à la fois aux problématiques de haute disponibilité et de reprise après sinistre.

Pour de nombreux cas d’usage courants, les clients peuvent utiliser Amazon Relational Database Service (Amazon RDS) pour SQL Server qui est un service géré par AWS, qui facilite le déploiement, l’exploitation et la mise à l’échelle de SQL Server sur AWS. Les clients peuvent également déployer et gérer leur propre base de données SQL Server sur Amazon Elastic Compute Cloud (Amazon EC2).

Dans cette série d’articles, nous allons comparer et mettre en perspective les différentes solutions disponibles pour assurer la reprise après sinistre de SQL Server sur Amazon EC2 et vous aider à comprendre la nature des compromis à réaliser ainsi que les coûts et la complexité d’implémentation de reprise après sinistre pour des infrastructures SQL Server sur AWS. Nous prévoyons d’écrire une série d’article similaire pour Amazon RDS pour SQL Server, vous pouvez en apprendre plus sur la résilience de Amazon RDS dans le guide utilisateur.

Cet article présente les terminologies techniques et les solutions de reprise après sinistre disponibles pour les différentes versions et éditions de SQL Server. Dans la deuxième partie, nous explorerons la sauvegarde et restauration de SQL Server, la copie des journaux de transaction SQL Server, et la mise en miroir de bases de données SQL Server. Dans la troisième partie, nous étudierons en détail les instances de cluster de basculement Always On SQL Server et les groupes de disponibilité Always On SQL Server. Finalement, dans la quatrième partie, nous aborderons AWS Database Migration Service (AWS DMS), CloudEndure Disaster Recovery, et nous ferons une synthèse toutes les technologies évoquées dans cette série.

Terminologie Technique

Nous utiliserons les termes suivants tout au long de cette série d’articles :

• Haute disponibilité (HA) – Le mécanisme de haute disponibilité protège votre centre de données, zones de disponibilité, serveurs, réseaux, et système de stockages des pannes pour assurer le maintien en condition opérationnel,
• Reprise après  sinistre (DR) –  Il s’agit de la préparation et du rétablissement d’un service après un  sinistre. N’importe quel événement qui a un impact négatif sur la continuité de service ou les coûts, peut être considéré comme un sinistre.  Il peut s’agir d’une panne matérielle ou logicielle, d’un incident réseau,  d’une panne d’alimentation, d’un dommage physique sur un bâtiment comme un  feux ou une inondation, d’une erreur humaine, ou de n’importe quel autre  incident disruptif,
• Objectif de temps de récupération (RTO) – Il s’agit du délai maximum acceptable (définit par votre organisation) entre le début de l’interruption de service et le rétablissement de ce service. Ceci détermine la fenêtre de temps considérée comme acceptable pour l’indisponibilité d’un service,
• Objectif de point de reprise (RPO) – Il s’agit de la durée maximale acceptable (définit par votre organisation) depuis le dernier point de récupération des données. Ceci détermine ce qui est considéré comme acceptable en termes de perte de données entre le dernier point de récupération et l’interruption de service,
• Bascule (Failover) – Le processus durant lequel un service est basculé de manière automatique vers un nœud en mode veille en cas d’indisponibilité du nœud principal. Le basculement ne nécessite pas d’intervention manuelle,
• Permutation  (Switchover) –  Contrairement à la bascule, la permutation est un process de transition  intentionnel du nœud primaire vers le nœud en mode veille (nouveau nœud  primaire) dans un but de test ou de maintenance planifiée. La permutation  nécessite une intervention manuelle,
• Retour à l’état initial (Failback) – Retour à l’état initial après une bascule ou une permutation, suite à la remise en service du nœud d’origine. Ce retour à l’état inital est toujours initié manuellement,
• Actif-passif – Dans une configuration de cluster actif-passif, le service n’est rendu que par un seul nœud (le nœud primaire) tant qu’il n’y a pas d’incident. Le service est transféré vers un nœud en mode veille si un incident est détecté. Ce transfert de service peut être réalisé via une bascule automatique ou via une permutation initiée manuellement.
• Actif-actif – Avec une configuration de cluster actif-actif, le service est rendu par les nœuds primaire et secondaire en même temps. Cette configuration ne nécessite pas de bascule si seulement l’un des nœuds actifs devient indisponible. Si l’un des nœuds est indisponible, l’autre nœud actif continue de rendre le service,
• Veilleuse (Pilot light) – Réplique vos données d’une région à une autre et provisionne une copie des éléments de base de votre infrastructure. Les ressources nécessaires pour supporter la réplication des données et des sauvegardes, comme les bases de données et le stockage objet, sont allumés en permanence. Les autres éléments comme les serveurs d’application sont pré-configurés, mais éteint et ne sont rallumés que durant les tests ou lors d’une bascule suite à l’activation d’un plan de reprise d’activité,
• Reprise semi-automatique (Warm standby) – Une  solution de reprise semi-automatique maintien une infrastructure réduite mais entièrement  fonctionnelle de votre environnement dans une région de reprise d’activité  après sinistre. Les systèmes critiques sont entièrement dupliqués et sont  allumés en permanence, mais avec une flotte de ressources réduite. En cas  de besoin, le système est mis à l’échelle de manière rapide afin d’absorber  la charge de production. Plus les capacités initialement provisionnées dans l’environnement de reprise semi-automatique sont importantes et plus l’objectif  de temps de récupération sera faible,
• Reprise progressive (Cold standby) – Une solution de reprise progressive assure la redondance de votre nœud primaire. Le nœud passif est  éteint et doit être allumé manuellement pour maintenir la synchronisation  avec le nœud primaire,
• Réplication synchrone – La réplication copie les changements de données d’une base de données à une autre. La plupart des solutions de réplication synchrone écrivent les données sur le stockage primaire et sur le répliqua simultanément. Ainsi, la copie primaire et le répliqua devraient toujours rester synchrones,
• Réplication asynchrone – Les solutions de réplication asynchrone copient les données vers le répliqua après les avoir écrites sur le stockage principal. Le processus de réplication s’exécute avec un minimum de latence vers le répliqua secondaire. Si le primaire est configuré en mode asynchrone, la bascule manuelle est possible. En cas de bascule, certaines données peuvent être perdues.

Le tableau suivant résume ce que vous pouvez attendre de la haute disponibilité et de la reprise après sinistre.

Prérequis concernant les versions et éditions de SQL Server

Le choix du type d’installation SQL Server varie en fonction des besoins applicatifs. Les différentes éditions de SQL Server offrent des performances, des moteurs d’exécution et des prix différents qui répondent à des besoins individuels ou organisationnels. Les composants SQL Server que vous installez peuvent également dépendre de vos besoins spécifiques. Le tableau suivant vous aide à comprendre comment faire le meilleur choix entre les différentes éditions et composants disponibles dans SQL Server. Le tableau suivant résume les solutions de reprise après sinistre par version de SQL Server. Nous allons étudier ces options dans cette série d’articles.

Le tableau suivant résume les solutions de reprise après sinistre par édition SQL Server.

Conclusion

Le choix d’une solution de reprise après sinistre dépend de vos besoins et de votre budget, mais également de la version et de l’édition du produit SQL Server que vous installez. Dans certain cas d’usage, il peut même être bénéfique de combiner plusieurs technologies de reprise après sinistre. Dans cet article, nous avons discuté du vocabulaire associé à la reprise d’activité, mais également des versions et des éditions pour implémenter des scénarios de reprise après sinistre avec AWS. Dans le prochain article, nous discuterons des sauvegardes restaurations SQL, de la copie des journaux de transaction SQL et de la mise en miroir des bases SQL pour des cas d’usage de reprise après sinistre.

Article orginal contribué par Ganapathi Varma Chekuri et Baris Furtinalar et adapté par Matthieu RUNTZ revu par Alexis Roger, Partner Solutions Architect chez AWS France.