Les composants matériels et logiciels du système SunPlex

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 nœuds de cluster avec des disques locaux (non partagés) ;

• un stockage multihôte (disques partagés entre les nœuds) ;

• des supports amovibles (bandes et CD) ;

• interconnexion de clusters ;

• des interfaces de réseau public ;

• des systèmes client ;

• une console administrative ;

• des périphériques d'accès à la console.

Le système SunPlex vous permet de combiner ces composants dans plusieurs types de configurations, décrits dans la rubrique SPARC: exemples de topologies Sun Cluster .

Vous trouverez l'illustration d'un exemple de configuration de cluster à deux nœuds dans la rubrique “Hardware Environment” du Sun Cluster Overview for Solaris OS.

Nœuds de cluster

Un nœud de cluster est une machine exécutant à la fois l'environnement d'exploitation Solaris et le logiciel Sun Cluster, cette machine est soit un membre courant du cluster (membre du cluster), soit un membre potentiel.

SPARC: le logiciel Sun Cluster permet d'avoir des clusters de deux à huit nœuds. Reportez-vous à la rubrique SPARC: exemples de topologies Sun Cluster pour obtenir de plus amples informations sur les configurations de nœuds prises en charge.

x86: Le logiciel Sun Cluster vous permet d'avoir deux nœuds dans un cluster. Reportez-vous à la rubrique x86: exemples de topologies Sun Cluster pour obtenir de plus amples informations sur les configurations de nœuds prises en charge.

Les nœuds de cluster sont généralement rattaché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 servir les requêtes sans être directement rattachés aux périphériques multihôtes.

En outre, les nœuds des configurations de bases de données parallèles partagent un accès simultané à tous les disques. Reportez-vous à la rubrique Périphériques multihôtes et au Chapitre 3, Notions-clés : administration et développement d'applications pour de plus amples informations sur les configurations des bases de données parallèles.

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 à travers un ou plusieurs réseaux physiquement indépendants. L'ensemble de ces réseaux est appelé interconnexion de cluster.

Chaque nœud du cluster sait lorsqu'un autre nœud 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 nœuds 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 cette possibilité de basculement, chaque nœud doit posséder suffisamment de capacité excédentaire pour prendre la charge des nœuds dont il constitue la sauvegarde ou le nœud secondaire.

Chaque nœud initialise son propre système de fichiers racine (/).

Composants logiciels pour les membres matériels du Cluster

Pour qu'ils puissent fonctionner comme des membres de cluster, les logiciels suivants doivent être installés :

• environnement d'exploitation Solaris ;

• logiciel Sun Cluster ;

• application de service de données ;

• gestion de 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 requiert pas forcément de logiciel de gestion de volumes tel que Solaris Volume Manager ou VERITAS Volume Manager.

• Consultez le Guide d'installation du logiciel Sun Cluster pour SE Solaris pour toute information concernant l'installation de l'environnement d'exploitation Solaris, Sun Cluster et le logiciel de gestion de volume.

• Consultez le Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour toute information concernant l'installation et la configuration des services de données.

• Reportez-vous au Chapitre 3, Notions-clés : administration et développement d'applications pour obtenir des informations théoriques sur les composants logiciels précédemment décrits.

La figure suivante fournit une vue d'ensemble des composants logiciels fonctionnant de concert pour créer l'environnement du logiciel Sun Cluster.

Figure 2–1 Relation synthétique entre les composants du logiciel Sun Cluster

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives aux membres du cluster.

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. Sun Cluster requiert un système de stockage multihôte pour que les clusters à deux nœuds puissent établir un quorum. Les clusters de plus de trois nœuds n'ont pas besoin de stockage multihôte.

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

• Ils peuvent tolérer des pannes sur un seul nœud.

• Ils stockent les données d'applications et peuvent aussi stocker les fichiers binaires et les fichiers de configuration d'applications.

• Ils protègent des pannes de nœud. Si les requêtes client accèdent aux données via un nœud qui échoue, elles sont basculées vers un autre nœud ayant une connexion directe aux mêmes disques.

• Ils sont accessibles soit globalement, à travers un nœud principal « contrôlant » les disques, soit simultanément et directement, à travers des chemins locaux. Oracle Real Application Clusters est la seule application utilisant actuellement l'accès simultané direct .

Un gestionnaire de volumes fournit aux configurations miroirs ou RAID-5 une redondance de données des périphériques multihôtes. À l'heure actuelle, Sun Cluster prend en charge les gestionnaires de volumes Solaris Volume Manager^TM et VERITAS Volume Manager (disponibles uniquement pour les clusters SPARC), ainsi que le contrôleur matériel RDAC RAID-5 sur plusieurs plates-formes RAID matérielles.

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

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives au stockage multihôte.

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 nœud 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é initiateur SCSI, 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. Lorsque le stockage de cluster se compose 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.

Les spécifications SCSI requièrent une adresse SCSI unique pour chaque périphérique du bus SCSI (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 pour 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. La procédure de définition d'une propriété scsi-initiator-id unique pour chaque carte de contrôleur SCSI est décrite dans le chapitre concernant chaque boîtier de disque de la Sun Cluster Hardware Collection.

Disques locaux

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

Vous pouvez rendre les systèmes de fichiers des disques locaux accessibles aux autres nœuds en les mettant 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 volumes 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.

Reportez-vous à la rubrique Périphériques globaux pour de plus amples informations sur les périphériques globaux.

Médias amovibles

Les médias 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 entretenez ces périphériques de la même manière que dans un environnement non clusterisé. Ils sont configurés comme des périphériques globaux dans Sun Cluster, chacun est donc accessible à tous les nœuds du cluster. Reportez-vous au manuel Sun Cluster 3.x Hardware Administration Manual for Solaris OS pour toute information concernant l'installation et la configuration des médias amovibles.

Reportez-vous à la rubrique Périphériques globaux pour de plus amples informations sur les 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 nœuds 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é Sun Cluster suppose que seuls les nœuds du cluster ont un accès physique à l'interconnexion.

Tous les nœuds doivent être connectés par l'interconnexion de cluster via au moins 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 nœuds, 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. En outre, 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 nœuds 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 nœuds, vous n'avez pas besoin de jonctions car les nœuds peuvent être directement connectés l'un à l'autre via des câbles physiques redondants connectés à des adaptateurs redondants sur chaque nœud. Les configurations à plus de deux nœuds requièrent généralement des jonctions.

• Câbles : connections physiques reliant soit deux adaptateurs réseau, soit un adaptateur et une jonction.

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives à l'interconnexion de cluster.

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 nœuds 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. En cas d'échec d'un des adaptateurs, le logiciel de IP Network Multipathing intervient pour basculer de l'interface défectueuse vers 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.

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives aux réseaux publics.

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 client utilisent des données ou autres services fournis par les applications serveur exécutées sur le cluster.

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

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives aux systèmes client.

Périphériques d'accès par console

Vous devez disposer d'un accès par console à l'ensemble des nœuds de cluster. Pour obtenir cet accès, utilisez le concentrateur de terminaux fourni avec le matériel de cluster, le SSP (System Service Processor) sur les serveurs Sun Enterprise E10000^TM (pour les clusters SPARC), le contrôleur système sur les serveurs Sun Fire^TM (également pour les clusters SPARC), ou un autre périphérique ayant accès à 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 nœud, 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 (System Service Processor) fournit un accès par console au Sun Enterprise E10000 server. Le SSP est une machine sur un réseau Ethernet configurée pour pendre en charge le Sun Enterprise E10000 server. C'est la console administrative du Sun Enterprise E10000 server. 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.

Il existe d'autres méthodes d'accès par console, notamment par d'autres concentrateurs de terminaux, l'accès 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^TM V65x, appelé console administrative, pour administrer le cluster actif. Habituellement, vous utilisez et exécutez des outils d'administration, tels que le Cluster Control Panel (CCP) et le module Sun Cluster pour le produit Sun Management Center^TM (à utiliser uniquement avec des clusters SPARC), sur la console administrative. L'option cconsole du CCP vous permet de vous connecter à plus d'un nœud en même temps. Pour de plus amples informations sur l'utilisation du CCP, reportez-vous au Sun Cluster System Administration Guide.

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

Les nœuds sont généralement configurés sans moniteur. Vous accédez ensuite à la console des nœuds à travers une session telnet ouverte à partir de la console administrative. Celle-ci est connectée à un concentrateur de terminaux à partir duquel vous accédez au port série du nœud (avec un Sun Enterprise E10000 server, vous vous connectez à partir du SSP). Reportez-vous à la rubrique Périphériques d'accès par console pour de plus amples informations.

Avec Sun Cluster, il n'est pas nécessaire d'utiliser une console administrative dédiée, bien qu'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.

Reportez-vous au Chapitre 4, Foire aux questions pour prendre connaissance des questions et réponses relatives à la console administrative.