Chapitre 3 Notions-clés destinées aux administrateurs système et aux développeurs d'applications

Ce chapitre décrit les notions-clés associées aux composants logiciels d'un système Sun Cluster. Il aborde les sujets suivants :

• Interfaces administratives

• Heure du cluster

• Structure à haute disponibilité

• Périphériques globaux

• Groupes de périphériques de disques

• Espace de noms global

• Systèmes de fichiers Cluster

• Contrôle de chemin de disque

• Quorum et périphériques de quorum

• Services de données

• Utilisation de l'interconnexion de cluster pour le trafic de services de données

• Ressources, groupes de ressources et types de ressource

• Configuration d'un projet de services de données

• Adaptateurs de réseau public et multi-acheminement sur réseau IP

• SPARC : Prise en charge de la reconfiguration dynamique

Ces informations sont destinées principalement aux administrateurs système et aux développeurs d'applications utilisant l'API et le kit de développement logiciel (SDK) Sun Cluster. Les administrateurs système y trouveront des informations de fond pour l'installation, la configuration et l'administration du logiciel de cluster. Les développeurs d'applications y trouveront les informations nécessaires à la compréhension de l'environnement de cluster dans lequel ils travailleront.

Interfaces administratives

Plusieurs interfaces utilisateur vous permettent d'installer, de configurer et d'administrer le système Sun Cluster. Les tâches d'administration système peuvent être effectuées par l'intermédiaire de l'interface utilisateur graphique de SunPlex Manager ou via l'interface de ligne de commande. Outre l'interface de ligne de commande, il existe des utilitaires, comme scinstall et scsetup qui permettent de simplifier les tâches d'installation et de configuration sélectionnées. Le système Sun Cluster intègre également un module fonctionnant avec Sun Management Center qui fournit une interface graphique utilisateur pour l'exécution de certaines tâches du cluster. Ce module est disponible uniquement pour les clusters SPARC. Pour une description complète des interfaces administratives, voir Outils d’administration du Guide d’administration système de Sun Cluster pour SE Solaris.

Heure du cluster

L'heure entre tous les nœuds du cluster doit être synchronisée. La synchronisation éventuelle des nœuds du cluster avec une heure extérieure n'a aucune incidence sur son fonctionnement. Le système Sun Cluster utilise le protocole NTP pour synchroniser les horloges entre les nœuds.

En général, si l'horloge système est modifiée d'une fraction de seconde, cela ne pose aucun problème. Cependant, si vous exécutez date(1), rdate(1M) ou xntpdate(1M) (de façon interactive ou dans des scripts cron) sur un cluster actif, vous pouvez modifier une heure de plus d'une fraction de seconde pour synchroniser l'horloge système avec la source de synchronisation. Cette modification forcée peut alors entraîner des problèmes avec l'horodateur des modifications de fichiers ou troubler le service NTP.

Si vous installez le système d'exploitation Solaris sur chaque nœud de cluster, vous pouvez modifier l'heure et la date par défaut de chaque nœud. Vous pouvez en général accepter les paramètres par défaut.

Si vous installez le logiciel Sun Cluster à l'aide de scinstall(1M), vous devez configurer le protocole NTP pour le cluster. Le logiciel Sun Cluster contient un fichier modèle, ntp.cluster (voir /etc/inet/ntp.cluster sur un nœud de cluster installé) qui crée une relation d'homologue entre tous les nœuds de cluster. Un nœud est désigné comme étant le nœud “préféré”. Les nœuds sont identifiés par leurs noms d'hôte privés et la synchronisation de l'heure se produit à travers l'interconnexion du cluster. Pour obtenir des instructions sur la configuration du cluster pour le protocole NTP, reportez-vous au Chapitre 2, Installation et configuration du logiciel Sun Cluster du Guide d’installation du logiciel Sun Cluster pour SE Solaris.

Vous pouvez aussi installer un ou plusieurs serveurs NTP à l'extérieur du cluster et modifier le fichier ntp.conf pour qu'il reflète cette configuration.

Lors d'un fonctionnement normal, vous ne devriez jamais avoir à modifier l'heure du cluster. Cependant si l'heure n'était pas réglée correctement lorsque vous avez installé le système d'exploitation Solaris et si vous souhaitez la modifier, la procédure adéquate est incluse dans le Chapitre 7, Administration du cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

Structure à haute disponibilité

Grâce au système Sun Cluster, tous les composants qui se trouvent sur le « chemin » reliant les utilisateurs aux données, y compris les interfaces réseau, les applications elles-mêmes, le système de fichiers et les disques multihôtes, sont hautement disponibles. Un composant du cluster est dit hautement disponible s'il est capable de survivre à toute panne (matérielle ou logicielle) unique du système.

Le tableau suivant affiche les types de panne des composants Sun Cluster (tant matériels que logiciels) et les types de récupération intégrés à la structure à haute disponibilité :

La structure à haute disponibilité du logiciel Sun Cluster détecte rapidement une panne de nœud et crée un serveur équivalent pour les ressources de la structure sur un nœud restant du cluster. Les ressources de la structure ne sont jamais toutes indisponibles en même temps. Celles qui ne sont pas affectées par une panne de nœud restent totalement disponibles pendant la récupération. En outre, celles du nœud défectueux redeviennent disponibles dès que la récupération est terminée. Une ressource de la structure récupérée n'a pas à attendre la récupération de toutes les autres.

La plupart des ressources de la structure à haute disponibilité sont récupérées de façon transparente pour les applications (services de données) les utilisant. La sémantique d'accès aux ressources de la structure est totalement préservée après l'échec d'un nœud. Les applications ne peuvent pas détecter que le serveur des ressources de la structure a été déplacé sur un autre nœud. La panne d'un nœud unique est complètement transparente pour les programmes des nœuds restants utilisant les fichiers, périphériques et volumes de disques connectés à ce nœud. Cette transparence est possible s'il existe un autre chemin matériel vers les disques d'un autre nœud. On peut par exemple utiliser des périphériques multihôtes ayant des ports connectés à plusieurs nœuds.

Moniteur d'appartenance au cluster

Pour assurer que les données ne s'altèrent pas, tous les nœuds doivent arriver à un accord cohérent sur l'appartenance au cluster. Si nécessaire, le moniteur d'appartenance au cluster coordonne la reconfiguration des services (applications) du cluster en réponse à une panne.

Le MAC reçoit des informations sur la connectivité aux autres nœuds depuis la couche de transport intracluster. Il utilise l'interconnexion du cluster pour échanger des informations d'état au cours d'une reconfiguration.

Après avoir détecté une modification d'appartenance au cluster, le CMM effectue une configuration synchronisée du cluster. Dans une configuration synchronisée, les ressources du cluster peuvent être redistribuées, en fonction de la nouvelle appartenance au cluster.

Contrairement aux versions précédentes du logiciel Sun Cluster, le CMM s'exécute entièrement dans le noyau.

Pour plus d'informations sur la protection du cluster contre le partitionnement en plusieurs clusters distincts, voir À propos de la séparation en cas d'échec .

Mécanisme failfast

Si le CMM détecte un problème crucial sur un nœud, il demande à la structure du cluster de l'arrêter de force et de le supprimer de l'appartenance au cluster. Ce mécanisme d'arrêt et de suppression est appelé failfast. Il entraîne l'arrêt d'un nœud de deux façons.

• Si un nœud quitte le cluster puis tente de démarrer un nouveau cluster sans avoir de quorum, il est « séparé » pour être empêché d'accéder aux disques partagés. Pour plus d'informations sur l'utilisation du mécanisme failfast, voir À propos de la séparation en cas d'échec .

• Si un ou plusieurs démons propres au cluster meurent (clexecd, rpc.pmfd, rgmd ou rpc.ed), la panne est détectée par le CMM et le nœud panique.

Lorsque la mort d'un démon de cluster provoque la panique d'un nœud, un message semblable au suivant s'affiche sur la console correspondant à ce nœud.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

Après la panique, le nœud peut redémarrer et tenter de rejoindre le cluster. Si le cluster est composé de systèmes SPARC, le nœud peut rester à l'invite de la PROM OpenBoot^TM. L'action suivante du nœud est déterminée par la définition du paramètre auto-boot?. Vous pouvez le définir avec eeprom(1M) à l'invite ok de la PROM OpenBoot.

Référentiel de configuration du cluster (CCR)

Le CCR utilise un algorithme de validation à deux phases pour les mises à jour : une mise à jour doit être effectuée sur tous les membres de cluster, faute de quoi elle est annulée. Le CCR utilise l'interconnexion du cluster pour appliquer les mises à jour distribuées.

Le CCR est constitué de fichiers texte, mais vous ne devez jamais les modifier manuellement. Chaque fichier contient une somme de contrôle enregistrée pour assurer la cohérence entre les nœuds. Une mise à jour manuelle de ces fichiers peut provoquer l'arrêt d'un nœud ou de l'ensemble du cluster.

Le CCR s'appuie sur le moniteur d'appartenance pour garantir qu'un cluster ne fonctionne que si un quorum a été atteint. Il est chargé de vérifier la cohérence des données au sein du cluster, d'effectuer des récupérations lorsque cela s'aèvre nécessaire et de faciliter les mises à jour des données.

Périphériques globaux

Le système Sun Cluster utilise des périphériques globaux pour fournir à tout périphérique d'un cluster un accès hautement disponible dans l'ensemble du cluster, à partir de n'importe quel nœud, quelle que soit la connexion physique de ce périphérique. En général, si un nœud tombe en panne alors qu'un périphérique global y a accès, le logiciel Sun Cluster change automatiquement le chemin vers ce périphérique et redirige l'accès en utilisant ce nouveau chemin. 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 multiports pris en charge par le logiciel Sun Cluster. Actuellement, les lecteurs de CD-ROM et de bande 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-ROM et périphérique de bande du cluster. Cela permet un accès cohérent à chaque périphérique à partir de n'importe quel nœud du cluster. L'espace de noms du périphérique global se trouve dans le répertoire /dev/global. Pour plus d'informations, voir Espace de noms global .

Les périphériques globaux à accès multiples fournissent plus d'un chemin d'accès au périphérique. Comme les disques multihôtes font partie d'un groupe de périphériques de disques hébergé par plusieurs nœuds, ils sont hautement disponibles.

ID de périphérique et pilote de pseudo IDP

Le logiciel Sun Cluster gère les périphériques globaux à travers une structure appelée pilote de pseudo IDP (ID de périphérique). 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.

Ce pilote fait partie intégrante de la fonction d'accès aux périphériques globaux du cluster. Il teste tous les nœuds du cluster et établit la liste des périphériques de disques uniques, assignant à chacun un numéro unique majeur et mineur d'une façon cohérente. L'accès aux périphériques globaux est effectué via l'ID de périphérique unique et non les ID de périphérique standard Solaris, par exemple c0t0d0 pour un disque.

Cette méthode garantit que toute application accédant aux disques (comme un gestionnaire de volume ou des applications utilisant des périphériques bruts) utilise un chemin d'accès cohérent à travers 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 nœud à l'autre, modifiant ainsi les conventions d'attribution de nom des périphériques Solaris. Le nœud 1 (Node1) peut par exemple considérer un disque multihôte comme c1t2d0, tandis que le nœud 2 (Node2) peut considérer ce même disque de manière totalement différente, comme c3t2d0 , par exemple. Le pilote d'IDP assigne un nom global, tel que d10, que les nœuds utilisent. Ainsi, chaque nœud obtient un mappage cohérent vers les disques multihôtes.

Les commandes scdidadm(1M) et scgdevs(1M) vous permettent de mettre à jour et de gérer les ID de périphérique. Pour plus d'informations, reportez-vous aux pages man suivantes :

• scdidadm(1M)

• scgdevs(1M)

Groupes de périphériques de disques

Dans le système Sun Cluster, tous les périphériques multihôtes doivent être sous le contrôle du logiciel Sun Cluster. Créez d'abord des groupes de disques du gestionnaire de volume—des ensembles de disques Solaris Volume Manager ou des groupes de disques VERITAS Volume Manager (qui peuvent être utilisés uniquement sur des clusters SPARC)—sur les disques multihôtes. Vous enregistrez ensuite les groupes de disques du gestionnaire de volume comme groupes de périphériques de disques. Un groupe de périphériques de disques est un type de périphérique global. En outre, Sun Cluster crée automatiquement un groupe de périphériques de disques bruts pour chaque disque et bande du cluster. Toutefois, ces groupes de périphériques du cluster restent à l'état hors ligne tant que vous ne les utilisez pas comme périphériques globaux.

L'enregistrement fournit au système Sun Cluster des informations permettant de savoir quels nœuds possèdent un chemin d'accès à quels groupes de disques du gestionnaire de volume. Ceux-ci deviennent alors globalement accessibles au sein du cluster. Si plus d'un nœud peut écrire sur (contrôler) un groupe de périphériques de disques, les données stockées sur ce groupe deviennent hautement disponibles. Ce groupe hautement disponible permet de contenir les systèmes de fichiers du cluster.

les groupes de périphériques de disques sont indépendants des groupes de ressources. Un nœud peut contrôler un groupe de ressources (représentant un groupe de services de données) tandis qu'un autre peut contrôler les groupes de disques auxquels les services de données accèdent. Toutefois, il est conseillé de conserver sur un même nœud le groupe de périphériques de disques qui stocke les données d'une application particulière et le groupe de ressources qui contient les ressources de cette application (démon de l'application). Pour plus d'informations sur l'association entre les groupes de périphériques de disques et les groupes de ressources, voir Relationship Between Resource Groups and Disk Device Groups du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Lorsqu'un nœud utilise un groupe de périphériques de disques, le groupe de disques du gestionnaire de volume devient « global », car il prend en charge plusieurs chemins vers les 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.

Basculement de groupes de périphériques d'un disque

Un boîtier de disque étant connecté à plusieurs nœuds, tous les groupes de périphériques de ce boîtier sont accessibles via un autre chemin en cas d'échec du nœud contrôlant le groupe de périphériques. Cette panne n'affecte pas l'accès au groupe de périphériques sauf pendant le laps de temps nécessaire à la récupération et aux contrôles de cohérence. Durant ce laps de temps, toutes les requêtes sont bloquées (de manière transparente pour l'application) jusqu'à ce que le système rende disponible le groupe de périphériques.

Figure 3–1 Groupe de périphériques de disques avant et après le basculement

Groupes de périphériques de disques multiports

Cette section décrit les propriétés des groupes de périphériques de disques qui vous permettent d'équilibrer les performances et la disponibilité dans une configuration de disques multiports. Le logiciel Sun Cluster propose deux propriétés qui permettent de configurer des disques multiports : preferenced et numsecondaries. Vous pouvez contrôler l'ordre dans lequel les nœuds essaient de prendre le contrôle en cas de basculement à l'aide de la propriété preferenced. La propriété nombre_nœuds_secondaires permet de définir le nombre souhaité de nœuds secondaires d'un groupe de périphériques.

Un service hautement disponible est dit arrêté si le nœud principal tombe en panne et si aucun nœud secondaire ne peut être promu au rang de nœud principal. Si le service bascule, la propriété preferenced étant définie sur true, alors les nœuds suivent l'ordre de la liste de nœuds pour en sélectionner un secondaire. La liste de nœuds définit l'ordre dans lequel les nœuds essaient de prendre le contrôle du nœud principal ou de passer de l'état de remplacement à celui de secondaire. La préférence d'un service de périphérique peut être modifiée de manière dynamique à l'aide de l'utilitaire scsetup(1M). La préférence associée aux fournisseurs de services dépendants, par exemple un système de fichiers global, est identique à celle du service de périphérique.

Les nœuds secondaires sont contrôlés par le nœud principal au cours du fonctionnement normal. Dans une configuration de disques à accès multiples, le contrôle de chaque nœud secondaire entraîne une dégradation des performances et une surconsommation de mémoire. La prise en charge des nœuds de remplacement a été implémentée pour réduire au minimum la dégradation des performances et la surconsommation de la mémoire provoquées par le contrôle de chaque nœud. Par défaut, votre groupe de périphériques de disques dispose d'un nœud principal et d'un nœud secondaire. Les nœuds disponibles restants deviennent des nœuds de remplacement. En cas de basculement, le nœud secondaire devient principal et le nœud dont la priorité est la plus élevée dans la liste de nœuds devient secondaire.

Le nombre de nœuds secondaires souhaité peut être défini sur n'importe quel entier compris entre un et le nombre de nœuds de fournisseur non principaux opérationnels dans le groupe de périphériques.

Si vous utilisez Solaris Volume Manager, vous devez créer le groupe de périphériques de disques avant de définir la propriété numsecondaries sur un nombre autre que la valeur par défaut.

Le nombre souhaité de nœuds secondaires par défaut pour les services de périphériques est un. Le nombre réel de fournisseurs secondaires géré par la structure des répliques correspond au nombre souhaité à moins que le nombre de fournisseurs non principaux opérationnels soit inférieur à celui qu'on attend. Vous devez modifier la propriété numsecondaries et vérifier la liste de nœuds si vous ajoutez ou supprimez des nœuds dans votre configuration. La gestion de la liste de nœuds et du nombre souhaité de nœuds secondaires empêche tout conflit entre le nombre configuré de nœuds secondaires et le nombre réel autorisé par la structure.

• (Solaris Volume Manager) Utilisez la commande metaset(1M) pour les groupes de périphériques Solaris Volume Manager avec les propriétés preferenced et numsecondaries pour gérer l'ajout et la suppression de nœuds dans votre configuration.

• (Veritas Volume Manager) Utilisez la commande scconf(1M) pour les groupes de périphériques de disques VxVM avec les propriétés preferenced et numsecondaries pour gérer l'ajout et la suppression de nœuds dans votre configuration.

• Pour plus d'informations sur les procédures à suivre pour modifier les propriétés d'un groupe de périphériques de disques, voir Administration de systèmes de fichiers de cluster : présentation du Guide d’administration système de Sun Cluster pour SE Solaris.

Espace de noms global

Le mécanisme du logiciel Sun Cluster qui active les périphériques globaux est l'espace de noms global. Cet espace comprend la hiérarchie /dev/global/ ainsi que les espaces de noms du gestionnaire de volume. L'espace de noms global reflète les disques multihôtes et les disques locaux (et tout autre périphérique du cluster, tel que CD et bandes) et fournit aux disques multihôtes plusieurs chemins de basculement. Chaque nœud physiquement connecté aux disques multihôtes fournit un chemin d'accès au stockage pour tout nœud du cluster.

Normalement, dans le cas de Solaris Volume Manager, les espaces de noms du gestionnaire de volume sont situés dans les répertoires /dev/md/diskset/dsk (et rdsk). Dans le cas de Veritas VxVM, les espaces de noms du gestionnaire de volume sont situés dans les répertoires /dev/vx/dsk/disk-group et /dev/vx/rdsk/disk-group. Ces espaces de noms sont constitués de répertoires pour chaque ensemble de disques Solaris Volume Manager et chaque groupe de disques VxVM importés dans le cluster. Chacun de ces répertoires contient un nœud de périphérique pour chaque métapériphérique ou volume de cet ensemble de disques ou groupe de disques.

Dans le système Sun Cluster, chaque nœud de périphérique de l'espace de noms du gestionnaire de volume local est remplacé par un lien symbolique vers un nœud de périphérique du système de fichiers /global/.devices/node@ nodeID, où nodeID est un nombre entier représentant les nœuds du cluster. Le logiciel Sun Cluster continue de présenter les périphériques du gestionnaire de volume, sous forme de liens symboliques, à leur emplacement standard. L'espace de noms global et l'espace de noms du gestionnaire de volume standard sont tous deux disponibles à partir de n'importe quel nœud du cluster.

Les avantages de l'espace de noms global sont décrits ci-dessous.

• Chaque nœud demeure pratiquement indépendant et le modèle d'administration du périphérique est légèrement modifié.

• Les périphériques peuvent devenir globaux de manière sélective.

• Les générateurs de liens de tiers demeurent opérationnels.

• À partir d'un nom de périphérique local donné, on peut facilement établir un mappage pour obtenir son nom global.

Exemples d'espaces de noms locaux et globaux

Le tableau suivant montre les mappages entre les espaces de noms locaux et globaux d'un disque multihôte, c0t0d0s0.

L'espace de noms global est automatiquement généré au moment de l'installation et mis à jour à chaque réinitialisation de configuration. Vous pouvez aussi le générer en exécutant la commande scgdevs(1M).

Systèmes de fichiers Cluster

Le système de fichiers de cluster possède les caractéristiques suivantes :

• Les emplacements d'accès aux fichiers sont transparents. Un processus peut ouvrir un fichier situé n'importe où sur le système. Les processus sur tous les nœuds peuvent utiliser le même nom de chemin pour localiser un fichier.

  ---

  Remarque –

  lorsqu'un système de fichiers de cluster lit des fichiers, il ne met pas à jour l'horaire d'accès sur ces fichiers.

  ---

• Des protocoles de cohérence sont utilisés pour préserver la sémantique d'accès aux fichiers UNIX même lorsqu'on accède au fichier simultanément à partir de plusieurs nœuds.

• La mise en mémoire cache extensive est utilisée avec des mouvements d’entrée/sortie de masse sans copie pour déplacer les données des fichiers de manière efficace.

• Le système de fichiers d'un cluster fournit des fonctionnalités de verrouillage de fichiers informatif hautement disponible par le biais des interfaces fcntl(2). Les applications exécutées sur plusieurs nœuds peuvent synchroniser l'accès aux données en utilisant le verrouillage de fichiers informatif sur le fichier d'un système de fichiers du cluster. Les verrous de fichiers sont immédiatement récupérés à partir de nœuds quittant le cluster ou d’applications échouant au verrouillage.

• L'accès aux données est assuré, même en cas de pannes. Les applications ne sont pas affectées par les pannes tant qu'un chemin d'accès aux disques demeure opérationnel. Cette garantie est aussi valable pour l'accès aux disques bruts et pour toutes les opérations du système de fichiers.

• Les systèmes de fichiers de cluster sont indépendants du système de fichiers sous-jacent et du logiciel de gestion de volumes. Les systèmes de fichiers de cluster rendent globaux tous les systèmes de fichiers sur les disques pris en charge.

Vous pouvez monter globalement un système de fichiers sur un périphérique global avec mount-g ou localement avec mount.

Les programmes peuvent accéder à un fichier d'un système de fichiers de cluster à partir de tout nœud du cluster par le biais du même nom de fichier (par exemple, /global/foo).

Un système de fichiers de cluster est monté sur tous les membres du cluster. Il est impossible de le monter sur un sous-ensemble des membres du cluster.

Un système de fichiers de cluster n'est pas un type de système de fichiers à part. Les clients vérifient le système de fichiers sous-jacent (par exemple UFS).

Utilisation des systèmes de fichiers de cluster

Dans le système Sun Cluster, tous les disques multihôtes sont placés dans des groupes de périphériques de disques, tels que des ensembles de disques Solaris Volume Manager, des groupes de disques VxVM ou des disques individuels n'étant pas sous le contrôle d'un gestionnaire de volume de logiciel.

Pour qu'un système de fichiers de cluster soit hautement disponible, le périphérique de stockage de disques sous-jacent doit être connecté à plusieurs nœuds. Ainsi, un système de fichiers local (stocké sur le disque local d'un nœud) créé à l'intérieur d'un système de fichiers de cluster n'est pas hautement disponible.

Vous pouvez monter des systèmes de fichiers de cluster comme vous monteriez tout autre système de fichiers :

• Manuellement — Utilisez la commande mount et les options de montage -g ou -o global pour monter le système de fichiers de cluster à partir de la ligne de commande, par exemple :

  SPARC : # mount -g /dev/global/dsk/d0s0 /global/oracle/data

• Automatiquement— Créez une entrée dans le fichier /etc/vfstab avec une option de montage global pour monter le système de fichiers de cluster à l'initialisation. Créez ensuite un point de montage sous le répertoire /global sur tous les nœuds. Le répertoire /global est conseillé : il n'est nullement impératif. Exemple de ligne pour un système de fichiers de cluster dans un fichier /etc/vfstab :

  SPARC : /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/data ufs 2 yes global,logging

Le logiciel Sun Cluster n'impose pas de stratégie de dénomination pour les systèmes de fichiers de cluster, mais vous pouvez en faciliter l'administration en créant un point de montage pour tous les systèmes de fichiers de cluster sous le même répertoire, par exemple /global/disk-device-group. Pour plus d'informations, voir Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) and Guide d’administration système de Sun Cluster pour SE Solaris.

Type de ressource HAStoragePlus

Le type de ressource HAStoragePlus est conçu pour optimiser la disponibilité des configurations des systèmes de fichiers locaux comme UFS (système de fichiers UNIX) et VxFS. Utilisez HAStoragePlus pour intégrer votre système de fichiers local à l'environnement Sun Cluster et en optimiser la disponibilité. HAStoragePlus intègre des fonctions supplémentaires en matière de système de fichiers telles que les contrôles, les montages et les démontages forcés qui permettent à Sun Cluster de basculer sur les systèmes de fichiers locaux en cas de panne. Pour permettre le basculement, le système de fichiers local doit résider sur des groupes de disques globaux dont les bascules correspondantes sont activées.

Pour plus d'informations sur l'utilisation du type de ressource HAStoragePlus, voir Enabling Highly Available Local File Systems du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

HAStoragePlus vous permet également de synchroniser le démarrage des ressources et des groupes de périphériques de disques dont les ressources dépendent. Pour plus d'informations, voir Ressources, groupes de ressources et types de ressource .

Option de montage Syncdir

Vous pouvez utiliser l'option de montage syncdir pour les systèmes de fichiers de cluster utilisant UFS en tant que système de fichiers sous-jacent. Toutefois, les performances seront sensiblement améliorées si vous ne la spécifiez pas. Si vous la spécifiez, les écritures sont compatibles POSIX. Si vous ne la spécifiez pas, le comportement est identique à celui des systèmes de fichiers NFS. Par exemple, sans syncdir, vous pourriez ne pas détecter de condition d'espace saturé avant de fermer un fichier. Avec syncdir (et le système POSIX), l'insuffisance d'espace disponible est découverte au moment de l'opération d'écriture. Les cas dans lesquels vous risquez d'avoir des problèmes si vous n'indiquez pas syncdir sont rares.

Si vous utilisez un cluster SPARC, VxFS ne dispose pas d'une option de montage équivalente à l'option de montage syncdir du système de fichiers UNIX. VxFS se comporte comme le système de fichiers UNIX lorsque l'option syncdir n'est pas spécifiée.

Pour consulter les questions fréquemment posées sur les périphériques globaux et les systèmes de fichiers de cluster, voir FAQ sur les systèmes de fichiers .

Contrôle de chemin de disque

La version actuelle du logiciel Sun Cluster prend en charge le contrôle de chemin de disque (CCD). Cette rubrique donne des informations théoriques sur le CCD, le démon CCD et les outils d'administration utilisés pour contrôler les chemins d'accès aux disques. Pour plus d'informations sur les procédures de contrôle, de désactivation du contrôle et de vérification du statut des chemins de disques, voir Guide d’administration système de Sun Cluster pour SE Solaris.

Le CCD n'est pas pris en charge sur les nœuds qui exécutent des versions commercialisées avant le logiciel Sun Cluster 3.1 10/03. N'utilisez pas les commandes de CCD au cours d'une mise à niveau progressive. Lorsque tous les nœuds ont été mis à niveau, ils doivent être en ligne pour permettre l'utilisation des commandes de CCD.

Présentation du CCD

Le CCD améliore la fiabilité globale des basculements et commutations en contrôlant la disponibilité du chemin d'accès au disque secondaire. La commande scdpm permet de vérifier la disponibilité du chemin d'accès au disque utilisé par une ressource avant sa commutation. Les options de cette commande vous permettent de contrôler les chemins de disques sur un nœud ou sur tous les nœuds du cluster. Pour plus d'informations sur les options de ligne de commande, voir scdpm(1M).

Les composants CCD sont installés à partir du package SUNWscu. Ce package est installé par la procédure d'installation de Sun Cluster standard. Pour plus d'informations sur l'interface d'installation, voir scinstall(1M). Le tableau suivant décrit l'emplacement d'installation par défaut des composants CCD :

Un démon CCD à multifile tourne sur chaque nœud. Le démon CCD (scdpmd) est lancé par un script rc.d lorsqu'un nœud s'initialise. Si un problème se produit, il est géré par pmfd et relancé automatiquement. La liste présentée ci-dessous décrit le fonctionnement de scdpmd au moment du démarrage initial.

au démarrage, le statut de chaque chemin d'accès au disque est initialisé sur UNKNOWN.

1. Le démon CCD collecte des informations sur les chemins de disques et les noms des nœuds dans le fichier de statut précédent ou dans la base de données CCR. Pour plus d'informations sur le CCR, voir Référentiel de configuration du cluster (CCR) . Une fois le démon CCD lancé, vous pouvez le forcer à lire la liste des disques contrôlés à partir d'un nom de fichier spécifié.

2. Le démon CCD initialise l'interface de communication pour répondre aux requêtes de composants extérieurs au démon, tels que l'interface de ligne de commande.

3. Le démon CCD pingue, toutes les dix minutes, l'état de chaque chemin d'accès aux disques inclus dans la liste contrôlée à l'aide des commandes scsi_inquiry. Chaque entrée est verrouillée pour empêcher l'interface de communication d'accéder au contenu d'une entrée en cours de modification.

4. Le démon CCD envoie une notification à Sun Cluster Event Framework et consigne le nouveau statut du chemin par le biais du mécanisme UNIX syslogd(1M).

Toutes les erreurs associées au démon sont rapportées par pmfd (1M). Toutes les fonctions de l'API renvoient la valeur 0 en cas de succès et -1 en cas d'échec.

Le démon CCD contrôle la disponibilité du chemin d'accès logique visible via plusieurs pilotes à chemins multiples, notamment Sun StorEdge Traffic Manager, HDLM et PowerPath. Les chemins d'accès physiques individuels gérés par ces pilotes ne sont pas contrôlés parce que le pilote multivoie masque les pannes individuelles du démon CCD.

Contrôle de chemins de disques

Cette rubrique présente deux méthodes de contrôle des chemins d'accès aux disques dans le cluster. 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. Elle permet également d'imprimer la liste des disques défectueux et de contrôler les chemins d'accès aux disques à partir d'un fichier.

La seconde méthode consiste à utiliser l'interface utilisateur graphique de SunPlex Manager. SunPlex Manager propose une vue topologique des chemins d'accès aux disques contrôlés dans le cluster. Cette vue est mise à jour toutes les 10 minutes afin de donner des informations sur le nombre de pings ayant échoué. Les informations fournies par l'interface utilisateur graphique de SunPlex doivent être utilisées en conjonction avec la commande scdpm(1M) pour administrer les chemins d'accès aux disques. Pour plus d'informations sur SunPlex Manager, voir Chapitre 10, Administration de Sun Cluster avec les interfaces graphiques du Guide d’administration système de Sun Cluster pour SE Solaris.

Utilisation de la commande scdpm pour contrôler les chemins d'accès aux disques

La commande scdpm(1M) intègre des commandes d'administration CCD vous permettant d'effectuer les tâches suivantes :

• contrôler un nouveau chemin de disque ;

• désactiver le contrôle d'un chemin de disque ;

• relire les données de configuration à partir de la base de données du CCR ;

• lire les disques pour les contrôler ou désactiver le contrôle depuis un fichier spécifié ;

• rapporter le statut d'un chemin ou de tous les chemins d'accès aux disques dans le cluster ;

• imprimer tous les chemins d'accès aux disques accessibles depuis un nœud.

Pour effectuer des tâches d'administration CCD sur le cluster, exécutez la commande scdpm(1M) avec l'argument chemin de disque à partir de n'importe quel nœud actif. Celui-ci est toujours constitué d'un nom de nœud et d'un nom de disque. Le nom de nœud n'est pas obligatoire et la valeur par défaut est all si aucun nom n'est spécifié. Le tableau présenté ci-après décrit les conventions d'attribution de noms applicables aux chemins d'accès aux disques.

l'utilisation du nom de chemin de disque global est fortement recommandé, car il est cohérent dans l'intégralité du cluster. Le nom de chemin de disque UNIX ne l'est pas, le chemin de disque UNIX d'un disque peut varier d'un nœud de cluster à l'autre. Il peut par exemple être c1t0d0 sur un nœud, et c2t0d0 sur un autre. Si vous utilisez des noms de chemins de disques UNIX, utilisez la commande scdidadm -L pour les mapper sur les noms de chemins de disques globaux avant d'utiliser des commandes de CCD. Pour plus d'informations, voir scdidadm(1M).

Utilisation de SunPlex Manager pour contrôler les chemins d'accès aux disques

SunPlex Manager vous permet de réaliser les tâches d'administration CCD de base suivantes :

• contrôler un chemin de disque ;

• désactiver le contrôle d'un chemin de disque ;

• afficher le statut de tous les chemins de disques dans le cluster.

Consultez l'aide en ligne de SunPlex Manager pour de plus amples informations sur la procédure d'administration des chemins de disques avec SunPlex Manager.

Quorum et périphériques de quorum

Cette section comporte les rubriques suivantes :

• À propos des décomptes de votes de quorum

• À propos de la séparation en cas d'échec

• À propos des configurations de quorum

• Respect des contraintes des périphériques de quorum

• Respect des recommandations portant sur les périphériques de quorum

• Configurations de quorum conseillées

• Configurations de quorum atypiques

• Configurations de quorum déconseillées

Pour connaître la liste des périphériques pris en charge comme périphériques de quorum par le logiciel Sun Cluster, contactez votre fournisseur de services Sun.

Comme les nœuds de cluster partagent des données et des ressources, un cluster ne doit jamais être divisé entre des partitions séparées actives simultanément, au risque d'altérer les données. Le moniteur d'appartenance au cluster (MAC) et l'algorithme de quorum garantissent l'exécution d'une instance au plus du même cluster à un moment donné, même si l'interconnexion de cluster est partitionnée.

Pour plus d'informations sur le quorum et le moniteur d'appartenance au cluster, reportez-vous à Appartenance au cluster du Présentation de Sun Cluster pour SE Solaris.

Deux types de problèmes proviennent des partitions de cluster :

• Split brain

• Amnésie

Le Split brain se produit lorsque l'interconnexion de cluster entre les nœuds est perdue et que le cluster se retrouve partitionné en sous-clusters. Chaque partition « croit » être la seule partition, car les nœuds d'une partition ne peuvent pas communiquer avec ceux de l'autre partition.

Une amnésie survient lorsque le cluster redémarre après un arrêt avec des données de configuration antérieures au moment de l'arrêt. Ce problème peut se produire si vous démarrez le cluster sur un nœud qui n'était pas sur la partition de cluster qui fonctionnait en dernier.

Le logiciel Sun Cluster évite les split brain et amnésies en :

• affectant un vote à chaque nœud ;

• mandatant une majorité de votes en faveur d'un cluster opérationnel.

Une partition dotée d'une majorité de votes obtient un quorum et est autorisée à fonctionner. Ce mécanisme de vote majoritaire évite les phénomènes de split brain et d'amnésie lorsque plus de deux nœuds sont configurés au sein d'un cluster. Toutefois, le décompte des votes des nœuds seul n'est pas suffisant lorsque plus de deux nœuds sont configurés dans le cluster. Dans un cluster à deux noeuds, la majorité est deux. Si un tel cluster à deux nœuds est partitionné, un vote externe est nécessaire pour que l'une des partitions obtienne le quorum. Ce vote externe est alors fourni par un périphérique de quorum.

À propos des décomptes de votes de quorum

Utilisez la commande scstat -q pour déterminer les informations suivantes :

• Nombre total de votes configurés

• Votes présents actuels

• Votes requis pour le quorum

Pour plus d'informations sur cette commande, reportez-vous à scstat(1M).

Les nœuds comme les périphériques de quorum apportent leurs votes au cluster afin de constituer le quorum.

Un nœud apporte ses votes en fonction de son état :

• Un nœud apporte un vote lorsqu'il est initialisé et devient membre du cluster.

• Un nœud apporte zéro vote lors de son installation.

• Un nœud apporte zéro vote lorsqu'un administrateur système place le nœud à l'état de maintenance.

Les périphériques de quorum apportent des votes en fonction du nombre de votes qui leur sont connectés. Lorsque vous configurez un périphérique de quorum, le logiciel Sun Cluster lui affecte un décompte de votes de N-1, où N correspond au 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).

Un périphérique de quorum apporte son vote si l'une des deux conditions suivantes est vérifiée :

• L'un des nœuds au moins auquel le périphérique de quorum est connecté est membre du cluster.

• L'un des nœuds au moins auquel le périphérique de quorum est connecté est en cours d'initialisation et ce nœud était membre de la dernière partition de cluster ayant possédé le périphérique de quorum.

Vous pouvez configurer les périphériques de quorum pendant l'installation du cluster ou ultérieurement, à l'aide des procédures décrites dans le Chapitre 5, Administration du quorum du Guide d’administration système de Sun Cluster pour SE Solaris.

À propos de la 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 » être seul propriétaire des disques multihôtes et à en posséder l'accès. Si plusieurs nœuds tentent d'écrire sur les disques, les données peuvent être endommagées.

La séparation en cas d'échec limite l'accès des nœuds aux périphériques multihôtes en les empêchant physiquement 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.

Les services des périphériques de disques intègrent des capacités de basculement pour les services utilisant des périphériques multihôtes. Si un membre de cluster, actuellement membre principal (propriétaire) du groupe de périphériques de disques échoue ou est inaccessible, un nouveau nœud principal est choisi. Ce nouveau nœud permet d'accéder au groupe de périphériques de disques pour poursuivre en n'étant soumis qu'à des interruptions mineures. Pendant ce processus, l'ancien nœud principal doit perdre l'accès aux périphériques pour que le nouveau nœud principal puisse être démarré. Toutefois, lorsqu'un membre se détache du cluster et n'est plus joignable, le cluster ne peut pas informer ce nœud de libérer les périphériques dont il était le nœud principal. Il faut donc trouver un moyen de permettre aux membres survivants d'accéder aux périphériques globaux et d'en prendre le contrôle à la place des membres défectueux.

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 périphériques multihôtes, pour les empêcher d'accéder à ces disques.

Les réservations de disques SCSI-2 prennent en charge une forme de réservations qui octroie l'accès à tous les nœuds liés au disque (en cas d'absence de réservation) ou à un seul nœud (celui qui détient la réservation).

Lorsqu'un membre détecte qu'un autre noeud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le noeud 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.

Si un nœud est détecté comme n'étant plus membre de cluster, une réservation SCSI est déclenchée sur tous les disques partagés entre ce nœud et les autres. Le nœud séparé risque de ne pas « savoir » qu'il est en cours de séparation et s'il essaie d'accéder à l'un des disques partagés, il détectera la réservation et s'emballera.

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

On appelle failfast le mécanisme par le biais duquel la structure du cluster s'assure qu'un nœud défectueux ne peut pas redémarrer et commencer à écrire dans le stockage partagé.

Les nœuds membres du cluster activent en permanence un ioctl spécifique, MHIOCENFAILFAST, pour les disques auxquels ils ont accès, notamment les disques de quorum. Cet ioctl est une directive adressée au pilote de disque. Il permet à un nœud de paniquer s'il ne peut pas accéder à un disque réservé par un autre nœud.

L'ioctl MHIOCENFAILFAST provoque la vérification par le pilote de l'erreur renvoyée par toutes les lectures et écritures d'un nœud sur le disque s'il s'agit du code d'erreur Reservation_Conflict . À l'arrière-plan, l'ioctl teste régulièrement le disque pour rechercher le code d'erreur Reservation_Conflict. Les chemins de flux de contrôle au premier plan et à l'arrière-plan paniquent si le code Reservation_Conflict est renvoyé.

Pour les disques SCSI-2, les réservations ne sont pas persistantes ; elles ne survivent pas aux réinitialisations des nœuds. Pour les disques SCSI-3 dotés de la fonction PGR (réservation de groupe persistante), les informations de réservation sont stockées sur le disque et persistent après réinitialisation des noeuds. Le mécanisme failfast fonctionne de la même façon, que vous ayez des disques SCSI-2 ou SCSI-3.

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. Un autre noeud faisant partie de la partition pouvant atteindre le quorum effectue des réservations sur les disques partagés. Si le nœud qui ne possède pas de quorum essaie d'accéder aux disques partagés, il reçoit un conflit de réservation et panique du fait du mécanisme failfast.

Après la panique, le noeud peut soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBoot^TM (OBP) si le cluster est constitué de systèmes SPARC. L'action entreprise est déterminée par la définition du paramètre auto-boot?. Vous pouvez définir auto-boot? sur eeprom(1M), à l'invite ok de la PROM OpenBoot dans un cluster SPARC. Vous pouvez également configurer ce paramètre avec l'utilitaire SCSI que vous pouvez exécuter après le démarrage du BIOS dans un cluster x86.

À propos des configurations de quorum

La liste suivante présente des faits concernant les configurations de quorum :

• Les périphériques de quorum peuvent contenir des données utilisateur.

• Dans une configuration N+1, où les périphériques de quorum N sont chacun connectés à l'un des 1 par le biais des nœuds N et du nœud N+1, le cluster survit à la mort de tous les 1 par le biais des nœuds N ou de l'un des nœuds N/2. Cette disponibilité suppose que le périphérique de quorum fonctionne correctement.

• Dans une configuration N-nœud où un seul périphérique de quorum se connecte à tous les nœuds, le cluster peut survivre à la mort d'un des nœuds N-1. Cette disponibilité suppose que le périphérique de quorum fonctionne correctement.

• Dans une configuration à N nœuds où un périphérique de quorum unique se connecte à tous les nœuds, le cluster peut survivre à la défaillance du périphérique de quorum si tous les nœuds du cluster sont disponibles.

Pour consulter les exemples de configurations de quorum à éviter, voir Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, voir Configurations de quorum conseillées .

Respect des contraintes des périphériques de quorum

Vous devez respecter les conditions requises suivantes. Si vous ignorez ces conditions, vous risquez de compromettre la disponibilité du cluster.

• Vérifiez que le logiciel Sun Cluster prend en charge votre périphérique comme périphérique de quorum.

  ---

  Remarque –

  Pour connaître la liste des périphériques pris en charge comme périphériques de quorum par le logiciel Sun Cluster, contactez votre fournisseur de services Sun.

  ---

  Le logiciel Sun Cluster prend en charge deux types de périphérique de quorum :

  • Les disques partagés multihôtes prenant en charge les réservations PGR SCSI-3.

  • Les disques partagés à deux hôtes prenant en charge les réservations SCSI-2.

• Dans une configuration à deux nœuds, vous devez configurer au moins un périphérique de quorum pour garantir qu'un nœud unique puisse continuer en cas de défaillance de l'autre nœud. Reportez-vous à la Figure 3–2.

Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, voir Configurations de quorum conseillées .

Respect des recommandations portant sur les périphériques de quorum

Utilisez les informations suivantes pour évaluer la configuration de quorum la mieux adaptée à votre topologie :

• Disposez-vous d'un périphérique pouvant être connecté à tous les nœuds du cluster ?

  • Si oui, configurez ce périphérique comme périphérique de quorum unique. Vous n'êtes pas tenu de configurer un autre périphérique de quorum, car votre configuration est optimale.

    ---

    Attention –

    Si vous ne tenez pas compte de ce conseil et ajoutez un autre périphérique de quorum, ce dernier va réduire la disponibilité de votre cluster.

    ---

  • Sinon, configurez votre ou vos périphériques sur deux ports.

• Assurez-vous que le nombre total de votes apportés par les périphériques de quorum est strictement inférieur au nombre de votes apportés par les nœuds. Sinon, vos nœuds ne pourraient pas constituer un cluster en cas d'indisponibilité de tous les disques, et ce même si tous les nœuds fonctionnent.

  ---

  Remarque –

  Dans certains environnements, vous pouvez réduire la disponibilité globale du cluster en fonction de vos besoins. Dans ces cas-là, vous pouvez ignorer les techniques habituelles préconisées. Soyez conscient toutefois que le non-respect de cette technique conseillée réduit la disponibilité globale. Par exemple, dans la configuration indiquée dans Configurations de quorum atypiques , le cluster est moins disponible : Les votes du quorum excèdent les votes des nœuds. Si l'accès au stockage partagé entre Nodes A et Node B est perdu, tout le cluster échoue.

  ---

  Pour consulter l'exception à cette recommandation, voir Configurations de quorum atypiques .

• Spécifiez un périphérique de quorum entre chaque paire de nœuds partageant l'accès au périphérique de stockage. Cette configuration de quorum accélère le processus de séparation en cas d'échec. Voir Quorum dans les configurations supérieures à deux nœuds .

• En général, si l'ajout d'un périphérique de quorum permet de rendre pair le nombre de votes, la disponibilité globale du cluster diminue.

• Les périphériques de quorum ralentissement légèrement les reconfigurations suite à l'arrivée ou à la mort d'un nœud. Limitez donc l'ajout de périphériques de quorum au strict minimum.

Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, reportez-vous à Configurations de quorum conseillées .

Configurations de quorum conseillées

Cette section indique des exemples de configurations de quorum conseillées. Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées .

Quorum dans les configurations à deux nœuds

Deux votes de quorum sont nécessaires pour la formation d'un cluster à deux nœuds. Ces deux votes peuvent dériver des deux nœuds de cluster ou d'un seul nœud et d'un périphérique de quorum.

Figure 3–2 Configuration à deux nœuds

Quorum dans les configurations supérieures à deux nœuds

Vous pouvez configurer un cluster supérieur à deux nœuds sans périphérique de quorum. Cependant, si vous procédez ainsi, vous ne pouvez pas démarrer le cluster sans une majorité de nœuds dans le cluster.

Configurations de quorum atypiques

La Figure 3–3 suppose que vous exécutez des applications stratégiques (une base de données Oracle, par exemple) sur Node A et Node B. Si le nœud A et le nœud B sont indisponibles et ne peuvent accéder aux données partagées, vous pouvez souhaiter la mise hors service totale du cluster. Sinon, cette configuration n'est pas véritablement optimale car elle n'offre pas la meilleure disponibilité.

Pour plus d'informations sur la recommandation à laquelle cette exception est liée, voir Respect des recommandations portant sur les périphériques de quorum .

Figure 3–3 Configuration atypique

Configurations de quorum déconseillées

Cette section donne des exemples de configurations de quorum à éviter. Pour consulter les exemples de configurations de quorum conseillées, reportez-vous à Configurations de quorum conseillées .

Services de données

Le terme service de données décrit une application telle qu'Oracle ou Sun Java System Web Server, configurée pour fonctionner sur un cluster plutôt que sur un seul serveur. Un service de données se compose d'une application, de fichiers de configuration Sun Cluster spécialisés et de méthodes de gestion Sun Cluster contrôlant les actions suivantes de l'application :

• Début

• Arrêter

• le contrôle et la prise de mesures correctives.

Pour plus d'informations sur les types de services de données, voir Services de données du Présentation de Sun Cluster pour SE Solaris.

La Figure 3–4 compare une application s'exécutant sur un seul serveur d'applications (modèle de serveur unique) à la même application s'exécutant sur un cluster (modèle de serveur clusterisé). La seule différence entre les deux configurations réside dans le fait que l'application clusterisée peut s'exécuter plus rapidement et avec un niveau supérieur de disponibilité.

Figure 3–4 Configuration client-serveur standard et configuration client-serveur clusterisée

Dans le modèle de serveur unique, vous configurez l'application pour accéder au serveur par le biais d'une interface de réseau public particulier (un nom d'hôte). Le nom d'hôte est associé à ce serveur physique.

Dans le modèle de serveur clusterisé, l'interface de réseau public est un nom d'hôte logique ou une adresse partagée. Le terme ressources réseau se rapporte à la fois aux noms d'hôtes logiques et aux adresses partagées.

Certains services de données nécessitent que vous indiquiez des noms d'hôtes logiques ou des adresses partagées comme interfaces réseau. Les noms d'hôtes logiques et les adresses partagées ne sont pas interchangeables. D'autres services de données vous permettent de spécifier les noms d'hôtes logiques comme les adresses partagées. Pour plus d'informations sur le type d'interface que vous devez spécifier, reportez-vous à l'installation et à la configuration de chaque service de données.

Une ressource réseau n'est pas associée à un serveur physique particulier. Elle peut migrer entre des serveurs physiques.

Une ressource réseau est initialement associée à un nœud, le nœud principal. En cas de panne du nœud principal, la ressource réseau et la ressource d'application basculent sur un autre nœud du cluster (un nœud secondaire). Lorsque la ressource réseau bascule, la ressource d'application continue de fonctionner sur le nœud secondaire après un bref laps de temps.

La Figure 3–5 compare le modèle de serveur unique au modèle de serveur clusterisé. Notez que dans le modèle de serveur clusterisé, une ressource réseau (nom d'hôte logique dans cet exemple) peut se déplacer entre plusieurs nœuds du cluster. L'application est configurée pour utiliser ce nom d'hôte logique à la place d'un nom d'hôte associé à un serveur particulier.

Figure 3–5 Nom d'hôte fixe et nom d'hôte logique

Une adresse partagée est également associée initialement à un nœud. Ce nœud s'appelle le nœud d'interface globale. Une adresse partagée (également appelée interface globale) est utilisée comme interface de réseau unique sur le cluster.

Le modèle de nom d'hôte logique et le modèle de service évolutif diffèrent, car dans ce dernier, chaque nœud dispose également de l'adresse partagée, configurée de manière active dans son interface de loopback. Cette configuration permet à plusieurs instances d'un service de données de s'activer simultanément sur plusieurs nœuds. Le terme « service évolutif » signifie que vous pouvez augmenter la puissance de calcul de l'application en ajoutant des nœuds de cluster supplémentaires afin d'améliorer les performances.

En cas d'échec du nœud d'interface globale, l'adresse partagée peut être démarrée sur un autre nœud où tourne aussi une instance de l'application (faisant ainsi de cet autre nœud le nouveau nœud d'interface globale). L'adresse partagée peut également basculer sur un autre nœud du cluster n'ayant pas exécuté l'application auparavant.

La Figure 3–6 compare la configuration à serveur unique à la configuration de service évolutif clusterisé. Notez que dans la configuration service évolutif, l'adresse partagée est présente sur tous les nœuds. De la même façon qu'un nom d'hôte logique est utilisé dans un service de données à basculement, l'application est configurée pour utiliser cette adresse partagée à la place d'un nom d'hôte associé à un serveur particulier.

Figure 3–6 Nom d'hôte fixe et adresse partagée

Méthodes des services de données

Le logiciel Sun Cluster intègre un ensemble de méthodes de gestion de services. Ces méthodes s'exécutent sous le contrôle du produit Gestionnaire du groupe de ressources (RGM), qui les utilise pour démarrer, arrêter et contrôler l'application sur les nœuds du cluster. Ces méthodes, avec les logiciels de cluster et les périphériques multihôtes, permettent aux applications de devenir des services de données évolutifs ou de basculement.

Le gestionnaire du groupe de ressources (RGM) gère aussi les ressources du cluster, notamment les instances d'une application et les ressources réseau (noms d'hôtes logiques et adresses partagées).

Outre les méthodes du logiciel Sun Cluster, le système Sun Cluster fournit également une API et plusieurs outils de développement de services de données. Ces outils permettent aux développeurs d'applications de développer les méthodes de services de données nécessaires à l'exécution d'autres applications en tant que services de données hautement disponibles avec le logiciel Sun Cluster.

Services de données de basculement

Si le nœud sur lequel le service de données fonctionne (nœud principal) échoue, le service est déplacé vers un autre nœud opérationnel sans intervention de l'utilisateur. 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.

Avec les services de données, les instances d'application ne tournent que sur un seul nœud. Si le détecteur de pannes détecte une panne, il essaie de redémarrer l'instance sur un même nœud ou de la lancer sur un autre nœud (basculement). Le résultat dépend de la configuration du service de données.

Services de données évolutifs

Le service de données évolutif permet d'avoir des instances fonctionnant sur plusieurs nœuds. Les services évolutifs utilisent les deux groupes de ressources suivants :

• un groupe de ressources évolutif, qui contient les ressources d'applications ;

• un groupe de ressources de basculement, qui contient les ressources réseau (adresses partagées) dont dépend le service évolutif.

Le groupe de ressources évolutif peut être connecté à plusieurs nœuds, 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 nœuds hébergeant un service évolutif utilisent la même adresse partagée pour héberger le service.

Les demandes de service entrent dans le cluster par le biais de l'interface de réseau unique (interface globale). Ces demandes sont ensuite distribuées aux nœuds, en fonction d'un des algorithmes prédéfinis définis par la règle d'équilibrage de charge. Le cluster peut utiliser cette règle pour équilibrer la charge de service entre plusieurs nœuds. Plusieurs interfaces globales peuvent exister sur différents nœuds qui hébergent d'autres adresses partagées.

Avec les services évolutifs, les instances d'application tournent sur plusieurs nœuds en même temps. Si le nœud hébergeant l'interface globale échoue, celle-ci bascule sur un autre nœud. Si une instance d'application en cours d'exécution échoue, elle essaie de redémarrer sur le même nœud.

S'il lui est impossible de redémarrer sur le même nœud et qu'un autre nœud non utilisé est configuré pour exécuter le service, celui-ci bascule sur le nœud non utilisé. Faute de quoi, le service continue de s'exécuter sur les nœuds restants, ce qui peut provoquer une dégradation de ses capacités de traitement.

l'état TCP de chaque instance d'application est conservé sur le nœud contenant l'instance et non sur le nœud d'interface globale. Ainsi, l'échec du nœud d'interface globale n'a pas d'incidence sur la connexion.

La Figure 3–7 affiche un exemple de groupe de ressources de basculement et de groupes de ressources évolutifs ainsi que les dépendances qui existent entre eux pour les services évolutifs. Cet exemple présente trois groupes de ressources. Le groupe de ressources de basculement contient les ressources d'applications des serveurs DNS à haute disponibilité et les ressources réseau utilisées à la fois par les serveurs DNS à haute disponibilité et les serveurs Web Apache à haute disponibilité (disponibles uniquement sur les clusters SPARC). Les groupes de ressources évolutifs ne contiennent que les instances d'application du serveur Web Apache. Notez que des dépendances de groupes de ressources existent entre les groupes de ressources évolutifs et de basculement (lignes pleines). Par ailleurs, toutes les ressources de l'application Apache dépendent de la ressource réseau schost-2, qui est une adresse partagée (pointillés).

Figure 3–7 SPARC : exemple de groupe de ressources évolutif et de basculement

Règles d'équilibrage de la charge

L'équilibrage de la charge permet d'améliorer les performances du service évolutif, tant en matière de temps de réponse que de rendement. Il existe deux classes de services de données évolutifs.

• Pur

• Sticky

Un service pur est à même de faire répondre l'une de ses instances aux demandes d'un client. Un service sticky est à même de demander à un client d'envoyer des demandes à la même instance. Ces dernières ne sont pas redirigées vers d'autres instances.

Un service pur utilise une règle d'équilibrage de la charge pondérée. Sous cette règle, les requêtes du client sont réparties de manière uniforme entre les instances de serveur du cluster. Supposons par exemple que chaque nœud d'un cluster à trois nœuds ait un poids de 1. Chaque nœud traitera 1/3 des demandes d'un client pour le compte de ce service. L'administrateur peut à tout moment changer les poids par le biais de l'interface de contrôle scrgadm(1M) ou de l'interface utilisateur graphique de Gestionnaire SunPlex.

Il existe deux types de services sticky : sticky ordinaire et sticky joker. Les services sticky permettent à plusieurs sessions d'application simultanées utilisant plusieurs connexions TCP de partager la mémoire d'état (état de la session d'application).

Les services sticky ordinaires permettent à un client de partager l'état entre plusieurs connexions TCP simultanées. Le client est dit « sticky » envers l'instance du serveur écoutant sur un port unique. Le client a la garantie que toutes ses requêtes vont vers la même instance de serveur, sous réserve que cette instance soit active et accessible et que la règle d'équilibrage de la charge ne soit pas modifiée alors que le service est en ligne.

Par exemple, un navigateur Web du client se connecte à une adresse IP partagée sur le port 80 à l'aide de trois connexions TCP différentes. Toutefois, les connexions échangent, au niveau du service, les informations de session mises en cache.

Une généralisation d'une règle sticky s'étend à plusieurs services évolutifs qui échangent des informations de session à l'arrière-plan et au niveau de la même instance. Le cas échéant, le client est dit « sticky » envers plusieurs instances de serveur sur le même nœud écoutant des ports différents.

Prenons l'exemple d'un client sur un site d'e-commerce, qui remplit son panier d'achat en utilisant le protocole HTTP sur le port 80. Le client bascule ensuite sur le protocole SSL sur le port 443 pour envoyer des données sécurisées afin de payer par carte de crédit les articles contenus dans le panier.

Les services sticky joker utilisent des numéros de port assignés de manière dynamique, mais attendent toujours des demandes du client qu'elles se dirigent vers le même nœud. Le client est dit « sticky joker » sur les ports qui ont la même adresse IP.

Un bon exemple de cette règle est le protocole FTP en mode passif. Par exemple, un client se connecte à un serveur FTP sur le port 21. Le serveur demande ensuite au client de se reconnecter à un serveur de ports d'écoute dans la plage des ports dynamiques. Toutes les demandes relatives à cette adresse IP sont transférées sur le même nœud par le biais duquel le serveur a informé le client des informations de contrôle.

La règle d'équilibrage de charge pondérée est appliquée par défaut pour chacune de ces règles sticky. Ainsi la requête initiale d'un client est dirigée vers l'instance imposée par l'équilibreur de charge. Une fois que le client a établi une affinité pour le nœud sur lequel l'instance s'exécute, les demandes futures sont dirigées sous conditions vers cette instance. Le nœud doit être accessible et la règle d'équilibrage de charge ne doit pas avoir été modifiée.

D'autres informations sur les règles d'équilibrage de charge spécifiques sont indiquées ci-dessous.

• Pondérée. La charge est répartie entre les différents nœuds en fonction de valeurs spécifiées. Cette règle est définie via l'utilisation de la valeur LB_WEIGHTED pour la propriété Load_balancing_weights. Si la charge d'un nœud n'est pas explicitement définie, elle sera par défaut égale à 1.

  La règle pondérée redirige un certain pourcentage du trafic provenant des clients vers un nœud particulier. Soit X=le poids et A=le total des poids de tous les nœuds actifs : un nœud actif peut s'attendre qu'environ X/A de toutes les nouvelles connexions soient dirigées vers lui. Toutefois, le nombre total de connexions doit être suffisamment important. Cette règle ne s'applique pas à des requêtes individuelles.

  Notez qu'elle ne fonctionne pas à tour de rôle. Si on utilisait une règle à tour de rôle (circulaire), chaque demande d'un client irait toujours vers un nœud différent. Par exemple, la première demande irait vers le nœud 1, la seconde, vers le nœud 2, etc.

• Sticky. Avec cette règle, le jeu de ports est connu au moment de la configuration des ressources d'application. Cette règle est définie via l'utilisation de la valeur LB_STICKY pour la propriété de ressource Load_balancing_policy.

• Sticky joker. Cette règle est un sur-ensemble de la règle « sticky » ordinaire. S'il s'agit d'un service évolutif identifié par l'adresse IP, les ports sont assignés par le serveur (et ne sont pas connus à l'avance). Les ports peuvent varier. Cette règle est définie via l'utilisation de la valeur LB_STICKY_WILD pour la propriété de ressource Load_balancing_policy.

Paramètres de rétablissement

Les groupes de ressources basculent d'un nœud sur un autre. Le cas échéant, le nœud secondaire d'origine devient le nouveau nœud principal. Les paramètres de rétablissement spécifient les actions qui se produisent lorsque le nœud principal d'origine est de nouveau en ligne. Vous pouvez soit autoriser le nœud principal d'origine à reprendre son rôle (rétablissement), soit permettre au nœud principal actuel de rester. Spécifiez l'option souhaitée en utilisant le paramètre de propriété du groupe de ressources Failback.

Si le nœud d'origine qui héberge le groupe de ressources est défectueux et redémarre sans arrêt, ce rétablissement peut réduire la disponibilité du groupe de ressources.

Détecteurs de pannes 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(s) démon(s) de l'application fonctionnent et que les clients sont servis. En fonction des informations renvoyé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.

Développement de nouveaux services de données

Sun propose des fichiers de configuration et des modèles de méthodes de gestion vous permettant de faire fonctionner différentes applications comme service évolutif ou de basculement au sein d'un cluster. Si Sun ne propose pas l'application que vous voulez exécuter en tant que service de basculement ou évolutif, vous avez une autre solution. Utilisez une API Sun Cluster ou l'API DSET pour configurer l'application à exécuter en tant que service de basculement ou service évolutif. Cependant, les applications ne peuvent pas toutes devenir un service évolutif.

Caractéristiques des services évolutifs

Un ensemble de critères détermine si une application peut devenir un service évolutif. Pour déterminer si c'est le cas de la vôtre, reportez-vous à la section Analyse du caractère approprié de l’application du Guide du développeur de services de données Sun Cluster pour SE Solaris. Cet ensemble de critères est résumé ci-dessous.

• Tout d'abord, un tel service est composé d'une ou de plusieurs instances de serveur. Chaque instance tourne sur un nœud différent du cluster et plusieurs instances du même service ne peuvent pas fonctionner sur le même nœud.

• Si le service fournit un magasin de données logique externe, vous devez être prudent. Vous devez synchroniser les accès simultanés à ce magasin depuis plusieurs instances de serveur pour éviter de perdre des mises à jour ou de lire des données en cours de modification. Notez l'utilisation du terme « externe » pour que ce magasin ne soit pas considéré comme en mémoire. Le terme « logique » indique que ce magasin s'affiche en tant qu'entité unique, bien qu'il puisse être répliqué. En outre, à chaque fois qu'une instance de serveur met à jour ce magasin de données logique, les autres instances peuvent immédiatement « voir » cette mise à jour.

  Le système Sun Cluster propose un stockage externe de ce type par le biais de son système de fichiers de cluster et de ses partitions brutes globales. Supposons par exemple qu'un service écrive des données sur un fichier journal externe ou qu'il modifie les données en place. Si plusieurs instances de ce service s'exécutent, chacune a accès à ce journal externe, auquel elles peuvent accéder simultanément. Les instances doivent alors synchroniser leur accès pour éviter toute interférence entre elles. Le service peut utiliser le verrouillage de fichier ordinaire Solaris via fcntl(2) et lockf(3C) pour obtenir la synchronisation souhaitée.

  Un autre exemple de ce type de magasin est une base de données d'arrière-plan, notamment la base de données Oracle Real Application Clusters Guard à haute disponibilité pour les clusters SPARC ou Oracle. Ce type de serveur de base de données d'arrière-plan propose une synchronisation intégrée en utilisant des requêtes de base de données ou des transactions de mise à jour. Ainsi, plusieurs instances de serveur n'ont pas besoin d'implémenter leur propre synchronisation.

  Le serveur Sun IMAP est un exemple de service non évolutif. Le service met à jour une mémoire, mais cette mémoire est privée et lorsque les instances IMAP écrivent dans cette mémoire, elles s'écrasent mutuellement parce que les mises à jour ne sont pas synchronisées. Le serveur IMAP doit être récrit pour synchroniser les accès simultanés.

• Pour finir, notez que les instances peuvent disposer de données privées disjointes de celles des autres instances. Dans un tel cas, le service n'a pas besoin d'accès simultané synchronisé, car les données sont privées : seule l'instance en question peut les manipuler. Dans ce cas, vous devez veiller à ne pas stocker ces données privées dans le système de fichiers de cluster, car ces données seront alors globalement accessibles.

API de services de données et API de bibliothèque de développement de service de données

Pour rendre les applications hautement disponibles, le système Sun Cluster fournit les éléments suivants :

• des services de données fournis dans le cadre du système Sun Cluster ;

• une API (interface de programme d'application) de services de données ;

• une API de bibliothèque de développement pour les services de données ;

• un service de données « générique ».

Le guide Sun Cluster Data Services Planning and Administration Guide for Solaris OS explique comment installer et configurer les services de données du système Sun Cluster. La collection de logiciels Sun Cluster 3.1 9/04 pour Solaris (Édition pour plate-forme SPARC) explique comment instrumenter d'autres applications pour qu'elles aient un haut niveau de disponibilité dans la structure Sun Cluster.

Les API Sun Cluster permettent aux développeurs d'applications de développer des détecteurs de pannes et des scripts qui démarrent et arrêtent les instances de services de données. Grâce à ces outils, une application peut être implémentée comme service de basculement ou service de données évolutif. Le système Sun Cluster propose un service de données « générique ». Utilisez-le pour générer rapidement les méthodes de démarrage et d'arrêt d'application requises et pour implémenter le service de données comme service de basculement ou service évolutif.

Utilisation de l'interconnexion de cluster pour le trafic de services de données

Un cluster doit avoir de multiples connexions réseau entre les nœuds pour former une interconnexion de cluster. Le logiciel Sun Cluster utilise plusieurs interconnexions pour atteindre les objectifs suivants :

• haute disponiblité ;

• performances améliorées.

Pour le trafic interne, notamment les données des systèmes de fichiers ou celles des services évolutifs, les messages sont agrégés sur toutes les interconnexions disponibles à tour de rôle. L'interconnexion de cluster est également mise à la disposition des applications pour garantir une communication hautement disponible entre les nœuds. Par exemple, une application répartie peut avoir des composants exécutés sur différents nœuds et ayant besoin de communiquer entre eux. En utilisant l'interconnexion de cluster plutôt que le transport public, ces connexions peuvent résister à l'échec d'un lien individuel.

Pour utiliser l'interconnexion de cluster dans le cadre des communications entre les nœuds, l'application doit adopter les noms d'hôtes privés que vous avez configurés lors de l'installation de Sun Cluster. Par exemple, si le nom d'hôte privé du nœud 1 est clusternode1-priv , utilisez ce nom pour communiquer sur l'interconnexion de cluster vers le nœud 1 (node 1). Les sockets TCP ouverts à l'aide de ce nom sont dirigés vers l'interconnexion de cluster et peuvent être redirigés de manière transparente en cas de panne du réseau.

Comme vous pouvez configurer les noms d'hôtes privés pendant l'installation de Sun Cluster, l'interconnexion de cluster utilise le nom que vous avez choisi à ce moment-là. Pour identifier le nom réel, utilisez la commande scha_cluster_get(3HA) avec l'argument scha_privatelink_hostname_node.

Les communications d'applications et les communications de cluster interne sont agrégées sur toutes les interconnexions. Comme les applications partagent l'interconnexion de cluster avec le trafic de cluster interne, la bande passante disponible pour les applications dépend de celle qui est utilisée par le reste du trafic de cluster. En cas de panne, le trafic interne et le trafic d'applications s'agrègent sur toutes les interconnexions disponibles.

Une adresse fixe est également assignée à chaque nœud. Cette adresse est transférée sur le pilote clprivnet. L'adresse IP effectue la correspondance avec le nom d'hôte privé du nœud : clusternode1-priv. Pour plus d'informations sur le pilote de réseau privé de Sun Cluster, consultez la page de manuel se référant à clprivnet(7).

Si votre application nécessite des adresses IP cohérentes sur tous les points, configurez l'application à lier à l'adresse par nœud, tant sur le client que sur le serveur. Toutes les connexions semblent alors provenir de cette adresse et y retourner.

Ressources, groupes de ressources et types de ressource

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

Les services de données sont des types de ressource. 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.

Une ressource est une instanciation d'un type de ressource défini au niveau du cluster. Plusieurs types de ressource sont définis.

Les ressources réseau sont des types de ressource SUNW.LogicalHostname ou SUNW.SharedAddress. Ces deux types de ressource sont pré-enregistrés dans le logiciel Sun Cluster.

Les types de ressource HAStorage et HAStoragePlus servent à synchroniser le démarrage des ressources et des groupes de périphériques de disques dont les ressources dépendent. Avant le démarrage d'un service de données, ils garantissent la disponibilité des chemins d'accès aux points de montage d'un système de fichiers de cluster, aux périphériques globaux et aux noms des groupes de périphériques. Pour plus d'informations, reportez-vous à « Synchronisation des démarrages entre les groupes de ressources et les groupes de périphériques de disques », du Guide d'installation et de configuration des services de données. Le type de ressource HAStoragePlus est désormais disponible dans Sun Cluster 3.0 5/02 et lui confère une autre fonctionnalité en optimisant la disponibilité des systèmes de fichiers locaux. Pour plus d'informations sur cette fonctionnalité, voir Type de ressource HAStoragePlus .

Les ressources gérées par le RGM sont placées dans des groupes, appelés groupes de ressources, afin de pouvoir être gérées en tant qu'unité. Si une commutation ou un basculement est initié sur un groupe de ressources, ce dernier se transforme en unité.

Si vous activez un groupe de ressources qui contient des ressources d'applications en ligne, l'application est lancée. La méthode de démarrage des services de données attend l'exécution de l'application avant de se fermer. La méthode permettant de définir à quel moment l'application est opérationnelle est identique à la méthode utilisée par le contrôleur de panne pour déterminer si un service de données est en train de servir des clients. Pour plus d'informations sur ce processus, voir Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Gestionnaire du groupe de ressources (RGM)

Le gestionnaire du groupe de ressources (RGM) contrôle les services de données (applications) comme des ressources gérées par des implémentations de type de ressource. Ces implémentations peuvent être fournies par Sun ou créées par un développeur à l'aide d'un modèle de service de données générique, l'API de la bibliothèque de développement d'un service de données (API BDSD) ou l'API de la gestion de ressources (API GR). L'administrateur du cluster crée et gère les ressources dans des conteneurs appelés groupes de ressources. Le RGM arrête et démarre les groupes de ressources des nœuds sélectionnés en réponse aux modifications des membres du cluster.

Le RGM agit sur les ressources et les groupes de ressources. Les actions du RGM peuvent faire passer les ressources et les groupes de ressources de l'état en ligne à l'état hors ligne et inversement. La section États et paramètres des ressources et des groupes de ressources décrit en détail les états et les paramètres qui peuvent être appliqués aux ressources et aux groupes de ressources.

Pour plus d'informations sur le lancement de projets Solaris sous le contrôle du RGM, voir Configuration d'un projet de services de données .

États et paramètres des ressources et des groupes de ressources

Un administrateur applique des paramètres statiques aux ressources et groupes de ressources. Ces paramètres ne peuvent être modifiés qu'à travers des actions d'administration. Le RGM déplace les groupes de ressources entre les « états » dynamiques décrits ci-après.

• Gérés ou non gérés : ces paramètres s'appliquent uniquement aux groupes de ressources d'un cluster. Les groupes de ressources sont gérés par le RGM. La commande scrgadm(1M) permet de gérer un groupe de ressources( ou de désactiver cette gestion) via le RGM. Ces paramètres ne changent pas après une reconfiguration du cluster.

  Au moment de sa création, un groupe de ressources n'est pas géré. Il doit l'être pour que ses ressources puissent devenir actives.

  Dans certains services de données, par exemple un serveur Web évolutif, des tâches doivent être effectuées avant le démarrage des ressources réseau et après leur arrêt. Ces tâches s'accomplissent par le biais des méthodes initialisation (INIT) et fin (FINI) des services de données. Les méthodes INIT ne fonctionnent que si le groupe de ressources dans lequel réside les ressources est à l'état « géré ».

  Lorsqu'un groupe de ressources passe de l'état « non géré » à « géré », toutes les méthodes INIT enregistrées pour le groupe sont exécutées sur les ressources du groupe.

  Lorsqu'un groupe de ressources passe de l'état « géré » à « non géré », toutes les méthodes FINI enregistrées sont appelées pour procéder à un nettoyage.

  Les méthodes INIT et FINI sont utilisées le plus couramment pour les ressources réseau des services évolutifs. Toutefois, vous pouvez les utiliser pour des tâches d'initialisation et de nettoyage qui ne sont pas effectuées par l'application.

• Activé ou désactivé : ces paramètres s'appliquent aux ressources d'un cluster. La commande scrgadm(1M) permet d'activer ou de désactiver une ressource. Ces paramètres ne changent pas après une reconfiguration du cluster.

  Une ressource est normalement activée et fonctionne dans le système.

  Si vous souhaitez supprimer la disponibilité de la ressource sur tous les nœuds de cluster, désactivez la ressource. Un ressource désactivée devient inutilisable.

• En ligne ou hors ligne : états dynamiques s'appliquant tant aux ressources qu'aux groupes de ressources.

  Ces états changent lorsque le cluster est reconfiguré lors d'un basculement ou d'une commutation. Vous pouvez également les modifier par le biais d'actions administratives. Utilisez la commande scswitch(1M) pour changer l'état en ligne ou hors ligne d'une ressource ou d'un groupe de ressources.

  Une ressource de basculement ou un groupe de ressources ne peuvent être connectés qu'à un seul nœud à la fois. Une ressource évolutive ou un groupe de ressources peuvent être en ligne sur certains nœuds et hors ligne sur d'autres. Durant une commutation ou un basculement, les groupes de ressources et les ressources qu'ils contiennent sont déconnectés d'un nœud puis reconnectés à un autre nœud.

  Si un groupe de ressources est hors ligne, alors toutes ses ressources le sont. Si un groupe de ressources est en ligne, alors toutes ses ressources activées le sont.

  Les groupes de ressources peuvent contenir plusieurs ressources ayant des dépendances entre elles. Ces dépendances nécessitent que les ressources soient mises en ligne et hors ligne dans un ordre particulier. Le temps nécessaire aux méthodes utilisées pour connecter et déconnecter les ressources peut varier pour chaque ressource. Du fait de l'existence de dépendances entre les ressources et du caractère variable des temps de démarrage et d'arrêt, les ressources d'un même groupe peuvent avoir différents états « en ligne » et « hors ligne » durant une reconfiguration du cluster.

Propriétés des ressources et des groupes de ressources

Vous pouvez configurer les valeurs des propriétés des ressources et des groupes de ressources de vos services de données Sun Cluster. Il existe des propriétés standard communes à tous les services de données et des propriétés d'extension propres à chaque service de données. Certaines propriétés standard et propriétés d'extension sont définies par des paramètres par défaut et vous n'avez pas à les modifier. D'autres propriétés doivent être définies au moment de la création et de la configuration des ressources. La documentation de chaque service de données indique quelles propriétés de ressources peuvent être définies et comment les définir.

Les propriétés standard permettent de configurer les propriétés des ressources et groupes de ressources habituellement indépendantes de tout service de données. Pour consulter cet ensemble de propriétés standard, voir Annexe A, Standard Properties du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Les propriétés d'extension du RGM (gestionnaire du groupe de ressources) donne des informations sur l'emplacement des binaires d'application et des fichiers de configuration. Les propriétés d'extension peuvent être modifiées lorsque vous configurez vos services de données. Elles sont décrites dans le manuel consacré au service de données.

Configuration d'un projet de services de données

Les services de données peuvent être configurés pour être lancés sous un nom de projet Solaris lorsqu'ils sont mis en ligne à l'aide du RGM. La configuration associe une ressource ou un groupe de ressources géré par le RGM à une ID de projet Solaris. La mise en correspondance de votre ressource ou groupe de ressources vers un ID projet vous permet d'utiliser des contrôles avancés, disponibles dans le système d'exploitation Solaris, pour gérer les charges de travail et la consommation du cluster.

Vous pouvez effectuer cette configuration uniquement si vous exécutez la version actuelle du logiciel Sun Cluster avec au minimum Solaris 9.

L'utilisation des fonctionnalités de gestion de Solaris dans un environnement Sun Cluster vous permet de vous assurer que vos applications les plus importantes sont prioritaires lors du partage d'un nœud avec d'autres applications. Il arrive que les applications partagent un nœud si vous avez des services consolidés ou si les applications ont basculé. L'utilisation des fonctionnalités de gestion décrites dans ce document peut améliorer la disponibilité d'une application stratégique en empêchant les applications à faible priorité de consommer des ressources système, par exemple le temps CPU.

La documentation Solaris relative à cette fonctionnalité décrit les « ressources » que sont le temps CPU, les processus, les tâches et composants semblables. La documentation Sun Cluster utilise le terme « ressources » pour décrire les entités qui sont sous le contrôle du RGM. La section suivante utilise le terme « ressource » pour désigner des entités Sun Cluster sous le contrôle du RGM. Elle utilise le terme « ressources » pour désigner le temps CPU, les processus et les tâches.

Cette section décrit la procédure de configuration des services de données pour le lancement de processus dans un project(4) Solaris 9 spécifié. Elle décrit également plusieurs scénarios de basculement et donne des suggestions de planification pour l'utilisation des fonctionnalités de gestion du système d'exploitation Solaris.

Pour plus d'informations sur les notions fondamentales et les procédures relatives à la fonctionnalité de gestion, voir Chapitre 1, Network Service (Overview) du System Administration Guide: Network Services.

Lorsque vous configurez des ressources et des groupes de ressources pour qu'ils utilisent les fonctionnalités de gestion de Solaris dans un cluster, suivez le processus général suivant :

1. Configurez les applications comme partie intégrante de la ressource.

2. Configurez les ressources comme partie intégrante d'un groupe de ressources.

3. Activez les ressources du groupe de ressources.

4. Activez la gestion du groupe de ressources.

5. Créez un projet Solaris pour votre groupe de ressources.

6. Configurez des propriétés standard pour associer le nom du groupe de ressources au projet que vous avez créé à l'étape 5.

7. Mettez le groupe de ressources en ligne.

Pour configurer les propriétés standard Resource_project_name ou RG_project_name afin d'associer l'ID projet Solaris à la ressource ou au groupe de ressources, utilisez l'option -y avec la commande scrgadm(1M). Définissez les valeurs des propriétés de la ressource ou du groupe de ressources. Pour consulter les définitions des propriétés, voir Annexe A, Standard Properties du Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Reportez-vous aux descriptions des propriétés r_properties(5) et rg_properties(5).

Le nom de projet spécifié doit figurer dans la base de données de projets (/etc/project) et le superutilisateur doit être configuré en tant que membre du projet nommé. Pour plus d'informations sur les notions fondamentales relatives à la base de données de projets, voir Chapitre 2, Projects and Tasks (Overview) du System Administration Guide: Solaris Containers-Resource Management and Solaris Zones. Pour consulter la description de la syntaxe d'un fichier projet, voir project(4).

Lorsque le RGM met les ressources ou les groupes de ressources en ligne, il lance les processus connexes sous le nom du projet.

les utilisateurs peuvent à tout moment associer la ressource ou le groupe de ressources à un projet. Toutefois, le nom du projet n'est pas effectif tant que la ressource ou le groupe de ressources n'ont pas été mis hors ligne, puis remis en ligne à l'aide du RGM.

Le lancement des ressources ou des groupes de ressources sous le nom de projet vous permet de configurer les fonctions indiquées ci-après pour gérer les ressources système au sein du cluster.

• Comptabilité étendue : elle constitue un moyen souple d'enregistrer la consommation d'une tâche ou d'un procédé. La comptabilité étendue vous permet d'examiner l'historique de l'utilisation et d'évaluer les besoins en capacité des charges de travail futures.

• Contrôles : ce mécanisme permet d'appliquer des contraintes aux ressources système. On peut empêcher les processus, tâches et projets de surconsommer certaines ressources système.

• Fair Share Scheduling (FSS) : cette fonction offre la possibilité de contrôler l'allocation de temps CPU aux charges de travail, en fonction de leur importance. L'importance des charges de travail est définie par le nombre de parts de temps CPU attribué à chaque charge. Pour plus d'informations, reportez-vous aux pages suivantes.

  • dispadmin(1M)

  • priocntl(1)

  • ps(1)

  • FSS(7).

• Pools : cette fonction offre la possibilité d'utiliser des partitions pour les applications interactives en fonction des besoins de l'application. Les pools permettent de segmenter un serveur qui prend en charge un certain nombre d'applications différentes. Grâce à l'utilisation de pools les réponses des applications deviennent plus prévisibles.

Détermination des besoins pour la configuration de projets

Avant de configurer des services de données pour l'utilisation des contrôles de Solaris dans un environnement Sun Cluster, vous devez choisir la méthode de contrôle et de suivi des ressources au travers des commutations et des basculements. Identifiez les dépendances dans le cluster avant de configurer un nouveau projet. Par exemple, les ressources et groupes de ressources dépendent des groupes de périphériques de disques.

Utilisez les propriétés de groupe de ressources nodelist, failback, maximum_primaries et desired_primaries qui sont configurées avec scrgadm(1M) afin d'identifier les propriétés de la liste de nœuds de votre groupe de ressources.

• Pour consulter une brève présentation des dépendances de la liste de nœuds entre les groupes de ressources et les groupes de périphériques de disques, voir Relationship Between Resource Groups and Disk Device Groups du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

• Pour une description détaillée des propriétés, voir rg_properties(5).

Utilisez les propriétés preferenced et failback configurées avec scrgadm(1M) et scsetup(1M) pour identifier les priorités de la liste de nœuds du groupe de périphériques de disques.

• Pour plus d'informations sur les notions fondamentales relatives à la propriété preferenced, voir Groupes de périphériques de disques multiports .

• Pour plus d'informations sur les procédures, reportez-vous au paragraphe “Comment changer les propriétés des périphériques de disques” dans Administration des groupes de périphériques de disques du Guide d’administration système de Sun Cluster pour SE Solaris.

• Pour plus d'informations sur les notions fondamentales relatives à la configuration des nœuds et au comportement des services de données de basculement et évolutifs, voir Matériel système et composants logiciels Sun Cluster .

Si vous configurez tous les nœuds du cluster de la même façon, les limites d'utilisation sont appliquées de manière identique aux nœuds principaux et aux nœuds secondaires. Les paramètres de configuration des projets ne sont pas tenus d'être identiques pour toutes les applications dans les fichiers de configuration. Tous les projets associés à l'application doivent au moins être accessibles par le biais de la base de données de projets sur tous les maîtres potentiels de l'application. Supposons que l'application 1 soit contrôlée par phys-schost-1, mais puisse être basculée sur phys-schost-2 ou phys-schost-3. Le projet associé à l'application 1 doit être accessible sur les trois nœuds (phys-schost-1, phys-schost-2 et phys-schost-3).

Les informations de la base de données de projets peuvent être contenues dans un fichier de base de données local /etc/project ou stockées dans la carte NIS ou dans le service d'annuaire LDAP.

Le système d'exploitation Solaris permet de configurer des paramètres d'utilisation de façon souple ; peu de limites sont imposées par Sun Cluster. Les choix de configuration sont tributaires des besoins du site. Tenez compte des indications précisées aux rubriques suivantes pour la configuration de vos systèmes.

Définition des limites de mémoire virtuelle par processus

Pour limiter la mémoire virtuelle par processus, définissez le paramètre process.max-address-space. Pour plus d'informations sur la définition de la valeur process.max-address-space, voir rctladm(1M).

Si vous utilisez des contrôles de gestion avec le logiciel Sun Cluster, configurez des limites de mémoire de façon appropriée, pour empêcher tout basculement superflu et tout effet « ping-pong » des applications. En règle générale, respectez les consignes indiquées ci-dessous.

• Ne définissez pas de limites de mémoire trop basses.

  Lorsqu'une application atteint sa limite de mémoire, elle peut basculer. Cet aspect est particulièrement important pour les applications de base de données, où les conséquences liées à l'atteinte de la limite de mémoire virtuelle sont imprévisibles.

• Les limites de mémoire des nœuds principaux et des nœuds secondaires ne doivent pas être identiques.

  Si elles l'étaient, un effet ping-pong pourrait se produire au moment où l'application atteint sa limite de mémoire et bascule sur un nœud secondaire ayant une limite de mémoire identique. Définissez une limite de mémoire légèrement supérieure sur le nœud secondaire. Vous préviendrez ainsi des effets ping-pong et l'administrateur système aura un laps de temps lui permettant de régler les paramètres si nécessaire.

• Utilisez les limites de la mémoire de gestion de ressources pour l'équilibrage de la charge.

  Vous pouvez par exemple utiliser les limites de la mémoire pour empêcher une application errante de consommer trop d'espace de swap.

Scénarios de basculement

Vous pouvez configurer les paramètres de gestion de sorte que l'allocation de la configuration de projet (/etc/project) soit opérationnelle durant le fonctionnement normal du cluster et dans les situations de commutation et de basculement.

Les rubriques suivantes présentent des exemples de scénarios.

• Les deux premières rubriques, “Cluster à deux nœuds avec deux applications“ et “Cluster à deux nœuds avec trois applications“, présentent des scénarios de basculement de nœuds complets.

• La rubrique “Basculement de groupes de ressources uniquement“ illustre les opérations de basculement d'une application seulement.

Dans un environnement Sun Cluster, vous configurez une application comme partie d'une ressource. Vous configurez ensuite une ressource comme partie d'un groupe de ressources. En cas de panne, le groupe de ressources ainsi que les applications qui lui sont associées basculent sur un autre nœud. Dans les exemples suivants les ressources n'apparaissent pas de manière explicite. Supposons que chaque ressource n'a qu'une seule application.

un basculement intervient en fonction de l'ordre de préférence de la liste de nœuds définie par le RGM.

Les exemples présentés ci-après comportent les contraintes suivantes :

• Application 1 (App-1) est configurée dans le groupe de ressources GR-1.

• Application 2 (App-2) est configurée dans le groupe de ressources GR-2.

• Application 3 (App-3) est configurée dans le groupe de ressources GR-3.

Bien que le nombre de parts attribuées reste le même, le pourcentage de temps CPU alloué à chaque application change après un basculement. Ce pourcentage dépend du nombre d'applications tournant sur le nœud et du nombre de parts attribuées à chaque application active.

Pour ces scénarios, supposons que nous avons les configurations suivantes :

• Toutes les applications sont configurées sous un même projet.

• Chaque ressource n'a qu'une seule application.

• Les applications ne sont pas les seuls processus actifs sur les nœuds.

• Les bases de données de projets sont configurées de la même manière sur tous les nœuds du cluster.

Cluster à deux nœuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux nœuds pour vous assurer que chaque hôte physique (phys-schost-1, phys-schost-2) sert de maître par défaut pour une application. Chaque hôte physique sert de nœud secondaire à l'autre hôte physique. Tous les projets associés à l'application 1 et à l'application 2 doivent être représentés dans les fichiers de bases de données de projets sur les deux nœuds. Lorsque le cluster fonctionne normalement, chaque application tourne sur son maître par défaut, où le temps UC lui est attribué par la fonction de gestion.

Lorsqu'un basculement ou une commutation a lieu, les deux applications tournent sur un seul nœud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, cette entrée du fichier /etc/project indique que 4 parts sont allouées à l'application 1 et qu'une part est allouée à l'application 2.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement. Le nombre de parts assignées ne change pas. Cependant, le pourcentage de temps CPU disponible pour chaque application peut changer. Il dépend du nombre de parts assignées à chaque processus qui exige du temps CPU.

Cluster à deux nœuds avec trois applications

Sur un cluster à deux nœuds avec trois applications, vous pouvez configurer un hôte physique (phys-schost-1) comme maître par défaut d'une application. Vous pouvez configurer le second hôte physique (phys-schost-2) comme maître par défaut pour les deux applications restantes. Dans l'exemple suivant, supposons que le fichier de base de données des projets se trouve sur chaque nœud. Le fichier de base de données des projets ne change pas lorsqu'un basculement ou une commutation a lieu.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none) 

Lorsque le cluster fonctionne normalement, 5 parts sont allouées à l'application 1 sur son maître par défaut, phys-schost-1. Ce nombre équivaut à 100 pour cent du temps UC parce que c'est la seule application qui demande du temps UC sur ce nœud. Trois parts et deux parts sont allouées respectivement aux applications 2 et 3 sur leur maître par défaut, phys-schost-2. L'application 2 reçoit 60 pour cent du temps CPU et l'application 3 reçoit 40 pour cent du temps CPU au cours du fonctionnement normal.

Si un basculement ou une commutation se produisent et que l'application 1 est basculée sur phys-schost-2, les parts des trois applications restent les mêmes. Toutefois, les pourcentages de ressources CPU sont allouées en fonction du fichier de la base de données des projets.

• L'application 1, avec 5 parts, reçoit 50 pour cent de l'UC.

• L'application 2, avec 3 parts, reçoit 30 pour cent de CPU.

• L'application 3, avec 2 parts, reçoit 20 pour cent de l'UC.

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement.

Basculement du groupe de ressources uniquement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, un groupe de ressources (et ses applications associées) peuvent basculer ou commuter sur un nœud secondaire. Pendant ce temps, le maître par défaut continue de fonctionner dans le cluster.

durant un basculement, l'application basculant se voit attribuer des ressources tel que spécifié dans le fichier de configuration du nœud secondaire. Dans cet exemple, les fichiers de base de données de projets sur les nœuds principal et secondaire ont les mêmes configurations.

Par exemple, cet échantillon de fichier de configuration spécifie que 1 part est allouée à l'application, 2 parts sont allouées à l'application 2 et 2 parts à l'application 3.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

Le diagramme suivant illustre les opérations normales et de basculement de cette configuration, où RG-2, qui contient l'application 2, bascule sur phys-schost-2. Notez que le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps CPU disponible pour chaque application peut changer, en fonction du nombre de parts assignées à chaque application qui exige du temps CPU.

Adaptateurs de réseau public et multi-acheminement sur réseau IP

Les clients adressent des requêtes de données au cluster à travers le réseau public. Chaque nœud du cluster est connecté à au moins un réseau public à travers une paire d'adaptateurs de réseau public.

Le logiciel de multi-acheminement sur réseau IP Solaris de Sun Cluster propose un mécanisme de base pour le contrôle des adaptateurs de réseau public et le basculement sur des adresses IP d'un adaptateur à un autre en cas de détection de panne. Chaque nœud du cluster a sa propre configuration de multi-acheminement sur réseau IP, qui peut être différente de celle des autres nœuds.

Les adaptateurs de réseau public sont organisés en groupes de multi-acheminement sur IP (groupes de multi-acheminement). Chaque groupe de multi-acheminement possède un ou plusieurs adaptateurs de réseau public. Chaque adaptateur d'un groupe peut être actif. Vous pouvez également configurer des interfaces de réserve qui sont inactives excepté en cas de basculement.

Le démon de multi-acheminement in.mpathd utilise une adresse IP de test pour détecter les pannes et les réparations. S'il détecte une panne sur l'un des adaptateurs, un basculement a lieu. Tout l'accès réseau bascule de l'adaptateur défectueux vers un autre adaptateur opérationnel du groupe de multi-acheminement. Ainsi, le démon conserve la connectivité du réseau public pour le nœud. Si vous avez configuré une interface de réserve, le démon la choisit. Sinon, le démon choisit l'interface ayant le plus petit nombre d'adresses IP. En cas de basculement au niveau de l'interface de l'adaptateur, les connexions de niveau supérieur, notamment TCP, ne sont pas affectées, excepté pendant un bref instant lors du basculement. En cas de succès du basculement des adresses IP, des diffusions ARP sont envoyées. Ainsi, le démon conserve les connexions aux clients distants.

En raison des caractéristiques de récupération de surcharge du protocole TCP, les points finaux TCP peuvent connaître un retard supplémentaire après un basculement réussi. Certains segments peuvent avoir été perdus pendant le basculement, activant le mécanisme de contrôle de la surcharge du protocole TCP.

Les groupes de multi-acheminement procurent aux blocs assemblés des ressources de nom d'hôte logique et d'adresse partagée. Vous pouvez aussi créer des groupes de multi-acheminement indépendamment des ressources de nom d'hôte logique et d'adresse partagée pour contrôler la connexion des nœuds du cluster au réseau public. Sur un nœud, le même groupe de multiacheminement peut héberger un nombre indéfini de ressources de nom d'hôte logique ou d'adresse partagée. Pour plus d'informations sur les ressources de nom d'hôte logique et d'adresse partagée, voir Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Le mécanisme multi-acheminement sur réseau IP est conçu pour détecter et masquer les pannes des adaptateurs. Il n'est pas destiné à effectuer une récupération à partir de l'utilisation d'un administrateur de ifconfig(1M) pour la suppression d'une des adresses IP logiques (ou partagées). Le logiciel Sun Cluster affiche les adresses IP logiques et partagées comme ressources gérées par le RGM. Pour ajouter ou supprimer une adresse IP, un administrateur doit utiliser scrgadm(1M) pour modifier le groupe de ressources qui contient la ressource.

Pour plus d'informations sur l'implémentation du multi-acheminement sur réseau IP Solaris, reportez-vous à la documentation appropriée du système d'exploitation Solaris installé sur le cluster.

SPARC : Prise en charge de la reconfiguration dynamique

La prise en charge de la fonction de reconfiguration dynamique (DR) par Sun Cluster 3.1 8/05 est développée par phases successives. Cette section propose des explications et des observations concernant la prise en charge de la fonction DR par Sun Cluster 3.1 8/05.

Toutes les exigences de configuration, procédures et restrictions applicables à la reconfiguration dynamique (DR) de Solaris s'appliquent également à la DR de Sun Cluster (à l'exception de l'opération d'arrêt progressif de l'environnement d'exploitation). Reportez-vous donc à la documentation relative à la DR de Solaris avant d'utiliser la fonction DR du logiciel Sun Cluster. Vous devez consulter en particulier les problèmes qui affectent les périphériques d'E/S non réseau pendant une séparation DR.

Les documents Sun Enterprise 10000 Dynamic Reconfiguration User Guide et Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual (des collections Solaris 8 on Sun Hardware ou Solaris 9 on Sun Hardware) peuvent tous deux être téléchargés à l'adresse http://docs.sun.com.

SPARC : Description générale d'une reconfiguration dynamique

La fonction DR permet des opérations, comme la suppression de matériel système, sur des systèmes en cours d'exécution. Les processus de la reconfiguration dynamique ont pour but d'assurer la continuité du fonctionnement du système. Il n'est pas nécessaire d'arrêter le système et d'interrompre la disponibilité du cluster.

La reconfiguration dynamique (DR) opère au niveau de la carte. Ainsi, une DR affecte tous les composants d'une carte. Chaque carte peut contenir plusieurs composants, notamment la CPU, la mémoire et les jonctions de périphériques des lecteurs de disques, lecteurs de bandes et connexions réseau.

Le retrait d'une carte qui contient des composants actifs entraîne des erreurs système. Avant la suppression d'une carte, le sous-système de la DR interroge d'autres systèmes, tels que Sun Cluster, pour déterminer si les composants de la carte sont en cours d'utilisation. Si le sous-système de la DR découvre qu'une carte est en cours d'utilisation, l'opération de suppression de la carte n'est pas effectuée. Ainsi, il est toujours conseillé de retirer une carte DR, car le sous-système de la DR rejette les opérations sur des cartes qui contiennent des composants actifs.

L'ajout de carte DR est également toujours conseillé. Les unités centrales et la mémoire d'une nouvelle carte sont automatiquement mises en service par le système. Cependant, l'administrateur système doit configurer manuellement le cluster pour l'utilisation de façon active des composants qui sont contenus sur cette nouvelle carte.

le sous-système de la DR comporte plusieurs niveaux. Si un niveau inférieur rapporte une erreur, le niveau supérieur fait de même. Cependant, si le niveau inférieur rapporte une erreur spécifique, le niveau supérieur indique Erreur inconnue. Vous pouvez ignorer sans risque cette erreur.

Les rubriques suivantes présentent quelques observations sur les conséquences de l'utilisation de la reconfiguration dynamique avec différents types de périphériques.

SPARC : Clustering DR : éléments à prendre en compte pour les périphériques CPU

Le logiciel Sun Cluster ne rejette pas le retrait de carte DR en raison de la présence de périphériques CPU.

Lorsqu'une opération d'ajout de carte par reconfiguration dynamique a réussi, les CPU de la carte ajoutée sont automatiquement incorporées au système.

SPARC : Clustering DR : éléments à prendre en compte pour la mémoire

Pour les besoins de la DR, tenez compte de deux types de mémoires.

• mémoire noyau

• mémoire non noyau

Ces deux types ne diffèrent qu'au niveau de l'utilisation. Le matériel utilisé est le même. La mémoire noyau est la mémoire utilisée par le système d'exploitation Solaris. Le logiciel Sun Cluster ne prend pas en charge les retraits d'une carte qui contient la mémoire noyau et rejette toute opération de ce type. Si le retrait de la carte DR affecte la mémoire autre que la mémoire noyau, le logiciel Sun Cluster ne rejette pas cette opération. Lorsqu'une carte qui contient de la mémoire est ajoutée par reconfiguration dynamique, la mémoire de cette carte est automatiquement incorporée au système.

SPARC : Clustering DR : éléments à prendre en compte pour les lecteurs de disques et de bandes

Sun Cluster rejette les opérations de suppression de cartes par reconfiguration dynamique sur les lecteurs actifs dans le nœud principal. Ces opérations peuvent être effectuées sur des lecteurs inactifs dans le nœud principal ou sur tous les lecteurs dans le nœud secondaire. Après l'opération DR, l'accès aux données de cluster se poursuit comme auparavant.

Sun Cluster rejette les opérations DR ayant un impact sur la disponibilité des périphériques de quorum. Pour consulter les éléments à prendre en compte sur les périphériques de quorum et la procédure à suivre pour effectuer des opérations DR sur ceux-ci, voir SPARC : Clustering DR : éléments à prendre en compte pour les périphériques de quorum .

Pour consulter les instructions détaillées sur l'exécution de ces actions, voir Reconfiguration dynamique avec périphériques de quorum du Guide d’administration système de Sun Cluster pour SE Solaris.

SPARC : Clustering DR : éléments à prendre en compte pour les périphériques de quorum

Si le retrait de carte DR affecte une carte qui contient l'interface d'un périphérique de quorum, le logiciel Sun Cluster rejette cette opération. Le logiciel Sun Cluster identifie également le périphérique de quorum affecté par cette opération. Vous devez désactiver la fonction de quorum du périphérique avant d'effectuer une opération de suppression de carte par reconfiguration dynamique.

Pour consulter les instructions détaillées sur l'administration du quorum, voir Chapitre 5, Administration du quorum du Guide d’administration système de Sun Cluster pour SE Solaris.

SPARC : Clustering DR : éléments à prendre en compte pour les interfaces d'interconnexion de cluster

Si le retrait de carte DR affecte une carte qui contient l'interface d'une interconnexion de cluster active, le logiciel Sun Cluster rejette cette opération. Le logiciel Sun Cluster identifie également l'interface affectée par cette opération. Vous devez utiliser un outil d'administration de Sun Cluster pour désactiver cette interface afin que cette opération puisse aboutir.

Le logiciel Sun Cluster nécessite que chaque nœud du cluster dispose au moins d'un chemin d'accès opérationnel à tous les nœuds du cluster. Ne désactivez pas une interface d'interconnexion privée prenant en charge le dernier chemin d'accès à un nœud du cluster.

Pour consulter les instructions détaillées sur l'exécution de ces actions, voir Administration des interconnexions de cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

SPARC : Clustering DR : éléments à prendre en compte pour les interfaces de réseau public

Si le retrait de carte DR affecte une carte qui contient une interface de réseau public active, le logiciel Sun Cluster rejette cette opération. Le logiciel Sun Cluster identifie également l'interface affectée par cette opération. Avant de retirer une carte qui contient une interface de réseau active, basculez tout le trafic de cette interface sur une autre interface opérationnelle dans le groupe de multi-acheminement, à l'aide de la commande if_mpadm(1M).

si l'adaptateur de réseau restant échoue au moment où vous supprimez l'adaptateur de réseau désactivé par reconfiguration dynamique, la disponibilité du cluster peut être menacée. L'adaptateur restant ne peut pas effectuer de basculement pendant toute la durée de l'opération DR.

Pour consulter les instructions détaillées sur l'exécution d'un retrait DR sur une interface de réseau public, voir Administration du réseau public du Guide d’administration système de Sun Cluster pour SE Solaris.