Migrer une base de données SQL Server depuis AWS EC2 vers Compute Engine

Ce tutoriel vous présente les différentes approches que vous pouvez utiliser pour migrer une base de données Microsoft SQL Server hébergée sur Amazon Elastic Compute Cloud (AWS EC2) vers Compute Engine.

Cette page aborde les approches suivantes :

• Migrer en effectuant une sauvegarde complète puis une restauration
• Migrer à l'aide d'un fichier BACPAC
• Migrer à l'aide de groupes de disponibilité Always On
• Migrer à l'aide de groupes de disponibilité distribués

Chaque méthode de migration présente des avantages et inconvénients distincts. Le choix de la stratégie de migration la plus appropriée dépend de votre situation et de vos priorités spécifiques. Nous vous recommandons de choisir la méthode de migration qui vous convient le mieux en fonction des éléments suivants :

• Disponibilité : vous devez déterminer si une approche de migration est disponible avec toutes les versions et licences de votre base de données SQL Server.

• Taille de la base de données : la taille de la base de données peut avoir un impact significatif sur les options de migration envisageables, sachant que des bases de données plus volumineuses peuvent nécessiter des stratégies différentes de celles utilisées pour les bases plus petites. Lorsque vous choisissez une approche de migration, tenez compte de la durée du transfert de données, des éventuels temps d'arrêt et des besoins en ressources.

• Tolérance aux temps d'arrêt : le niveau de temps d'arrêt acceptable pendant la migration est un facteur crucial. Certaines méthodes permettent de réduire les temps d'arrêt au maximum, voire de les éliminer, tandis que d'autres nécessitent un temps d'arrêt plus long. Choisissez une approche de migration qui vous offre un temps d'arrêt acceptable.

• Complexité : la complexité du schéma de base de données, des dépendances des applications et de l'environnement global peut avoir une influence sur l'approche de migration adoptée. Assurez-vous que la méthode de migration que vous choisissez permet la migration des objets non liés à la base de données, tels que les jobs d'agent SQL, les serveurs associés, les autorisations et les objets utilisateur.

• Coût : l'aspect financier de la migration peut également être un facteur à prendre en compte. Des méthodes de migration différentes entraînent une variation des coûts associés au transfert de données, aux ressources de calcul et à d'autres services. Choisissez la méthode de migration qui vous convient le mieux.

• Sécurité et conformité des données : assurez-vous que la méthode de migration choisie respecte vos exigences en termes de sécurité et de conformité des données. Pensez au chiffrement des données, aux contrôles d'accès et aux exigences spécifiques à votre secteur qui s'appliquent à vos données.

Objectifs

Ce tutoriel vous explique comment effectuer les tâches suivantes pour migrer votre base de données SQL Server d'AWS EC2 vers Compute Engine :

• Déployer une instance SQL Server sur Compute Engine
• Migrer en effectuant une sauvegarde complète et une restauration
• Migrer à l'aide d'un fichier BACPAC
• Migrer à l'aide de groupes de disponibilité Always On
• Migrer à l'aide de groupes de disponibilité distribués

Coûts

Ce tutoriel fait appel à des composants payants de Google Cloud, y compris ceux-ci :

• Compute Engine
• Cloud Load Balancing

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   Préparer le projet et le réseau

   Pour préparer votre projet Google Cloud et votre cloud privé virtuel (VPC) pour le déploiement de SQL Server en vue de la migration, procédez comme suit :

   1. Dans la console Google Cloud , cliquez sur Activer Cloud Shell pour ouvrir Cloud Shell.

      Accéder à la console Google Cloud

   2. Définissez votre ID de projet par défaut :

      gcloud config set project PROJECT_ID
      

      Remplacez PROJECT_ID par l'ID de votre projet Google Cloud .

   3. Définissez votre région par défaut :

      gcloud config set compute/region REGION
      

      Remplacez REGION par l'ID de la région dans laquelle vous souhaitez effectuer le déploiement.

   4. Définissez votre zone par défaut :

      gcloud config set compute/zone ZONE
      

      Remplacez ZONE par l'ID de la zone dans laquelle vous souhaitez effectuer le déploiement. Assurez-vous que la zone est valide dans la région que vous avez spécifiée à l'étape précédente.

   Créer une instance SQL Server sur Compute Engine

   Avant de migrer votre base de données SQL Server vers Compute Engine, vous devez créer une machine virtuelle (VM) sur Compute Engine pour l'héberger.

   Exécutez la commande suivante pour créer une instance SQL Server sur Compute Engine :

   2022 Standard

   gcloud compute instances create sql-server-std-migrate-vm \
   --project=PROJECT_ID \
   --zone ZONE \
   --machine-type n4-standard-8 \
   --subnet SUBNET_NAME \
   --create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-standard-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
   --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write
   

   Remplacez les éléments suivants :

   • PROJECT_ID par l'ID de votre projet Google Cloud .
   • ZONE par l'ID de la zone.
   • SUBNET_NAME par le nom de votre sous-réseau VPC.

   2022 Enterprise

   gcloud compute instances create sql-server-ent-migrate-vm \
   --project=PROJECT_ID \
   --zone ZONE \
   --machine-type n4-standard-8 \
   --subnet SUBNET_NAME \
   --create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-enterprise-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
   --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write
   

   Remplacez les éléments suivants :

   • PROJECT_ID par l'ID de votre projet Google Cloud .
   • ZONE par l'ID de la zone.
   • SUBNET_NAME par le nom de votre sous-réseau VPC.

   Pour en savoir plus sur la création d'instances SQL Server sur Compute Engine, consultez Créer une instance SQL Server.

   Configurer votre VM SQL Server et vous y connecter

   Pour configurer votre VM SQL Server et vous y connecter, procédez comme suit :

   1. Définissez le mot de passe Windows initial pour votre compte :

      1. Dans la console Google Cloud , accédez à la page Instances de VM.

         Accéder à la page "Instances de VM"

      2. Cliquez sur le nom de la VM SQL Server.

      3. Cliquez sur le bouton Définir un mot de passe Windows.

      4. Saisissez un mot de passe, puis cliquez sur Définir lorsque vous êtes invité à définir le nouveau mot de passe Windows.

      5. Enregistrez le nom d'utilisateur et le mot de passe.

   2. Connectez-vous à la VM SQL Server :

      1. Utilisez l'adresse IP publique de la VM SQL Server (indiquée sur la page Instances de VM) ainsi que les identifiants enregistrés à l'étape précédente pour vous connecter à votre VM SQL Server par le biais du Bureau à distance Microsoft (RDP).

      2. Exécutez SQL Server Management Studio (SSMS) en tant qu'administrateur.

      3. Vérifiez que la case Trust server certificate (Faire confiance au certificat du serveur) est cochée, puis cliquez sur Connect (Se connecter).

   Votre VM SQL Server est désormais prête à être utilisée pour la migration de la base de données. Pour créer des identifiants utilisateur afin de vous connecter à votre VM SQL Server et de la gérer, consultez Créer un compte de connexion.

   Sauvegarde et restauration complètes de la base de données

   Une sauvegarde et une restauration complètes de la base de données constituent la méthode de migration de base de données la plus courante et la plus simple. Avec cette approche, une sauvegarde complète de la base de données SQL Server est effectuée à partir de l'environnement source. Elle est ensuite restaurée dans l'environnement Google Cloud de destination. Bien que cette méthode soit relativement simple, elle peut prendre un certain temps pour les bases de données volumineuses en raison du temps nécessaire pour créer et restaurer la sauvegarde.

   Cette section explique comment utiliser SSMS pour exporter votre base de données SQL Server. Elle utilise pour cela un exemple de base de données AdventureWorks2022.

   Créer une sauvegarde complète de la base de données

   Pour créer une sauvegarde complète de la base de données, procédez comme suit :

   1. Connectez-vous à votre VM AWS EC2 à l'aide de Microsoft RDP.

   2. Connectez-vous à SQL Server à l'aide de SSMS.

   3. Développez le dossier des bases de données dans l'explorateur d'objets.

   4. Effectuez un clic droit sur le nom de la base de données, puis cliquez sur Tasks (Tâches) dans le menu.

   5. Cliquez sur Back up (Sauvegarder) pour ouvrir l'assistant de sauvegarde de base de données.

      1. Vérifiez le nom de la base de données à sauvegarder, et assurez-vous que le type de sauvegarde est défini sur "Complète".

      2. Cliquez sur Add (Ajouter) sous la destination de la sauvegarde complète.

      3. Cliquez sur l'icône à trois points (...) afin de sélectionner le dossier et le nom du fichier de sauvegarde.

      4. Cliquez sur OK pour définir le nom du fichier, puis de nouveau sur OK pour définir la destination.

         

      5. Cliquez sur OK pour démarrer la sauvegarde de la base de données, puis attendez qu'elle se termine.

         Une fois le processus de sauvegarde terminé, un fichier de sauvegarde est généré. Vous pouvez maintenant utiliser ce fichier de sauvegarde pour migrer le contenu de la base de données vers une VM Compute Engine.

      6. Cliquez sur OK pour quitter l'assistant de sauvegarde de base de données.

   Transférer le fichier de sauvegarde vers une VM Compute Engine

   Pour migrer le contenu de votre base de données SQL Server, vous devez transférer le fichier de sauvegarde créé à l'étape précédente vers la VM Compute Engine que vous avez créée. Pour en savoir plus sur les différentes options de transfert, consultez Transférer des fichiers vers des VM Windows.

   Restaurer votre base de données SQL Server à partir du fichier de sauvegarde

   Pour restaurer la base de données à partir du fichier de sauvegarde, procédez comme suit :

   1. Connectez-vous à votre VM Compute Engine à l'aide de RDP.

   2. Connectez-vous à SQL Server à l'aide de SSMS.

   3. Dans l'explorateur d'objets, effectuez un clic droit sur le dossier Databases (Bases de données), puis cliquez sur Restore Database (Restaurer la base de données).

   4. Pour la section Source, cliquez sur Device (Dispositif), puis sur l'icône à trois points (...) pour ouvrir la page "Select backup device" (Sélectionner un appareil de sauvegarde).

   5. Vérifiez que "Backup media type" (type de support de sauvegarde) est défini sur "File" (Fichier), puis cliquez sur Add (Ajouter) pour sélectionner le fichier de sauvegarde.

      

   6. Cliquez sur OK pour définir le fichier de sauvegarde comme dispositif de restauration.

   7. Cliquez sur OK pour restaurer la base de données.

      Une fois le processus terminé, votre base de données est migrée vers le serveur SQL Server de destination sur Compute Engine.

   8. Pour vérifier que le processus s'est terminé correctement, vous pouvez développer le dossier databases (bases de données) dans l'explorateur d'objets et vérifier si la base de données migrée est visible.

      

   Migrer à l'aide d'un fichier BACPAC

   Un fichier de package de sauvegarde (BACPAC) est une représentation logique d'une base de données SQL Server. Il peut être exporté depuis l'environnement AWS source, puis importé dans l'environnement Google Cloud de destination. Cette méthode est généralement plus rapide qu'une sauvegarde et une restauration complètes pour les petites bases de données, mais elle peut ne pas convenir aux très grandes bases de données ni à celles qui présentent des dépendances complexes.

   La section suivante explique comment migrer votre base de données SQL Server à l'aide d'un fichier BACPAC.

   Créer une exportation BACPAC

   Pour créer une exportation BACPAC, procédez comme suit :

   1. Connectez-vous à la VM AWS EC2 à l'aide de Microsoft RDP.

   2. Connectez-vous à SQL Server à l'aide de SSMS.

   3. Développez le dossier databases (bases de données) dans l'explorateur d'objets.

   4. Effectuez un clic droit sur le nom de la base de données, puis cliquez sur Tasks (Tâches).

   5. Cliquez sur Export Data-tier Application (Exporter l'application de la couche Données) pour ouvrir l'assistant d'exportation.

      1. Cliquez sur Next (Suivant).

      2. Cliquez sur Browse (Parcourir) au niveau de l'option Save to local disk (Enregistrer sur le disque local), puis sélectionnez le fichier BACPAC.

      3. Cliquez sur l'onglet Advanced (Avancé), puis sélectionnez le ou les schémas que vous souhaitez exporter.

      4. Cliquez sur Next (Suivant) pour accéder au récapitulatif.

      5. Cliquez sur Finish (Terminer) pour exporter le fichier BACPAC, puis attendez que l'exportation se termine.

      6. Cliquez sur Close (Fermer) pour quitter l'assistant.

   6. Transférez le fichier BACPAC créé lors des étapes précédentes vers votre VM de destination sur Compute Engine. Pour en savoir plus sur les options de transfert, consultez Transférer des fichiers vers des VM Windows.

   Restaurer votre base de données SQL Server à partir d'un fichier BACPAC

   Pour restaurer la base de données à partir du fichier BACPAC, procédez comme suit :

   1. Connectez-vous à la VM Compute Engine à l'aide de RDP.

   2. Connectez-vous à SQL Server à l'aide de SSMS.

   3. Dans l'explorateur d'objets, effectuez un clic droit sur le dossier Databases (Bases de données), puis cliquez sur Import Data-tier Application (Importer une application de la couche Données).

   4. Cliquez sur Next (Suivant).

   5. Cliquez sur Browse (Parcourir), sélectionnez le fichier BACPAC que vous souhaitez restaurer, puis cliquez sur Next (Suivant).

   6. Vérifiez le nom de la nouvelle base de données, puis cliquez sur Next (Suivant).

   7. Cliquez sur Finish (Terminer), puis attendez que l'importation soit terminée.

   8. Cliquez sur Close (Fermer) pour quitter l'assistant.

   9. Pour vérifier que le processus s'est terminé correctement, vous pouvez développer le dossier databases (bases de données) dans l'explorateur d'objets et vérifier si la base de données migrée est visible.

   Migrer à l'aide de groupes de disponibilité Always On (AOAG)

   Un AOAG est une fonctionnalité de haute disponibilité et de reprise après sinistre fournie par SQL Server. Vous pouvez utiliser un groupe de disponibilité Always On pour migrer des clusters AOAG existants, des serveurs SQL autonomes et des clusters de basculement Windows Server (WSFC). Avec cette méthode, une instance répliquée de la base de données est créée dans l'environnement Google Cloud de destination, et les données sont synchronisées entre la source et la cible. Une fois la synchronisation terminée, l'instance répliquée dans l'environnement Google Cloud de destination peut être définie comme instance principale. Cette méthode minimise les temps d'arrêt, mais nécessite diverses configurations supplémentaires. Pour les migrations simples avec une grande tolérance aux temps d'arrêt, d'autres méthodes peuvent être plus simples et plus économiques.

   Avant de commencer

   Avant de commencer la migration, assurez-vous vérifiez les points suivants :

   • Pour assurer un transfert sécurisé et fluide des données, établissez une connexion d'appairage entre AWS et Google Cloud. Pour en savoir plus, consultez Créer des connexions VPN haute disponibilité entre Google Cloud et AWS.

   • Assurez-vous que la base de données source est exécutée en mode autonome et que les serveurs source et de destination sont associés à un annuaire Active Directory (AD). Si la base de données source fait déjà partie d'un cluster WSFC utilisant un groupe de disponibilité Always On, consultez Migrer à l'aide de groupes de disponibilité distribués.

   • Assurez-vous que toutes les clés de chiffrement de la base de données SQL Server source sont installées sur toutes les instances SQL Server qui rejoindront le groupe AOAG.

   Préparer votre serveur SQL Server à intégrer un groupe AOAG

   Pour pouvoir ajouter des serveurs SQL à un groupe de disponibilité Always On, vous devez activer la fonctionnalité AOAG sur toutes les instances SQL Server que vous souhaitez ajouter au groupe.

   Pour activer la fonctionnalité AOAG sur toutes les VM SQL Server que vous souhaitez ajouter à un AOAG, procédez comme suit :

   1. Activez AOAG sur votre serveur SQL Server.

      1. Connectez-vous à votre VM SQL Server à l'aide de RDP.

      2. Ouvrez PowerShell en mode administrateur.

      3. Exécutez la commande suivante pour activer AOAG sur votre serveur SQL Server :

         Enable-SqlAlwaysOn -ServerInstance $env:COMPUTERNAME -Force
         

      4. Exécutez la commande suivante pour ouvrir un port de pare-feu pour la réplication des données :

         netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
         

      5. Répétez l'étape 1 pour toutes les VM SQL Server que vous souhaitez ajouter au groupe de disponibilité Always On.

   2. Créez un utilisateur pour votre serveur SQL Server sur l'annuaire AD.

      $Credential = Get-Credential -UserName sql_server -Message 'Enter password'
      New-ADUser `
      -Name "sql_server" `
      -Description "SQL Admin account." `
      -AccountPassword $Credential.Password `
      -Enabled $true -PasswordNeverExpires $true
      

   3. Effectuez la procédure suivante sur toutes les instances SQL Server qui font partie du groupe de disponibilité Always On :

      1. Accédez au Gestionnaire de configuration SQL Server.
      2. Dans le volet de navigation, sélectionnez SQL Server Services (Services SQL Server).
      3. Dans la liste des services, faites un clic droit sur SQL Server (MSSQLSERVER), puis sélectionnez Properties (Propriétés).
      4. Sous Log on as (Se connecter en tant que), modifiez le compte comme suit :
         • Nom du compte : DOMAIN\sql_server, où DOMAIN est le nom NetBIOS de votre domaine AD.
         • Mot de passe : saisissez le mot de passe que vous avez choisi à l'étape 2 de cette section.

      5. Cliquez sur OK.

      6. Lorsque vous êtes invité à redémarrer SQL Server, sélectionnez Yes (Oui).

   Votre serveur SQL Server s'exécute désormais sous un compte utilisateur de domaine.

   Remarque : Vérifiez que vous avez bien effectué ces étapes de configuration sur toutes les instances de VM que vous souhaitez ajouter au groupe de disponibilité Always On. Si ce n'est pas le cas, la configuration de l'AOAG échouera.

   Configurer le point de terminaison de mise en miroir pour votre base de données SQL Server

   Pour créer le point de terminaison de votre AOAG, procédez comme suit :

   1. Si la base de données SQL Server source est chiffrée avec le chiffrement TDE (Transparent Data Encryption), suivez cette procédure pour sauvegarder, transférer et installer les certificats et les clés sur le serveur SQL Server de destination.

   2. Connectez-vous à la base de données source sur AWS à l'aide de SSMS.

   3. Exécutez la commande T-SQL suivante pour créer le point de terminaison du groupe de disponibilité :

      USE [master]
      GO
      CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
      GO
      
      USE [DATABASE_NAME]
      GO
      CREATE USER [NET_DOMAIN\sql_server] FOR LOGIN [NET_DOMAIN\sql_server]
      GO
      
      USE [master]
      GO
      CREATE ENDPOINT migration_endpoint
          STATE=STARTED
          AS TCP (LISTENER_PORT=5022)
          FOR DATABASE_MIRRORING (ROLE=ALL);
      GO
      
      GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
      GO
      

      Remplacez NET_DOMAIN par le nom NetBIOS de votre domaine AD et DATABASE_NAME par le nom de la base de données à migrer.

      Conseil : Le port d'écoute par défaut est le 5022, mais vous pouvez utiliser n'importe quel autre port disponible.

   4. Connectez-vous au serveur SQL de destination sur Google Cloud à l'aide de SSMS et exécutez la commande T-SQL suivante pour créer le point de terminaison de mise en miroir de la base de données :

      CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
      GO
      
      CREATE ENDPOINT migration_endpoint
          STATE=STARTED
          AS TCP (LISTENER_PORT=5022)
          FOR DATABASE_MIRRORING (ROLE=ALL);
      GO
      
      GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
      GO
      

      Remplacez NET_DOMAIN par le nom NetBIOS de votre domaine AD.

   5. Vérifiez les points de terminaison en accédant à Server Objects > Endpoints > Database Mirroring (Objets serveur > Points de terminaison > Mise en miroir de la base de données) dans l'explorateur d'objets de SSMS.

      

   Créer le groupe de disponibilité Always On (AOAG)

   Pour créer un AOAG, procédez comme suit :

   1. Connectez-vous à la base de données source sur AWS à l'aide de SSMS.

   2. Exécutez la commande T-SQL suivante pour définir le mode de récupération de la base de données sur "complète" et effectuer une sauvegarde complète :

      USE [master]
      GO
      
      ALTER DATABASE [DATABASE_NAME]
      SET RECOVERY FULL;
      BACKUP DATABASE [DATABASE_NAME]
      TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\DATABASE_NAME.bak';
      

      Remplacez DATABASE_NAME par le nom de la base de données à migrer.

   3. Exécutez la commande T-SQL suivante pour créer l'AOAG :

      USE [master]
      GO
      
      CREATE AVAILABILITY GROUP [migration-ag]
      WITH (
          AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
          DB_FAILOVER = OFF,
          DTC_SUPPORT = NONE,
          REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
      )
      FOR DATABASE [DATABASE_NAME]
      REPLICA ON
      N'SOURCE_SERVERNAME' WITH (
          ENDPOINT_URL = 'TCP://SOURCE_HOSTNAME:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          BACKUP_PRIORITY = 50,
          SEEDING_MODE = AUTOMATIC,
          SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
      ),
      N'DEST_SERVERNAME' WITH (
          ENDPOINT_URL = 'TCP://DEST_HOSTNAME:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          BACKUP_PRIORITY = 50,
          SEEDING_MODE = AUTOMATIC,
          SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
      );
      GO
      

      Remplacez les éléments suivants :

      • DATABASE_NAME par le nom de la base de données à migrer.
      • SOURCE_SERVERNAME par le nom du serveur de la base de données source.
      • DEST_SERVERNAME par le nom du serveur de la base de données de destination.
      • SOURCE_HOSTNAME par le nom de domaine complet (FQDN) de la source.
      • DEST_HOSTNAME par le nom de domaine complet de la cible.
      Remarque : Le groupe de disponibilité Always On utilise un mode de validation asynchrone et le basculement automatique est désactivé pour minimiser l'impact sur le serveur SQL principal.

   4. Exécutez la commande T-SQL suivante sur la base de données de destination pour l'ajouter à l'AOAG :

      USE [master]
      GO
      
      ALTER AVAILABILITY GROUP [migration-ag] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
      ALTER AVAILABILITY GROUP [migration-ag] GRANT CREATE ANY DATABASE;
      GO
      

   5. Vérifiez l'état du groupe AOAG et de la base de données nouvellement créés dans l'Explorateur d'objets, ou en exécutant la commande T-SQL suivante :

      SELECT * FROM sys.dm_hadr_availability_group_states
      GO
      

      

   Le groupe AOAG SQL Server est maintenant configuré et continue la synchronisation entre AWS et Google Cloud. L'étape suivante consiste à configurer un WSFC et un écouteur pour la haute disponibilité et la reprise après sinistre. Pour en savoir plus, consultez Clustering de basculement Windows Server avec SQL Server et Qu'est-ce qu'un écouteur de groupe de disponibilité ?.

   Migrer à l'aide de groupes de disponibilité distribués

   Un groupe de disponibilité distribué est un type particulier de groupe de disponibilité qui s'étend sur deux groupes de disponibilité distincts. Il est conçu pour offrir des fonctionnalités de haute disponibilité et de reprise après sinistre entre des zones géographiques dispersées. Cette architecture permet une réplication des données et un basculement fluides entre les groupes de disponibilité principal et secondaire, ce qui est idéal pour la migration de données. Pour en savoir plus, consultez Groupes de disponibilité distribués.

   Remarque : Les groupes de disponibilité distribués ne sont pas compatibles avec les groupes de disponibilité utilisant des noms de réseau distribués (DNN). Pour en savoir plus, consultez Interopérabilité des fonctionnalités avec un groupe de disponibilité (AG) et un écouteur de DNN

   .

   Les sections suivantes expliquent comment migrer votre base de données SQL Server à l'aide de groupes de disponibilité distribués.

   Avant de commencer

   Assurez-vous de disposer d'un WSFC avec SQL Server utilisant un groupe de disponibilité avec un écouteur de nom de réseau virtuel (VNN), exécuté sur AWS.

   Préparer l'environnement de destination

   Pour préparer l'environnement de destination, procédez comme suit :

   1. Pour configurer un WSFC avec SQL Server à l'aide d'un groupe de disponibilité utilisant un équilibreur de charge interne sur Google Cloud, consultez Configurer des groupes de disponibilité AlwaysOn SQL Server avec commit synchrone à l'aide d'un équilibreur de charge interne.

   2. Dans l'explorateur d'objets, vérifiez que bookshelf-ag a été créé et réplique la base de données bookshelf. Une fois la vérification effectuée, suivez les étapes ci-après pour supprimer le groupe de disponibilité ainsi que la base de données des deux nœuds de votre cluster de basculement.

      

   3. Connectez-vous à node-1 dans SSMS et enregistrez l'adresse IP de l'écouteur bookshelf.

      SELECT * FROM sys.availability_group_listeners
      

   4. Exécutez la commande T-SQL suivante pour supprimer le groupe de disponibilité bookshelf-ag et la base de données bookshelf :

      USE master
      GO
      
      DROP AVAILABILITY GROUP [bookshelf-ag]
      GO
      ALTER DATABASE [bookshelf] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
      GO
      DROP DATABASE [bookshelf]
      GO
      

   5. Exécutez le code T-SQL suivant sur node-2 dans SSMS pour supprimer la base de données répliquée :

      USE master
      GO
      
      DROP DATABASE [bookshelf]
      GO
      

   Créer un groupe de disponibilité distribué

   Pour créer un groupe de disponibilité à utiliser pour le groupe de disponibilité distribué, procédez comme suit :

   1. Exécutez la commande T-SQL suivante sur node-1 :

      USE master
      GO
      
      CREATE AVAILABILITY GROUP [gcp-dest-ag]
      FOR
      REPLICA ON
          N'NODE-1' WITH
          (
              ENDPOINT_URL = N'TCP://NODE-1:5022',
              FAILOVER_MODE = MANUAL,
              AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
              BACKUP_PRIORITY = 50,
              SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
              SEEDING_MODE = AUTOMATIC
          ),
          N'NODE-2' WITH
          (
              ENDPOINT_URL = N'TCP://NODE-2:5022',
              FAILOVER_MODE = MANUAL,
              AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
              BACKUP_PRIORITY = 50,
              SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
              SEEDING_MODE = AUTOMATIC
          );
      GO
      

   2. Créez un écouteur.

      USE master;
      GO
      
      ALTER AVAILABILITY GROUP [gcp-dest-ag]
      ADD LISTENER N'gcp-dest-lsnr' (
      WITH IP (
      (N'LISTENER_IP', N'255.255.255.0')
      ),
      PORT = 1433);
      GO
      

      Remplacez LISTENER_IP par l'adresse IP de l'écouteur.

   3. Connectez-vous à node-2 à l'aide de SSMS et exécutez la commande T-SQL suivante pour l'ajouter au groupe de disponibilité gcp-dest-ag :

      USE master
      GO
      
      ALTER AVAILABILITY GROUP [gcp-dest-ag] JOIN;
      ALTER AVAILABILITY GROUP [gcp-dest-ag] GRANT CREATE ANY DATABASE;
      

   4. Connectez-vous à l'instance répliquée principale du serveur SQL Server source sur AWS à l'aide de SSMS, puis exécutez la commande T-SQL suivante pour créer un groupe de disponibilité distribué :

      USE [master]
      GO
      
      CREATE AVAILABILITY GROUP [distributed-ag]
      WITH (DISTRIBUTED)
      AVAILABILITY GROUP ON
      'AWS_AG' WITH
      (
          LISTENER_URL = 'tcp://AWS_LISTENER:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          SEEDING_MODE = AUTOMATIC
      ),
      'gcp-dest-ag' WITH
      (
          LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          SEEDING_MODE = AUTOMATIC
      )
      GO
      

      Remplacez AWS_AG par le nom du groupe de disponibilité dans AWS et AWS_LISTENER par l'écouteur du groupe de disponibilité AWS.

      Remarque : L'URL d'écouteur spécifiée pour chaque groupe de disponibilité correspond au nom d'hôte de l'écouteur ainsi qu'au port du point de terminaison de mise en miroir de la base de données. Si vous utilisez un port autre que 5022, veillez à modifier la valeur du port avant d'exécuter la commande T-SQL.

   5. Dans SMSS, exécutez la commande T-SQL suivante sur node-1 pour l'ajouter au groupe de disponibilité distribué :

      Conseil : Utilisez un outil tel que Netcat ou Test-NetConnection pour vérifier que les écouteurs source et de destination sont accessibles sur le port du point de terminaison (5022) à partir des instances répliquées principales de la source et de la destination. Des règles de pare-feu supplémentaires peuvent être nécessaires pour autoriser le trafic.

      USE [master]
      GO
      
      ALTER AVAILABILITY GROUP [distributed-ag]
      JOIN
      AVAILABILITY GROUP ON
      'AWS_AG' WITH
      (
          LISTENER_URL = 'tcp://AWS_LISTENER:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          SEEDING_MODE = AUTOMATIC
      ),
      'gcp-dest-ag' WITH
      (
          LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
          FAILOVER_MODE = MANUAL,
          SEEDING_MODE = AUTOMATIC
      )
      GO
      

      Remplacez AWS_AG par le nom du groupe de disponibilité dans AWS et AWS_LISTENER par l'écouteur du groupe de disponibilité AWS.

   6. Exécutez la commande T-SQL suivante sur "node-1" pour vérifier que tous les groupes de disponibilité sont opérationnels et qu'ils assurent la réplication du groupe de disponibilité distribué vers le nouveau cluster SQL Server sur Google Cloud :

      SELECT * FROM sys.dm_hadr_availability_group_states
      GO
      

   Effectuer un nettoyage

   Une fois le tutoriel terminé, vous pouvez procéder au nettoyage des ressources que vous avez créées afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées. Dans les sections suivantes, nous allons voir comment supprimer ou désactiver ces ressources.

   Supprimer le projet

   Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

   Pour supprimer le projet :

   Attention : La suppression d'un projet entraîne l'effet décrit ci-dessous :

   • Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
   • Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

   Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

   1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

   2. In the project list, select the project that you want to delete, and then click Delete.
   3. In the dialog, type the project ID, and then click Shut down to delete the project.