test

Présentation de Sun Cluster pour SE Solaris

Chapitre 2 Notions fondamentales de Sun Cluster

Ce chapitre décrit les notions fondamentales liées aux composants matériels et logiciels du système Sun Cluster que vous devez comprendre avant de travailler avec les systèmes Sun Cluster.

Ce chapitre se compose des sections suivantes

Noeuds de cluster

Un noeud de cluster est une machine sur laquelle s'exécutent à la fois le logiciel Solaris et le logiciel Sun Cluster. Le logiciel Sun Cluster permet d'avoir de deux à huit noeuds dans un cluster.

Les noeuds de cluster sont généralement connectés à un ou plusieurs disques. Ceux qui ne le sont pas utilisent le système de fichiers de cluster pour accéder aux disques multihôtes. Les nœuds de configurations de bases de données parallèles partagent l'accès simultané à certains ou à tous les disques.

Chaque noeud du cluster sait lorsqu'un autre noeud rejoint ou quitte le cluster. De même, il sait quelles ressources fonctionnent localement et quelles ressources fonctionnent sur les autres noeuds du cluster.

Les noeuds d'un même cluster doivent avoir des capacités de traitement, de mémoire et d'E/S similaires afin que les basculements éventuels s'effectuent sans dégradation significative des performances. En raison de la possibilité de basculement, chaque nœud doit avoir des capacités suffisantes pour satisfaire les critères de niveau de service en cas d'échec d'un nœud.

Interconnexion de cluster

L'interconnexion de cluster est la configuration physique de périphériques utilisés pour transférer des communications de clusters privés et des communications de services de données entre les nœuds du cluster.

Les interconnexions redondantes permettent de poursuivre une opération sur les interconnexions subsistantes alors que les administrateurs système isolent les pannes et réparent une communication. Le logiciel Sun Cluster détecte, répare et réinitie automatiquement la communication sur l'interconnexion réparée.

Pour plus d'informations, reportez-vous à la rubrique Interconnexion de cluster .

Appartenance au cluster

Le moniteur d'appartenance au cluster (CMM, Cluster Membership Monitor) est un ensemble distribué d'agents échangeant des messages via l'interconnexion de cluster pour effectuer les tâches suivantes :

La fonction principale du CMM est d'établir l'appartenance au cluster, requérant un accord pour tout le cluster de l'ensemble de noeuds participant au cluster à tout moment. Il détecte les principales modifications d'état du cluster sur chaque noeud, comme une perte de communication entre un ou plusieurs noeuds. Il se base sur le module du noyau de transport pour générer les pulsations sur le média de transport vers d'autres nœuds du cluster. Lorsqu'il ne détecte pas de pulsation de la part d'un noeud dans la période de temporisation définie, le CMM considère que le noeud est défaillant et il initie une reconfiguration du cluster pour renégocier l'appartenance au cluster.

Pour déterminer l'appartenance au cluster et pour assurer l'intégrité des données, le CMM effectue les tâches suivantes :

Pour plus d'informations sur la manière dont le cluster se protège des partitionnements en plusieurs clusters, reportez-vous à la rubrique Intégrité des données .

Référentiel de configuration du cluster

Le référentiel de configuration du cluster (CCR, Cluster Configuration Repository) est une base de données privée, distribuée, à l'échelle du cluster pour le stockage d'informations relatives à la configuration et à l'état du cluster. Pour éviter toute corruption des données de configuration, chaque nœud doit connaître l'état actuel des ressources du cluster. Le CCR veille à ce que tous les noeuds aient une vue cohérente du cluster. Il est mis à jour en cas d'erreur ou de récupération, ou lorsque l'état général du cluster est modifié.

Les structures du CCR contiennent les types d'information suivants :

Détecteurs de pannes

Le système Sun Cluster rend tous les composants du « chemin » entre les utilisateurs et les données hautement disponibles en surveillant les applications elles-mêmes, le système de fichiers et les interfaces réseau.

Le logiciel Sun Cluster détecte rapidement une panne de noeud et crée un serveur équivalent pour les ressources sur le noeud défaillant. Grâce au logiciel Sun Cluster, les ressources non affectées par le noeud défaillant restent disponibles lors de la récupération ; les ressources du noeud défaillant sont, une fois réparées, à nouveau disponibles.

Contrôle des services de données

Chaque service de données Sun Cluster intègre un détecteur de pannes le sondant périodiquement pour vérifier son état. Un détecteur de pannes vérifie que le ou les démons d'application s'exécutent et que les clients sont servis. Sur la base des informations retournées par les sondes, des actions prédéfinies telles que le redémarrage des démons ou le déclenchement d'un basculement peuvent être initiées.

Contrôle de chemin de disque

Le logiciel Sun Cluster prend en charge le contrôle de chemin de disque (CCD). Le CCD améliore la fiabilité générale du basculement et de la commutation en rapportant la panne d'un chemin d'accès aux disques secondaire. Vous pouvez utiliser une des deux méthodes de contrôle de chemin de disque. La première méthode consiste à utiliser la commande scdpm. Cette commande permet de contrôler, de désactiver le contrôle ou d'afficher le statut des chemins d'accès aux disques dans le cluster. Pour plus d'informations sur les options de ligne de commande, reportez-vous à la page man scdpm(1M).

La seconde méthode consiste à utiliser l'interface utilisateur graphique (IUG) de Gestionnaire SunPlex. Gestionnaire SunPlex offre une vue topologique des chemins contrôlés. Cette vue est mise à jour toutes les 10 minutes afin de donner des informations sur le nombre de pings ayant échoué.

Contrôle du multiacheminement sur réseau IP

Chaque noeud du cluster a sa propre configuration de Multiacheminement sur réseau IP, pouvant être différente de celle des autres noeuds. Multiacheminement sur réseau IP contrôle les pannes de communication réseau suivantes :

Périphériques de quorum

Un périphérique de quorum est un disque, partagé par deux nœuds ou plus, participant aux votes utilisés pour calculer le quorum du cluster utilisé. Le cluster ne peut fonctionner que si un quorum de votes a été établi. Le périphérique de quorum est utilisé lorsqu'un cluster est segmenté en plusieurs ensembles de nœuds pour déterminer quel ensemble de nœuds constitue le nouveau cluster.

Les noeuds du cluster et les périphériques de quorum votent tous pour former un quorum. Par défaut les noeuds du cluster acquièrent un nombre de vote de quorum égal à un lorsqu'ils sont initialisés et deviennent membres du cluster. Les nœuds peuvent aussi avoir un nombre de vote égal à zéro, lorsqu'ils sont en cours d'installation ou ont été placés à l'état de maintenance par un administrateur.

Les périphériques de quorum acquièrent des votes de quorum en fonction du nombre de noeuds connectés au périphérique. Lorsque vous configurez un périphérique de quorum, il acquiert un nombre maximum de votes de N-1, où N est le nombre de votes connectés au périphérique de quorum. Par exemple, un périphérique de quorum connecté à deux noeuds avec un nombre de votes différent de zéro possède un nombre de quorums égal à un (deux moins un).

Intégrité des données

Le système Sun Cluster tente d'empêcher toute corruption des données et veille à leur intégrité. Comme les noeuds du cluster partagent des données et des ressources, un cluster ne doit jamais se diviser en partitions distinctes actives en même temps. Le CMM veille à ce qu'il n'y ait toujours qu'un seul cluster opérationnel à tout moment.

Des partitions de cluster peuvent provoquer deux types de problèmes : le split brain et l'amnésie. Le split brain a lieu lorsque l'interconnexion entre les noeuds du cluster est perdue et que le cluster est partitionné en sous-clusters, chaque sous-cluster croyant être la seule partition. Un sous-cluster ignorant l'existence d'autres sous-clusters peut entraîner un conflit au niveau des ressources partagées tel que la duplication des adresses réseau et la corruption de données.

L'amnésie apparaît si tous les nœuds quittent le cluster en groupes successifs. Prenons l'exemple d'un cluster à deux noeuds avec les noeuds A et B. Si le noeud A tombe en panne, les données de configuration du CCR ne sont mises à jour que sur le noeud B, et pas sur le noeud A. Si le noeud B tombe en panne par la suite, et que le noeud A est réinitialisé, ce dernier s'exécutera avec l'ancien contenu du CCR. Cet état est appelé amnésie et peut conduire à exécuter un cluster avec des informations de configuration obsolètes.

Le split brain et l'amnésie peuvent être évités en donnant un vote à chaque nœud et en attribuant une majorité de votes à un autre cluster opérationnel. Une partition dotée d'une majorité de votes possède un quorum et est autorisée à fonctionner. Ce mécanisme de majorité de votes fonctionne bien si le cluster compte plus de deux noeuds. Dans un cluster à deux noeuds, la majorité est deux. Si ce cluster est partitionné, un vote externe permet à une partition d'obtenir le quorum. Ce vote externe est alors fourni par un périphérique de quorum. Un périphérique de quorum peut être n'importe quel disque partagé entre les deux nœuds.

Le Tableau 2–1 décrit la manière dont le logiciel Sun Cluster utilise le quorum pour éviter les problèmes de split brain et d'amnésie.

Tableau 2–1 Quorum du cluster et problèmes de split brain et d'amnésie

Type de partition 

Solution du quorum 

Split brain 

N'autorise que les partitions (sous-cluster) ayant une majorité de votes à s'exécuter comme le cluster (avec une telle majorité, il ne peut exister qu'une seule partition). Lorsqu'un nœud a perdu la course au quorum, il panique.  

Amnésie 

Garantit, lors de l'initialisation, que le cluster possède au moins un nœud faisant partie des derniers membres du cluster (possédant donc les données de configuration les plus à jour).  

Séparation en cas d'échec

Une panne entraînant la partition du cluster (appelée split brain) est un des problèmes majeurs que peut rencontrer un cluster. Lorsque ce phénomène se produit, les nœuds ne peuvent pas tous communiquer, ainsi, des nœuds individuels ou des sous-ensembles de nœuds risquent de tenter de former des clusters individuels ou des sous-ensembles. Chaque partition ou sous-ensemble peut « croire » qu'il est le seul à être propriétaire des disques multihôtes et à en posséder l'accès. Les tentatives d'écriture des différents noeuds sur les disques peuvent entraîner une corruption des données.

La séparation en cas d'échec limite l'accès des nœuds aux disques multihôtes en les empêchant d'accéder aux disques. Lorsqu'un noeud quitte le cluster (parce qu'il a échoué ou a été partitionné), la séparation en cas d'échec assure qu'il ne peut plus accéder aux disques. Seuls les membres actuels des nœuds ont accès aux disques, garantissant ainsi l'intégrité des données.

Le système Sun Cluster utilise le mode de réservation des disques SCSI pour implémenter la séparation en cas d'échec. Grâce au système de réservation SCSI, les nœuds défectueux sont « isolés » à l'extérieur des disques multihôtes, pour les empêcher d'accéder à ces disques.

Lorsqu'un membre détecte qu'un autre nœud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le nœud défaillant d'accéder aux disques partagés. Lors de la séparation en cas d'échec, le nœud séparé panique et un message de « conflit de réservation » s'affiche sur la console.

Mécanisme failfast pour la séparation en cas d'échec

Le mécanisme failfast fait paniquer un nœud défaillant, mais ne l'empêche pas de redémarrer. Après la panique, le noeud peut redémarrer et tenter de rejoindre le cluster.

Si un nœud perd la connectivité aux autres nœuds du cluster et qu'il ne fait pas partie d'une partition pouvant atteindre un quorum, il est supprimé de force du cluster par un autre nœud. Tout nœud faisant partie de la partition pouvant atteindre le quorum effectue des réservations sur les disques partagés. Le noeud n'ayant pas de quorum panique alors en conséquence du mécanisme failfast.

Périphériques

Le système de fichiers global donne à tous les fichiers d'un cluster un même niveau d'accessibilité et de visibilité pour tous les noeuds. De même, le logiciel Sun Cluster rend tous les périphériques d'un cluster accessibles et visibles dans tout le cluster. C'est-à-dire que le sous-système d'E/S rend possible l'accès à tout périphérique du cluster, à partir de n'importe quel nœud, quel que soit le lieu physique de connexion du périphérique. Cet accès est appelé accès périphérique global.

Périphériques globaux

Les systèmes Sun Cluster utilisent des périphériques globaux pour fournir un accès hautement disponible dans tout le cluster à tout périphérique d'un cluster, à partir de n'importe quel noeud. En général, si un nœud est défaillant lorsqu'il permet l'accès à un périphérique global, le logiciel Sun Cluster change le chemin vers ce périphérique et redirige l'accès en utilisant ce nouveau chemin. Cette redirection est facile avec les périphériques globaux car le même nom de périphérique est utilisé, quel que soit le chemin. L'accès aux périphériques distants s'effectue de la même manière que pour des périphériques locaux utilisant le même nom. Ainsi, l'API d'accès à un périphérique global d'un cluster est le même que celui utilisé pour accéder à un périphérique localement.

Les périphériques globaux de Sun Cluster comprennent les disques, les CD et les bandes. Cependant, les disques sont les seuls périphériques globaux à ports multiples pris en charge. Cette prise en charge limitée signifie qu'actuellement, les CD et bandes ne sont pas des périphériques hautement disponibles. Les disques locaux installés sur chaque serveur ne disposent pas non plus d'accès multiples et ne sont donc pas hautement disponibles.

Le cluster assigne automatiquement un ID unique à chaque disque, CD et bande du cluster. Cela permet un accès consistant à chaque périphérique à partir de n'importe quel nœud du cluster.

ID de périphérique

Le logiciel Sun Cluster gère les périphériques globaux à travers une structure appelée pilote d'ID de périphériques (IDP). Ce pilote est utilisé pour assigner automatiquement un ID unique à chaque périphérique du cluster, notamment aux disques multihôtes, aux lecteurs de bandes et aux CD.

Le pilote d'ID de périphériques (IDP) fait partie intégrante de la fonction d'accès aux périphériques globaux du cluster. Il sonde tous les noeuds du cluster et dresse la liste des périphériques de disques uniques. Le pilote d'IDP affecte également un numéro majeur et mineur unique à chaque périphérique cohérent sur tous les nœuds du cluster. L'accès aux périphériques globaux se fait à travers l'IDP unique affecté par le pilote d'IDP au lieu des IDP Solaris traditionnels.

Cela garantit que toute application accédant à des disques, comme Solaris Volume Manager ou Sun Java System Directory Server, utilisera un chemin cohérent dans le cluster. Cette cohérence est particulièrement importante pour les disques multihôtes, car les numéros majeurs et mineurs de chaque périphérique peuvent varier d'un noeud à l'autre. Ces numéros peuvent également modifier les conventions d'attribution de noms de périphériques Solaris.

Périphériques locaux

Le logiciel Sun Cluster gère également les périphériques locaux. Ces périphériques ne sont accessibles que sur un noeud exécutant un service et ayant une connexion physique vers ce cluster. N'ayant pas à répliquer les informations d'état sur plusieurs nœuds en même temps, les périphériques locaux peuvent être plus avantageux en termes de performances par rapport aux périphériques globaux. La défaillance du domaine d'un périphérique supprime l'accès à ce périphérique, à moins qu'il ne soit partagé par plusieurs nœuds.

Groupes de périphériques de disques

Les groupes de périphériques de disques permettent aux groupes de disques gestionnaires de volumes de devenir « globaux » car ils fournissent des prises en charge multihôtes et de multiacheminement aux disques sous-jacents. Chaque nœud du cluster physiquement relié aux disques multihôtes fournit un chemin d'accès au groupe de périphériques de disques.

Dans le système Sun Cluster, vous pouvez contrôler les disques multihôtes qui utilisent le logiciel Sun Cluster en les enregistrant en tant que groupes de périphériques de disques. Cet enregistrement fournit au système Sun Cluster des informations permettant d'identifier quels nœuds possèdent un chemin d'accès à quels groupes de disques gestionnaires de volumes. Le logiciel Sun Cluster crée dans le cluster un groupe de périphériques de disques bruts pour chaque disque et chaque lecteur de bande. Ces groupes de périphériques du cluster restent à l'état hors ligne jusqu'à ce que vous y accédiez en tant que périphériques globaux, soit en montant un système de fichiers global, soit en accédant à un fichier de base de données brut.

Services de données

Un service de données est la combinaison de fichiers logiciels et de configuration permettant à une application de s'exécuter sans modification dans une configuration de Sun Cluster. Lors de l'exécution d'une configuration de Sun Cluster, une application s'exécute comme une ressource contrôlée par le gestionnaire de groupes de ressources (RGM, Resource Group Manager). Un service de données permet de configurer une application telle que Sun Java System Web Server ou la base de données Oracle pour qu'elle s'exécute sur le cluster et non sur un serveur unique.

Le logiciel d'un service de données fournit des implémentations de méthodes de gestion de Sun Cluster effectuant les opérations suivantes sur l'application :

Les fichiers de configuration d'un service de données définissent les propriétés de la ressource représentant l'application au RGM.

Le RGM contrôle la disposition des services de données évolutifs et de basculement du cluster. Il démarre et arrête les services de données sur les noeuds sélectionnés du cluster en réponse aux modifications d'appartenance au cluster. Il permet aux applications de services de données d'utiliser la structure de cluster.

Le RGM contrôle les services de données en tant que ressources. Ces implémentations sont soit fournies par Sun, soit créées par un développeur utilisant un modèle de service de données générique, l'API de bibliothèque de développement de services de données (API DSDL, Data Service Development Library API) ou l'API de gestion de ressources (RMAPI, Resource Management API). L'administrateur du cluster crée et gère les ressources dans des conteneurs appelés groupes de ressources. Les actions du RGM et de l'administrateur peuvent faire passer les ressources et les groupes de ressources de l'état en ligne à l'état hors ligne et inversement.

Types de ressources

Un type de ressource est un ensemble de propriétés décrivant une application à un cluster. Cet ensemble comprend des informations sur la manière dont l'application est démarrée, arrêtée et contrôlée sur les nœuds du cluster. Un type de ressource comprend également des propriétés spécifiques à l'application devant être définies pour pouvoir utiliser l'application dans le cluster. Les services de données de Sun Cluster ont plusieurs types de ressources prédéfinis. Par exemple, Sun Cluster HA pour Oracle est le type de ressource SUNW.oracle-server et Sun Cluster HA pour Apache le type de ressource SUNW.apache.

Ressources

Une ressource est une instance d'un type de ressource défini au niveau du cluster. Le type de ressource permet d'installer plusieurs instances d'une application sur le cluster. Lorsque vous initialisez une ressource, le RGM affecte des valeurs à des propriétés spécifiques à l'application, et la ressource hérite de ces propriétés au niveau du type de ressources.

Les services de données utilisent plusieurs types de ressources. Les applications, telles qu'Apache Web Server ou Sun Java System Web Server utilisent des adresses réseau (noms d'hôtes logiques et adresses partagées) dont dépendent les applications. Les ressources de l'application et du réseau constituent une unité de base que gère le RGM.

Groupes de ressources

Les ressources gérées par le RGM sont placées dans des groupes de ressources de manière à être gérées comme une unité. Un groupe de ressources est un ensemble de ressources connexes ou interdépendantes, Par exemple, une ressource dérivée d'un type de ressource SUNW.LogicalHostname peut être placée dans le même groupe de ressources qu'une ressource dérivée d'un type de ressource de base de données Oracle. Si une commutation ou un basculement est initié sur le groupe de ressources, ce dernier se transforme en unité.

Types de services de données

Les services de données permettent aux applications de devenir hautement disponibles et les services évolutifs aident à éviter une interruption majeure de l'application après une défaillance unique au sein du cluster.

Lorsque vous configurez un service de données, vous devez le configurer comme un des types de services de données suivants :

Services de données de basculement

Le basculement est le processus par lequel le cluster déplace automatiquement une application d'un nœud principal défaillant vers un nœud secondaire redondant. Les applications de basculement ont les caractéristiques suivantes :

Si le détecteur de pannes rencontre une erreur, il essaie soit de redémarrer l'instance sur le même noeud, soit de la démarrer sur un autre noeud (basculement), selon la configuration du service de données. Les services de basculement utilisent un groupe de ressources de basculement contenant des ressources d'instances d'application et des ressources réseau (noms d'hôtes logiques). Les noms d'hôtes logiques sont des adresses IP pouvant être configurées sur un nœud puis automatiquement retirées pour être configurées sur un autre nœud.

Les clients risquent de subir une brève interruption de service et de devoir se reconnecter après un basculement. Toutefois, ils ignorent la modification du serveur physique fournissant le service.

Services de données évolutifs

Les services de données évolutifs permettent aux instances d'application de s'exécuter sur plusieurs noeuds en même temps. Ils utilisent deux groupes de ressources. Le groupe de ressources évolutif contient les ressources d'application et le groupe de ressources de basculement contient les ressources réseau (adresses partagées) dont dépend le service évolutif. Le groupe de ressources évolutif peut être connecté à plusieurs noeuds, permettant ainsi à plusieurs instances du service de fonctionner en même temps. Le groupe de ressources de basculement hébergeant les adresses partagées ne peut être connecté qu'à un seul nœud à la fois. Tous les noeuds hébergeant un service évolutif utilisent la même adresse partagée pour héberger le service.

Le cluster reçoit des requêtes de service à travers une interface réseau unique (interface globale). Ces requêtes sont distribuées aux nœuds, en fonction d'un des algorithmes prédéfinis définis par la règle d'équilibrage de la charge. Le cluster peut utiliser cette règle pour équilibrer la charge de service entre plusieurs nœuds.

Applications parallèles

Les systèmes Sun Cluster fournissent un environnement partageant l'exécution en parallèle d'applications sur tous les nœuds du cluster à l'aide de bases de données parallèles. Prise en charge Sun Cluster des clusters Oracle Parallel Server/Real Application est un ensemble de packages qui, une fois installé, permet aux clusters Oracle Parallel Server/Real Application de s'exécuter sur les noeuds de Sun Cluster. Ce service de données permet également à Prise en charge Sun Cluster des clusters Oracle Parallel Server/Real Application d'être géré à l'aide des commandes de Sun Cluster.

Une application parallèle a été instrumentée pour s'exécuter dans un environnement de cluster de sorte que l'application puisse être gérée par deux noeuds ou plus en même temps. Dans un environnement de clusters Oracle Parallel Server/Real Application , plusieurs instances d'Oracle coopèrent pour fournir l'accès à la même base de données partagée. Les clients d'Oracle peuvent utiliser n'importe quelle instance pour accéder à la base de données. Ainsi, si une instance ou plus sont défaillantes, les clients peuvent se connecter à une instance survivante et continuer à accéder à la base de données.