Un cluster est un groupe d'ordinateurs (nœuds) qui travaillent ensemble pour fournir une solution partagée. À un niveau élevé, un cluster peut être considéré comme ayant trois parties (souvent définies comme une pile de clusters).
Concepts de base
- Ressources : C'est la raison pour laquelle les clusters sont les services qui doivent rester hautement disponibles.
- Agents ressources : Il s'agit de scripts de composants du système d'exploitation qui démarrent, arrêtent et surveillent les ressources, en fonction d'un ensemble de paramètres de ressources.
- Agents de clôture : Ce sont des scripts qui exécutent des actions de clôture de nœud, en fonction d'une cible et d'un périphérique de clôture.
- Escrime : La possibilité de désactiver les nœuds.
- Quorum : Encapsule la capacité de déterminer si le cluster peut continuer à fonctionner en toute sécurité ou non.
Types de clusters
Les quatre types sont les suivants :
- Haute disponibilité (HA) : Utilisé pour la tolérance aux pannes afin de maintenir les services du serveur à la disposition des employés ou des clients.
- Équilibrage de charge : Équilibre la charge entre plusieurs systèmes lorsqu'un service doit être disponible pour plusieurs systèmes à la fois (peut être utilisé pour les trois autres types de clusters).
- Distribué : Les tâches seront gérées par différents systèmes.
- Parallèle (Beowulf) : Les tâches sont gérées par plusieurs processeurs sur plusieurs systèmes.
De même par la configuration il existe plusieurs types de clusters :
- Groupement manuel : Vous permet de classer, fusionner et diviser manuellement les clusters si le résultat des algorithmes de tri automatique des pics n'est pas satisfaisant.
- Fusionner des clusters : Lorsque plusieurs clusters semblent correspondre à la même unité.
- Diviser les clusters : Vous pouvez créer un nouveau cluster en dessinant un polygone autour d'un ensemble de pics dans la vue des caractéristiques, la vue d'amplitude, la vue d'amplitude du modèle ou les vues d'attribut de pic.
REMARQUE : Chez Rackspace, nous utilisons principalement des clusters HA et parfois LB. Chez Rackspace, nous utilisons le terme Red Hat Cluster Suite (RHCS) sur RHEL 6 et Pacemaker Configuration System csd daemon daemonm (PCS) sur RHEL 7 pour assurer la connectivité entre les nœuds du cluster et fournir une plate-forme pour les services en cluster.
La suite de cluster fournit des outils pour créer, configurer et contrôler le cluster.
Raisons d'avoir un cluster
Il existe différentes raisons d'utiliser un cluster. Nous les utilisons pour fournir un backend résilient et hautement disponible pour les solutions. Cela concerne principalement les services backend tels que MySQL, NFS ou Redis, où le service peut se trouver derrière un serveur Web frontal.
La haute disponibilité est fournie via un basculement automatique - en cas de panne sur un nœud de cluster, les services en cluster exécutés sur ce nœud seront automatiquement déplacés vers un nœud qui fonctionne correctement.
Les clusters utilisent généralement un stockage partagé (SAN) afin que les données soient persistantes lorsque les services se déplacent entre les nœuds.
Dans le cas où un nœud ne répond plus, ce nœud sera généralement redémarré (clôturé) par d'autres nœuds afin de préserver l'intégrité des données du stockage partagé et de la propriété IP flottante.
Cluster Linux open source haute disponibilité
Certains fournisseurs de systèmes d'exploitation Linux proposent des logiciels de clustering, tels que SUSE Linux HAE; Red Hat Enterprise Linux (RHEL); et Oracle Real Application Clusters (RAC).
Bien qu'ils vous permettent de créer un cluster de basculement, ils présentent une variété de défis, cela est très manuel et sujet aux erreurs humaines.
Les extensions HA open source Linux nécessitent un degré élevé de compétences techniques, ce qui crée des problèmes de complexité et de fiabilité qui défient la plupart des opérateurs.
SUSE
SUSE Linux Enterprise Server et Red Hat Enterprise Linux offrent à la fois un environnement SAN et sans SAN, mais nécessitent qu'un logiciel de réplication appelé DRBD soit installé et configuré dans le système d'exploitation pour prendre en charge la réplication des données dans l'environnement sans SAN. Malheureusement, cela nécessite des scripts personnalisés lourds, ce qui peut prendre beaucoup de temps pour tester et valider et nécessite un nouveau test lorsque des mises à jour sont apportées à l'environnement. Étant donné que ces sociétés sont avant tout des sociétés de systèmes d'exploitation, leur assistance est axée sur les problèmes au niveau du système d'exploitation et il n'y a souvent que peu ou pas d'expertise en haute disponibilité pour aider un client à résoudre ses problèmes.
Clusters d'applications Oracle Reak (RAC)
Oracle RAC est une solution à haute disponibilité, mais elle est principalement conçue pour le niveau de gestion de la base de données. Cela signifie que vous aurez besoin d'une solution HA différente pour les composants qui effectuent la surveillance, la gestion et la récupération de vos niveaux d'application. Oracle RAC est également très coûteux, vous obligeant à mettre à niveau vers Oracle Enterprise Edition en plus de payer pour l'option RAC, par rapport à d'autres solutions de clustering Linux, telles que SIOS Protection Suite.
Suite de protection SIOS pour le clustering Linux
La suite de protection SIOS pour Linux offre une combinaison étroitement intégrée de clustering de basculement haute disponibilité, de surveillance continue des applications, de réplication des données et de politiques de récupération configurables, protégeant vos applications critiques contre les temps d'arrêt et les sinistres. Alors que SIOS Protection Suite peut fonctionner dans un environnement SAN pour prendre en charge un cluster matériel HA traditionnel, l'architecture adopte une approche sans partage pour le clustering de serveurs, ce qui lui permet de fonctionner sans SAN. Il offre une solution robuste, polyvalente et facilement configurable avec des politiques de basculement/récupération automatiques et manuelles pour une grande variété d'applications.
SIOS Protection Suite pour Linux comprend :
- Gardien de vie SIOS : Fournit un logiciel de clustering de basculement flexible qui surveille l'ensemble de la pile d'applications.
- Gestionnaire de données SIOS : Fournit une réplication de données rapide et efficace basée sur l'hôte et au niveau des blocs pour la mise en miroir du stockage local dans une configuration de cluster sans SAN ou la réplication vers des sites distants ou dans le cloud pour la reprise après sinistre.
- Kits de récupération d'applications multiples (ARK) : Avec des outils de configuration et de validation automatisés intégrés au produit pour protéger vos applications et données stratégiques contre les interruptions et les sinistres.
C'est la profondeur des connaissances de l'équipe de SIOS en matière de récupération d'applications et l'automatisation de la surveillance et de la récupération des applications de la solution qui la rend plus facile à utiliser et un choix meilleur et moins coûteux par rapport aux solutions de clustering Linux proposées par SUSE, Red Hat et Oracle.
En outre, SIOS LifeKeeper prend en charge toutes les principales distributions Linux, y compris Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS et Oracle Linux et s'adapte à une large gamme d'architectures de stockage. Le logiciel SIOS a été adapté et optimisé pour fonctionner sur ces systèmes d'exploitation et les composants sont testés afin de garantir que la solution de cluster sans SAN fonctionnera sur chaque système d'exploitation.
Enfin, avec SIOS Protection Suite pour Linux, vous pouvez exécuter vos applications critiques dans un environnement cloud flexible et évolutif, tel qu'Amazon Web Services (AWS) sans sacrifier les performances, la haute disponibilité ou la protection contre les sinistres.
Cluster Linux dans AWS
Bien que les fournisseurs de cloud, tels qu'AWS, offrent des options de haute disponibilité, ils n'offrent pas le niveau de haute disponibilité et l'étendue de la protection sur l'ensemble de l'infrastructure d'application que les clients exigent et que vous obteniez autrefois en utilisant des clusters avant le cloud computing. C'est pourquoi AWS s'associe à SIOS. SIOS Protection Suite pour Linux atteint ces niveaux souhaités de haute disponibilité pour nos clients communs et les applications critiques qu'ils déplacent vers le cloud AWS.
SIOS Protection Suite pour Linux sur AWS fournit tous les éléments dont vous avez besoin pour créer un cluster Linux haute disponibilité dans un cloud privé virtuel (VPC) au sein d'une seule région AWS sur deux zones de disponibilité. Il prend également en charge une protection prête à l'emploi pour les systèmes SAP, les bases de données Oracle et d'autres applications critiques pour l'entreprise.
SIOS et AWS proposent SIOS Protection Suite Quickstart sur AWS, qui vous aide à créer un cluster haute disponibilité Linux entièrement configuré et opérationnel en quelques étapes courtes. Il configure une architecture AWS pour SIOS Protection Suite pour Linux et la déploie dans votre compte AWS en une demi-heure environ. Ce Quick Start, disponible sur AWS Marketplace, est destiné aux utilisateurs en entreprise qui souhaitent déployer SIOS Protection Suite pour Linux sur AWS dans leur environnement de test ou de production.
Clustering SIOS pour Linux
SIOS est une société de haute disponibilité qui s'est concentrée ces 20 dernières années sur la fourniture d'une haute disponibilité spécialement conçue pour SAP, SQL, Linux, Oracle et d'autres applications. Son expérience est intégrée à son produit, et l'installation et la configuration prennent une fraction du temps et du coût par rapport aux scripts personnalisés avec les distributions Linux. De plus, SIOS teste et valide les nouvelles versions des systèmes d'exploitation et des applications afin que ses clients n'aient pas à le faire. Lorsqu'un client appelle SIOS pour obtenir de l'aide, il est mis en relation avec un expert en haute disponibilité :quelqu'un qui se concentre uniquement sur la haute disponibilité et qui le fait depuis très longtemps.
Sous Linux, le logiciel le plus utilisé est Pacemaker
Présentation du stimulateur cardiaque
L'infrastructure de cluster du module complémentaire High Availability fournit les fonctions de base permettant à un groupe d'ordinateurs (appelés nœuds ou membres) de fonctionner ensemble en tant que cluster. Une fois qu'un cluster est formé à l'aide de l'infrastructure de cluster, vous pouvez utiliser d'autres composants pour répondre à vos besoins de clustering (par exemple, configurer un cluster pour partager des fichiers sur un système de fichiers GFS2 ou configurer le basculement de service). L'infrastructure du cluster remplit les fonctions suivantes :
- Gestion des clusters.
- Gestion des verrous.
- Escrime.
- Gestion de la configuration du cluster.
Architecture du stimulateur cardiaque
Un cluster configuré avec Pacemaker comprend des démons de composants distincts qui surveillent l'appartenance au cluster, des scripts qui gèrent les services et des sous-systèmes de gestion des ressources qui surveillent les ressources disparates. Les composants suivants forment l'architecture Pacemaker :
Base d'informations sur le cluster (CIB)
Le démon d'informations Pacemaker, qui utilise XML en interne pour distribuer et synchroniser les informations de configuration et d'état actuelles du coordinateur désigné (DC), un nœud affecté par Pacemaker pour stocker et distribuer l'état et les actions du cluster au moyen du CIB à tous les autres nœuds du cluster.
Démon de gestion des ressources du cluster (CRMd)
Les actions des ressources du cluster Pacemaker sont acheminées via ce démon. Les ressources gérées par CRMd peuvent être interrogées par les systèmes clients, déplacées, instanciées et modifiées si nécessaire.
Chaque nœud de cluster comprend également un démon de gestionnaire de ressources locales (LRMd) qui agit comme une interface entre CRMd et les ressources. LRMd transmet les commandes de CRMd aux agents, telles que le démarrage et l'arrêt et le relais des informations d'état.
Tirez sur l'autre nœud dans la tête (STONITH)
Souvent déployé en conjonction avec un interrupteur d'alimentation, STONITH agit comme une ressource de cluster dans Pacemaker qui traite les demandes de clôture, éteignant avec force les nœuds et les retirant du cluster pour garantir l'intégrité des données. STONITH est configuré en CIB et peut être surveillé comme une ressource de cluster normale.
corosync est le composant - et un démon du même nom - qui répond aux principaux besoins d'adhésion et de communication des membres pour les clusters à haute disponibilité. Il est nécessaire au bon fonctionnement du module complémentaire High Availability.
En plus de ces fonctions d'adhésion et de messagerie, corosync :
Gère les règles de quorum et la détermination.
Fournit des fonctionnalités de messagerie pour les applications qui coordonnent ou fonctionnent sur plusieurs membres du cluster et doivent donc communiquer des informations avec état ou autres entre les instances.
Outils de configuration et de gestion du stimulateur cardiaque
Pacemaker propose deux outils de configuration pour le déploiement, la surveillance et la gestion du cluster.
PCS peut contrôler tous les aspects de Pacemaker et du démon de rythme cardiaque Corosync. Un programme basé sur la ligne de commande, pcs peut effectuer les tâches de gestion de cluster suivantes :
- Créer et configurer un cluster Pacemaker/Corosync.
- Modifier la configuration du cluster pendant son exécution.
- Configurez à distance Pacemaker et Corosync, ainsi que démarrez, arrêtez et affichez les informations d'état du cluster.
Interface Web pcsd
Une interface utilisateur graphique pour créer et configurer des clusters Pacemaker/Corosync, avec les mêmes fonctionnalités et capacités que l'utilitaire pcs basé sur la ligne de commande.
Afin de maintenir l'intégrité et la disponibilité du cluster, les systèmes de cluster utilisent un concept connu sous le nom de quorum pour empêcher la corruption et la perte de données. Un cluster a le quorum lorsque plus de la moitié des nœuds du cluster sont en ligne. Pour atténuer le risque de corruption des données en raison d'une défaillance, Pacemaker arrête par défaut toutes les ressources si le cluster n'a pas de quorum.
Dans un système de cluster, de nombreux nœuds peuvent travailler sur plusieurs données de production vitales. Les nœuds d'un cluster occupé à plusieurs nœuds pourraient commencer à agir de manière erratique ou devenir indisponibles, incitant les administrateurs à agir. Les problèmes causés par les nœuds de cluster errants peuvent être atténués en établissant une politique de clôture.
Lorsque Pacemaker détermine qu'un nœud est en panne, il communique aux autres composants de l'infrastructure du cluster que le nœud est en panne. STONITH clôture le nœud défaillant lorsqu'il est informé de la panne. D'autres composants d'infrastructure de cluster déterminent les actions à entreprendre, ce qui inclut l'exécution de toute récupération nécessaire. Par exemple, DLM et GFS2, lorsqu'ils sont informés d'une panne de nœud, suspendent l'activité jusqu'à ce qu'ils détectent que STONITH a terminé la clôture du nœud défaillant. Après confirmation que le nœud défaillant est clôturé, DLM et GFS2 effectuent la récupération. DLM libère les verrous du nœud défaillant ; GFS2 récupère le journal du nœud défaillant.
La clôture au niveau du nœud via STONITH peut être configurée avec une variété de dispositifs de clôture pris en charge, notamment :
- Alimentation sans interruption (UPS) : Un appareil contenant une batterie qui peut être utilisée pour clôturer les appareils en cas de panne de courant.
- Unité de distribution électrique (PDU) : Appareil doté de plusieurs prises de courant utilisé dans les centres de données pour une distribution électrique propre, ainsi que des services de clôture et d'isolation électrique.
- Dispositifs de contrôle de l'alimentation des lames : Des systèmes dédiés installés dans un centre de données configuré pour clôturer les nœuds du cluster en cas de panne.
- Appareils éteints : Appareils connectés au réseau qui gèrent la disponibilité des nœuds de cluster et peuvent effectuer le fencing, la mise sous/hors tension et d'autres services par les administrateurs localement ou à distance.
Classes de ressources du module complémentaire haute disponibilité Red Hat
Plusieurs classes d'agents de ressources sont prises en charge par le module complémentaire Red Hat High Availability :
- LSB : L'agent Linux Standards Base résume les services conformes pris en charge par le LSB, à savoir les services dans /etc/init.d et les codes de retour associés pour les états de service réussis et échoués (état démarré, arrêté, en cours d'exécution).
- OCF : L'Open Cluster Framework est un sur-ensemble de la LSB (Linux Standards Base) qui définit des normes pour la création et l'exécution de scripts d'initialisation de serveur, les paramètres d'entrée pour les scripts à l'aide de variables d'environnement, etc.
- systemd : Le plus récent gestionnaire de services système pour les systèmes basés sur Linux, systemd utilise des ensembles de fichiers d'unité plutôt que des scripts d'initialisation comme le font LSB et OCF. Ces unités peuvent être créées manuellement par les administrateurs ou peuvent même être créées et gérées par les services eux-mêmes. Pacemaker gère ces unités de la même manière qu'il gère les scripts d'initialisation OCF ou LSB.
- Parfait : Tout comme systemd, Upstart est un gestionnaire d'initialisation système alternatif pour Linux. Upstart utilise des travaux, par opposition aux unités dans les scripts systemd ou init.
- STONITH : Un agent de ressources exclusivement pour les services de clôture et les agents de clôture utilisant STONITH.
- Nagios : Agents qui extraient les plug-ins pour l'outil de surveillance du système et de l'infrastructure Nagios.
Ressources de surveillance
Pour vous assurer que les ressources restent saines, vous pouvez ajouter une opération de surveillance à la définition d'une ressource. Si vous ne spécifiez pas d'opération de surveillance pour une ressource, par défaut, la commande pcs créera une opération de surveillance, avec un intervalle déterminé par l'agent de ressource.
Contraintes de ressources
Vous pouvez déterminer le comportement d'une ressource dans un cluster en configurant des contraintes. Vous pouvez configurer les catégories de contraintes suivantes :
- Contraintes d'emplacement : Une contrainte d'emplacement détermine sur quels nœuds une ressource peut s'exécuter.
- Contraintes de commande : Une contrainte d'ordre détermine l'ordre dans lequel les ressources s'exécutent.
- contraintes d'emplacement : Une contrainte de colocation détermine où les ressources seront placées par rapport aux autres ressources.
En tant que raccourci pour configurer un ensemble de contraintes qui localiseront un ensemble de ressources ensemble et garantiront que les ressources démarrent séquentiellement et s'arrêtent dans l'ordre inverse, Pacemaker prend en charge le concept de groupes de ressources.
Groupes de ressources
L'un des éléments les plus courants d'un cluster est un ensemble de ressources qui doivent être regroupées, démarrer séquentiellement et s'arrêter dans l'ordre inverse. Pour simplifier cette configuration, Pacemaker prend en charge le concept de groupes.
Vous créez un groupe de ressources avec la commande pcs resource, en spécifiant les ressources à inclure dans le groupe. Si le groupe n'existe pas, cette commande crée le groupe. Si le groupe existe, cette commande ajoute des ressources supplémentaires au groupe. Les ressources démarreront dans l'ordre que vous les spécifiez avec cette commande et s'arrêteront dans l'ordre inverse de leur ordre de démarrage.
Références
- Composants de cluster - Clusterlabs
- Syndrome du cerveau divisé - Techtarget
- Cluster Linux – SIOS
- Clustering – Physique
- Cluster Linux – Linux.org
- Introduction aux clusters – Linux Blimp
- Présentation du stimulateur cardiaque - Red Hat
Utilisez l'onglet Commentaires pour faire des commentaires ou poser des questions. Vous pouvez également démarrer une conversation avec nous.