Haute disponibilité et protection des données pour les configurations des groupes de disponibilité

S’applique à : SQL Server - Linux

Cet article présente les configurations de déploiement prises en charge pour les groupes de disponibilité Always On SQL Server sur des serveurs Linux. Un groupe de disponibilité prend en charge la haute disponibilité et la protection des données. La détection automatique des défaillances, le basculement automatique et la reconnexion transparente après le basculement offrent une haute disponibilité. Les réplicas synchronisés assurent la protection des données.

Sur un cluster de basculement Windows Server (WSFC), une configuration courante pour la haute disponibilité utilise deux réplicas synchrones et un troisième serveur ou partage de fichiers pour fournir le quorum. Le témoin de partage de fichiers valide la configuration du groupe de disponibilité, l’état de la synchronisation et le rôle du réplica, par exemple. Cette configuration garantit que le réplica secondaire choisi comme cible de basculement présente les dernières modifications de configuration des groupes de disponibilité et de données.

Le WSFC synchronise les métadonnées de configuration pour l’arbitrage de basculement entre les réplicas du groupe de disponibilité et le témoin de partage de fichiers. Quand un groupe de disponibilité n’est pas sur un WSFC, les instances de SQL Server stockent les métadonnées de configuration dans la base de données master.

Par exemple, un groupe de disponibilité sur un cluster Linux possède CLUSTER_TYPE = EXTERNAL. Il n’existe aucun WSFC pour arbitrer le basculement. Dans ce cas, les métadonnées de configuration sont managées et maintenues par les instances de SQL Server. Étant donné qu’il n’existe aucun serveur témoin dans ce cluster, une troisième instance de SQL Server est requise pour stocker les métadonnées de l’état de configuration. Les trois instances de SQL Server fournissent ensemble un stockage de métadonnées distribué pour le cluster.

Le gestionnaire de clusters peut interroger les instances de SQL Server dans le groupe de disponibilité et orchestrer le basculement pour maintenir une haute disponibilité. Dans un cluster Linux, le Pacemaker est le gestionnaire de clusters.

SQL Server 2017 (14.x) CU1 offre une haute disponibilité pour un groupe de disponibilité avec CLUSTER_TYPE = EXTERNAL pour deux réplicas synchrones et un réplica de configuration uniquement. La réplica de configuration uniquement peut être hébergée sur n'importe quelle édition de SQL Server 2017 (14.x) CU 1 ou des versions ultérieures (y compris l'édition SQL Server Express). Le réplica de configuration uniquement conserve les informations de configuration sur le groupe de disponibilité dans la base de données master, mais ne contient pas les bases de données utilisateur dans le groupe de disponibilité.

Impact de la configuration sur les paramètres de ressource par défaut

SQL Server 2017 (14.x) introduit le paramètre de ressource de cluster REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Ce paramètre garantit que le nombre spécifié de réplicas secondaires écrivent les données de transaction dans le journal avant que le réplica principal ne valide chaque transaction. Lorsque vous utilisez un gestionnaire de cluster externe, ce paramètre affecte la haute disponibilité et la protection des données. La valeur par défaut du paramètre dépend de l’architecture au moment de la création de la ressource de cluster. Quand vous installez l’agent de ressource SQL Server mssql-server-ha et que vous créez une ressource de cluster pour le groupe de disponibilité, le gestionnaire de clusters détecte la configuration du groupe de disponibilité et définit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT en conséquence.

S’il est pris en charge par la configuration, le paramètre de l’agent de ressource REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT est défini sur la valeur qui fournit la haute disponibilité et la protection des données. Pour plus d’informations, consultez Comprendre l’agent de ressource SQL Server pour Pacemaker.

Les sections suivantes expliquent le comportement par défaut de la ressource de cluster.

Choisissez une conception de groupe de disponibilité pour répondre aux exigences spécifiques de l’entreprise en matière de haute disponibilité, de protection des données et de lecture à l’échelle.

Les configurations suivantes décrivent les modèles de conception de groupes de disponibilité et les fonctionnalités de chaque modèle. Ces modèles de conception s’appliquent aux groupes de disponibilité avec CLUSTER_TYPE = EXTERNAL pour les solutions à haute disponibilité.

• Trois réplicas synchrones
• Deux réplicas synchrones
• Deux réplicas synchrones et un réplica de configuration uniquement

Trois réplicas synchrones

Cette configuration se compose de trois réplicas synchrones. Par défaut, il offre une haute disponibilité et une protection des données. Il peut également fournir une mise à l’échelle en lecture.

Un groupe de disponibilité avec trois réplicas synchrones peut fournir une mise à l’échelle en lecture, une haute disponibilité et une protection des données. Le tableau suivant décrit le comportement de disponibilité.

¹ Par défaut

Deux réplicas synchrones

Cette configuration permet la protection des données. À l’instar des autres configurations des groupes de disponibilité, il peut activer l’échelle de lecture. La configuration des deux réplicas synchrones ne fournit pas une haute disponibilité automatique. Une configuration à deux réplicas est uniquement applicable à la version RTM de SQL Server 2017 (14.x) et n’est plus prise en charge avec les versions supérieures (CU1 et ultérieures) de SQL Server 2017 (14.x) .

Un groupe de disponibilité avec deux réplicas synchrones offre une mise à l’échelle en lecture et une protection des données. Le tableau suivant décrit le comportement de disponibilité.

¹ Par défaut

Deux réplicas synchrones et un réplica de configuration uniquement

Un groupe de disponibilité avec deux réplicas synchrones (ou plus) et un réplica de configuration uniquement assurent la protection des données et peuvent également fournir une haute disponibilité. Le diagramme suivant illustre cette architecture :

1. Réplication synchrone des données utilisateur vers le réplica secondaire. Il comprend également des métadonnées de configuration des groupes de disponibilité.
2. Réplication synchrone des métadonnées de configuration des groupes de disponibilité. Il n’inclut pas les données utilisateur.

Dans le diagramme des groupes de disponibilité, un réplica principal envoie (push) des données de configuration au réplica secondaire et au réplica de configuration uniquement. Le réplica secondaire reçoit également les données utilisateur. Le réplica de configuration uniquement ne reçoit pas de données utilisateur. Le réplica secondaire est en mode de disponibilité synchrone. Le réplica de configuration uniquement ne contient pas les bases de données dans le groupe de disponibilité, uniquement les métadonnées relatives au groupe de disponibilité. Les données de configuration sur le réplica de configuration uniquement sont validées de façon synchrone.

La valeur par défaut pour REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT est 0. Le tableau suivant décrit le comportement de disponibilité.

¹ Par défaut

Spécifications

• Tous les réplicas d’un groupe de disponibilité avec un réplica de configuration uniquement doivent être SQL Server 2017 (14.x) CU 1 ou une version ultérieures.
• Toute édition de SQL Server peut héberger un réplica de configuration uniquement, y compris des SQL Server Express.
• Le groupe de disponibilité a besoin d’au moins un réplica secondaire en plus du réplica principal.
• Les réplicas de configuration uniquement ne sont pas comptabilisés dans le nombre maximal de réplicas par instance de SQL Server. L’édition standard SQL Server autorise jusqu’à trois réplicas, SQL Server Entreprise Edition en autorise jusqu’à 9.

Considérations

• Il n’y a pas plus d’un réplica de configuration uniquement par groupe de disponibilité.
• Un réplica de configuration uniquement ne peut pas être un réplica principal.
• Vous ne pouvez pas modifier le mode de disponibilité d’un réplica de configuration uniquement. Pour passer d’un réplica de configuration uniquement à un réplica secondaire synchrone ou asynchrone, supprimez le réplica de configuration uniquement et ajoutez un réplica secondaire avec le mode de disponibilité requis.
• Un réplica de configuration uniquement est synchrone avec les métadonnées du groupe de disponibilité. Il n’y a aucune donnée utilisateur.
• Un groupe de disponibilité avec un réplica principal et un réplica de configuration uniquement, mais aucun réplica secondaire n’est pas valide.
• Vous ne pouvez pas créer un groupe de disponibilité sur une instance de l’édition SQL Server Express.

Comprendre l’agent de ressources SQL Server pour Pacemaker

SQL Server 2017 (14.x) a introduit sequence_number dans sys.availability_groups pour afficher si un réplica marqué comme SYNCHRONOUS_COMMIT était à jour. sequence_number est une valeur de type BIGINT à croissance monotone qui représente l’état de mise à jour du réplica du groupe de disponibilité local par rapport au reste des réplicas du groupe. Les basculements, les ajouts ou les suppressions de réplicas, et les autres opérations sur les groupes de disponibilité, mettent à jour ce numéro. Le numéro est mis à jour sur le réplica principal avant d’être transmis en mode push aux réplicas secondaires. Ainsi, un réplica secondaire à jour dispose des mêmes informations sequence_number .que le réplica primaire.

Quand Pacemaker décide de promouvoir un réplica en principal, il envoie d’abord une notification à tous les réplicas pour extraire le numéro de séquence et le stocker (nous appelons ceci la notification de prépromotion). Ensuite, quand Pacemaker tente effectivement de promouvoir un réplica en principal, le réplica n’assure sa promotion que si son numéro de séquence est supérieur à tous les numéros de séquence de tous les réplicas. Autrement, il rejette l’opération de promotion. De cette façon, seul le réplica ayant le numéro de séquence le plus élevé peut être promu principal, ce qui évite toute perte de données.

Ce résultat n’est garanti que si au moins un réplica candidat à la promotion possède le même numéro de séquence que le principal précédent. Pour ce faire, le comportement par défaut est que l’agent de ressource Pacemaker définit automatiquement REQUIRED_COPIES_TO_COMMIT de sorte qu’au moins un réplica secondaire de validation synchrone est à jour et disponible pour être la cible d’un basculement automatique. Avec chaque action de supervision, la valeur de REQUIRED_COPIES_TO_COMMIT est calculée (et mise à jour si nécessaire) selon la formule (« nombre de réplicas avec validation synchrone » / 2). Ensuite, au moment du basculement, l’agent de ressource nécessitera la réponse de (total number of replicas - required_copies_to_commit réplicas) à la notification de prépromotion pour pouvoir promouvoir un d’entre eux en principal. Le réplica avec le sequence_number le plus élevé sera promu en principal.

Par exemple, prenons le cas d’un groupe de disponibilité avec trois réplicas synchrones : un réplica principal et deux réplicas secondaires avec validation synchrone.

• REQUIRED_COPIES_TO_COMMIT est de 3 / 2 = 1

• Le nombre de réplicas nécessaires pour répondre à l’action de prépromotion est 3-1 = 2. Ainsi, 2 réplicas doivent être actifs pour que le basculement soit déclenché. Cela signifie que, dans le cas d’une indisponibilité du réplica principal, si un des réplicas secondaires ne répond pas et que seul un des réplicas secondaires répond à l’action de prépromotion, l’agent de ressource ne peut pas garantir que le réplica secondaire qui a répondu a le sequence sequence_number, .le plus élevé, et le basculement n’est pas déclenché.

Un utilisateur peut choisir de remplacer le comportement par défaut et de configurer la ressource du groupe de disponibilité pour qu’elle ne définisse pas REQUIRED_COPIES_TO_COMMIT automatiquement comme ci-dessus.

Pour définir REQUIRED_COPIES_TO_COMMIT sur 0, exécutez :

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

La commande équivalente dans crm (sur SLES) est :

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Pour revenir à la valeur calculée par défaut, exécutez :

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Trouver un équilibre entre la haute disponibilité et la protection des données

Ce comportement par défaut s’applique également dans le cas de 2 réplicas synchrones (principal + secondaire). Pacemaker applique REQUIRED_COPIES_TO_COMMIT = 1 par défaut de façon à garantir que le réplica secondaire est toujours à jour pour une protection maximale des données.

sudo pcs resource update <ag1> required_copies_to_commit=0

Une fois cette valeur remplacée, l’agent de ressource utilise la nouvelle valeur pour REQUIRED_COPIES_TO_COMMIT et cesse de la calculer. Cela signifie que les utilisateurs doivent la mettre à jour manuellement en conséquence (par exemple s’ils augmentent le nombre de réplicas).

Le tableau ci-dessous décrit le résultat d’une indisponibilité pour les réplicas principaux ou secondaires dans différentes configurations des ressources d’un groupe de disponibilité :

Groupe de disponibilité : deux  réplicas de synchronisation

¹ Comportement par défaut de l’agent de ressource SQL Server pour Pacemaker.

Groupe de disponibilité : trois réplicas de synchronisation

¹ Comportement par défaut de l’agent de ressource SQL Server pour Pacemaker.

Contenu connexe

• Groupes de disponibilité pour SQL Server sur Linux