Ce tutoriel explique comment activer la réplication asynchrone sur disque persistant (PD Async Replication) 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. Dans ce document, un sinistre est un événement au cours duquel un cluster haute disponibilité (HA) de base de données principale est défaillant ou devient indisponible. Une base de données principale peut échouer lorsque la région dans laquelle elle se trouve devient défaillante ou inaccessible.
Ce tutoriel est destiné aux architectes, aux administrateurs et aux ingénieurs de bases de données.
Objectifs
- Activer la réplication asynchrone sur disque persistant pour tous les nœuds du cluster de groupe de disponibilité SQL Server AlwaysOn exécutés sur Google Cloud.
- Simuler un sinistre et exécuter un processus complet de reprise après sinistre pour valider la configuration de reprise après sinistre
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.
Avant de commencer
Pour ce tutoriel, vous avez besoin d'un projet Google Cloud. Vous pouvez en créer un ou sélectionner un projet existant :
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Reprise après sinistre dans Google Cloud
Dans Google Cloud, la reprise après sinistre (DR) consiste à assurer la continuité du traitement, en particulier en cas de défaillance ou d'indisponibilité d'une région. 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 de machine virtuelle (VM) de la région principale vers la région de DR.
Reprise après sinistre pour la réplication asynchrone sur disque persistant
La réplication asynchrone sur disque persistant (PD Async Replication) fournit une réplication de stockage de blocs à faibles RPO et RTO pour la reprise après sinistre active/passive interrégionale.
La réplication asynchrone sur disque persistant est une option de stockage qui permet une réplication asynchrone des données entre deux régions. Dans le cas peu probable d'une panne régionale, la réplication asynchrone sur disque persistant vous permet de basculer vos données vers une région secondaire et de redémarrer votre charge de travail dans cette région.
La réplication asynchrone sur disque persistant 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.
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 sur disque persistant, 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, et la réplication de disques de la région principale vers la région de reprise après sinistre.
Figure 1 : Architecture de reprise après sinistre avec Microsoft SQL Server et réplication asynchrone sur disque persistant
Cette architecture fonctionne comme suit :
- Deux instances de Microsoft SQL Server (une instance principale et une instance de secours) font partie d'un groupe de disponibilité et se trouvent dans la même région (R1), mais dans des zones différentes (zones A et B). Les deux instances de la région R1 coordonnent leurs états à l'aide du mode de commit synchrone. Le mode synchrone est utilisé car il offre une haute disponibilité et permet de conserver un état cohérent des données.
- 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. Les données sont répliquées de manière asynchrone par l'infrastructure sous-jacente.
- Seuls les disques sont répliqués dans la région R2. 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émarre lorsqu'une région devient indisponible. Ce processus définit les étapes opérationnelles qui doivent être effectuées (manuellement ou automatiquement) pour limiter la défaillance régionale et définir l'exécution d'une instance principale dans une région disponible.
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, la réplication de disque de la région principale vers la région de DR est arrêtée. Une nouvelle VM est créée à partir des instances répliquées des disques et mise en ligne.
- La nouvelle base de données principale de la région de reprise après sinistre (R2) est validée et mise en ligne, 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é, dans laquelle la nouvelle instance principale dispose d'un nœud de secours.
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 Edition
- SQL Server 2017 Enterprise Edition
- SQL Server 2019 Enterprise Edition
- SQL Server 2022 Enterprise Edition
Le tutoriel utilise la fonctionnalité des groupes de disponibilité AlwaysOn SQL Server.
Si vous n'avez pas besoin d'une base de données principale Microsoft SQL Server à haute disponibilité et qu'une seule instance de base de données vous suffit en tant qu'instance principale, vous pouvez utiliser les versions suivantes de SQL Server :
- SQL Server 2016 Standard Edition
- SQL Server 2017 Standard Edition
- SQL Server 2019 Standard Edition
- SQL Server 2022 Standard Edition
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 dans la région de reprise après sinistre pour SQL Server, 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 des groupes de disponibilité AlwaysOn SQL Server.
Ce tutoriel utilise us-central1 comme région principale (appelée R1).
Si vous avez suivi la procédure décrite dans Configurer des groupes de disponibilité AlwaysOn SQL Server, 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 toutes les VM créées et configurées, activez la copie de disque entre les régions en créant un groupe de cohérence pour tous les disques associés aux VM. Les données sont copiées à partir des disques sources vers les nouveaux disques vides créés dans la région désignée.
Créez un groupe de cohérence pour les nœuds SQL et le contrôleur de domaine. L'une des limites pour un disque zonal est que les groupes de cohérence ne peuvent pas couvrir plusieurs zones.
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
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-1-datadisk \ --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 node-2-datadisk \ --zone=$REGION-b \ --resource-policies=node-2-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 associée.
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-1-datadisk-replica \ --zone=$DR_REGION-a \ --size=$PD_SIZE \ --primary-disk=node-1-datadisk \ --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 node-2-datadisk-replica \ --zone=$DR_REGION-b \ --size=$PD_SIZE \ --primary-disk=node-2-datadisk \ --primary-disk-zone=$REGION-b 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-1-datadisk \ --zone=$REGION-a \ --secondary-disk=node-1-datadisk-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 node-2-datadisk \ --zone=$REGION-b \ --secondary-disk=node-2-datadisk-replica \ --secondary-disk-zone=$DR_REGION-b 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 de DR, 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/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
Créez des VM dans la région de DR à l'aide d'instances répliquées de disque. Ces VM auront l'adresse IP de la VM source.
NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --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=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica 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
Nous avons simulé une interruption de service et effectué un basculement vers la région de reprise après sinistre. Nous pouvons 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, vous allez exécuter une requête SELECT à 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;
Effectuer un nettoyage
Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, procédez comme suit :
Supprimer le projet
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Étapes suivantes
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.