Guide des notions fondamentales de Sun Cluster pour SE Solaris

Chapitre 2 Principales notions fondamentales destinées aux fournisseurs de services matériels

Ce chapitre décrit les notions fondamentales liées aux composants matériel d'une configuration système Sun Cluster. Les sujets traités sont les suivants :

Matériel système et composants logiciels Sun Cluster

Ces informations s'adressent en priorité aux fournisseurs de services matériel. Ces notions peuvent aider les fournisseurs de services à mieux comprendre les relations entre les divers composants matériels avant d'installer, de configurer ou d'entretenir le matériel de cluster. Elles peuvent aussi s'avérer utiles pour les administrateurs système qui y trouveront des informations de référence pour l'installation, la configuration et l'administration du logiciel de cluster.

Un cluster comprend plusieurs composants matériels, notamment :

des noeuds de cluster avec des disques locaux (non partagés) ;
un stockage multihôte (disques partagés entre les noeuds) ;
des médias amovibles (bandes et CD-ROM) ;
interconnexion de cluster ;
des interfaces de réseau public ;
des systèmes client ;
une console administrative ;
des dispositifs d'accès à la console.

Le système Sun Cluster vous permet de combiner ces composants et d'obtenir de nombreuses configurations. Les sections suivantes décrivent ces configurations :

Pour obtenir un exemple de configuration d'un cluster à deux nœuds, voir Environnement matériel de Sun Cluster du Présentation de Sun Cluster pour SE Solaris.

Noeuds de cluster

Un nœud de cluster est une machine exécutant à la fois le système d'exploitation Solaris et le logiciel Sun Cluster. Un nœud de cluster est également un membre actuel du cluster (un membre de cluster) ou un membre potentiel.

le logiciel SPARC : Sun Cluster prend en charge un à seize nœuds par cluster. Pour plus d'informations sur les configurations de nœuds prises en charge, voir SPARC : Topologies Sun Cluster pour SPARC .
le logiciel x86: Sun Cluster prend en charge deux nœuds par cluster. Pour plus d'informations sur les configurations de nœuds prises en charge, voir x86 : Topologies Sun Cluster pour x86 .

Les nœuds de cluster sont généralement connectés à un ou plusieurs périphériques multihôtes. Ceux qui ne le sont pas utilisent le système de fichiers de cluster pour accéder aux périphériques multihôtes. Par exemple, dans une configuration de services évolutifs, les nœuds peuvent traiter les requêtes sans être directement connectés aux périphériques multihôtes.

De plus, les nœuds des configurations de bases de données parallèles partagent un accès simultané à tous les disques.

Pour plus d'informations sur l'accès simultané aux disques, voir Périphériques multihôtes .
Pour plus d'informations sur les configurations de bases de données parallèles, voir SPARC : Topologie de paire clusterisée pour SPARC et x86 : Topologie de paire clusterisée pour x86 .

Tous les nœuds du cluster sont regroupés sous un nom commun, « le nom du cluster », utilisé pour accéder au cluster et le gérer.

Les adaptateurs de réseau public relient les nœuds aux réseaux publics, permettant ainsi au client d'accéder au cluster.

Les membres du cluster communiquent avec les autres nœuds du cluster par le biais d'un ou de plusieurs réseaux physiquement indépendants. Cet ensemble de réseaux physiquement indépendants est désigné sous le nom d'interconnexion de cluster.

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 nœuds 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 basculements, tous les nœuds doivent disposer d'une capacité excédentaire leur permettant de gérer la charge de travail de tous les nœuds dont ils constituent le noeud secondaire ou de sauvegarde.

Chaque noeud initialise son propre système de fichiers racine (/).

Composants logiciels des membres matériels du cluster

Pour fonctionner comme un membre du cluster, un noeud doit être équipé des logiciels suivants :

Système d'exploitation Solaris
Logiciel Sun Cluster
application de service de données ;
Gestion des volumes (Solaris Volume Manager^TM ou VERITAS Volume Manager)

Une configuration utilisant un RAID (réseau redondant de disques indépendants) matériel constitue une exception. Cette configuration ne nécessite pas de gestionnaire de volume logiciel comme Solaris Volume Manager ou VERITAS Volume Manager.

Pour plus d'informations sur l'installation du système d'exploitation Solaris, de Sun Cluster et du logiciel de gestion de volume, voir Guide d’installation du logiciel Sun Cluster pour SE Solaris.
Pour plus d'informations sur l'installation et la configuration des services de données, voir Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Pour plus d'informations conceptuelles sur les composants logiciels précédents, voir Chapitre 3, Notions-clés destinées aux administrateurs système et aux développeurs d'applications .

La figure ci-après affiche une vue générale des composants logiciels qui fonctionnent ensemble pour créer l'environnement logiciel Sun Cluster.

Figure 2–1 Relations générales des composants logiciels Sun Cluster

Illustration : le contexte précédent décrit le graphique.

Pour consulter les questions et les réponses sur les membres de cluster, voir Chapitre 4, Questions fréquemment posées .

Périphériques multihôtes

Les disques pouvant être connectés à plus d'un nœud à la fois sont appelés périphériques multihôtes. Dans l'environnement Sun Cluster, le stockage multihôte rend les disques hautement disponibles. Le logiciel Sun Cluster requiert le stockage multihôte pour les clusters à deux nœuds, afin d'établir un quorum. Les clusters supérieurs à deux nœuds ne nécessitent pas de périphériques de quorum. Pour plus d'informations sur le quorum, voir Quorum et périphériques de quorum .

Les périphériques multihôtes possèdent les caractéristiques suivantes :

la tolérance aux pannes de nœuds uniques.
la capacité à stocker des données d'application, des binaires d'applications et des fichiers de configuration.
la protection contre les pannes de nœuds. Si les requêtes client accèdent aux données via un nœud défaillant, elles sont basculées vers un autre nœud ayant une connexion directe aux mêmes disques.
accès soit global par un nœud principal « gérant » les disques, soit simultané direct via les chemins locaux. Actuellement, Oracle Real Application Clusters Guard est la seule application à utiliser l'accès simultané direct.

Un gestionnaire de volume fournit aux configurations miroirs ou RAID-5 une redondance de données des périphériques multihôtes. Actuellement, Sun Cluster prend en charge les gestionnaires de volume Solaris Volume Manager et VERITAS Volume Manager, qui peut être utilisé uniquement sur les clusters SPARC, ainsi que le contrôleur de matériel RAID-5 RDAC sur plusieurs plates-formes RAID matérielles.

La combinaison de périphériques multihôtes avec la mise en miroir et l'entrelacement (striping) protège à la fois contre les pannes de nœuds et les pannes de disques individuels.

Pour consulter les questions et les réponses sur le stockage multihôte, voir Chapitre 4, Questions fréquemment posées .

SCSI multi-initiateur

Cette rubrique s'applique uniquement aux périphériques de stockage SCSI et non au stockage fibre Channel utilisé pour les périphériques multihôtes.

Sur un serveur autonome, le noeud contrôle les activités du bus SCSI par le biais du circuit de l'adaptateur d'hôte SCSI connectant ce serveur à un bus SCSI particulier. Ce circuit est appelé SCSI initiateur. il initie toutes les activités de ce bus SCSI. L'adresse SCSI par défaut des cartes de contrôleur SCSI dans les systèmes Sun est 7.

Dans les configurations en cluster, le stockage est partagé entre plusieurs nœuds du serveur à l'aide de périphériques multihôtes. Si le stockage de cluster est constitué de périphériques SCSI en mode asymétrique ou différentiel, la configuration est appelée « SCSI multi-initiateur ». Comme son nom l'indique, plusieurs initiateurs SCSI figurent sur le bus SCSI.

Cette spécification SCSI nécessite que chaque périphérique d'un bus SCSI ait une adresse SCSI unique. (la carte de contrôleur est également un dispositif du bus SCSI). La configuration matérielle par défaut dans un environnement multi-initiateur entraîne un conflit, car toutes les cartes de contrôleur sont définies sur 7 par défaut.

Pour résoudre ce conflit, sur chaque bus SCSI, laissez l'adresse d'une des cartes de contrôleur sur 7, et définissez tous les autres sur des adresses SCSI non utilisées. Afin de bien répartir ces adresses SCSI « non utilisées », choisissez des adresses non utilisées à l'heure actuelle et non utilisables dans le futur. Par exemple, l'ajout de capacité de stockage par l'installation de nouveaux lecteurs à des emplacements vides crée des adresses non utilisables dans le futur.

Dans la plupart des configurations, l'adresse SCSI disponible pour un second adaptateur d'hôte est 6.

Vous pouvez modifier les adresses SCSI sélectionnées pour ces cartes de contrôleur à l'aide de l'un des outils suivants permettant de définir la propriété scsi-initiator-id :

eeprom(1M)
PROM OpenBoot sur un système SPARC ;
utilitaire SCSI exécuté de façon optionnelle après initialisation du BIOS sur un système x86.

Elle peut être définie globalement pour un nœud ou individuellement pour chaque carte de contrôleur. Les instructions de définition d'une propriété scsi-initiator-id unique pour chaque adaptateur hôte SCSI sont incluses dans Sun Cluster 3.0-3.1 With SCSI JBOD Storage Device Manual for Solaris OS.

Disques locaux

Les disques locaux ne sont connectés qu'à un seul noeud. Par conséquent, les disques locaux ne sont pas protégés contre les pannes de nœuds (ils ne sont donc pas hautement disponibles). Toutefois, tous les disques, y compris les disques locaux, sont inclus dans l'espace de noms global et sont configurés comme périphériques globaux. Ainsi, les disques eux-mêmes sont visibles depuis tous les nœuds de cluster.

Vous pouvez mettre les systèmes de fichiers des disques locaux à la disposition d'autres nœuds en les plaçant sous un point de montage global. Si un des nœuds sur lequel est monté l'un de ces systèmes de fichiers globaux échoue, tous les nœuds perdent l'accès à ce système de fichiers. L'utilisation d'un gestionnaire de volume vous permet de mettre ces disques en miroir, évitant ainsi qu'une panne ne rende ces systèmes de fichiers inaccessibles ; les gestionnaires de volumes ne protègent cependant pas des pannes de nœuds.

Pour plus d'informations sur les périphériques globaux, voir Périphériques globaux .

Support amovible

Les supports amovibles tels que les lecteurs de bandes et lecteurs de CD sont pris en charge par le cluster. En général, vous installez, configurez et utilisez ces périphériques de la même façon que dans un environnement non clusterisé. Ces périphériques sont configurés en tant que périphériques globaux dans Sun Cluster, de façon que chaque nœud du cluster puisse accéder à chaque périphérique. Pour plus d'informations sur l'installation et la configuration des supports amovibles, voir Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS.

Pour plus d'informations sur les périphériques globaux, reportez-vous à Périphériques globaux .

Interconnexion de cluster

L'interconnexion de cluster est la configuration physique des périphériques utilisés pour le transfert de communications privées du cluster et de celles des services de données entre les noeuds du cluster. L'interconnexion étant fortement sollicitée pour les communications privées du cluster, les performances peuvent être amoindries.

Seuls les nœuds du cluster peuvent être y connectés. Le modèle de sécurité de Sun Cluster suppose que seuls les nœuds de cluster disposent d'un accès physique à l'interconnexion de cluster.

Tous les nœuds doivent être connectés par l'interconnexion de cluster via au minimum deux réseaux ou chemins d'accès redondants physiquement indépendants, afin d'éviter un point de panne unique. Il peut y avoir plusieurs réseaux physiquement indépendants (de deux à six) entre deux noeuds, quels qu'ils soient.

L'interconnexion de cluster se compose de trois éléments matériels : les adaptateurs, les jonctions et les câbles. La liste présentée ci-dessous décrit chacun de ces éléments matériels.

Adaptateurs : cartes d'interface réseau résidant dans chaque nœud du cluster. Leur nom se compose d'un nom de périphérique immédiatement suivi d'un numéro d'unité physique, par exemple, qfe2. Certains adaptateurs n'ont qu'une connexion physique au réseau, tandis que d'autres, comme la carte qfe, en possèdent plusieurs. Certains contiennent à la fois des interfaces réseau et des interfaces de stockage.

Un adaptateur réseau à plusieurs interfaces peut entraîner un point de panne unique s'il tombe en panne. Pour assurer une disponibilité maximale, planifiez votre cluster de sorte que l'unique chemin d'accès entre deux nœuds ne dépende pas d'un seul adaptateur réseau.
Jonctions : commutateurs résidant à l'extérieur des noeuds du cluster. Ils remplissent des fonctions d'intercommunication et de commutation vous permettant de connecter plus de deux nœuds entre eux. Dans un cluster à deux noeuds, vous n'avez pas besoin de jonctions car les noeuds peuvent être directement connectés l'un à l'autre via des câbles physiques redondants connectés à des adaptateurs redondants sur chaque noeud. Les configurations à plus de deux noeuds requièrent généralement des jonctions.
Câbles : connexions physiques installées entre deux adaptateurs réseau ou entre un adaptateur et une jonction.

Pour consulter les questions et les réponses sur l'interconnexion de cluster, voir Chapitre 4, Questions fréquemment posées .

Interfaces de réseau public

Les clients se connectent au cluster via des interfaces de réseau public. Chaque carte d'adaptateur réseau peut être connectée à un ou plusieurs réseaux publics, selon si elle possède plusieurs interfaces matérielles ou non. Vous pouvez définir des noeuds pour qu'ils prennent en charge plusieurs cartes d'interfaces de réseau public configurées de façon à ce qu'elles soient toutes actives, et puissent ainsi se servir mutuellement de sauvegarde en cas de basculement. Si l'un des adaptateurs tombe en panne, le logiciel multi-acheminement sur réseau IP est appelé et bascule l'interface défectueuse sur un autre adaptateur du groupe.

Aucune remarque d'ordre matériel particulière ne s'applique au clustering pour les interfaces de réseau public.

Pour consulter les questions et les réponses sur les réseaux publics, voir Chapitre 4, Questions fréquemment posées .

Systèmes client

Les systèmes client comprennent des stations de travail et autres serveurs accédant au cluster via le réseau public. Les programmes côté client utilisent les données ou d'autres services des applications côté serveur qui s'exécutent sur le cluster.

Les systèmes client ne sont pas hautement disponibles. Par contre, les données et applications du cluster le sont.

Pour consulter les questions et les réponses sur les systèmes client, voir Chapitre 4, Questions fréquemment posées .

Dispositifs d'accès à la console

Vous devez disposer d'un accès par console à l'ensemble des noeuds de cluster. Pour accéder à la console, utilisez l'un des périphériques suivants :

le concentrateur de terminaux acquis avec votre matériel de cluster ;
le processeur SSP sur les serveurs Sun Enterprise E10000 (pour les clusters SPARC) ;
le contrôleur de système sur les serveurs Sun Fire^TM (également pour les clusters SPARC) ;
un autre périphérique pouvant accéder à ttya sur chaque nœud.

Un seul concentrateur de terminaux pris en charge est disponible auprès de Sun et son utilisation n'est pas obligatoire. Il permet d'accéder à /dev/console sur chaque noeud, via un réseau TCP/IP. Vous disposez ainsi d'un accès par console pour chaque nœud à partir d'une station de travail distante située n'importe où sur le réseau.

Le SSP propose un accès à la console aux serveurs Sun Enterprise E1000. Le SSP est une machine installée sur un réseau Ethernet qui est configurée pour prendre en charge le serveur Sun Enterprise E1000. Pour le serveur Sun Enterprise E1000, il s'agit de la console administrative. En utilisant les fonctions de la console de réseau Sun Enterprise E10000, toutes les stations de travail du réseau peuvent ouvrir une session de console hôte.

Les autres méthodes d'accès par la console comprennent des concentrateurs de terminaux, un accès au port série tip(1) à partir d'un autre nœud et des terminaux non intelligents. Vous pouvez utiliser les claviers et moniteurs Sun^TM ou d'autres périphériques port série si votre fournisseur de services matériels les prend en charge.

Console administrative

Vous pouvez utiliser une station de travail UltraSPARC® dédiée ou un serveur Sun Fire V65x, appelés console administrative, pour administrer le cluster actif. Habituellement, vous pouvez installer et exécuter un logiciel outil administratif, par exemple le CCP et le module Sun Cluster pour le produit Sun Management Center (à utiliser uniquement avec des clusters SPARC) sur la console administrative. L'option cconsole du CCP vous permet de vous connecter à plus d'un noeud en même temps. Pour plus d'informations sur l'utilisation du CCP, voir Chapitre 1, Introduction à l’administration de Sun Cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

La console administrative n'est pas un nœud de cluster. Elle permet d'accéder à distance aux noeuds du cluster, soit via le réseau public, soit éventuellement à travers un concentrateur de terminaux basé sur le réseau. Si votre cluster est constitué de la plate-forme Sun Enterprise E10000, vous devez vous connecter au SSP à partir de la console administrative, à l'aide de la commande netcon(1M).

Les noeuds sont généralement configurés sans moniteur. Vous accédez à leur console par le biais d'une session telnet à partir de la console administrative. Cette console est connectée à un concentrateur de terminaux, lequel est connecté au port série du nœud. S'il s'agit d'un serveur Sun Enterprise E1000, vous vous connectez à partir du SSP. Pour plus d'informations, voir Dispositifs d'accès à la console .

Avec Sun Cluster, il n'est pas nécessaire d'avoir une console administrative dédiée, mais elle présente les avantages suivants :

Elle permet une gestion centralisée des clusters en regroupant les outils de gestion et de console sur la même machine.
Elle peut permettre une résolution plus rapide des problèmes par votre fournisseur de services matériels.

Pour consulter les questions et les réponses sur la console administrative, voir Chapitre 4, Questions fréquemment posées .

SPARC : Topologies Sun Cluster pour SPARC

Une topologie est un plan de connexion reliant les nœuds de cluster aux plates-formes de stockage d'un environnement Sun Cluster. Le logiciel Sun Cluster prend en charge toutes les topologies respectant les directives indiquées ci-dessous.

Un environnement Sun Cluster composé de systèmes SPARC prend en charge un maximum de seize nœuds d'un cluster, quelles que soient les configurations de stockage implémentées.
Un périphérique de stockage partagé peut être connecté à autant de noeuds qu'il peut en prendre en charge.
Les périphériques de stockage partagés n'ont pas besoin d'être connectés à tous les nœuds du cluster. Toutefois, ils doivent être connectés à au moins deux noeuds.

Le logiciel Sun Cluster ne nécessite pas que vous configuriez un cluster en utilisant des topologies particulières. Les topologies décrites ci-dessous ont pour but de fournir le vocabulaire nécessaire à une discussion relative à un plan de connexion de cluster, et correspondent à des plans de connexions classiques :

Paire clusterisée
paire+N ;
N+1 (étoile) ;
N*N (évolutive).

Les rubriques suivantes présentent des exemples schématiques de chaque topologie.

SPARC : Topologie de paire clusterisée pour SPARC

Une topologie de paire clusterisée correspond à deux nœuds fonctionnant dans le cadre administratif d'un même cluster. Dans cette configuration, les basculements ne se produisent qu'entre deux éléments d'une paire. Toutefois, tous les nœuds sont connectés par l'interconnexion de cluster et sont contrôlés par le logiciel Sun Cluster. Cette topologie peut être utilisée pour exécuter une application de base de données parallèle sur une paire, et une application évolutive ou de basculement sur une autre paire.

En utilisant le système de fichiers de cluster, vous pouvez également disposer d'une configuration à deux paires. Plus de deux nœuds peuvent exécuter un service évolutif ou une base de données parallèle même si tous les nœuds ne sont pas directement connectés aux disques qui stockent les données d'application.

La figure présentée ci-après illustre une configuration de paires clusterisées.

Figure 2–2 SPARC : topologie de paire clusterisée

SPARC : Topologie paire+N pour SPARC

La topologie paire+N comprend une paire de nœuds directement connectés au système de stockage partagé et un ensemble de nœuds utilisant l'interconnexion de cluster pour accéder au système de stockage partagé ; ils n'ont eux-mêmes pas de connexion directe.

La figure présentée ci-après illustre une topologie paire+N où deux des quatre noeuds (le noeud 3 et le noeud 4) utilisent l'interconnexion de cluster pour accéder au système de stockage. Cette configuration peut être étendue et inclure des noeuds supplémentaires n'ayant pas d'accès direct au système de stockage partagé.

Figure 2–3 topologie paire+N

SPARC : Topologie N+1 (étoile) pour SPARC

Une topologie N+1 comprend un certain nombre de noeuds principaux et un noeud secondaire. Vous n'avez pas besoin de configurer les noeuds principaux et le noeud secondaire de la même manière. Les noeuds principaux sont activement impliqués dans la fourniture de services d'application. Le nœud secondaire n'a pas besoin d'être inactif en attendant la panne d'un nœud principal.

Le noeud secondaire est le seul noeud de la configuration à être physiquement connecté à tout le système de stockage multihôte.

Si une erreur se produit sur un nœud principal, Sun Cluster bascule les ressources sur le nœud secondaire, sur lequel elles fonctionnent jusqu'à ce qu'elles basculent de nouveau (automatiquement ou manuellement) sur le nœud principal.

Le nœud secondaire doit toujours avoir une capacité de CPU suffisamment importante pour assumer la charge supplémentaire d'un nœud principal défectueux.

La figure présentée ci-après illustre une configuration N+1.

Figure 2–4 SPARC : topologie N+1

SPARC : Topologie N*N (évolutive) pour SPARC

Une topologie N*N permet à tous les périphériques de stockage partagés du cluster de se connecter à tous les nœuds de ce dernier. Cette topologie permet aux applications à haut niveau de disponibilité de basculer d'un nœud sur un autre sans occasionner de dégradation de service. En cas de basculement, le nouveau nœud peut accéder au périphérique de stockage en utilisant un chemin d'accès local et non l'interconnexion privée.

La figure suivante illustre une configuration N*N.

Figure 2–5 SPARC : topologie N*N

x86 : Topologies Sun Cluster pour x86

Une topologie est un plan de connexion reliant les nœuds de cluster aux plates-formes de stockage du cluster. Sun Cluster prend en charge toutes les topologies respectant les directives indiquées ci-dessous.

Sun Cluster constitué de systèmes x86 prend en charge des clusters à deux nœuds.
Les périphériques de stockage partagés doivent être connectés aux deux noeuds.

Sun Cluster ne requiert pas de topologies spécifiques pour la configuration d'un cluster. La topologie de paire clusterisée suivante, seule topologie pour clusters composés de nœuds x86, est présentée pour introduire la terminologie du schéma de connexion d'un cluster. Elle correspond à un schéma de connexion type.

La rubrique suivante présente un exemple de diagramme de cette topologie.

x86 : Topologie de paire clusterisée pour x86

Une topologie de paire clusterisée correspond à deux nœuds fonctionnant dans le cadre administratif d'un même cluster. Dans cette configuration, les basculements ne se produisent qu'entre deux éléments d'une paire. Toutefois, tous les nœuds sont connectés par l'interconnexion de cluster et fonctionnent sous le contrôle du logiciel Sun Cluster. Cette topologie peut être utilisée pour exécuter une application de base de données parallèle, évolutive ou de basculement sur la paire.