Conditions préalables : migrer vers une machine virtuelle SQL Server à l’aide d’un groupe de disponibilité distribué
Utilisez un groupe de disponibilité distribué pour migrer une instance autonome de SQL Server ou un groupe de disponibilité Always On vers SQL Server sur des machines virtuelles Azure.
Cet article décrit les conditions préalables pour préparer vos environnements source et cible afin de migrer votre instance ou groupe de disponibilité SQL Server vers des machines virtuelles SQL Server à l’aide d’un groupe de disponibilité distribué.
La migration d’une base de données (ou de plusieurs) à partir d’une instance autonome à l’aide d’un groupe de disponibilité distribué est une solution simple qui ne nécessite pas de cluster de basculement Windows Server ou d’écouteur de groupe de disponibilité sur la source ou la cible. La migration d’un groupe de disponibilité nécessite un cluster et un écouteur à la fois sur la source et sur la cible.
SQL Server source
Pour migrer votre instance ou votre groupe de disponibilité, votre instance SQL Server source doit répondre aux conditions préalables suivantes :
- Pour une migration d’instance autonome, la version minimale prise en charge est SQL Server 2017. Pour une migration de groupe de disponibilité, SQL Server 2016 ou une version ultérieure est pris en charge.
- Votre édition de SQL Server doit être d’entreprise.
- Vous devez activer la fonctionnalité Always On.
- Les bases de données que vous comptez migrer ont été intégralement sauvegardées.
- Si vous avez déjà un groupe de disponibilité, il doit être dans un état sain. Si vous créez un groupe de disponibilité dans le cadre de ce processus, celui-ci doit être dans un état sain avant de commencer la migration.
- Les ports utilisés par l ’instance SQL Server (1433 par défaut) et le point de terminaison de la base de données en miroir (5022 par défaut) doivent être ouverts dans le pare-feu. Pour migrer des bases de données dans un groupe de disponibilité, assurez-vous que le port utilisé par l’écouteur est également ouvert dans le pare-feu.
Machine virtuelle SQL Server cible
Avant que vos instances SQL Server soient prêtes pour la migration, assurez-vous qu’elles répondent aux conditions préalables suivantes :
- Le compte Azure qui effectue la migration est affecté en tant que propriétaire ou collaborateur au groupe de ressources qui contient les machines virtuelles SQL Server cibles.
- 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.
- Par souci de simplicité, l’instance SQL Server cible doit correspondre à la version de l’instance SQL Server source actuelle. Si vous choisissez d’utiliser une version plus élevée de SQL Server sur la cible pour mettre à niveau votre base de données pendant le processus de migration, vous devrez le faire manuellement plutôt que d’utiliser l’amorçage automatique fourni dans cette série d’articles. Pour plus d’informations, consultez Migrer vers des versions ultérieures de SQL Server.
- L’édition de SQL Server doit être d’entreprise.
- Vous devez activer la fonctionnalité Always On.
- Les ports utilisés par l ’instance SQL Server (1433 par défaut) et le point de terminaison de la base de données en miroir (5022 par défaut) doivent être ouverts dans le pare-feu. Pour migrer des bases de données dans un groupe de disponibilité, assurez-vous que le port utilisé par l’écouteur est également ouvert dans le pare-feu.
Connectivité
Les instances SQL source et cible doivent avoir une connexion réseau établie.
Si l’instance SQL Server source est située sur un réseau local, configurez une connexion VPN de site à site ou une connexion Azure ExpressRoute entre le réseau local et le réseau virtuel où réside votre machine virtuelle SQL Server cible.
Si votre instance SQL Server source se trouve sur un réseau virtuel Azure différent de la machine virtuelle SQL Server cible, configurez le peering de réseau virtuel.
Authentification
Pour simplifier l’authentification entre vos instances SQL Server source et cible, joignez les deux serveurs au même domaine, de préférence du côté source, et appliquez l’authentification basée sur le domaine. Étant donné qu’il s’agit de l’approche recommandée, les étapes de cette série de tutoriels supposent que les instances SQL Server source et cible font partie du même domaine.
Si les serveurs source et cible font partie de domaines différents, configurez la fédération entre les deux domaines ou configurez un groupe de disponibilité indépendant du domaine.