Migrer Microsoft SQL Server d'AWS vers Google Cloud

Last reviewed 2023-05-05 UTC

Ce document explique comment migrer une instance Microsoft SQL Server installée sur Amazon Elastic Compute Cloud (Amazon EC2) vers une instance Microsoft SQL Server sur Compute Engine dans Google Cloud. Cette migration n'est basée que sur la technologie de base de données intégrée fournie par Microsoft SQL Server. Il s'agit dans les faits d'une méthode sans temps d'arrêt qui utilise un groupe de disponibilité toujours activé. Le groupe de disponibilité toujours activé couvre AWS et Google Cloud via VPN, et permet la duplication de la base de données Microsoft SQL Server. Dans ce document, nous partons du principe que vous maîtrisez la configuration du réseau, Google Cloud, Compute Engine, AWS et Microsoft SQL Server.

Si vous souhaitez n'effectuer qu'une duplication, vous pouvez suivre les étapes de ce tutoriel, mais il faut vous arrêter après avoir ajouté les données de test et omettre les étapes de basculement.

Objectifs

  • Déployer un groupe de disponibilité toujours activé Microsoft SQL Server multicloud couvrant une instance Microsoft SQL Server dans Amazon EC2 et une instance Microsoft SQL Server dans Google Cloud sur Compute Engine
  • Configurer une instance Microsoft SQL principale dans Amazon EC2
  • Configurer l'instance Microsoft SQL Server dans Google Cloud en tant qu'instance secondaire de l'instance Microsoft SQL Server principale dans AWS (cible de duplication des données)
  • Terminer la migration des données en faisant de l'instance Microsoft SQL Server secondaire dans Google Cloud l'instance Microsoft SQL Server principale dans Google Cloud

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. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Ce tutoriel nécessite également des ressources sur AWS qui peuvent entraîner des coûts.

Avant de commencer

  1. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  2. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  3. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

Comprendre la migration de base de données

La migration de base de données déplace les données d'une base de données source vers une base de données cible. En général, vous pouvez migrer un sous-ensemble de données ou disposer d'un schéma différent dans la base de données source et cible. Cependant, ce tutoriel traite de migration homogène de base de données, qui nécessite la migration de la base de données complète sans modification. La base de données cible est une copie de la base de données source.

Migration de base de données sans temps d'arrêt

Le terme zéro temps d'arrêt fait référence au fait que lors de la migration, les clients qui accèdent à la base de données source restent entièrement opérationnels et ne sont pas interrompus. Le seul temps d'arrêt se produit lorsque les clients doivent se reconnecter à la base de données cible une fois la migration terminée. Bien que cette méthode ne constitue pas un temps d'arrêt nul, le terme fait référence à un tel scénario de temps d'arrêt minimal.

Pour en savoir plus sur la migration de base de données, consultez les pages Migration de base de données : concepts et principes (partie 1) et Migration de base de données : concepts et principes (partie 2). Ces articles présentent un aperçu de la complexité possible de la migration de la base de données dans différents scénarios.

Migration de base de données à l'aide de la technologie Microsoft SQL Server

Certaines technologies de migration de base de données fournissent des composants et des services distincts. Lorsque la migration de la base de données nécessite une copie de la base de données source, vous pouvez utiliser la technologie intégrée Microsoft SQL Server.

Ce tutoriel utilise la technologie de groupe de disponibilité toujours activé de Microsoft SQL Server pour connecter la base de données source (principale) à une base de données cible (secondaire). Cette technologie fournit une duplication asynchrone entre la base de données principale et la base de données secondaire. Comme la base de données principale se trouve dans Amazon EC2 et que la base de données secondaire se trouve dans Google Cloud sur Compute Engine, la duplication accomplit la migration de la base de données. Une fois toutes les données migrées via la duplication asynchrone, la version secondaire est promue en instance principale et les clients peuvent se reconnecter à la nouvelle instance principale pour un traitement continu.

Cette approche permet d'effectuer des tests explicites via une duplication d'essai dans une base de données cible de test : vous pouvez démarrer la duplication, maintenir son exécution pendant un certain temps, puis l'arrêter. La base de données cible de test est cohérente et vous pouvez l'utiliser pour tester l'application. Une fois les tests terminés, vous pouvez supprimer la base de données cible de test et lancer la duplication pour une base de données active.

Architecture de migration de base de données multicloud

Le schéma suivant représente l'architecture de déploiement globale pour une migration de base de données multicloud :

Un groupe de disponibilité toujours activé connecte une base de données AWS à une base de données Google Cloud.

Le schéma précédent montre la base de données SQL Server source (principale) dans AWS en tant qu'instance Amazon EC2. Le schéma montre également la base de données cible (secondaire) dans Google Cloud. Les bases de données sont connectées par un groupe de disponibilité toujours activé. Nous partons du principe que la connexion réseau entre AWS et Google Cloud est une connexion VPN haute disponibilité sécurisée.

Configurer un groupe de disponibilité Microsoft SQL Server multicloud

Dans les sections suivantes, vous allez configurer un groupe de disponibilité toujours activé à deux nœuds dans lequel le nœud principal réside dans AWS et le nœud secondaire réside dans Google Cloud. Cette configuration est décrite plus haut dans ce document dans la section Architecture de migration de base de données multicloud.

Les tableaux suivants récapitulent les nœuds et les adresses IP que vous allez configurer dans ce tutoriel. Pour chaque VM de base de données, vous allouez deux adresses IP en plus de l'adresse IP principale : une adresse IP pour le cluster de basculement Windows Server (WSFC, Windows Server Failover Cluster) et une adresse IP pour l'écouteur du groupe de disponibilité.

Fournisseur Instance Adresse IP principale Adresses IP de l'écouteur du WSFC et du groupe de disponibilité WSFC Groupe de disponibilité
AWS cluster-sql1 192.168.1.4 192.168.1.5
192.168.1.6 		Name: cluster-dbclus Name: cluster-ag
Listener: ag-listener
Google Cloud cluster-sql2 10.1.1.4 10.1.1.5
10.1.1.6
Fournisseur Instance Adresse IP principale —
AWS dc-windows 192.168.1.100 Domain controller

Les instructions utilisent ces noms et adresses IP comme exemples. Si vous souhaitez utiliser vos propres noms et adresses IP, remplacez les exemples de valeurs dans les instructions.

Prérequis pour AWS

Sur AWS, vous devez disposer de deux machines virtuelles : l'une qui exécute le contrôleur de domaine, l'autre qui exécute un serveur SQL Server. Le contrôleur de domaine utilisé comme exemple dans ce tutoriel a la configuration suivante :

Domain                    : dbeng.com
Domain controller         : Name: dc-windows
                            Private IP: 192.168.1.100
VPC Subnet                : 192.168.1.0/24
SQL Server service account: dbeng\sql_service

La VM SQL Server utilisée comme exemple dans ce tutoriel fait partie d'un domaine Windows Active Directory dans Amazon EC2. Le serveur dispose de deux adresses IP secondaires devant être utilisées par l'écouteur du WSFC et du groupe de disponibilité. La VM SQL Server possède la configuration suivante :

VM Instance : Name: cluster-sql1
              Private IP: 192.168.1.4
              Secondary Private IPs: 192.168.1.5, 192.168.1.6
VPC Subnet  : 192.168.1.0/24

Vous pouvez utiliser le compte de service NT SERVICE\MSSQLSERVER en tant que compte de service SQL Server. Au cours de la configuration du groupe de disponibilité toujours activé, vous accordez l'accès aux comptes de machine (dbeng\cluster-sql1$, dbeng\cluster-sql2$) au lieu du compte de domaine. La section suivante fournit les commandes permettant de configurer le groupe de disponibilité.

Prérequis pour la connectivité entre AWS et Google Cloud

Pour connecter votre projet AWS à votre projet Google Cloud, configurez la connectivité réseau suivante :

  1. Configurez un cloud privé virtuel Google et un VPC AWS dans vos projets respectifs, puis configurez un VPN entre les VPC. Pour en savoir plus sur la configuration d'un VPN entre Google Cloud et AWS, consultez la section VPN multicloud et sous-réseaux multizones : configuration du réseau pour les déploiements de base de données multicloud.

  2. Dans Cloud Shell, créez un sous-réseau dans le projet Google Cloud dans lequel vous créez l'instance SQL Server. Si vous disposez déjà d'un sous-réseau, vous pouvez l'utiliser, mais veillez à configurer les règles de pare-feu à l'étape suivante.

    gcloud compute networks create demo-vpc --subnet-mode custom

gcloud compute networks subnets create demo-subnet1 \
  --network demo-vpc --region us-east4 --range 10.1.1.0/24

    Ce tutoriel utilise les valeurs suivantes :

    • VPC : demo-vpc
    • Sous-réseau : demo-subnet1; 10.1.1.0/24

    Le sous-réseau apparaît sur la page Réseaux VPC de la console Google Cloud.

  3. Dans votre projet Google Cloud, créez une règle de pare-feu pour ouvrir tout le trafic entre votre sous-réseau Google Cloud et votre sous-réseau AWS :

    gcloud compute firewall-rules create allow-vpn-ports \
  --network demo-vpc --allow tcp:1-65535,udp:1-65535,icmp \
  --source-ranges 10.1.1.0/24,192.168.1.0/24

    La règle de pare-feu apparaît sur la page Pare-feu de la console Google Cloud.

  4. Dans votre projet AWS, créez une règle de pare-feu dans le groupe de sécurité pour ouvrir tout le trafic entre votre sous-réseau Google Cloud et votre sous-réseau AWS, comme illustré dans la capture d'écran suivante :

    Les règles de trafic entrant d'AWS sont définies pour autoriser tout le trafic, tous les protocoles et toutes les plages de ports.

    Dans un environnement de production, vous pouvez envisager de n'ouvrir que les ports TCP/UDP requis. L'ouverture des ports requis seulement limite le trafic potentiellement nuisible et suit un principe de moindre nécessité.

Créer une instance dans Google Cloud pour le groupe de disponibilité toujours activé

Ce tutoriel fonctionne avec les éditions et les fonctionnalités suivantes de Microsoft SQL Server :

  • Édition :
    • Microsoft SQL Server 2016 Enterprise Edition
    • Microsoft SQL Server 2017 Enterprise Edition
    • Microsoft SQL Server 2019 Enterprise Edition
    • Microsoft SQL Server 2022 Enterprise Edition
    • Microsoft SQL Server 2016 Standard Edition
    • Microsoft SQL Server 2017 Standard Edition
    • Microsoft SQL Server 2019 Standard Edition
    • Microsoft SQL Server 2022 Standard Edition
  • Fonctionnalité : Groupes de disponibilité toujours activé

Les instructions suivantes utilisent l'image Microsoft SQL Server 2019 Enterprise Edition : sql-ent-2019-win-2019. Si vous souhaitez installer les éditions Microsoft SQL Server Enterprise 2017, 2016 ou 2022, utilisez plutôt sql-ent-2017-win-2019, sql-ent-2016-win-2019 ou sql-ent-2022-win-2019, respectivement. Pour obtenir la liste de toutes les images, consultez la page Détails des systèmes d'exploitation de Compute Engine.

Dans les étapes suivantes, vous allez créer une instance SQL Server dans Google Cloud pour le groupe de disponibilité. L'instance utilise la configuration d'adresse IP suivante avec des adresses IP d'alias :

VM Instance: Name: cluster-sql2
             Private IP: 10.1.1.4
             Secondary Private IPs: 10.1.1.5, 10.1.1.6

Créez une instance nommée cluster-sql2 à partir d'images SQL Server publiques avec une taille de disque de démarrage de 200 Go et un type de machine n1-highmem-4. Les instances SQL Server nécessitent généralement plus de ressources de calcul que l'instance du contrôleur de domaine. Si vous avez besoin de ressources de calcul supplémentaires par la suite, vous pourrez modifier le type de machine de ces instances. S'il vous faut davantage d'espace de stockage, ajoutez un disque ou redimensionnez le disque de démarrage persistant. Dans les groupes de disponibilité plus importants, vous pouvez créer plusieurs instances.

Les étapes suivantes incluent également l'option --metadata sysprep-specialize-script-ps1 qui exécute une commande Microsoft PowerShell lors de la création de l'instance pour installer la fonctionnalité de clustering de basculement.

  1. Dans Cloud Shell, créez une instance SQL Server dans Google Cloud qui utilise la même version de système d'exploitation que dans AWS :

    gcloud compute instances create cluster-sql2 --machine-type n1-highmem-4 \
  --boot-disk-type pd-ssd --boot-disk-size 200GB \
  --image-project windows-sql-cloud --image-family sql-ent-2019-win-2019 \
  --zone us-east4-a \
  --network-interface "subnet=demo-subnet1,private-network-ip=10.1.1.4,aliases=10.1.1.5;10.1.1.6" \
  --can-ip-forward \
  --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"

  2. Définissez un nom d'utilisateur et un mot de passe Windows avant de vous connecter à l'instance.

  3. Lorsque vous utilisez le protocole RDP (Remote Desktop Protocol) sur votre ordinateur portable, créez une règle de pare-feu autorisant l'accès à l'instance.

  4. Connectez-vous à l'instance Google Cloud via RDP et ouvrez une invite PowerShell avec élévation de privilèges (exécuter en tant qu'administrateur).

  5. Dans ce tutoriel, vous allez configurer un DNS local pour utiliser le contrôleur de domaine dans AWS (192.168.1.100) pour éviter de créer une autre VM dans Google Cloud. Pour les charges de travail de production, nous vous recommandons d'utiliser un contrôleur de domaine (principal ou secondaire) dans Google Cloud pour éviter l'authentification via le tunnel VPN.

    Dans l'instance PowerShell avec élévation de privilèges, vous devez pouvoir pinguer le contrôleur de domaine 192.168.1.100 :

    ping 192.168.1.100

    Si le ping échoue, assurez-vous que le pare-feu et le tunnel VPN sont configurés correctement entre AWS et Google Cloud, comme décrit dans la section Prérequis pour la connectivité ci-dessus.

  6. Comme le serveur a été configuré initialement avec DHCP, modifiez l'instance pour utiliser des adresses IP statiques :

    netsh interface ip set address name=Ethernet static 10.1.1.4 255.255.255.0 10.1.1.1 1

    Après avoir exécuté la commande précédente, vous perdez la connexion. Reconnectez-vous via le protocole RDP.

  7. Configurez le DNS local pour utiliser le contrôleur de domaine dans AWS et ouvrez les ports de pare-feu locaux pour SQL Server. L'ouverture des ports de pare-feu permet à SQL Server de se connecter aux serveurs SQL distants.

    netsh interface ip set dns Ethernet static 192.168.1.100

netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

  8. Ajoutez l'instance au domaine Windows :

    Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force

    La commande vous invite à saisir les identifiants de l'administrateur du domaine. Lorsque l'exécution de la commande est terminée, l'instance redémarre.

    Si la commande ne s'exécute pas, assurez-vous de l'exécuter en tant qu'administrateur.

  9. Utilisez le compte dbeng\Administrator pour vous reconnecter à l'instance à l'aide de RDP.

  10. Définissez le compte de service SQL Server :

    1. Ouvrez le gestionnaire de configuration 2019 de SQL Server.
    2. Dans l'onglet Services SQL Server, effectuez un clic droit sur SQL Server (MSSQLSERVER), puis cliquez sur Propriétés.
    3. Définissez le compte et le mot de passe de dbeng\sql_service.
    4. Redémarrez SQL Server.

  11. Renommez l'instance SQL Server afin qu'elle corresponde au nom de l'ordinateur et redémarrez SQL Server :

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

Vous allez ensuite configurer l'instance dans AWS.

Configurer l'instance dans AWS

Ce tutoriel suppose que vous avez déjà configuré les éléments suivants dans AWS :

  • L'instance SQL Server fait partie du domaine Active Directory.
  • Le DNS local fonctionne correctement et le nom du serveur distant dans Google Cloud (cluster-sql2.dbeng.com)) peut être traduit en adresse IP.
  • Les règles de pare-feu sont ouvertes entre les sous-réseaux sur AWS et Google Cloud.

Pour configurer cluster-sql1 dans AWS, procédez comme suit :

  1. Connectez-vous à l'instance AWS à l'aide du protocole RDP (cluster-sql1).
  2. Ouvrez une invite PowerShell avec élévation de privilèges (exécutée en tant qu'administrateur).

  3. Installez le clustering de basculement Windows si ce n'est pas déjà fait.

    Install-WindowsFeature Failover-Clustering -IncludeManagementTools

    Cette commande nécessite un redémarrage si la fonctionnalité n'a pas encore été installée. Après le redémarrage, passez à l'étape suivante.

  4. Ouvrez les ports de pare-feu locaux pour l'instance SQL Server dans AWS :

    netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol="icmpv4:8,any" dir=in action=allow

  5. Renommez l'instance SQL Server afin qu'elle corresponde au nom de l'ordinateur et redémarrez SQL Server :

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

  6. Vérifiez que l'instance dans AWS peut se connecter à l'instance dans Google Cloud lorsque vous utilisez le nom de l'instance distante. Pour tester la connexion, exécutez les commandes suivantes à partir d'un compte de domaine permettant d'accéder à SQL Server.

    1. Testez la connexion réseau :

      ping -4 cluster-sql2.dbeng.com

      La sortie ressemble à ceci :

      RESULTS:
Pinging cluster-sql2.dbeng.com [10.1.1.4] with 32 bytes of data:
Reply from 10.1.1.4: bytes=32 time=3ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127

    2. Testez l'authentification Windows sur le serveur distant :

      sqlcmd -E -S cluster-sql2.dbeng.com -Q "SELECT 'CONNECTED'"

      La sortie ressemble à ceci :

      RESULTS:
--------------------------------------------------------------------------
CONNECTED

(1 rows affected)

    Si vous ne parvenez pas à vous connecter, vérifiez que le DNS fonctionne correctement et que les règles de pare-feu sont ouvertes entre les sous-réseaux AWS et Google Cloud.

Vérifier que l'instance Google Cloud est prête à rejoindre le groupe de disponibilité

  1. Utilisez le compte dbeng\Administrator pour vous connecter à l'instance Google Cloud à l'aide du protocole RDP (cluster-sql2).
  2. Ouvrez une invite PowerShell avec élévation de privilèges (exécutée en tant qu'administrateur).

  3. Vérifiez que l'instance dans Google Cloud peut se connecter à l'instance dans AWS lorsque vous utilisez son nom. Pour tester la connexion, exécutez les commandes suivantes à partir d'un compte de domaine permettant d'accéder à SQL Server.

    1. Testez la connexion réseau :

      ping -4 cluster-sql1.dbeng.com

      La sortie ressemble à ceci :

      RESULTS:
Pinging CLUSTER-SQL1.dbeng.com [192.168.1.4] with 32 bytes of data:
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127

    2. Testez l'authentification Windows sur le serveur distant :

      sqlcmd -E -S cluster-sql1 -Q "SELECT 'CONNECTED'"

      La sortie ressemble à ceci :

      RESULTS:
------------------------------------------------------------
CONNECTED

(1 rows affected)

      Si vous ne parvenez pas à vous connecter, vérifiez que le DNS fonctionne correctement et que les règles de pare-feu sont ouvertes entre les sous-réseaux AWS et Google Cloud.

  4. Créez des dossiers sous C:\SQLData et C:\SQLLog. Les données et les fichiers journaux de la base de données utilisent ces dossiers.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

  5. Créez un dossier sous C:\SQLBackup et un partage Windows à l'adresse \\cluster-sql2\SQLBackup pour transférer la sauvegarde à partir de l'instance AWS. Vous pouvez utiliser tout autre partage réseau disponible sur les deux serveurs.

    New-Item "C:\SQLBackup" –type directory
New-SmbShare -Name "SQLBackup" -Path "C:\SQLBackup" -FullAccess
"dbeng.com\cluster-sql1$","dbeng.com\cluster-sql2$","NT
SERVICE\MSSQLSERVER","authenticated users","dbeng.com\sql_service"

Les instances sont à présent prêtes pour le groupe de disponibilité. Comme vous ne disposez que de deux instances, dans la section suivante, vous allez configurer un témoin de partage de fichiers pour obtenir un nombre de votes majoritaire et atteindre un quorum.

Créer un témoin de partage de fichiers

Pour obtenir un nombre de votes majoritaire et atteindre un quorum dans un scénario de basculement, créez un partage de fichiers qui sert de témoin. Pour les besoins de ce tutoriel, vous allez créer le témoin de partage de fichiers sur la VM du contrôleur de domaine. Dans un environnement de production, il est recommandé de créer le témoin de partage de fichiers sur n'importe quel serveur de votre domaine Active Directory.

  1. Utilisez le compte dbeng\Administrator pour vous connecter à la VM du contrôleur de domaine, dc-windows, à l'aide du protocole RDP.
  2. Ouvrez une invite PowerShell avec élévation de privilèges (exécutée en tant qu'administrateur).

  3. Créez le dossier témoin :

    New-Item "C:\QWitness" –type directory

  4. Partagez le dossier :

    New-SmbShare -Name "QWitness" -Path "C:\QWitness" -Description "SQL File Share Witness" -FullAccess "dbeng.com\Administrator", "dbeng.com\cluster-sql1$", "dbeng.com\cluster-sql2$"

  5. Utilisez dbeng.com\Administrator pour vous connecter à cluster-sql1 et à cluster-sql2 à l'aide du protocole RDP.

  6. Vérifiez que vous pouvez accéder au répertoire partagé à partir des deux serveurs :

    dir \\dc-windows\QWitness

    Si vous n'avez pas accès à l'annuaire partagé, essayez de modifier la connexion réseau sur le nœud pour définir le serveur WINS de sorte qu'il corresponde au serveur du domaine. Le changement de connexion réseau peut prendre quelques secondes. La capture d'écran suivante montre les paramètres WINS mis à jour :

    Paramètres d'adresse WINS mis à jour dans les paramètres avancés TCP/IP.

Tout est maintenant prêt pour le groupe de disponibilité. Vous allez ensuite configurer le clustering de basculement.

Configurer le clustering de basculement

Dans cette section, vous allez configurer le WSFC et activez la haute disponibilité toujours activée pour les deux instances. Exécutez toutes les commandes de configuration suivantes à partir de l'instance dans AWS.

  1. Connectez-vous à l'instance AWS (cluster-sql1) à l'aide du protocole RDP.
  2. Ouvrez une invite PowerShell avec élévation de privilèges (exécutée en tant qu'administrateur).

  3. Définissez des variables qui reflètent votre environnement de cluster. Pour cet exemple, définissez les variables suivantes :

    $node1 = "cluster-sql1.dbeng.com"
$node2 = "cluster-sql2.dbeng.com"
$nameWSFC = "cluster-dbclus" #Name of cluster
$ipWSFC1 = "192.168.1.5" #IP address of cluster in subnet 1 (AWS)
$ipWSFC2 = "10.1.1.5"    #IP address of cluster in subnet 2 (Google Cloud)

  4. Créez le cluster de basculement (l'exécution de cette commande peut prendre un certain temps) :

    New-Cluster -Name $nameWSFC -Node $node1, $node2 -NoStorage -StaticAddress $ipWSFC1, $ipWSFC2

Set-ClusterQuorum -FileShareWitness \\dc-windows\QWitness

  5. Activez la haute disponibilité toujours activée sur le nœud 1. Si vous n'avez pas encore activé la haute disponibilité toujours activée, ces commandes obligent SQL Server à redémarrer.

    Enable-SqlAlwaysOn -ServerInstance $node1 -Force

  6. Activez la haute disponibilité toujours activée sur le nœud 2. Ces commandes arrêtent le service SQL Server avant d'activer SQL toujours activé. Vous pouvez donc ignorer l'erreur suivante : Enable-SqlAlwaysOn : StopService failed for Service 'MSSQLSERVER'.

    Get-Service -ComputerName $node2 -Name "MSSQLServer" | Stop-Service -Force

Enable-SqlAlwaysOn -ServerInstance $node2 -Force

Get-Service -ComputerName $node2 -Name "MSSQLServer" | Start-Service

  7. Créez des dossiers sous C:\SQLData et C:\SQLLog. Utilisez ces dossiers pour les données et fichiers journaux de la base de données TestDB. Si votre serveur possède déjà une base de données ayant cette structure de dossiers, vous pouvez ignorer cette étape. Si vous n'êtes pas sûr, exécutez les commandes et ignorez les messages d'erreur concernant les dossiers préexistants.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

Le gestionnaire du cluster de basculement est prêt. Vous devez maintenant créer le groupe de disponibilité.

Créer le groupe de disponibilité

Dans cette section, vous allez créer une base de données de test dans AWS (cluster-sql1) et la configurer pour qu'elle fonctionne avec un nouveau groupe de disponibilité. Vous pouvez également spécifier une base de données existante pour le groupe de disponibilité.

  1. Connectez-vous à l'instance AWS (cluster-sql1) à l'aide du protocole RDP.
  2. Ouvrez une invite PowerShell avec élévation de privilèges (exécutée en tant qu'administrateur).

  3. Créez un dossier sous C:\SQLBackup pour stocker une sauvegarde de la base de données. La sauvegarde est obligatoire pour que vous puissiez configurer le groupe de disponibilité sur une nouvelle base de données.

    New-Item "C:\SQLBackup" –type directory

  4. Si aucune base de données n'est déjà configurée, exécutez SQL Server Management Studio et créez une base de données de test dans l'instance AWS (cluster-sql1) :

    CREATE DATABASE TestDB
ON PRIMARY (NAME = 'TestDB_Data', FILENAME='C:\SQLData\TestDB_Data.mdf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
LOG ON (NAME = 'TestDB_Log', FILENAME='C:\SQLLog\TestDB_Log.ldf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
GO

USE [TestDB]
Exec dbo.sp_changedbowner @loginame = 'sa', @map = false;
ALTER DATABASE [TestDB] SET RECOVERY FULL;
GO

BACKUP DATABASE TestDB to disk = 'C:\SQLBackup\TestDB-backup.bak' WITH INIT
GO

  5. Dans Microsoft SQL Server Management Studio, sélectionnez Requête > Mode SQLCMD.

    SQL Server Management Studio propose un assistant permettant de créer les groupes de disponibilité. Dans ce tutoriel, vous utilisez les commandes SQL à la place, pour faciliter le débogage des problèmes que vous pourriez rencontrer lors de la connexion à différents fournisseurs de cloud. Si vous préférez, vous pouvez exécuter l'assistant de groupe de disponibilité et passer à l'étape suivante pour vérifier la synchronisation du groupe de disponibilité.

  6. Exécutez les requêtes suivantes en mode SQLCMD. Si vous utilisez une base de données préexistante, remplacez TestDB par le nom de votre base de données.

    1. Créez un point de terminaison dans le premier nœud et accordez l'autorisation au point de terminaison :

      :Connect CLUSTER-SQL1
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
  AS TCP (LISTENER_PORT = 5022)
  FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    2. Activez la session d'événement étendue AlwaysOn_health dans le premier nœud. Les groupes de disponibilité nécessitent une session d'événement étendu.

      :Connect CLUSTER-SQL1
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    3. Créez un point de terminaison dans le deuxième nœud et accordez l'autorisation au point de terminaison :

      :Connect CLUSTER-SQL2
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    4. Activez la session d'événement étendue AlwaysOn_health dans le deuxième nœud. Les groupes de disponibilité nécessitent une session d'événement étendu.

      :Connect CLUSTER-SQL2
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    5. Créez le groupe de disponibilité dans le premier nœud :

      :Connect CLUSTER-SQL1
USE [master]
GO

--DROP AVAILABILITY GROUP [cluster-ag];
GO

CREATE AVAILABILITY GROUP [cluster-ag]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
DB_FAILOVER = OFF,
DTC_SUPPORT = NONE)
FOR DATABASE [TestDB]
REPLICA ON N'CLUSTER-SQL1' WITH (ENDPOINT_URL = N'TCP://CLUSTER-SQL1.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL),
  N'CLUSTER-SQL2' WITH (ENDPOINT_URL = N'TCP://cluster-sql2.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL);
GO

    6. Associez le deuxième nœud au groupe de disponibilité que vous venez de créer :

      :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] JOIN;
GO

    7. Créez une sauvegarde de base de données dans le premier nœud :

      :Connect CLUSTER-SQL1
BACKUP DATABASE [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    8. Restaurez la sauvegarde de la base de données sur le deuxième nœud :

      :Connect CLUSTER-SQL2
RESTORE DATABASE [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

    9. Créez une sauvegarde du journal des transactions dans le premier nœud :

      :Connect CLUSTER-SQL1
BACKUP LOG [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    10. Restaurez la sauvegarde du journal des transactions dans le deuxième nœud :

      :Connect CLUSTER-SQL2
RESTORE LOG [TestDB] FROM  DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

  7. Pour vérifier qu'aucune erreur n'est présente dans la synchronisation, exécutez la requête suivante et assurez-vous que la colonne connected_state_desc a la valeur CONNECTED :

    :Connect CLUSTER-SQL2
select r.replica_server_name, r.endpoint_url,
       rs.connected_state_desc, rs.last_connect_error_description,
       rs.last_connect_error_number, rs.last_connect_error_timestamp
 from sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r
   on rs.replica_id=r.replica_id
 where rs.is_local=1

    • Si la colonne connected_state_desc comporte le message d'erreur An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)', exécutez la commande suivante pour essayer de supprimer l'erreur :

      :Connect CLUSTER-SQL1
IF SUSER_ID('DBENG\CLUSTER-SQL2$') IS NULL
   CREATE LOGIN [DBENG\CLUSTER-SQL2$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL2$]
GO

:Connect CLUSTER-SQL2
IF SUSER_ID('DBENG\CLUSTER-SQL1$') IS NULL
  CREATE LOGIN [DBENG\CLUSTER-SQL1$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL1$]
GO

      Réexécutez la requête précédente pour vous assurer que l'erreur de synchronisation ne se produit plus. Vous devrez peut-être attendre quelques minutes pour que l'erreur soit résolue. Si l'erreur persiste, consultez la page Résoudre les problèmes de configuration des groupes de disponibilité toujours activé (SQL Server).

  8. Terminez la configuration du groupe de disponibilité :

    :Connect CLUSTER-SQL2
ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]
GO

ALTER DATABASE [TestDB] SET HADR RESUME;
GO

  9. Vérifiez que le groupe de disponibilité est synchronisé :

    1. Dans SQL Server Management Studio, sous Haute disponibilité toujours activée > Groupes de disponibilité, effectuez un clic droit sur le groupe de disponibilité, puis sélectionnez Afficher le tableau de bord.

    2. Vérifiez que l'état de synchronisation principal est Synchronized (synchronisé) et que l'état de synchronisation secondaire est Synchronizing (en cours de synchronisation), comme indiqué dans la capture d'écran suivante :

      SQL Server Management Studio affiche l'état de synchronisation pour le groupe de disponibilité.

  10. Pour ajouter un écouteur, sous Haute disponibilité toujours activée > Groupes de disponibilité > cluster-ag (Primary) > Écouteurs du groupe de disponibilité, faites un clic droit sur le nom du groupe de disponibilité, puis sélectionnez Ajouter écouteur.

  11. Dans la boîte de dialogue Nouvel écouteur de groupe de disponibilité, spécifiez les paramètres suivants pour l'écouteur :

    • Nom DNS de l'écouteur : ag-listener
    • Port : 1433
    • Mode réseau : Static IP

  12. Ajoutez deux champs de sous-réseau et d'adresse IP. Pour cet exemple, utilisez les paires de sous-réseau et d'adresse IP suivantes. Ces paires sont les adresses IP que vous avez créées en plus de l'adresse IP principale sur les VM d'instance de SQL Service :

    1. Pour la première paire, saisissez les valeurs suivantes :
      • Sous-réseau : 192.168.1.0/24
      • Adresse IPv4 : 192.168.1.6
    2. Pour la deuxième paire, saisissez les valeurs suivantes :
      • Sous-réseau : 10.1.1.0/24
      • Adresse IPv4 : 10.1.1.6

  13. Lorsque vous avez terminé d'ajouter des paires de sous-réseau et d'adresse IP, cliquez sur OK.

  14. Connectez-vous à SQL Server à l'aide de ag-listener.dbeng.com en tant que nom de base de données SQL Server au lieu d'utiliser le nom des instances. Cette connexion pointe vers l'instance actuellement active.

    1. Dans l'explorateur d'objets, cliquez sur Se connecter, puis sélectionnez Moteur de base de données.
    2. Dans la boîte de dialogue Se connecter au serveur, dans le champ Nom du serveur, saisissez le nom de l'écouteur ag-listener.dbeng.com.

    3. Après avoir ajouté le nom du serveur, cliquez sur Se connecter. L'explorateur d'objets affiche la nouvelle connexion, comme illustré dans la capture d'écran suivante :

      L'explorateur d'objets affiche une connexion.

    Si vous êtes connecté à cluster-sql2 à l'aide de RDP, vous pouvez éventuellement répéter cette étape pour établir la connexion.

Ajouter des données de test

Dans cette section, vous allez ajouter une table de test et des données de test à la base de données TestDB dans cluster-sql1, puis vérifier la duplication des données.

  1. Créez une table nommée Persons dans cluster-sql1 :

    :Connect CLUSTER-SQL1
USE TestDB;
CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    PRIMARY KEY (PersonID)
);

  2. Insérez quelques lignes :

    :Connect CLUSTER-SQL1
USE TestDB;
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (1, 'Velasquez', 'Ava');
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (2, 'Delaxcrux', 'Paige');

  3. Si vous utilisez l'édition Enterprise, activez l'accès en lecture de l'instance dupliquée avec accès en lecture (cluster-sql2) afin de pouvoir vérifier que la duplication a lieu. L'édition Standard n'est pas compatible avec l'accès en lecture seule à l'instance dupliquée avec accès en lecture. Si vous utilisez l'édition Standard, passez à la section suivante pour exécuter le basculement vers Google Cloud.

    :Connect CLUSTER-SQL1
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

  4. Dans l'édition Enterprise, interrogez la table dans cluster-sql2 pour vérifier que le contenu de la table a bien été dupliqué :

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

Maintenant que les données sont dupliquées de cluster-sql1 à cluster-sql2, vous allez exécuter le basculement. Si vous souhaitez seulement effectuer une duplication, vous pouvez ignorer les sections suivantes et ne pas exécuter le basculement ou le remplacement. Si vous ne souhaitez pas conserver les ressources que vous avez utilisées pour la duplication, vous pouvez éviter qu'elles soient facturées en suivant les étapes de nettoyage à la fin de ce tutoriel.

Exécuter le basculement vers Google Cloud

Pour garantir la cohérence d'un ensemble de données, tous les clients qui écrivent sur cluster-sql1 doivent être arrêtés afin que toutes les données puissent être dupliquées dans cluster-sql2 avant d'exécuter le basculement.

Pour assurer la cohérence, toutes les données doivent être entièrement dupliquées. Dans cette section, vous allez effectuer une duplication complète des données en définissant le mode de disponibilité sur SYNCHRONOUS_COMMIT. Cette modification garantit une duplication complète de cluster-sql1 vers cluster-sql2.

  1. Pour définir le mode de disponibilité des deux nœuds sur le commit synchrone, exécutez la commande SQL suivante dans cluster-sql1. La définition des deux nœuds sur le commit synchrone est le seul moyen de s'assurer qu'aucune donnée n'est perdue.

    :Connect CLUSTER-SQL1
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

  2. Cluster-sql2 est maintenant prêt à devenir le nœud principal. Connectez-vous à cluster-sql2 et définissez-le comme nœud principal :

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
GO

  3. Définissez le mode de disponibilité sur le commit asynchrone dans les deux nœuds. cluster-sql2 étant le nœud principal, exécutez les commandes SQL suivantes dans cluster-sql2 :

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

    Vous êtes maintenant prêt à utiliser cluster-sql2 en tant que nœud principal pour les applications. cluster-sql1 est le nœud secondaire dupliqué de manière asynchrone.

  4. Maintenant que cluster-sql2 est le nœud principal, interrogez la table dans cluster-sql2 pour vérifier que le contenu de la table a bien été dupliqué :

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

    Le résultat correspond aux données de test que vous avez insérées dans la table plus tôt dans ce tutoriel.

Pour effectuer une vérification de duplication supplémentaire, vous pouvez créer une table et insérer une seule ligne sur le nouveau nœud principal. Lorsque la table et sa ligne apparaissent sur le réseau secondaire, vous savez que la duplication fonctionne.

Action de remplacement

Vous devrez peut-être parfois repasser du nouveau nœud principal à l'ancien. Lorsque vous avez effectué le basculement vers Google Cloud plus tôt dans ce tutoriel, vous avez défini l'ancien nœud principal (cluster-sql1) comme nœud secondaire du nouveau nœud principal (cluster-sql2).

Pour effectuer un remplacement, suivez le processus permettant d'exécuter le basculement vers Google Cloud et remplacez les valeurs suivantes :

  • Remplacez le nœud principal d'origine (cluster-sql1) par le nouveau nœud (cluster-sql2).
  • Remplacez le nœud secondaire d'origine (cluster-sql2) par le nouveau nœud secondaire (cluster-sql1).

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

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 dans Google Cloud

  1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer le projet dans AWS

Étant donné que vous avez créé et utilisé des ressources dans AWS, celles-ci continuent d'être facturées. Pour vous assurer qu'aucun autre coût n'est cumulé, supprimez ces ressources sur AWS.

Étape suivante