Le groupe de disponibilité SQL Server Always ON est une solution destinée à atteindre une haute disponibilité et une reprise après sinistre pour les bases de données SQL Server. Nous pouvons configurer cette fonctionnalité entre les installations SQL Server basées sur Windows, les installations SQL Server basées sur Linux, et même entre les installations SQL Server Linux et Windows ensemble.
Les groupes de disponibilité sont étroitement intégrés aux technologies de cluster sous une forme de basculement automatique et de protection des données en répliquant les données sur leurs réplicas secondaires respectifs. Cependant, il n'est pas toujours obligatoire d'avoir un gestionnaire de ressources de cluster pour configurer les groupes de disponibilité.
Pour configurer les groupes de disponibilité SQL Server, nous avons besoin de WSFC – Cluster de basculement Windows Server technologie pour Windows -installations basées sur SQL Server et PACEMAKER pour Linux -installations basées sur SQL Server.
stimulateur cardiaque est un gestionnaire de ressources de cluster open source que nous pouvons utiliser pour gérer les ressources et assurer la disponibilité du système, en cas de défaillance des systèmes Linux.
WSFC est un produit Microsoft développé pour prendre en charge les exigences de cluster Windows.
Lorsque vous examinez les groupes de disponibilité configurés dans SQL Server pour les deux types de système d'exploitation, cela semble similaire dans SQL Server Management Studio.
Cependant, cet article explique les groupes de disponibilité entre le SQL Server basé sur Ubuntu Linux installations utilisant le PACEMAKER technologie de cluster donc je considérerai uniquement cette configuration.
Configuration du type de cluster
Comme je l'ai indiqué ci-dessus, nous avons trois variantes pour configurer les groupes de disponibilité pour SQL Server, selon le système d'exploitation :
- entre les installations SQL Server basées sur Windows ;
- entre les installations SQL Server basées sur Linux ;
- entre le type mixte d'installations SQL Server basées sur Windows et Linux.
Microsoft a introduit le Cluster_type paramètre de configuration pour identifier et configurer une technologie de cluster appropriée pour les groupes de disponibilité. Il s'agit d'un élément de configuration qui définit le type de technologie de cluster que nous utilisons pour les groupes de disponibilité, quel que soit le système d'exploitation sur lequel l'instance SQL Server est basée.
Vous pouvez récupérer et valider la configuration existante du type de cluster à l'aide de vue de gestion dynamique (DMV) SQL Server sys.availability_groups . Il y a deux colonnes nommées cluster_type et cluster_type_desc . Nous pouvons lire ces colonnes pour définir la configuration du type de cluster de la configuration du groupe de disponibilité.
Ce paramètre de configuration a 3 valeurs pour répondre aux exigences de la technologie de cluster pour chaque variante :
WSFC .Vous devez utiliser l'option WSFC (cluster de basculement de serveur Windows) si vous avez des installations SQL Server basées sur Windows. Il n'est pas pris en charge pour les installations SQL Server basées sur Linux.
EXTERNE . Si vous configurez des groupes de disponibilité entre des installations SQL Server basées sur Linux, vous devez utiliser le gestionnaire de cluster PACEMAKER et choisir EXTERNAL cluster taper . Le mode de basculement doit également être EXTERNE (dans WSFC, il sera automatique).
AUCUN . Si vous ne souhaitez utiliser aucune technologie de clustering pour vos groupes de disponibilité, sélectionnez AUCUN . Cette option s'applique si vous souhaitez configurer des groupes de disponibilité entre les instances Linux et Windows de SQL Server. Même si vous avez configuré le clustering pour votre système, une fois que vous avez défini la valeur du type de cluster sur AUCUN, les groupes de disponibilité n'utiliseront pas la technologie de cluster. Le mode de basculement pour le type de cluster NONE est toujours Manuel .
Un nouveau paramètre :les secondaires synchronisés requis pour valider
À partir de SQL Server 2017, Microsoft a introduit un nouveau paramètre appelé required_synchronized_secondaries_to_commit . Il active l'option de basculement automatique si vous avez configuré le type de cluster sur EXTERNE pour la configuration du cluster PACEMAKER.
La valeur de ce paramètre est définie par défaut lorsque vous configurez l'agent de ressources SQL Server mssql-server-ha et créez la configuration du cluster.
Vous pouvez également modifier manuellement la valeur selon vos besoins en exécutant la commande ci-dessous :
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Remarque :nous ne pouvons modifier le paramètre ci-dessus que via Pacemaker sous Linux. Il est impossible de le modifier à l'aide de l'instruction T-SQL pour les déploiements basés sur Linux. Cependant, pour les déploiements basés sur Windows, nous pouvons modifier ce paramètre par une instruction T-SQL.
Vous trouverez ci-dessous les valeurs possibles pour required_synchronized_secondaries_to_commit
0 – Cela signifie que les réplicas secondaires n'ont pas besoin d'être synchronisés avec le réplica principal respectif. Ainsi, il ne prend pas en charge le basculement automatique. Vous devez lancer le basculement manuellement si le réplica principal tombe en panne. Important :il y a un risque de perte de données lorsque vous choisissez cette valeur pour la configuration.
1 – Cela signifie qu'au moins un réplica secondaire doit être dans l'état synchronisé pour réaliser le basculement automatique.
2 – Cela signifie que les deux réplicas secondaires doivent être synchronisés avec le réplica principal. Le basculement automatique est pris en charge.
Réplicas pour participer à un groupe de disponibilité
Le nombre de réplicas pouvant participer à un groupe de disponibilité dépend de l'édition SQL Server installée.
- La norme SQL Server l'édition ne prend en charge que les réplicas à deux nœuds pour un groupe de disponibilité avec le réplica supplémentaire de configuration uniquement.
- Le SQL Server Entreprise prend en charge jusqu'à neuf réplicas :un réplica principal et huit réplicas secondaires.
Étant donné que SQL Server Standard Edition ne prend en charge que deux réplicas (un réplica principal et un réplica secondaire), Microsoft a introduit un nouveau concept appelé réplica de configuration uniquement dans SQL Server 2017 CU1 pour obtenir un basculement automatique pour les serveurs SQL exécutés sur des systèmes Linux.
Il existe deux options de conception possibles :
- Trois répliques synchrones. Cette configuration peut être déployée uniquement avec l'édition SQL Server Enterprise. Il y aura 3 copies de vos bases de données de disponibilité. Cette architecture permet les 3 fonctionnalités d'échelle de lecture, de haute disponibilité et de protection des données.
- Deux réplicas synchrones et un réplica de configuration uniquement. Vous pouvez également configurer cette conception à l'aide de l'édition SQL Server Standard, en exécutant deux réplicas synchrones sur l'édition SQL Server Standard et le réplica 3 sur l'édition SQL Server Express qui agit comme le réplica de configuration uniquement. Il s'agit d'une conception économique qui prend en charge la haute disponibilité avec basculement automatique et protection de la base de données.
Réplication à deux nœuds
Les configurations de répliques à deux nœuds pour les groupes de disponibilité est une option de déploiement très populaire pour garantir la haute disponibilité des bases de données SQL Server. Nous réalisons le basculement automatique à l'aide de la technologie de cluster de basculement Windows Server et d'un témoin de partage de fichiers dans les déploiements SQL Server basés sur Windows.
Le partage de fichiers est généralement utilisé sur un nœud supplémentaire dans WSFC pour fournir une configuration de quorum pour les configurations de réplica à deux nœuds. WSFC synchronise toutes les métadonnées de configuration sur les deux réplicas et sur le troisième nœud ou témoin de partage de fichiers pour un basculement en douceur. Tout arbitrage de basculement pour le groupe de disponibilité SQL Server basé sur Windows se produit au niveau de la couche WSFC.
Si nous voulons réaliser le basculement automatique pour les déploiements de groupes de disponibilité SQL Server basés sur Linux, la configuration ci-dessus ne fonctionnera pas. C'est parce que WSFC ne peut être utilisé que pour les installations SQL Server basées sur Windows.
Pour remédier à cette limitation et activer le basculement automatique pour les déploiements à deux réplicas basés sur Linux, Microsoft a introduit un nouveau concept.
Réplica de configuration uniquement
Un réplica de configuration uniquement est une option dans laquelle nous installons une instance supplémentaire de SQL Server sur le troisième nœud. Ce nœud fonctionnera comme un serveur témoin pour la configuration du réplica à deux nœuds afin de prendre en charge le basculement automatique. Nous pouvons créer un réplica de configuration uniquement par groupe de disponibilité .
Pour les instances SQL Server basées sur Linux où nous utilisons le type de cluster EXTERNAL pour PACEMAKER, l'arbitrage de basculement ne fonctionne pas au niveau du cluster comme WSFC. Tous les arbitrages de basculement se produisent au niveau de la couche SQL Server, car toutes les métadonnées de configuration du groupe de disponibilité sont stockées dans les bases de données principales de chaque réplica.
Microsoft a introduit le concept de réplica de configuration uniquement pour gérer le quorum pour les groupes de disponibilité SQL Server basés sur Linux. Ce concept n'héberge aucune base de données utilisateur pour participer à un groupe de disponibilité. Il stocke toutes les informations de configuration du groupe de disponibilité dans la base de données principale pour garantir le bon déroulement de tous les arbitrages de basculement.
Vous pouvez utiliser n'importe quelle édition de SQL Server pour le réplica de configuration uniquement. Même l'édition SQL Server Express conviendra pour économiser votre coût de licence pour la troisième réplique. N'oubliez pas que le réplica de configuration uniquement n'hébergera aucune base de données dans le groupe de disponibilité. Ainsi, vous n'aurez que deux copies de bases de données dans un groupe de disponibilité.
Par défaut, required_synchronized_secondaries_to_commit est défini sur 0 lorsque nous utilisons le réplica de configuration uniquement. Nous pouvons modifier manuellement cette valeur à 1 si nécessaire.
Examinez le schéma de conception du réplica synchrone à deux nœuds et d'un réplica de configuration uniquement pour obtenir un basculement automatique et une protection des données.
Nous pouvons voir qu'il existe 3 machines virtuelles nommées AOAGVM1, AOAGVM2 et AOAGVM3. Ils sont tous exécutés par le système Ubuntu Linux et SQL Server est configuré sur les trois systèmes Linux. Les bases de données de disponibilité sont hébergées sur AOAGVM1 et AOAGVM2.
AOAGVM1 agit comme un réplica principal, tandis que AOAGVM2 est un réplica secondaire. AOAGVM3 sert de réplica de configuration uniquement, qui est l'édition SQL Server Express. Aucune base de données utilisateur n'est hébergée sur ce troisième réplica.
Le cluster Pacemaker a été configuré entre les trois nœuds pour prendre en charge la technologie de cluster pour la configuration de groupe de disponibilité basée sur Linux.
Pour configurer ou implémenter la conception ci-dessus, nous devons effectuer les étapes suivantes :
- Installez SQL Server sur trois systèmes Ubuntu (l'édition SQL Server Express conviendra pour une réplique configurée uniquement).
- Configurer des groupes de disponibilité entre trois nœuds.
- Configurer le cluster PACEMAKER entre trois nœuds.
- Ajouter ou intégrer un groupe de disponibilité en tant que ressource dans le groupe de clusters.
Consultez l'article associé pour terminer l'étape 1 (installation d'instances SQL Server sur trois nœuds).
Restez à l'écoute de mon prochain article où j'expliquerai le processus étape par étape pour mettre en œuvre la conception ci-dessus. Notre objectif sera d'obtenir un basculement automatique et une protection des données à l'aide du réplica synchrone à 2 nœuds et d'un réplica de configuration uniquement.
Nous serons heureux d'entendre vos réflexions et vos conseils pratiques à ce sujet. N'hésitez pas à les partager dans la section Commentaires.
