Pacemaker pour les groupes de disponibilité et les instances de cluster de basculement sur Linux

S’applique à : SQL Server - Linux

À partir de SQL Server 2017 (14.x), SQL Server est pris en charge sur Linux et sur Windows. Comme les SQL Serverdéploiements SQL Server basés sur Windows, les bases de données et les instances doivent être hautement disponibles sous Linux. Cet article présente les informations de base pour comprendre Pacemaker avec Corosync, ainsi que la procédure pour planifier et déployer la solution pour les configurations SQL Server.

Notions de base sur le module complémentaire/l’extension HA

Toutes les distributions actuellement prises en charge sont livrées avec le module complémentaire/l’extension de haute disponibilité, sur la base de la pile de clusters de Pacemaker. Cette pile intègre deux composants clés : Pacemaker et Corosync. Tous les composants de la pile sont :

• Pacemaker. Composant de clustering de base qui coordonne des opérations dans les machines en cluster.
• Corosync. Infrastructure et ensemble d’API qui fournissent des éléments comme le quorum, la capacité à redémarrer les processus ayant échoué, etc.
• libQB. Fournit des éléments comme la journalisation.
• Agent de ressources. Fonctionnalité spécifique fournie pour qu’une application puisse être intégrée dans Pacemaker.
• Agent de clôture. Scripts/fonctionnalité qui permettent d’isoler les nœuds et de les traiter en cas de problèmes.

Certains points de cette solution sont similaires au déploiement de configurations en cluster à l’aide de Windows, mais d’autres diffèrent. Dans Windows, la forme de disponibilité du clustering, appelée cluster de basculement Windows Server (WSFC), est intégrée au système d’exploitation, et la fonctionnalité qui permet la création d’un WSFC, clustering de basculement, est désactivée par défaut. Dans Windows, les groupes de disponibilité et les instances de cluster de basculement (FCI) sont basés sur un WSFC et ont en commun une intégration avancée en raison de la DLL de ressource spécifique fournie par SQL Server. Cette solution étroitement couplée est possible dans l’ensemble parce que tout vient d’un seul fournisseur.

Sur Linux, alors que chaque distribution prise en charge dispose d’un Pacemaker, chaque distribution peut être personnalisée et avoir des implémentations et des versions légèrement différentes. Certaines des différences sont reflétées par les instructions données dans cet article. La couche de clustering est open source. Ainsi, bien qu’elle soit fournie avec les distributions, elle n’est pas étroitement intégrée de la même façon qu’un WSFC sous Windows. C’est pourquoi Microsoft fournit mssql-server-ha, de sorte que SQL Server et la pile de Pacemaker peuvent fournir une expérience proche de celle de Windows, mais pas exactement identique, pour les groupes de disponibilité et les instances de cluster de basculement (FCI).

Pour obtenir une documentation complète sur Pacemaker, y compris une explication plus détaillée de tous les éléments avec des informations de référence complètes, pour RHEL et SLES :

• RHEL
• SLES

Ubuntu n’a pas de guide pour la disponibilité.

Pour plus d’informations sur l’ensemble de la pile, consultez également la page de documentation de Pacemaker sur le site ClusterLabs.

Concepts et terminologie de Pacemaker

Cette section documente les concepts et la terminologie courants pour une implémentation de Pacemaker.

Nœud

Un nœud est un serveur participant au cluster. Un cluster Pacemaker prend en charge jusqu’à 16 nœuds en mode natif. Ce nombre peut être dépassé si Corosync n’est pas exécuté sur des nœuds supplémentaires, mais Corosync est requis pour SQL Server. Par conséquent, le nombre maximal de nœuds qu’un cluster peut avoir pour une configuration basée sur SQL Server est de 16 ; il s’agit de la limite de Pacemaker, qui n’a rien à voir avec les limitations maximales imposées par SQL Server pour les groupes de disponibilité ou les instances de cluster de basculement (FCI).

Ressource

Un cluster WSFC et un cluster Pacemaker sont conçus pour une ressource. Une ressource est une fonctionnalité spécifique qui s’exécute dans le contexte du cluster, par exemple un disque ou une adresse IP. Par exemple, sous Pacemaker, des ressources d’instances de cluster de basculement (FCI) et de groupes de disponibilité peuvent être créées. Cela est similaire à un cluster WSFC, où une ressource SQL Server s’affiche pour une instance de cluster de basculement (FCI) ou pour une ressource de groupe de disponibilité lors de la configuration d’un groupe de disponibilité. Toutefois, cette solution n’est pas équivalent en raison de différences sous-jacentes dans la manière dont SQL Server s’intègre dans Pacemaker.

Pacemaker a des ressources standard et de clonage. Les ressources de clonage s’exécutent simultanément sur tous les nœuds. Par exemple, une adresse IP qui s’exécute sur plusieurs nœuds à des fins d’équilibrage de charge. Toute ressource créée pour les instances de cluster de basculement (FCI) utilise une ressource standard, car un seul nœud peut héberger une instance de cluster de basculement (FCI) à un moment donné.

Quand un groupe de disponibilité est créé, il nécessite une forme spécialisée de ressource de clonage appelée ressource à plusieurs états. Alors qu’un groupe de disponibilité n’a qu’un seul réplica principal, le groupe de disponibilité proprement dit s’exécute sur tous les nœuds sur lesquels il est configuré pour fonctionner et il peut potentiellement autoriser des opérations comme l’accès en lecture seule. Étant donné qu’il s’agit d’une utilisation « en direct » du nœud, les ressources sont conçues avec deux états : Promu (précédemment Maître) et Non promu (précédemment Esclave). Pour plus d'informations, consultez Ressources à plusieurs états : ressources qui ont plusieurs modes.

Groupes/ensembles de ressources

À l’instar des rôles dans un WSFC, un cluster Pacemaker a le concept d’un groupe de ressources. Un groupe de ressources (appelé ensemble dans SLES) est une collection de ressources qui fonctionnent ensemble et peuvent basculer d’un nœud à un autre en tant qu’unité unique. Les groupes de ressources ne peuvent pas contenir de ressources qui sont configurées avec l’état Promu ou Non promu. Il n’est donc pas possible de les utiliser pour des groupes de disponibilité. Bien qu’un groupe de ressources puisse être utilisé pour les instances de cluster de basculement (FCI), cette configuration n’est généralement pas recommandée.

Contraintes

Les clusters WSFC ont différents paramètres pour les ressources et d’autres éléments comme les dépendances, qui indiquent au cluster WSFC une relation parent/enfant entre deux ressources différentes. Une dépendance est simplement une règle indiquant à WSFC quelle ressource doit d’abord être en ligne.

Bien qu’un cluster Pacemaker n’intègre pas le concept de dépendances, il existe des contraintes. Il existe trois types de contraintes : colocalisation, emplacement et classement.

• Une contrainte de colocalisation détermine si deux ressources devraient ou non être exécutées sur le même nœud.
• Une contrainte de localisation indique au cluster Pacemaker où une ressource peut (ou ne peut pas) être exécutée.
• Une contrainte de classement indique au cluster Pacemaker l’ordre dans lequel les ressources doivent démarrer.

Quorum, agents de délimitation et STONITH

Le concept de quorum sous Pacemaker est semblable à celui d’un WSFC. L’objectif du mécanisme d’un quorum du cluster est de garantir que le cluster soit en état de fonctionnement. Un WSFC et les modules complémentaires HA pour les distributions Linux ont le concept de vote, où chaque nœud compte dans le quorum. Vous souhaitez une majorité des votes, sinon, dans le pire des cas, le cluster est arrêté.

Contrairement à un WSFC, il n’existe aucune ressource témoin à utiliser avec le quorum. À l’instar d’un WSFC, l’objectif est de conserver un nombre d’électeurs impair. La configuration du quorum envisage de manière différente les groupes de disponibilité et les instances de cluster de basculement (FCI).

Les clusters WSFC surveillent l’état des nœuds participants et les gèrent lorsqu’un problème survient. Les versions ultérieures des clusters WSFC offrent des fonctionnalités comme la mise en quarantaine d’un nœud qui ne fonctionne pas correctement ou qui n’est pas disponible (le nœud n’est pas activé, la communication réseau est interrompue, etc.). Côté Linux, ce type de fonctionnalité est fourni par un agent de délimitation. Le concept est parfois appelé délimitation. Toutefois, ces agents de délimitation sont spécifiques au déploiement. Ils sont souvent fournis par des fournisseurs de matériel et certains éditeurs de logiciels comme ceux qui fournissent des hyperviseurs. Par exemple, VMware fournit un agent de délimitation qui peut être utilisé pour les machines virtuelles Linux virtualisées à l’aide de vSphere.

Le quorum et les délimitations sont liés dans un autre concept appelé STONITH (Shoot the Other Node in the Head). STONITH doit disposer d’un cluster Pacemaker pris en charge sur toutes les distributions Linux. Pour plus d’informations, consultez Délimitation dans un cluster de haute disponibilité Red Hat (RHEL).

corosync.conf

Le fichier corosync.conf contient la configuration du cluster. Il se trouve dans /etc/corosync. Dans le cadre d’opérations quotidiennes normales, il n’est jamais nécessaire de modifier ce fichier si le cluster est configuré correctement.

Emplacement du journal de cluster

Les emplacements de journal pour les clusters Pacemaker diffèrent selon la distribution.

• RHEL et SLES : /var/log/cluster/corosync.log
• Ubuntu : /var/log/corosync/corosync.log

Pour modifier l'emplacement de journalisation par défaut, modifiez corosync.conf.

Planifier des clusters Pacemaker pour SQL Server

Cette section traite des points de planification importants pour un cluster Pacemaker.

Virtualiser des clusters Pacemaker sur Linux pour SQL Server

L’utilisation de machines virtuelles pour déployer SQL Server basé sur Linux pour des groupes de disponibilité et des instances de cluster de basculement (FCI) est régie par les mêmes règles que pour leurs équivalents Windows. Il existe un ensemble de règles de base pour la prise en charge des déploiements SQL Server virtualisés fournis par Microsoft dans Stratégie de support pour les produits Microsoft SQL Server qui s’exécutent dans un environnement de virtualisation matérielle. De plus, différents hyperviseurs tels Microsoft Hyper-V and VMware ESXi peuvent avoir des variances différentes en raison des différences entre les plateformes proprement dites.

Concernant les groupes de disponibilité et les instances de cluster de basculement (FCI) dans le cadre de la virtualisation, vérifiez que l’anti-affinité est définie pour les nœuds d’un cluster Pacemaker donné. Lorsqu’elles sont configurées pour la haute disponibilité dans une configuration de groupe de disponibilité ou d’instances de cluster de basculement (FCI), les machines virtuelles qui hébergent SQL Server ne doivent jamais s’exécuter sur le même hôte d’hyperviseur. Par exemple, si une instance de cluster de basculement (FCI) à deux nœuds est déployée, au moins trois hôtes d’hyperviseur sont nécessaires afin d’en avoir un prêt à fonctionner pour les machines virtuelles hébergeant un nœud en cas de défaillance d’un hôte, en particulier si des fonctionnalités comme la migration dynamique ou vMotion sont utilisées.

Pour la documentation Hyper-V, consultez Utilisation du clustering invité pour la haute disponibilité.

Network (Réseau)

Contrairement à un WSFC, Pacemaker n’a besoin ni de nom dédié ni d’au moins une adresse IP dédiée pour le cluster Pacemaker proprement dit. Les groupes de disponibilité et les instances de cluster de basculement (FCI) nécessitent des adresses (consultez la documentation correspondante pour plus d’informations), mais aucun nom, car il n’existe aucune ressource de nom réseau. SLES autorise la configuration d’une adresse IP à des fins d’administration, mais ce n’est pas obligatoire, comme expliqué dans la section Créer le cluster Pacemaker.

Comme un WSFC, Pacemaker préfèrerait une mise en réseau redondante, donc des cartes réseau distinctes (cartes réseau ou cartes réseau physiques) avec des adresses IP individuelles. En ce qui concerne la configuration du cluster, chaque adresse IP doit avoir ce que l’on appelle son propre anneau. Toutefois, comme avec les clusters WSFC aujourd’hui, de nombreuses implémentations sont virtualisées ou se trouvent dans le cloud public, où une seule carte réseau virtualisée (carte réseau virtuelle) est présentée au serveur. Si toutes les cartes réseau physiques et virtuelles sont connectées au même commutateur physique ou virtuel, il n’y pas de véritable redondance au niveau de la couche réseau. Par conséquent, la configuration de plusieurs cartes réseau est une sorte d’illusion pour la machine virtuelle. La redondance réseau est généralement intégrée à l’hyperviseur pour les déploiements virtualisés et est vraiment intégrée dans le cloud public.

L’une des différences entre plusieurs cartes d’interface réseau et Pacemaker d’un côté et un WSFC de l’autre est que Pacemaker autorise plusieurs adresses IP sur le même sous-réseau, contrairement à un WSFC. Pour plus d’informations sur plusieurs sous-réseaux et clusters Linux, consultez l’article Configurer des groupes de disponibilité Always On à sous-réseaux multiples et des instances de cluster de basculement.

Quorum et STONITH

La configuration et la configuration requise du quorum sont liées aux déploiements spécifiques aux groupes de disponibilité et aux instances de cluster de basculement (FCI) de SQL Server.

STONITH est requis pour un cluster de Pacemaker pris en charge. Utilisez la documentation de la distribution pour configurer STONITH. Un exemple se trouve au niveau de la délimitation basée sur le stockage pour SLES. Il existe également un agent STONITH pour VMware vCenter pour les solutions ESXI. Pour plus d’informations, consultez Agent de plug-in Stonith pour le clôturage SOAP VCenter de machine virtuelle VMware VM (non officiel).

Interopérabilité

Cette section décrit comment un cluster Linux peut interagir avec un WSFC ou avec d’autres distributions de Linux.

WSFC

Actuellement, il n’existe pas de méthode directe pour faire fonctionner un WSFC et un cluster Pacemaker ensemble. Cela signifie qu’il n’est pas possible de créer un groupe de disponibilité ou une instance de cluster de basculement (FCI) qui fonctionne sur un WSFC et sur Pacemaker. Toutefois, il existe deux solutions d’interopérabilité, toutes deux conçues pour les groupes de disponibilité. La seule façon dont une instance de cluster de basculement (FCI) peut faire partie d’une configuration multiplateforme est en tant qu’instance dans l’un de ces deux scénarios :

• Un groupe de disponibilité avec un type de cluster de type Aucun. Pour plus d'informations, consultez la documentation des groupes de disponibilité.
• Un groupe de disponibilité distribué, qui est un type spécial de groupe de disponibilité permettant à deux groupes de disponibilité différents d’être configurés comme leur propre groupe de disponibilité. Pour plus d’informations sur les groupes de disponibilité distribués, consultez la documentation Groupes de disponibilité distribués.

Autres distributions Linux

Sur Linux, tous les nœuds d’un cluster Pacemaker doivent se trouver sur la même distribution. Cela signifie par exemple qu’un nœud RHEL ne peut pas faire partie d’un cluster Pacemaker doté d’un nœud SLES. La raison principale a déjà été indiquée : les distributions peuvent avoir des versions et des fonctionnalités différentes. Des dysfonctionnements sont donc possibles. La combinaison de distributions a le même scénario que la combinaison de clusters WSFC et de Linux : utiliser des groupes de disponibilité de type Aucun ou distribués.

Contenu connexe

• Déployer un cluster Pacemaker pour SQL Server sur Linux
• Configurer un cluster Pacemaker pour des groupes de disponibilité SQL Server