Migrer un groupe de disponibilité SQL Server vers plusieurs sous-réseaux - SQL Server sur des machines virtuelles Azure

  • Article

S’applique à :SQL Server sur la machine virtuelle Azure

Cet article vous explique comment migrer votre groupe de disponibilité Always On d’un même sous-réseau vers plusieurs sous-réseaux pour simplifier la connexion à votre écouteur dans Azure avec votre serveur SQL sur des machines virtuelles Azure.

Conseil

Il existe de nombreuses méthodes pour déployer un groupe de disponibilité. Simplifiez votre déploiement pour éviter d’utiliser un équilibreur de charge Azure ou un nom de réseau distribué (DNN) pour votre groupe de disponibilité Always On, et créez vos machines virtuelles SQL Server dans plusieurs sous-réseaux au sein du même réseau virtuel Azure. Si vous avez déjà créé votre groupe de disponibilité dans un seul sous-réseau, vous pouvez le migrer vers un environnement multi-sous-réseau.

Vue d'ensemble

Les clients qui exécutent SQL Server sur des machines virtuelles Azure peuvent implémenter un groupe de disponibilité Always On dans un même sous-réseau ou plusieurs sous-réseaux. Une configuration multi-sous-réseau simplifie l’environnement du groupe de disponibilité en évitant d’utiliser un équilibreur de charge Azure ou un nom de réseau distribué (DNN) pour router le trafic vers l’écouteur sur le réseau Azure. Bien que l’utilisation d’une approche multi-sous-réseau soit recommandée, elle demande des chaînes de connexion pour qu’une application utilise MultiSubnetFailover = true, ce qui peut ne pas être possible immédiatement en raison des changements au niveau de l’application.

Si vous avez initialement créé un groupe de disponibilité dans un même sous-réseau et que vous utilisez un équilibreur de charge Azure ou un DNN pour l’écouteur, et si vous voulez maintenant réduire la complexité en adoptant une configuration multi-sous-réseau, vous pouvez le faire en quelques étapes.

Avant de commencer la migration d’un environnement existant, évaluez les risques liés au changement d’un environnement en cours d’utilisation.

Vous avez deux façons de migrer votre groupe de disponibilité vers plusieurs sous-réseaux :

  • Créer un environnement pour effectuer des tests côte à côte
  • Déplacer manuellement un groupe de disponibilité existant

Attention

L’exécution d’une migration implique un certain risque, vous devez donc, comme toujours, effectuer des tests approfondis dans un environnement hors production avant de passer à un environnement de production.

Nouvel environnement avec des tests côte à côte

La première méthode pour passer à un groupe de disponibilité multi-sous-réseau consiste à configurer un nouvel environnement. S’il s’agit de l’approche choisie, vous devez :

  1. Créer des machines virtuelles
  2. Créer un groupe de disponibilité dans une configuration multi-sous-réseau
  3. Sauvegarder votre base de données actuelle et la restaurer dans le nouvel environnement

Pour commencer, dans le nouvel environnement multi-sous-réseau, créez l’écouteur avec un nom différent de l’environnement mono-sous-réseau existant. Le nouvel écouteur dans le nouveau groupe de disponibilité permet de tester côte à côte l’application (test avec le multi-sous-réseau et l’équilibreur de charge ou le DNN actuels en place).

Une fois l’environnement multi-sous-réseau validé, vous pouvez basculer sur la nouvelle infrastructure. Selon l’environnement (production, test), utilisez une fenêtre de maintenance pour faire le changement. Pendant la fenêtre de maintenance, restaurez la base de données sur le nouveau réplica principal, supprimez l’écouteur de groupe de disponibilité dans les deux environnements, puis recréez l’écouteur dans l’environnement multi-sous-réseau en utilisant le même nom que l’écouteur précédent, celui utilisé dans la chaîne de connexion de l’application.

La configuration d’un nouvel environnement dans une configuration multi-sous-réseau est désormais plus facile avec l’expérience de déploiement du portail Azure.

Déplacer manuellement un groupe de disponibilité existant

L’autre option consiste à passer manuellement de l’environnement mono-sous-réseau à un environnement multi-sous-réseau. Pour migrer en utilisant cette méthode, vous avez besoin des prérequis suivants :

  • Une adresse IP pour chaque machine dans un nouveau sous-réseau
  • Des chaînes de connexion qui utilisent déjà MultiSubnetFailover = true

Pour migrer votre groupe de disponibilité vers une configuration multi-sous-réseau, suivez ces étapes :

  1. Créez un sous-réseau pour chaque sous-réseau secondaire, car toutes les machines virtuelles se trouvent actuellement dans le même sous-réseau.

  2. Déterminez l’IP du cluster et l’IP de l’écouteur pour tous les serveurs du groupe de disponibilité. Par exemple, si vous avez un groupe de disponibilité avec deux nœuds, vous avez la configuration suivante :

    Nom de la machine virtuelle Subnet IP du cluster Adresse IP de l’écouteur
    VM1 (réplica principal) 10.1.1.0/24 (sous-réseau existant) 10.1.1.15 10.1.1.16
    VM2 (réplica secondaire) 10.1.2.0/24 (nouveau sous-réseau) 10.1.2.15 10.1.2.16

  3. Ajoutez l’IP du cluster et l’IP de l’écouteur au serveur de réplica principal. L’ajout de ces adresses IP est une opération en ligne.

  4. Dans le portail Azure, déplacez le serveur secondaire vers le nouveau sous-réseau en accédant à >Réseau > Interface réseau > Configurations IP sur la machine virtuelle. Le déplacement du serveur vers un nouveau sous-réseau redémarre le serveur de réplica secondaire.

  5. Ajoutez l’IP du cluster et l’IP de l’écouteur au serveur de réplica secondaire. L’ajout de ces adresses IP est une opération en ligne.

  6. À ce stade, comme les adresses IP et les sous-réseaux sont en place, vous pouvez supprimer l’équilibreur de charge.

  7. Supprimez l’écouteur.

  8. Si vous utilisez Windows Server 2019 et versions ultérieures, ignorez cette étape. Si vous utilisez Windows Server 2016, ajoutez manuellement les IP du cluster à l’instance FCI.

  9. Recréez l’écouteur avec les nouvelles IP de l’écouteur.

  10. Videz le DNS sur tous les serveurs en utilisant ipconfig /flushdns.

Étapes suivantes