Groupes de disponibilité Always On sur SQL Server sur les machines virtuelles Azure

Article
04/06/2023

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

Cet article présente les groupes de disponibilité Always On pour SQL Server sur les machines virtuelles Azure.

Pour commencer, consultez le didacticiel sur le groupe de disponibilité.

Vue d’ensemble

Les groupes de disponibilité Always On sur les machines virtuelles Azure sont similaires à des groupes de disponibilité Always On locaux et s’appuient sur le cluster de basculement Windows Server sous-jacent. Toutefois, étant donné que les machines virtuelles sont hébergées dans Azure, il existe également quelques points supplémentaires à prendre en considération, comme la redondance des machines virtuelles et le routage du trafic sur le réseau Azure.

Le diagramme suivant illustre un groupe de disponibilité pour SQL Server sur les machines virtuelles Azure :

Availability Group

Notes

Il est désormais possible d’effectuer un lift-and-shift de votre solution de groupe de disponibilité vers SQL Server sur des machines virtuelles Azure à l’aide d’Azure Migrate. Pour plus d’informations, consultez Migrer un groupe de disponibilité.

Redondance des machines virtuelles

Pour accroître la redondance et la haute disponibilité, les machines virtuelles SQL Server doivent se trouver dans le même groupe à haute disponibilité ou dans des zones de disponibilité différentes.

Le fait de placer un ensemble de machines virtuelles dans un même groupe à haute disponibilité protège contre les interruptions dues à la défaillance d’un équipement au sein d’un centre de données (les machines virtuelles au sein d’un groupe à haute disponibilité ne partagent pas les ressources) ou de mises à jour (les machines virtuelles au sein d’un groupe à haute disponibilité ne sont pas mises à jour simultanément).

Les zones de disponibilité protègent contre la défaillance d’un centre de données dans son intégralité, chaque zone représentant un ensemble de centres de données au sein d’une région. En faisant en sorte de placer les ressources dans différentes zones de disponibilité, aucune panne au niveau d’un centre de données ne peut mettre toutes vos machines virtuelles hors connexion.

Pendant la création de machines virtuelles Azure, vous devez choisir entre configurer des groupes à haute disponibilité ou des zones de disponibilité. Une machine virtuelle Azure ne peut pas faire partie des deux.

Si les zones de disponibilité peuvent fournir une meilleure disponibilité que les groupes à haute disponibilité (99,99 % contre 99,95 %), les performances doivent également être prises en considération. Les machines virtuelles d’un groupe à haute disponibilité peuvent être placées dans un groupe de placement de proximité qui garantit qu’elles sont à proximité les unes des autres, réduisant ainsi la latence réseau entre elles. Les machines virtuelles qui sont situées dans différentes zones de disponibilité ont une plus grande latence réseau entre elles, ce qui peut augmenter le temps nécessaire à la synchronisation des données entre le réplica principal et le ou les réplicas secondaires. Cela peut entraîner des retards sur le réplica principal et accroître le risque de perte de données en cas de basculement non planifié. Il est important de tester la solution proposée en situation de charge et de vérifier qu’elle est conforme aux contrats SLA en termes de performances et de disponibilité.

Connectivité

Pour relier l’expérience locale de connexion à votre écouteur de groupe de disponibilité, déployez vos machines virtuelles SQL Server sur plusieurs sous-réseaux au sein du même réseau virtuel. Quand vous avez plusieurs réseaux, vous n’avez pas besoin d’une dépendance supplémentaire sur un équilibreur de charge Azure ou d’un nom de réseau distribué (DNN) pour router votre trafic vers votre écouteur.

Si vous déployez vos machines virtuelles SQL Server dans un même sous-réseau, vous pouvez configurer un nom de réseau virtuel (VNN) et un équilibreur de charge Azure, ou un nom de réseau distribué (DNN) pour router le trafic vers votre écouteur de groupe de disponibilité. Passez en revue les différences entre les deux, puis déployez un nom de réseau distribué (DNN) ou un nom de réseau virtuel (VNN) pour votre groupe de disponibilité.

La plupart des fonctionnalités de SQL Server fonctionnent de façon transparente avec les groupes de disponibilité lors de l’utilisation du DNN, mais certaines fonctionnalités peuvent nécessiter une attention particulière. Pour plus d’informations, consultez Interopérabilité des groupes de disponibilité et de DNN.

Il est également important de noter qu’il y a 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 modifie son routage.
Connexions existantes : les connexions à une base de données spécifique au sein d’un groupe de disponibilité de basculement qui bascule 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é de 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.

La configuration d’un écouteur VNN dans Azure nécessite un équilibreur de charge. Il existe deux options principales pour les équilibreurs de charge dans Azure : externe (public) ou interne. L’équilibreur de charge externe (public) est accessible sur Internet et est associé à une adresse IP virtuelle publique accessible via Internet. Un équilibreur de charge interne prend en charge seulement des clients qui sont au sein du même réseau virtuel. Pour les deux types d’équilibreurs de charge, vous devez activer Retour direct du serveur.

Vous pouvez encore vous connecter à chaque réplica de disponibilité séparément en vous connectant directement à l’instance de service. En outre, puisque les groupes de disponibilité sont à compatibilité descendante avec les clients de mise en miroir de bases de données, vous pouvez vous connecter aux réplicas de disponibilité comme les serveurs partenaires de mise en miroir de bases de données tant que les réplicas sont configurés de façon similaire à la mise en miroir de bases de données :

Il y a un réplica principal et un réplica secondaire.
Le réplica secondaire est configuré comme non lisible (option Secondaire accessible en lecture définie sur Non).

Voici un exemple de chaîne de connexion cliente, qui correspond à cette configuration de type mise en miroir de bases de données, utilisant ADO.NET ou SQL Server Native Client :

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Pour plus d’informations sur la connectivité client, consultez :

Un sous-réseau unique nécessite un équilibreur de charge

Quand vous créez un écouteur de groupe de disponibilité sur un cluster de basculement Windows Server (WSFC) local traditionnel, un enregistrement DNS est créé pour l’écouteur avec l’adresse IP que vous fournissez. Cette adresse IP est mappée à l’adresse MAC du réplica principal actuel dans les tables ARP des commutateurs et routeurs sur le réseau local. Pour ce faire, le cluster utilise l’ARP gratuit (GARP) où il diffuse le dernier mappage d’adresses IP-MAC sur le réseau chaque fois qu’un nouveau réplica principal est sélectionné après le basculement. Dans ce cas, l’adresse IP correspond à l’écouteur et le MAC au réplica principal actuel. Le GARP force une mise à jour des entrées de table ARP pour les commutateurs et les routeurs. Tous les utilisateurs qui se connectent à l’adresse IP de l’écouteur sont acheminés de manière fluide vers le réplica principal actuel.

Pour des raisons de sécurité, la diffusion n’est pas autorisée sur le cloud public (Azure, Google, AWS). L’utilisation des ADP et des GARP sur Azure ne sont donc pas prises en charge. Pour pallier cette différence dans les environnements de mise en réseau, les machines virtuelles SQL Server d’un groupe de disponibilité de sous-réseau unique utilisent des équilibreurs de charge pour acheminer le trafic vers les adresses IP appropriées. Les équilibreurs de charge sont configurés avec une adresse IP front-end qui correspond à l’écouteur et un port de sonde est attribué pour qu’Azure Load Balancer interroge régulièrement l’état des réplicas dans le groupe de disponibilité. Étant donné que seule la machine virtuelle SQL Server de réplica principal répond à la sonde TCP, le trafic entrant est ensuite acheminé vers la machine virtuelle qui répond correctement à la sonde. En outre, le port de sonde correspondant est configuré en tant qu’adresse IP du cluster WSFC, afin de s’assurer que le réplica principal réponde à la sonde TCP.

Les groupes de disponibilité configurés dans un sous-réseau unique doivent utiliser soit un équilibreur de charge, soit un nom de réseau distribué (DNN) pour acheminer le trafic vers le réplica approprié. Pour éviter ces dépendances, configurez votre groupe de disponibilité dans plusieurs sous-réseaux afin que l’écouteur de groupe de disponibilité soit configuré avec une adresse IP pour un réplica dans chaque sous-réseau et qu’il puisse acheminer le trafic de manière appropriée.

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.

Mécanisme de bail

Pour SQL Server, la DLL de ressource du groupe de disponibilité détermine l’état d’intégrité du groupe de disponibilité à l’aide du mécanisme de bail et de la détection de l’état d’intégrité AlwaysOn. La DLL de ressource du groupe de disponibilité expose l’intégrité des ressources via l’opération IsAlive. Le moniteur de ressource interroge IsAlive à l’intervalle de pulsation du cluster, qui est défini par les valeurs CrossSubnetDelay et SameSubnetDelay au niveau du cluster. Sur un nœud principal, le service de cluster lance un basculement chaque fois que l’appel IsAlive à la DLL de ressource indique que le groupe de disponibilité n’est pas sain.

La DLL de ressource du groupe de disponibilité supervise l’état des composants internes de SQL Server. Sp_server_diagnostics signale l’intégrité de ces composants à SQL Server selon un intervalle contrôlé par HealthCheckTimeout.

Contrairement à d’autres mécanismes de basculement, l’instance SQL Server joue un rôle actif dans le mécanisme de bail. Le mécanisme de bail est utilisé comme validation LooksAlive entre l’hôte des ressources du cluster et le processus SQL Server. Le mécanisme est utilisé pour garantir que les deux côtés (le service de cluster et le service SQL Server) sont fréquemment en contact dans le but de vérifier l’état de l’autre et empêcher un scénario de type Split-Brain.

Lors de la configuration d’un groupe de disponibilité dans des machines virtuelles Azure, il est souvent nécessaire de configurer ces seuils différemment par rapport à un environnement local. Pour configurer les paramètres de seuil conformément aux bonnes pratiques pour les machines virtuelles Azure, consultez les bonnes pratiques pour les clusters.

Configuration réseau

Déployez vos machines virtuelles SQL Server sur plusieurs sous-réseaux autant que possible pour éviter la dépendance sur un équilibreur de charge Azure ou un nom de réseau distribué (DNN) afin d’acheminer le trafic vers votre écouteur de groupe de disponibilité.

Sur un cluster de basculement de machine virtuelle Azure, nous recommandons une seule carte réseau par serveur (nœud de cluster). Le réseau Azure a une redondance physique, ce qui rend inutiles les cartes réseau supplémentaires sur un cluster de basculement de machine virtuelle Azure. Même si le rapport de validation du cluster émet un avertissement indiquant que les nœuds sont accessibles sur un seul réseau, vous pouvez l’ignorer en toute sécurité sur les clusters de basculement de machine virtuelle Azure.

Groupe de disponibilité de base

Comme le groupe de disponibilité de base n’autorise pas plus d’un réplica secondaire et qu’il n’y a pas d’accès en lecture sur le réplica secondaire, vous pouvez utiliser les chaînes de connexion de mise en miroir de bases de données pour les groupes de disponibilité de base. En utilisant la chaîne de connexion, vous n’avez plus besoin d’avoir des écouteurs. Ne plus dépendre des écouteurs est utile pour les groupes de disponibilité sur les machines virtuelles Azure, car un équilibreur de charge ou l’ajout d’adresses IP supplémentaires à l’équilibreur de charge ne sont plus nécessaires quand vous avez plusieurs écouteurs pour des bases de données supplémentaires.

Par exemple, pour se connecter explicitement via TCP/IP à la base de données de groupe de disponibilité AdventureWorks sur Réplica_A ou Réplica_B d’un groupe de disponibilité de base (ou de tout groupe de disponibilité qui n’a qu’un seul réplica secondaire et où l’accès en lecture n’est pas autorisé dans le réplica secondaire), une application cliente peut fournir la chaîne de connexion de mise en miroir de bases de données pour se connecter au groupe de disponibilité

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Options de déploiement

Conseil

Pour éviter d’utiliser un Azure Load Balancer ou un nom de réseau distribué (DNN) pour votre groupe de disponibilité Always On, créez vos machines virtuelles SQL Server dans plusieurs sous-réseaux au sein du même réseau virtuel Azure.

Il existe plusieurs options pour déployer un groupe de disponibilité sur SQL Server sur des machines virtuelles Azure, certaines comportant davantage d’automatisation que d’autres.

Le tableau suivant fournit une comparaison des options disponibles :

	Portail Azure,	Azure CLI/PowerShell	Modèles de démarrage rapide	Manuel (un seul sous-réseau)	Manuel (plusieurs sous-réseaux)
Version SQL Server	2016 +	2016 +	2016 +	2012 +	2012 +
Édition de SQL Server	Entreprise	Entreprise	Entreprise	Entreprise, Standard	Entreprise, Standard
Version de Windows Server	2016 +	2016 +	2016 +	Tous	Tous
Crée le cluster à votre place	Oui	Oui	Oui	Non	Non
Crée le groupe de disponibilité et l’écouteur à votre place	Oui	Non	Non	Non	Non
Crée un écouteur et un équilibreur de charge de manière indépendante	N/A	Non	Non	Oui	N/A
Possibilité de créer un écouteur DNN à l’aide de cette méthode ?	N/A	Non	Non	Oui	N/A
Configuration de quorum WSFC	Témoin de cloud	Témoin de cloud	Témoin de cloud	Tous	Tous
Reprise d’activité avec plusieurs régions	Non	Non	Non	Oui	Oui
Prise en charge de plusieurs sous-réseaux	Oui	Non	Non	N/A	Oui
Prise en charge d'un domaine d'application existant	Oui	Oui	Oui	Oui	Oui
Reprise d’activité avec plusieurs zones dans la même région	Oui	Oui	Oui	Oui	Oui
Groupe de disponibilité distribué sans domaine d’application	Non	Non	Non	Oui	Oui
Groupe de disponibilité distribué sans cluster	Non	Non	Non	Oui	Oui
Nécessite un équilibreur de charge ou DNN	Non	Oui	Oui	Oui	Non

Étapes suivantes

Pour commencer, passez en revue les meilleures pratiques relatives à HADR, puis déployez manuellement votre groupe de disponibilité avec le didacticiel sur le groupe de disponibilité.

Pour en savoir plus, consultez :