Cette page a été traduite par l'API Cloud Translation.

Migrer une base de données SQL Server d'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 sur Amazon Elastic Compute Cloud (AWS EC2) vers Compute Engine.

Cette page aborde les approches suivantes :

Chaque méthode de migration présente des avantages et des inconvénients différents. La stratégie de migration la plus adapté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é : vérifiez si une approche de migration est compatible 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 possibles, car les bases de données plus volumineuses peuvent nécessiter des stratégies différentes de celles des bases de données 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 au minimum, voire d'éliminer les temps d'arrêt, 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 influencer l'approche de la migration. Assurez-vous que la méthode de migration que vous choisissez est compatible avec la migration des objets non liés à la base de données, tels que les jobs de l'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. Différentes méthodes de migration entraînent des coûts variables 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 à l'aide de la sauvegarde et de la restauration complètes
Migrer à l'aide d'un fichier BACPAC
Migrer à l'aide des groupes de disponibilité Always On
Migrer à l'aide de groupes de disponibilité distribués

Coûts

Ce tutoriel utilise des composants facturables de Google Cloud, y compris :

Utilisez le Simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

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

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
Verify that billing is enabled for your Google Cloud project.
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) au déploiement de SQL Server pour 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 :
Standard 2022
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 : avec l'ID de votre projet Google Cloud .

ZONE avec l'ID de la zone.

SUBNET_NAME avec 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 : avec l'ID de votre projet Google Cloud .

ZONE avec l'ID de la zone.

SUBNET_NAME avec 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 sur la page Instances de VM et les identifiants enregistrés à l'étape précédente pour vous connecter à votre VM SQL Server à l'aide du Bureau à distance Microsoft (RDP).
  2. Exécutez SQL Server Management Studio (SSMS) en tant qu'administrateur.
  3. Vérifiez que la case Faire confiance au certificat du serveur est cochée, puis cliquez sur 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 identifiant.

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

La sauvegarde et la 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, puis restaurée dans l'environnement de destination Google Cloud . Bien que cette méthode soit relativement simple, elle peut prendre du temps pour les grandes bases de données 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 à l'aide d'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 Sauvegarder pour ouvrir l'assistant de sauvegarde de la base de données.
  1. Vérifiez que le nom de la base de données à sauvegarder et le type de sauvegarde sont définis sur "Complète".
  2. Cliquez sur Ajouter sous la destination de la sauvegarde complète.
  3. Cliquez sur l'icône représentant des points de suspension (...) pour 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 et attendez qu'elle se termine.
    
    Une fois le processus de sauvegarde terminé, un fichier de sauvegarde est créé. Vous pouvez désormais 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 la 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 Source, cliquez sur Appareil, puis sur l'icône en forme de points de suspension (...) pour ouvrir la page "Sélectionner un appareil de sauvegarde".
5. Vérifiez que le type de support de sauvegarde est défini sur "Fichier", puis cliquez sur Ajouter pour sélectionner le fichier de sauvegarde.
6. Cliquez sur OK pour définir le fichier de sauvegarde comme appareil 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 Exporter l'application de niveau Données pour ouvrir l'assistant d'exportation.
  1. Cliquez sur Suivant.
  2. Cliquez sur Parcourir dans l'option Enregistrer sur le disque local, puis sélectionnez le fichier BACPAC.
  3. Cliquez sur l'onglet Avancé, puis sélectionnez le ou les schémas que vous souhaitez exporter.
  4. Cliquez sur Suivant pour accéder au récapitulatif.
  5. Cliquez sur Terminer pour exporter le fichier BACPAC et attendez que l'exportation se termine.
  6. Cliquez sur 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 niveau Données).
4. Cliquez sur Suivant.
5. Cliquez sur Parcourir, sélectionnez le fichier BACPAC que vous souhaitez restaurer, puis cliquez sur Suivant.
6. Vérifiez le nom de la nouvelle base de données, puis cliquez sur Suivant.
7. Cliquez sur Terminer et attendez que l'importation soit terminée.
8. Cliquez sur 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 des groupes de disponibilité Always On

Un AOAG est une fonctionnalité de haute disponibilité et de reprise après sinistre de SQL Server. Vous pouvez utiliser un groupe de disponibilité AlwaysOn pour migrer des clusters de groupes de disponibilité AlwaysOn existants, des serveurs SQL autonomes et des clusters de basculement Windows Server (WSFC). Avec cette méthode, une réplique de la base de données est créée dans l'environnement de destination Google Cloud 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 principale. Cette méthode minimise les temps d'arrêt, mais nécessite une configuration et une configuration supplémentaires. Pour les migrations simples avec une tolérance aux temps d'arrêt importante, d'autres méthodes peuvent être plus simples et plus économiques.

Avant de commencer

Avant de commencer la migration, assurez-vous des points suivants :
- Pour assurer une transition sécurisée 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 à l'aide d'un groupe de disponibilité AlwaysOn, 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 à faire partie d'un groupe AOAG

Pour pouvoir ajouter des serveurs SQL à un groupe AOAG, 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.
  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 AOAG.
2. Créez un utilisateur pour votre serveur SQL sur votre 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. Procédez comme suit sur toutes les instances SQL Server qui font partie du groupe de disponibilité AlwaysOn :
  1. Accédez à l'outil Gestionnaire de configuration SQL Server.
  2. Dans le volet de navigation, sélectionnez Services SQL Server.
  3. Dans la liste des services, faites un clic droit sur SQL Server (MSSQLSERVER), puis sélectionnez Propriétés.
  4. Sous 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 Oui.
Votre serveur SQL Server s'exécute désormais sous un compte utilisateur de domaine.

Remarque : Assurez-vous d'avoir effectué ces étapes de configuration sur toutes les instances de VM que vous souhaitez ajouter au groupe AOAG. Sinon, 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 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 la 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 à 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 d'accès aux objets

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 "complet" 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 le groupe 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 avec le nom de la base de données à migrer.
  - SOURCE_SERVERNAME avec le nom du serveur de la base de données source.
  - DEST_SERVERNAME avec le nom du serveur de la base de données de destination.
  - SOURCE_HOSTNAME : nom de domaine complet (FQDN) de la source.
  - DEST_HOSTNAME avec le nom de domaine complet de la cible.
  Remarque : Le groupe AOAG utilise le 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 au groupe 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 de se synchroniser 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 couvre deux groupes de disponibilité distincts. Il est conçu pour offrir des fonctionnalités de haute disponibilité et de reprise après sinistre dans des zones géographiques dispersées. Cette architecture permet une réplication et un basculement des données 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 la section Groupes de disponibilité distribués.

Remarque : Les groupes de disponibilité distribués ne sont pas compatibles avec les groupes de disponibilité qui utilisent des noms de réseau distribués (DNN). Pour en savoir plus, consultez Interopérabilité des fonctionnalités avec le groupe de disponibilité et l'écouteur 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é avec 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 qu'il réplique la base de données bookshelf. Une fois la validation effectuée, suivez les étapes suivantes pour supprimer le groupe de disponibilité et 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 du récepteur 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 au réplica principal du serveur SQL 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 de l'é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 la mise en miroir de la base de données. Si vous utilisez un port autre que 5022, veillez à le modifier avant d'exécuter le T-SQL.
5. Exécutez la commande T-SQL suivante dans SSMS 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 répliques 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 en bon état et qu'ils sont répliqués dans le 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 :
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.

Migrer une base de données SQL Server d'AWS EC2 vers Compute Engine Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Objectifs

Coûts

Avant de commencer

Préparer le projet et le réseau

Créer une instance SQL Server sur Compute Engine

Standard 2022

2022 Enterprise

Configurer votre VM SQL Server et vous y connecter

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

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

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

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

Migrer à l'aide d'un fichier BACPAC

Créer une exportation BACPAC

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

Migrer à l'aide des groupes de disponibilité Always On

Avant de commencer

Préparer votre serveur SQL Server à faire partie d'un groupe AOAG

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

Créer le groupe d'accès aux objets

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

Avant de commencer

Préparer l'environnement de destination

Créer un groupe de disponibilité distribué

Effectuer un nettoyage

Supprimer le projet

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