Ce tutoriel explique comment activer la réplication asynchrone Hyperdisk Balanced dans deux régions Google Cloud en tant que solution de reprise après sinistre (DR). Il explique également comment lancer les instances de DR en cas de sinistre.
Les instances de cluster de basculement (FCI) Microsoft SQL Server sont des instances SQL Server uniques à disponibilité élevée déployées sur plusieurs nœuds de cluster de basculement Windows Server (WSFC). À tout moment, l'un des nœuds du cluster héberge activement l'instance SQL. En cas de panne zonale ou de problème de VM, WSFC transfère automatiquement la propriété des ressources de l'instance à un autre nœud du cluster, ce qui permet aux clients de se reconnecter. Les instances FCI SQL Server nécessitent que les données soient stockées sur des disques partagés pour pouvoir être accessibles sur tous les nœuds WSFC.
Pour vous assurer que le déploiement SQL Server peut résister à une panne régionale, répliquez les données de disque de la région principale vers une région secondaire en activant la réplication asynchrone. Ce tutoriel utilise des disques multi-écrivains Hyperdisk équilibrés à haute disponibilité pour activer la réplication asynchrone dans deux régions Google Cloud en tant que solution de reprise après sinistre (DR) pour SQL Server FCI. Il explique également comment lancer les instances de DR en cas de sinistre. Dans ce document, un sinistre est un événement au cours duquel un cluster de base de données principale est défaillant ou devient indisponible, car la région du cluster devient indisponible, peut-être en raison d'une catastrophe naturelle.
Ce tutoriel est destiné aux architectes, aux administrateurs et aux ingénieurs de bases de données.
Reprise après sinistre dans Google Cloud
La reprise après sinistre dans Google Cloud consiste à maintenir un accès continu aux données lorsqu'une région est défaillante ou devient inaccessible. Il existe plusieurs options de déploiement pour le site de DR, qui dépendent des exigences liées à l'objectif de reprise après sinistre (RPO) et à l'objectif de temps de récupération (RTO). Ce tutoriel présente l'une des options permettant de répliquer les disques associés à la machine virtuelle de la région principale vers la région de reprise après sinistre.
Reprise après sinistre à l'aide de la réplication asynchrone Hyperdisk
La réplication asynchrone Hyperdisk est une option de stockage qui permet de copier le stockage de manière asynchrone pour répliquer les disques entre deux régions. Dans le cas peu probable d'une panne régionale, la réplication asynchrone Hyperdisk vous permet de basculer vos données vers une région secondaire et de redémarrer vos charges de travail dans cette région.
La réplication asynchrone Hyperdisk réplique les données d'un disque associé à une charge de travail en cours d'exécution (le disque principal) sur un disque distinct situé dans une autre région. Le disque qui reçoit les données répliquées est appelé disque secondaire. La région dans laquelle le disque principal est exécuté est appelée région principale, et la région dans laquelle le disque secondaire est exécuté est appelée région secondaire. Pour garantir que les instances répliquées de tous les disques associés à chaque nœud SQL Server contiennent des données correspondant à un même point dans le temps, les disques sont ajoutés à un groupe de cohérence. Les groupes de cohérence vous permettent d'effectuer des reprises après sinistre et des tests de reprise après sinistre sur plusieurs disques.
Architecture de reprise après sinistre
Pour la réplication asynchrone Hyperdisk, le schéma suivant illustre une architecture minimale prenant en charge la haute disponibilité de la base de données dans une région principale, R1, et la réplication de disques de la région principale vers la région secondaire, R2.
Figure 1 : Architecture de reprise après sinistre avec Microsoft SQL Server et réplication asynchrone Hyperdisk
Cette architecture fonctionne comme suit :
- Deux instances de Microsoft SQL Server (une instance principale et une instance de secours) font partie d'un cluster FCI et se trouvent dans la région principale (R1), mais dans des zones différentes (zones A et B). Les deux instances partagent un disque Hyperdisk équilibré à haute disponibilité, ce qui permet d'accéder aux données depuis les deux VM. Pour obtenir des instructions, consultez Configurer un cluster FCI SQL Server avec le mode écriture simultanée Hyperdisk Balanced à haute disponibilité.
- Les disques des deux nœuds SQL sont ajoutés aux groupes de cohérence et répliqués dans la région de reprise après sinistre R2. Compute Engine réplique de manière asynchrone les données de R1 vers R2.
- La réplication asynchrone ne réplique que les données sur les disques vers R2 et ne réplique pas les métadonnées de la VM. Lors de la reprise après sinistre, de nouvelles VM sont créées et les disques répliqués existants sont associés aux VM afin de mettre les nœuds en ligne.
Processus de reprise après sinistre
Le processus de reprise après sinistre définit les étapes opérationnelles que vous devez suivre après qu'une région est devenue indisponible pour reprendre la charge de travail dans une autre région.
Un processus de base de reprise après sinistre sur une base de données comprend les étapes suivantes :
- La première région (R1) qui exécute l'instance de base de données principale devient indisponible.
- L'équipe en charge des opérations reconnaît officiellement le sinistre et décide si un basculement est nécessaire.
- Si un basculement est nécessaire, vous devez arrêter la réplication entre les disques principal et secondaire. Une nouvelle VM est créée à partir des instances répliquées des disques et mise en ligne.
- La base de données de la région de reprise après sinistre (R2) est validée et mise en ligne. La base de données de la région R2 devient la nouvelle base de données principale, ce qui permet la connectivité.
- Les utilisateurs reprennent le traitement sur la nouvelle base de données principale et accèdent à l'instance principale dans la région R2.
Bien que ce processus de base définisse à nouveau une base de données principale opérationnelle, il n'établit pas une architecture complète de haute disponibilité, car la nouvelle base de données principale n'est pas répliquée.
Figure 2 : Déploiement de SQL Server après la reprise après sinistre avec réplication asynchrone sur disque persistant
Revenir à une région récupérée
Lorsque la région principale (R1) est de nouveau en ligne, vous pouvez planifier et exécuter le processus de restauration. Le processus de restauration comprend toutes les étapes décrites dans ce tutoriel, mais dans ce cas, R2 est la région source et R1 est la région de récupération.
Choisir une édition SQL Server
Ce tutoriel s'applique aux versions suivantes de Microsoft SQL Server :
- SQL Server 2016 Enterprise et Standard Edition
- SQL Server 2017 Enterprise et Standard Edition
- SQL Server 2019 Enterprise et Standard Edition
- SQL Server 2022 Enterprise et Standard Edition
Le tutoriel utilise l'instance de cluster de basculement SQL Server avec un disque Hyperdisk équilibré à haute disponibilité.
Si vous n'avez pas besoin des fonctionnalités de SQL Server Enterprise, vous pouvez utiliser l'édition Standard de SQL Server :
Avec les versions 2016, 2017 2019 et 2022 de SQL Server, Microsoft SQL Server Management Studio est déjà installé dans l'image. Vous n'avez pas besoin de l'installer séparément. Dans un environnement de production, nous vous recommandons toutefois d'installer une instance de Microsoft SQL Server Management Studio sur une VM distincte dans chaque région. Si vous configurez un environnement à haute disponibilité, vous devez effectuer une installation de Microsoft SQL Server Management Studio dans chaque zone afin de garantir que le service reste disponible si une autre zone devient indisponible.
Configurer la reprise après sinistre pour Microsoft SQL Server
Ce tutoriel utilise l'image sql-ent-2022-win-2022 pour Microsoft SQL Server Enterprise.
Pour obtenir la liste complète des images, consultez la section Images d'OS.
Configurer un cluster à haute disponibilité comprenant deux instances
Pour configurer la réplication de disque pour SQL Server entre deux régions, vous devez d'abord créer un cluster à haute disponibilité à deux instances dans une région.
Une instance sert d'instance principale, tandis que l'autre sert d'instance de secours. Pour effectuer cette étape, suivez les instructions de la page Configurer un cluster FCI SQL Server avec le mode écriture simultanée Hyperdisk Balanced à haute disponibilité.
Ce tutoriel utilise us-central1 pour la région principale R1.
Si vous avez suivi la procédure décrite dans Configurer un cluster FCI SQL Server avec le mode multiauteur à haute disponibilité Hyperdisk équilibré, vous avez créé deux instances SQL Server dans la même région (us-central1). Vous avez déployé une instance SQL Server principale (node-1) dans la zone us-central1-a et une instance de secours (node-2) dans la zone us-central1-b.
Activer la réplication asynchrone des disques
Une fois que vous avez créé et configuré toutes les VM, activez la réplication de disque entre les deux régions en procédant comme suit :
Créez un groupe de cohérence pour les nœuds SQL Server et le nœud hébergeant les rôles de témoin et de contrôleur de domaine. L'une des limites pour les groupes de cohérence est qu'ils ne peuvent pas couvrir plusieurs zones. Vous devez donc ajouter chaque nœud à un groupe de cohérence distinct.
gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group multiwriter-disk-const-grp \ --region=$REGION
Ajoutez les disques des VM principales et de secours aux groupes de cohérence correspondants.
gcloud compute disks add-resource-policies node-1 \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-2 \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies mw-datadisk-1 \ --region=$REGION \ --resource-policies=multiwriter-disk-const-grp gcloud compute disks add-resource-policies witness \ --zone=$REGION-c \ --resource-policies=witness-disk-const-grp
Créez des disques secondaires vides dans la région secondaire.
DR_REGION="us-west1" gcloud compute disks create node-1-replica \ --zone=$DR_REGION-a \ --size=50 \ --primary-disk=node-1 \ --primary-disk-zone=$REGION-a gcloud compute disks create node-2-replica \ --zone=$DR_REGION-b \ --size=50 \ --primary-disk=node-2 \ --primary-disk-zone=$REGION-b gcloud compute disks create multiwriter-datadisk-1-replica \ --replica-zones=$DR_REGION-a,$DR_REGION-b \ --size=$PD_SIZE \ --type=hyperdisk-balanced-high-availability \ --access-mode READ_WRITE_MANY \ --primary-disk=multiwriter-datadisk-1 \ --primary-disk-region=$REGION gcloud compute disks create witness-replica \ --zone=$DR_REGION-c \ --size=50 \ --primary-disk=witness \ --primary-disk-zone=$REGION-c
Démarrez la réplication des disques. Les données sont répliquées à partir du disque principal vers le disque vide nouvellement créé dans la région de reprise après sinistre.
gcloud compute disks start-async-replication node-1 \ --zone=$REGION-a \ --secondary-disk=node-1-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-2 \ --zone=$REGION-b \ --secondary-disk=node-2-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication multiwriter-datadisk-1 \ --region=$REGION \ --secondary-disk=multiwriter-datadisk-1-replica \ --secondary-disk-region=$DR_REGION gcloud compute disks start-async-replication witness \ --zone=$REGION-c \ --secondary-disk=witness-replica \ --secondary-disk-zone=$DR_REGION-c
À ce stade, les données doivent se répliquer entre les régions.
L'état de réplication de chaque disque doit indiquer Active.
Simuler une reprise après sinistre
Dans cette section, vous allez tester l'architecture de reprise après sinistre configurée dans ce tutoriel.
Simuler une interruption et exécuter un basculement de reprise après sinistre
Lors d'un basculement, vous créez des VM dans la région de DR et leur associez les disques répliqués. Pour simplifier le basculement, vous pouvez utiliser un autre cloud privé virtuel (VPC) dans la région de DR pour la reprise afin d'utiliser la même adresse IP.
Avant de démarrer le basculement, assurez-vous que node-1 est le nœud principal du groupe de disponibilité AlwaysOn que vous avez créé. Lancez le contrôleur de domaine et le nœud SQL Server principal pour éviter tout problème de synchronisation des données, car les deux nœuds sont protégés par deux groupes de cohérence distincts.
Pour simuler une panne, procédez comme suit :
Créez un VPC de reprise.
DRVPC_NAME="default-dr" DRSUBNET_NAME="default-recovery" gcloud compute networks create $DRVPC_NAME \ --subnet-mode=custom CIDR=$(gcloud compute networks subnets describe default \ --region=$REGION --format=value\(ipCidrRange\)) gcloud compute networks subnets create $DRSUBNET_NAME \ --network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION
Arrêtez la réplication de données.
PROJECT=$(gcloud config get-value project) gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \ --zone=$REGION-a gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \ --zone=$REGION-b gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/multiwriter-disk-const-grp \ --zone=$REGION-c gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \ --zone=$REGION-c
Arrêtez les VM sources dans la région principale.
gcloud compute instances stop node-1 \ --zone=$REGION-a gcloud compute instances stop node-2 \ --zone=$REGION-b gcloud compute instances stop witness \ --zone=$REGION-c
Renommez les VM existantes pour éviter les doublons dans le projet.
gcloud compute instances set-name witness \ --new-name=witness-old \ --zone=$REGION-c gcloud compute instances set-name node-1 \ --new-name=node-1-old \ --zone=$REGION-a gcloud compute instances set-name node-2 \ --new-name=node-2-old \ --zone=$REGION-b
Créez des VM dans la région de reprise après sinistre à l'aide des disques secondaires. Ces VM auront l'adresse IP de la VM source.
NODE1IP=$(gcloud compute instances describe node-1-old --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2-old --zone $REGION-b --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness-old --zone $REGION-c --format=value\(networkInterfaces[0].networkIP\)) gcloud compute instances create node-1 \ --zone=$DR_REGION-a \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE1IP\ --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \ --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional gcloud compute instances create witness \ --zone=$DR_REGION-c \ --machine-type=n2-standard-2 \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $WITNESSIP \ --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica gcloud compute instances create node-2 \ --zone=$DR_REGION-b \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE2IP\ --disk=boot=yes,device-name=node-2-replica,mode=rw,name=node-2-replica \ --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional
Vous avez simulé une interruption de service et effectué un basculement vers la région de reprise après sinistre. Vous pouvez maintenant vérifier si l'instance secondaire fonctionne correctement.
Vérifier la connectivité SQL Server
Une fois les VM créées, vérifiez que les bases de données ont bien été récupérées et que le serveur fonctionne comme prévu. Pour tester la base de données, exécutez une requête à partir de la base de données récupérée.
- Connectez-vous à la VM SQL Server à l'aide du Bureau à distance.
- Ouvrez SQL Server Management Studio.
- Dans la boîte de dialogue Se connecter au serveur, vérifiez que le nom du serveur est défini sur
node-1et sélectionnez Se connecter. Dans le menu Fichier, sélectionnez Fichier > Nouveau > Requête avec la connexion actuelle.
USE [bookshelf]; SELECT * FROM Books;