Utiliser le groupe de disponibilité distribué pour migrer le groupe de disponibilité

Article
07/03/2024

Utilisez un groupe de disponibilité distribué pour migrer les bases de données dans un groupe de disponibilité Always On, tout en conservant la haute disponibilité et la prise en charge de la récupération d’urgence après la migration de vos machines virtuelles SQL Server sur Azure.

Une fois que vous avez confirmé que vos instances de SQL Server source répondent aux conditions préalables, suivez les étapes de cet article pour créer une disponibilité distribuée entre votre groupe de disponibilité existant et votre groupe de disponibilité cible sur vos machines virtuelles SQL Server sur Azure.

Cet article est destiné aux bases de données participant à un groupe de disponibilité et nécessite un cluster de basculement Windows Server (WSFC) et un écouteur de groupe de disponibilité. Il est également possible de migrer des bases de données à partir d’une instance SQL Server autonome.

Configuration initiale

La première étape consiste à créer vos machines virtuelles SQL Server dans Azure. Pour ce faire, vous pouvez utiliser le portail Azure, Azure PowerShell ou un modèle ARM.

N’oubliez pas de configurer vos machines virtuelles SQL Server conformément aux conditions préalables. Choisissez entre un déploiement sur un seul sous-réseau, qui s’appuie sur un Azure Load Balancer ou un nom réseau distribué pour acheminer le trafic vers votre écouteur de groupe de disponibilité, ou un déploiement sur plusieurs sous-réseaux, qui n’a pas cette exigence. Le déploiement sur plusieurs sous-réseaux est recommandé. Pour en savoir plus, consultez connectivité.

Par souci de simplicité, joignez vos machines virtuelles SQL Server cibles au même domaine que vos instances SQL Server sources. Sinon, joignez votre machine virtuelle SQL Server cible à un domaine fédéré avec le domaine de vos instances SQL Server sources.

Pour utiliser l’amorçage automatique pour créer votre groupe de disponibilité distribué (DAG), le nom d’instance pour l’instance principale (source) globale du DAG doit correspondre au nom d’instance du redirecteur (cible) du DAG. En cas de différence de nom d’instance entre l’instance principale globale et le redirecteur, vous devez utiliser l’amorçage manuel pour créer le DAG, et ajouter manuellement tout fichier de base de données supplémentaire à l’avenir.

Cet article utilise les exemples de paramètres suivants :

Nom de la base de données : Adventureworks2022
Noms de la machine source : OnPremNode1 (principal global dans le DAG), OnPremNode2
Noms de l’instance SQL Server source : MSSQLSERVER, MSSQLSERVER
Nom du groupe de disponibilité source : OnPremAg
Nom de l’écouteur de groupe de disponibilité source : OnPremAG_LST
Noms des machines virtuelles SQL Server cibles : SQLVM1 (redirecteur dans le DAG), SQLVM2
Noms d’instance cible de machine virtuelle SQL Server sur Azure : MSSQLSERVER, MSSQLSERVER
Nom du groupe de disponibilité cible : AzureAG
Nom de l’écouteur de groupe de disponibilité source : AzureAG_LST
Nom du point de terminaison : Hadr_endpoint
Nom du groupe de disponibilité distribué : DAG
Nom de domaine : Contoso

Créer des points de terminaison

Utilisez Transact-SQL (T-SQL) pour créer des points de terminaison sur vos deux instances sources (OnPremNode1, OnPremNode2) et vos instances SQL Server cibles (SQLVM1, SQLVM2).

Si vous avez déjà configuré un groupe de disponibilité sur les instances sources, exécutez uniquement ce script sur les deux instances cibles.

Pour créer vos points de terminaison, exécutez ce script de T-SQL sur les serveurs source et cible :

CREATE ENDPOINT [Hadr_endpoint] STATE = STARTED AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATA_MIRRORING(ROLE = ALL,
    AUTHENTICATION = WINDOWS NEGOTIATE,
    ENCRYPTION = REQUIRED ALGORITHM AES);
GO

Les comptes de domaine ont automatiquement accès aux points de terminaison, mais les comptes de service peuvent ne pas faire automatiquement partie du groupe d’administrateur système et ne pas avoir d’autorisation de connexion. Pour accorder manuellement compte de service SQL Server une autorisation de connexion au point de terminaison, exécutez le script de T-SQL suivant sur les deux serveurs :

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [<your account>];

Créer un groupe de disponibilité source

Étant donné qu’un groupe de disponibilité distribué est un groupe de disponibilité spécial qui s’étend sur deux groupes de disponibilité individuels, vous devez tout d’abord créer un groupe de disponibilité sur les deux instances SQL Server sources.

Si vous avez déjà un groupe de disponibilité sur vos instances sources, ignorez cette section.

Utilisez Transact-SQL (T-SQL) pour créer un groupe de disponibilité (OnPremAG) entre vos deux instances sources (OnPremNode1, OnPremNode2) pour la base de données Adventureworks2022 d’exemple.

Pour créer le groupe de disponibilité sur les instances sources, exécutez ce script sur le réplica principal source (OnPremNode1) :

CREATE AVAILABILITY GROUP [OnPremAG]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = PRIMARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE
)
FOR DATABASE [Adventureworks2022] REPLICA
ON N'OnPremNode1' WITH (
    ENDPOINT_URL = N'TCP://OnPremNode1.contoso.com:5022',
    FAILOVER_MODE = AUTOMATIC,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
),
N'OnPremNode2' WITH (
    ENDPOINT_URL = N'TCP://OnPremNode2.contoso.com:5022',
    FAILOVER_MODE = AUTOMATIC,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);

Ensuite, joignez le réplica secondaire (OnPremNode2) au groupe de disponibilité (OnPremAg).

Pour joindre le groupe de disponibilité, exécutez ce script sur le réplica secondaire source :

ALTER AVAILABILITY GROUP [OnPremAG] JOIN;
GO
ALTER AVAILABILITY GROUP [OnPremAG] GRANT CREATE ANY DATABASE;
GO

Enfin, créez l’écouteur pour votre groupe de disponibilité de redirecteur global (OnPremAG).

Pour créer l’écouteur, exécutez ce script sur le réplica principal source :

USE [master]
GO

ALTER AVAILABILITY GROUP [OnPremAG]
ADD LISTENER N'OnPremAG_LST' (
    WITH IP (
        (<available_static_ip>, <mask>),
        PORT = 60173
    )
);
GO

Créer un groupe de disponibilité cible

Vous devez également créer un groupe de disponibilité sur les machines virtuelles SQL Server cibles.

Si vous avez déjà configuré un groupe de disponibilité entre vos instances SQL Server dans Azure, ignorez cette section.

Utilisez Transact-SQL (T-SQL) pour créer un groupe de disponibilité (AzureAG) sur les instances SQL Server cibles (SQLVM1 and SQLVM2).

Pour créer le groupe de disponibilité sur la cible, exécutez ce script sur le réplica principal cible :

CREATE AVAILABILITY GROUP [AzureAG] FOR REPLICA
ON N'SQLVM1' WITH (
    ENDPOINT_URL = N'TCP://SQLVM1.contoso.com:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC
),
N'SQLVM2' WITH (
    ENDPOINT_URL = N'TCP://SQLVM2.contoso.com:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC
);
GO

Ensuite, joignez le réplica secondaire cible (SQLVM2) au groupe de disponibilité (AzureAG).

Exécutez ce script sur le réplica secondaire cible :

ALTER AVAILABILITY GROUP [AzureAG] JOIN;
GO
ALTER AVAILABILITY GROUP [AzureAG] GRANT CREATE ANY DATABASE;
GO

Enfin, créez un écouteur (AzureAG_LST) pour votre groupe de disponibilité cible (AzureAG). Si vous avez déployé vos machines virtuelles SQL Server sur plusieurs sous-réseaux, créez votre écouteur à l’aide de Transact-SQL. Si vous avez déployé vos machines virtuelles SQL Server sur un seul sous-réseau, configurez Azure Load Balancer ou un nom de réseau distribué pour votre écouteur.

Pour créer votre écouteur, exécutez ce script sur le réplica principal du groupe de disponibilité dans Azure.

ALTER AVAILABILITY GROUP [AzureAG]
ADD LISTENER N'AzureAG_LST' (
    WITH IP (
        (N'<primary replica_secondary_ip>', N'<primary_mask>'),
        (N'<secondary replica_secondary_ip>', N'<secondary_mask>')
    ),
    PORT = <port_number_you_set>
);
GO

Créer un groupe de disponibilité distribué

Après avoir configuré vos groupes de disponibilité source (OnPremAG) et cible (AzureAG), créez votre groupe de disponibilité distribué de sorte qu’il s’étende jusqu’aux deux groupes de disponibilité individuels.

Utilisez Transact-SQL sur l’instance principale globale SQL Server source (OnPremNode1) et le groupe de disponibilité (OnPremAG) pour créer le groupe de disponibilité distribué (DAG).

Pour créer le groupe de disponibilité distribué sur la source, exécutez ce script sur le principal global source :

CREATE AVAILABILITY GROUP [DAG]
WITH (DISTRIBUTED) AVAILABILITY GROUP
ON 'OnPremAG' WITH (
    LISTENER_URL = 'tcp://OnPremAG_LST.contoso.com:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC
),
'AzureAG' WITH (
    LISTENER_URL = 'tcp://AzureAG_LST.contoso.com:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC
);
GO

Notes

Le mode d’amorçage est défini sur AUTOMATIC, car la version de SQL Server est identique sur la source et la cible. Si votre SQL Server cible est une version supérieure, ou si votre instance principale globale et le redirecteur ont des noms d’instance différents, créez le groupe de disponibilité distribué, puis joignez le groupe de disponibilité secondaire au groupe de disponibilité distribué avec SEEDING_MODE défini sur MANUAL. Ensuite, restaurez manuellement vos bases de données de l’instance source vers l’instance cible de SQL Server. Consultez Mise à niveau des versions pendant la migration pour en savoir plus.

Une fois votre groupe de disponibilité distribué créé, joignez le groupe de disponibilité cible (AzureAG) sur l’instance du redirecteur cible (SQLVM1) au groupe de disponibilité distribué (DAG).

Pour joindre le groupe de disponibilité cible au groupe de disponibilité distribué, exécutez ce script sur l’écouteur cible :

ALTER AVAILABILITY GROUP [DAG]
INNER JOIN AVAILABILITY GROUP
ON 'OnPremAG' WITH (
        LISTENER_URL = 'tcp://OnPremAG_LST.contoso.com:5022',
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        FAILOVER_MODE = MANUAL,
        SEEDING_MODE = AUTOMATIC
        ),
'AzureAG' WITH (
    LISTENER_URL = 'tcp://AzureAG_LST.contoso.com:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC
);
GO

Si vous devez annuler, mettre en pause ou retarder la synchronisation entre les groupes de disponibilité source et cible (par exemple, en cas de problèmes de performances), exécutez ce script sur l’instance primaire globale source (OnPremNode1) :

ALTER AVAILABILITY GROUP [DAG]
MODIFY AVAILABILITY GROUP ON 'AzureAG'
WITH (SEEDING_MODE = MANUAL);

Pour plus d’informations, consultez Annuler l’amorçage automatique pour le redirecteur.

Terminer la migration à l’aide d’un groupe de disponibilité distribué

Partager via

Utiliser le groupe de disponibilité distribué pour migrer le groupe de disponibilité

Configuration initiale

Créer des points de terminaison

Créer un groupe de disponibilité source

Créer un groupe de disponibilité cible

Créer un groupe de disponibilité distribué

Commentaires

Ressources supplémentaires

Partager via

Utiliser le groupe de disponibilité distribué pour migrer le groupe de disponibilité

Configuration initiale

Créer des points de terminaison

Créer un groupe de disponibilité source

Créer un groupe de disponibilité cible

Créer un groupe de disponibilité distribué

Contenu connexe

Commentaires

Ressources supplémentaires