Partage via

Interopérabilité des fonctionnalités avec un groupe de disponibilité (AG) et un écouteur de DNN

  • Article

S’applique à :SQL Server sur la machine virtuelle 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.

Certaines fonctionnalités de SQL Server reposent sur un nom de réseau virtuel (VNN) codé en dur. Par conséquent, lors de l’utilisation de l’écouteur de DNN avec votre groupe de disponibilité AlwaysOn et SQL Server sur des machines virtuelles Azure dans un sous-réseau unique, il peut y avoir des aspects supplémentaires à prendre en considération.

Cet article décrit les fonctionnalités et l’interopérabilité de SQL Server avec l’écouteur de DNN du groupe de disponibilité.

Différences de comportement

Il existe des différences de comportement entre les fonctionnalités de l’écouteur VNN et de l’écouteur DNN :

  • Temps de basculement : le temps de basculement est plus court lors de l’utilisation d’un écouteur DNN, car il n’est pas nécessaire d’attendre que l’équilibreur de charge réseau détecte l’événement de défaillance et change son routage.
  • Connexions existantes : les connexions à une base de données spécifique au sein d’un groupe de disponibilité à basculement se ferment, mais d’autres connexions au réplica principal restent ouvertes puisque le DNN reste en ligne pendant le processus de basculement. Ce comportement diffère de l’environnement VNN traditionnel, où toutes les connexions au réplica principal se ferment généralement quand le groupe de disponibilité bascule, que l’écouteur est mis hors connexion et que le réplica principal passe au rôle secondaire. Lors de l’utilisation d’un écouteur DNN, il peut être nécessaire d’ajuster les chaînes de connexion d’application pour garantir que les connexions sont redirigées vers le nouveau réplica principal après un basculement.
  • Transactions ouvertes : les transactions ouvertes sur une base de données dans un groupe de disponibilité à basculement se ferment et sont restaurées, et vous devez vous reconnecter manuellement. Par exemple, dans SQL Server Management Studio, fermez la fenêtre de requête et ouvrez-en une nouvelle.

Pilotes clients

Pour les pilotes ODBC, OLEDB, ADO.NET, JDBC, PHP et Node.js, les utilisateurs doivent spécifier explicitement le nom et le port de l’écouteur de DNN en tant que nom de serveur dans la chaîne de connexion. Pour garantir une connectivité rapide lors du basculement, ajoutez MultiSubnetFailover=True à la chaîne de connexion si le client SQL le prend en charge.

Outils

Les utilisateurs de SQL Server Management Studio, sqlcmd, Azure Data Studio et SQL Server Data Tools doivent spécifier explicitement le nom et le port de l’écouteur de DNN en tant que nom de serveur dans la chaîne de connexion pour se connecter à l’écouteur.

La création de l’écouteur de DNN via l’interface graphique utilisateur de SQL Server Management Studio (SSMS) n’est pas prise en charge actuellement.

Groupes de disponibilité et instances FCI

Vous pouvez configurer un groupe de disponibilité AlwaysOn en utilisant une instance de cluster de basculement (failover cluster instance, FCI) en tant qu’un des réplicas. Pour que cette configuration fonctionne avec l’écouteur de DNN, l’instance de cluster de basculement doit également utiliser le DNN, car il n’existe aucun moyen de placer l’adresse IP virtuelle de celle-ci dans la liste d’adresses IP du DNN d’AG.

Dans cette configuration, l’URL du point de terminaison de mise en miroir pour le réplica FCI doit utiliser le DNN de l’instance FCI. De même, si l’instance FCI est utilisée en tant que réplica en lecture seule, le routage en lecture seule vers le réplica FCI doit utiliser le DNN de l’instance FCI.

Le format du point de terminaison de mise en miroir est le suivant : ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Par exemple, si le nom DNS de votre DNN de FCI est dnnlsnr et que 5022 est le port du point de terminaison de mise en miroir de la FCI, l’extrait de code Transact-SQL (T-SQL) pour créer l’URL du point de terminaison ressemble à ceci :

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

De même, le format de l’URL de routage en lecture seule est le suivant : TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Par exemple, si votre nom DNS DNN est dnnlsnret que 1444 est le port utilisé par l’instance FCI cible en lecture seule de SQL Server, l’extrait de code T-SQL pour créer l’URL de routage en lecture seule ressemble à ceci :

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Vous pouvez omettre le port dans l’URL s’il s’agit du port 1433 par défaut. Pour une instance nommée, configurez un port statique pour l’instance nommée et spécifiez-le dans l’URL de routage en lecture seule.

Groupe de disponibilité distribué

Si votre écouteur de groupe de disponibilité est configuré à l’aide d’un nom de réseau distribué (DNN), la configuration d’un groupe de disponibilité distribué au-dessus de votre groupe de disponibilité n’est alors pas prise en charge.

Réplication

Les réplications transactionnelles, de fusion et de capture instantanée prennent toutes en charge le remplacement de l’écouteur de VNN par l’écouteur de DNN et le port dans les objets de réplication qui se connectent à l’écouteur.

Pour plus d’informations sur l’utilisation de la réplication avec des groupes de disponibilité, consultez Éditeur et AG, Abonné et AG, et Distributeur and AG.

MSDTC

Les MSDTC tant local qu’en cluster sont pris en charge, mais le MSDTC utilise un port dynamique qui requiert un service Azure Load Balancer standard pour configurer le port de haute disponibilité (HA). Par conséquent, la machine virtuelle doit utiliser une réservation IP standard, indispensable pour la connecter à Internet.

Définissez deux règles, l’une pour le port 135 du Mappeur de point de terminaison RPC et l’autre pour le port MSDTC réel. Après le basculement, modifiez la règle d’équilibreur de charge sur le nouveau port MSDTC après son changement sur le nouveau nœud.

Si le MSDTC est local, veillez à autoriser les communications sortantes.

Requête distribuée

La requête distribuée s’appuie sur un serveur lié, qui peut être configuré à l’aide de l’écouteur de DNN d’AG et du port. Si le port n’est pas 1433, choisissez l’option Utiliser une autre source de données dans SQL Server Management Studio (SSMS) lors de la configuration de votre serveur lié.

FILESTREAM

La fonctionnalité FILESTREAM est prise en charge, mais pas pour les scénarios où les utilisateurs accèdent au partage de fichiers étendu à l’aide de l’API de fichier Windows.

FileTable

La fonctionnalité FileTable est prise en charge, mais pas pour les scénarios où les utilisateurs accèdent au partage de fichiers étendu à l’aide de l’API de fichier Windows.

Serveurs liés

Configurez le serveur lié à l’aide du nom et du port d’écouteur de DNN d’AG. Si le port n’est pas 1433, choisissez l’option Utiliser une autre source de données dans SQL Server Management Studio (SSMS) lors de la configuration de votre serveur lié.

Forum aux questions

Quelle version de SQL Server prend en charge l’écouteur de DNN d’AG ?

SQL Server 2019 CU 8 et versions ultérieures.

Quelle est le temps de basculement prévu en cas d’utilisation de l’écouteur de DNN ?

Pour l’écouteur de DNN, le temps de basculement est le même que le temps de basculement d’AG, sans aucun temps supplémentaire (comme le temps de sonde lorsque vous utilisez Azure Load Balancer).

Existe-t-il des versions requises pour que les clients SQL prennent en charge le DNN avec OLEDB et ODBC ?

Nous recommandons la prise en charge de la chaîne de connexion MultiSubnetFailover=True pour l’écouteur de DNN. Elle est disponible à partir de SQL Server 2012 (11.x).

Des modifications de configuration de SQL Server sont-elles nécessaires pour pouvoir utiliser l’écouteur de DNN ?

Aucune modification de configuration de SQL Server n’est nécessaire pour utiliser le DNN, mais certaines fonctionnalités de SQL Server peuvent nécessiter davantage d’attention.

Le DNN prend-il en charge les clusters qui ont plusieurs sous-réseaux ?

Oui. Le cluster lie le DNN dans le DNS aux adresses IP physiques de tous les réplicas du groupe de disponibilité, quel que soit le sous-réseau. Le client SQL essaie toutes les adresses IP du nom DNS, quel que soit le sous-réseau.

L’écouteur DNN du groupe de disponibilité prend-il en charge le routage en lecture seule ?

Oui. Le routage en lecture seule est pris en charge par l’écouteur DNN.

Contenu associé