Chapitre 3 Notions-clés : administration et développement d'applications

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

• Interfaces d'administration

• 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 de cluster

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

• Services de données

• Développement de nouveaux services de données

• Ressources, groupes de ressources et types de ressources

• Adaptateurs de réseau public et IP Network Multipathing

• SPARC: prise en charge de la reconfiguration dynamique

Ces informations sont plus particulièrement destinées aux administrateurs système et aux développeurs d'applications utilisant l'API et le SDK de SunPlex. Les administrateurs système y trouveront des informations en vue de l'installation, de la configuration et de 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 d'administration

Vous avez le choix entre plusieurs interfaces utilisateur pour installer, configurer et administrer le système SunPlex. Les tâches d'administration système peuvent être effectuées à travers l'interface utilisateur graphique de SunPlex Manager ou à travers l'interface de ligne de commande. L’interface de ligne de commande comporte des utilitaires, tels que scinstall et scsetup, permettant de simplifier les tâches d’installation et de configuration sélectionnées. Le système SunPlex contient également un module fonctionnant dans le cadre de Sun Management Center fournissant une interface utilisateur graphique pour effectuer des tâches particulières du cluster. Ce module est disponible uniquement pour les clusters SPARC. Reportez-vous à “Outils d'administration” dans le Guide d'administration du système Sun Cluster System pour SE Solaris pour une description complète des interfaces d'administration.

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 SunPlex utilise le protocole NTP (Network Time Protocol) 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. Toutefois, si vous exécutez date(1), rdate(1M) ou xntpdate(1M) (interactivement ou à l'intérieur de scripts cron) sur un cluster en activité, vous pouvez forcer la modification de l'heure de bien 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.

Lorsque vous installez l'environnement d'exploitation Solaris sur chaque nœud du cluster, vous avez la possibilité de modifier la date et l'heure par défaut du nœud. Vous pouvez en général accepter les paramètres par défaut.

Une des étapes du processus d'installation de Sun Cluster à l'aide de scinstall(1M) consiste à configurer NTP pour le cluster. Sun Cluster fournit un fichier de modèles, ntp.cluster (consultez /etc/inet/ntp.cluster sur un nœud installé) établissant une relation d'homologues entre tous les nœuds du cluster, un nœud étant désigné comme le « préféré ». Les nœuds sont identifiés par leurs noms d'hôtes privés et la synchronisation de l'heure a lieu à travers l'interconnexion de cluster. Pour consulter les instructions de configuration du cluster pour NTP, reportez-vous à “Installation et configuration du logiciel Sun Cluster” dans le 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. Toutefois, si l'heure a été mal réglée lors de l'installation de l'environnement d'exploitation Solaris et que vous souhaitiez la modifier, vous trouverez la procédure adéquate dans la rubrique “Administration du cluster ” du Guide d'administration du système Sun Cluster pour SE Solaris.

Structure à haute disponibilité

Le système SunPlex rend tous les composants du « chemin d'accès » reliant les utilisateurs aux données hautement disponibles, y compris les interfaces réseaux, les applications elles-mêmes, le système de fichiers et les périphériques multihôtes. Un composant du cluster est dit hautement disponible s'il est capable de survivre à toute panne (matérielle ou logicielle) unique du système.

Vous trouverez dans le tableau les types de pannes de SunPlex (matérielles et logicielles) et les types de récupération intégrés à la structure à haute disponibilité.

La structure à haute disponibilité de Sun Cluster détecte rapidement l'échec d'un nœud et crée un nouveau serveur équivalent pour les ressources de la structure sur un autre nœud. Les ressources de la structure ne sont jamais toutes indisponibles en même temps. Celles n'ayant pas été affectées par l'échec d'un nœud sont totalement disponibles durant 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 s'aperçoivent simplement pas que le serveur de la ressource a été déplacé vers un autre nœud. L'échec d'un seul nœud est totalement transparent pour les programmes sur les autres nœuds utilisant les fichiers, les périphériques et les volumes de disques rattachés à ce nœud, tant qu'il existe un autre chemin d'accès matériel aux disques depuis 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 être sur 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 du cluster. 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, le MAC réalise une configuration synchronisée du cluster, au cours de laquelle les ressources peuvent être redistribuées en fonction de la nouvelle appartenance au cluster.

Contrairement à certaines versions antérieures du logiciel Sun Cluster, le MAC s'exécute entièrement dans le noyau.

Reportez-vous à la rubrique À propos de la séparation en cas d'échec pour de plus amples informations sur la manière dont le cluster s'autoprotège d'un partitionnement en plusieurs clusters distincts.

Mécanisme failfast

Si le MAC détecte un problème critique sur un nœud, il fait appel à la structure du cluster pour arrêter le nœud de force (panique) et le supprimer de l’appartenance au cluster. Le mécanisme par lequel ce processus intervient est appelé failfast. Il provoque l'arrêt d'un nœud de deux manières.

• Si un nœud quitte le cluster puis tente de démarrer un nouveau cluster sans avoir de quorum, on le « sépare » pour l'empêcher d'accéder aux disques partagés. Reportez-vous à la rubrique À propos de la séparation en cas d'échec pour de plus amples informations sur l'utilisation du mécanisme failfast.

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

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 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? avec eeprom(1M), à l'invite ok de la PROM OpenBoot.

Cluster Configuration Repository (CCR)

Le CCR utilise un algorithme de validation à deux phases pour les mises à jour : si une mise à jour ne se déroule pas correctement sur tous les membres du cluster, elle est réexécuté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 nécessaire et de faciliter les mises à jour des données.

Périphériques globaux

Le système SunPlex utilise des périphériques globaux pour fournir un accès hautement disponible dans tout le cluster à tous ses périphériques, à partir de n'importe quel nœud, indépendamment de l'emplacement auquel est physiquement rattaché le périphérique. En général, si un nœud tombe en panne au moment où il fournit un accès à un périphérique global, Sun Cluster trouve automatiquement un autre chemin vers lequel il redirige l'accès. Les périphériques globaux de SunPlex comprennent les disques, les CD et les bandes. Cependant, les disques sont les seuls périphériques globaux multiports pris en charge. Cela signifie qu'actuellement, les CD et bandes ne sont pas des périphériques hautement disponibles. Les disques locaux installés sur chaque serveur ne disposent pas non plus d'accès multiples et ne sont donc pas hautement disponibles.

Le cluster assigne automatiquement un ID unique à chaque disque, CD et bande du cluster. Cela permet un accès consistant à chaque périphérique à partir de n'importe quel nœud du cluster. L'espace de noms du périphérique global se trouve dans le répertoire /dev/global. Reportez-vous à la rubrique Espace de noms global pour de plus amples informations.

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

ID de périphérique (IDP)

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

Le pseudo pilote d'ID de périphériques (IDP) fait partie intégrante de la fonction d'accès aux périphériques globaux du cluster. Il examine tous les nœuds du cluster et élabore une liste de périphériques de disques uniques, assignant à chacun un numéro majeur et mineur unique, consistant sur tous les nœuds du cluster. L'accès aux périphériques globaux se fait à l'aide de l'ID de périphérique unique assigné par le pilote d'IDP, plutôt que par l'ID de périphérique Solaris traditionnelle, par exemple c0t0d0 pour un disque.

Cette approche assure que toute application accédant aux disques (telle qu'un gestionnaire de volumes ou des applications utilisant des périphériques bruts) utilise un chemin d'accès consistant au sein du 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 peut par exemple considérer un disque multihôte comme c1t2d0, et le nœud 2 peut considérer ce même disque complètement différemment, comme c3t2d0 . Le pilote d'IDP assigne un nom global, tel que d10, que les nœuds utilisent. Ainsi, chaque nœud a une représentation consistante des disques multihôtes.

La mise à jour et l'administration des ID de périphériques se fait à l'aide des commandes scdidadm(1M) et scgdevs(1M). Pour plus d'informations, consultez les pages man suivantes :

• scdidadm(1M)

• scgdevs(1M)

Groupes de périphériques de disques

Dans le système SunPlex, tous les périphériques multihôtes doivent être sous le contrôle de Sun Cluster. Vous devez d'abord créer les groupes de disques du gestionnaire de volumes, soit des jeux de disques Solaris Volume Manager soit des groupes de disques VERITAS Volume Manager (disponibles uniquement dans les clusters basés sur SPARC), sur les disques multihôtes. Vous enregistrez ensuite les groupes de disques du gestionnaire de volumes 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 indique au système SunPlex pour chaque nœud les détails de chemin d'accès aux groupes de disques du gestionnaire de volumes. 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. Le groupe de périphériques de disques à haute disponibilité peut être utilisé pour héberger les systèmes de fichiers de 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 processus de services de données) tandis qu'un autre peut contrôler le(s) groupe(s) de disques auxquels accèdent les services de données. Toutefois, la meilleure façon de procéder est de garder sur le même nœud le groupe de périphériques stockant des données d'application particulières et le groupe de ressources contenant les ressources de l'application (le démon de l'application). Reportez-vous à la rubrique “Relationship Between Resource Groups and Disk Device Groups” du Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour obtenir davantage d'informations sur l'association entre les groupes de ressources et les groupes de périphériques de disques dans la liste de nœuds.

Dans un groupe de périphériques de disques, le groupe de disques du gestionnaire de volumes devient « global » parce qu'il fournit un support multivoie aux disques sous-jacents. Chaque nœud du cluster physiquement relié aux disques multihôtes fournit un chemin d'accès au groupe de périphériques de disques.

Basculement du groupe de périphériques de disques

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 Basculement du groupe de périphériques de disques

Groupes de périphériques de disques à accès multiples

Cette rubrique décrit les propriétés des groupes de périphériques de disques vous permettant d'équilibrer performances et disponibilité dans une configuration de disques à accès multiples. Le logiciel Sun Cluster propose deux propriétés pour la configuration de disques à accès multiples : prédilection et nombre_nœuds_secondaires . La propriété prédilection permet de déterminer l'ordre dans lequel les nœuds tentent de prendre le contrôle en cas de basculement. 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 système à haute disponibilité est considéré comme défectueux lorsque le nœud principal tombe en panne et qu'aucun nœud secondaire n'est susceptible de prendre le relais. Si un basculement survient alors que la propriété prédilection est définie sur true, un nœud secondaire est sélectionné en fonction de l'ordre de priorité de la liste de nœuds. La liste de nœuds définit l'ordre dans lequel les nœuds vont tenter d'endosser le rôle de nœud principal ou de passer de nœud de réserve à nœud 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, sera 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 de nœuds de réserve a été implémentée pour minimiser ces conséquences fâcheuses. Par défaut, votre groupe de périphériques de disques aura un nœud principal et un nœud secondaire. Les autres nœuds disponibles apparaîtront en ligne à l'état de nœud de réserve. En cas de basculement, le nœud secondaire devient principal et le nœud prioritaire sur la liste de nœuds devient secondaire.

Le nombre souhaité de nœuds secondaires peut être égal à n'importe quel nombre entier compris entre un et le nombre de nœuds fournisseurs 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 pouvoir modifier la valeur par défaut de la propriété nombre_nœuds_secondaires.

Le nombre souhaité de nœuds secondaires par défaut pour les services de périphériques est un. Le nombre réel de nœuds secondaires maintenu par la structure de réplication correspond au nombre souhaité, à moins que le nombre de nœuds non principaux opérationnels soit inférieur à ce nombre. Si vous ajoutez ou supprimez des nœuds de votre configuration, vous devrez modifier la propriété nombre_nœuds_secondaires et vérifier deux fois la liste de nœuds. La maintenance de la liste de nœuds et du nombre souhaité de nœuds secondaires empêche les conflits entre le nombre de nœuds secondaires configurés et le nombre réel autorisé par la structure.L'utilisation conjointe de la commande metaset(1M) pour les groupes de périphériques Solaris Volume Manager ou, si vous utilisez Veritas Volume Manager, de la commande scconf(1M) pour les groupes de périphériques de disques VxVM et des propriétés prédilection et nombre_nœuds_secondaires permet de gérer l'ajout et la suppression de nœuds de votre configuration. Reportez-vous à la rubrique “Administering Cluster File Systems Overview” du Sun Cluster System Administration Guide for Solaris OS pour de plus amples informations sur la procédure de modification des propriétés des groupes de périphériques de disques.

Espace de noms global

Le mécanisme du logiciel Sun Cluster permettant d'activer les périphériques globaux est appelé espace de noms global. Il inclut la hiérarchie /dev/global/ ainsi que les espaces de noms du gestionnaire de volumes. 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 aux périphériques de stockage à n'importe quel nœud du cluster.

Habituellement, les espaces de noms du gestionnaire de volumes se trouvent dans les répertoires /dev/md/jeu_disques/dsk (et rdsk) pour Solaris Volume Manager. Pour Veritas VxVM, les espaces de noms du gestionnaire de volumes sont situés dans les répertoires /dev/vx/dsk/ groupe_disques et /dev/vx/rdsk/ groupe_disques. Ces espaces de noms correspondent à des répertoires pour chaque ensemble de disques Solaris Volume Manager et chaque groupe de disques VxVM respectivement importés dans le cluster. Chacun de ces répertoires abrite un nœud de périphérique pour chaque métapériphérique ou volume de ce jeu ou groupe de disques.

Dans le système SunPlex, chaque nœud de périphérique de l'espace de noms du gestionnaire de volumes local est remplacé par un lien symbolique vers un nœud de périphérique du système de fichiers /global/.devices/node@ID_nœud, où ID_nœud est un nombre entier représentant les nœuds du cluster. Les périphériques du gestionnaire de volumes continuent d'être représentés comme des liens symboliques par Sun Cluster, même à leur emplacement standard. L'espace de noms global et l'espace de noms du gestionnaire de volumes standard sont tous deux disponibles à partir de n'importe quel nœud du cluster.

L'espace de noms global présente les avantages suivants :

• 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.

Exemple 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 de 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ù dans le système et les processus sur tous les nœuds peuvent utiliser le même nom de chemin d'accès 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 informatives à haute disponibilité par le biais des interfaces fcntl(2). Les applications tournant sur plusieurs nœuds peuvent synchroniser l'accès aux données en utilisant ces fonctionnalités sur un fichier du système de fichiers de 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.

Le système de fichiers peut être monté globalement à l'aide de la commande mount -g ou localement en utilisant la commande mount.

Les programmes peuvent accéder au fichier d'un système de fichiers de cluster à partir de n'importe quel nœud et avec le 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. Autrement dit, les clients voient le système de fichiers sous-jacent (par exemple, UFS).

Utilisation des systèmes de fichiers de cluster

Dans le système SunPlex, tous les disques multihôtes sont placés dans des groupes de périphériques de disques, tels que des jeux 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 volumes du 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.

Tout comme les systèmes de fichiers classiques, les systèmes de fichiers de cluster peuvent être montés de deux manières :

• Manuellement : utilisez la commande mount avec les options de montage -g ou -o global pour monter le système de fichiers du 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 l'option de montage global pour monter le système de fichiers du cluster au moment de l'initialisation. Créez ensuite un point de montage sous le répertoire /global sur tous les nœuds. Le répertoire /global est un emplacement recommandé, mais non obligatoire. Voici une ligne d'échantillon d'un système de fichiers de cluster provenant d'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 d'attribution de noms particulière pour les systèmes de fichiers de cluster, mais vous pouvez faciliter l'administration en créant un point de montage pour tous les systèmes de fichiers du cluster sous le même répertoire, par exemple /global/groupe_périphériques_disques. Pour plus d'informations, consultez Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) et le Guide d'administration du système Sun Cluster pour SE Solaris.

Type de ressource HAStoragePlus

Le type de ressource HAStoragePlus est destiné à rendre hautement disponibles les configurations de systèmes de fichiers non globaux tels qu'UFS et VxFS. Il permet d'intégrer votre système de fichiers local à l'environnement Sun Cluster et de le rendre hautement disponible. HAStoragePlus fournit des fonctionnalités supplémentaires pour les systèmes de fichiers telles que les contrôles, les montages et les démontages forcés permettant à Sun Cluster de basculer sur des systèmes de fichiers locaux. 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.

Reportez-vous à la rubrique “ Enabling Highly Available Local File Systems” dans Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour obtenir des informations sur la manière d'utiliser le type de ressource HAStoragePlus.

HAStoragePlus peut aussi être utilisé pour synchroniser le démarrage des ressources et des groupes de périphériques de disques dont dépendent les ressources. Pour de plus amples informations, reportez-vous à la rubrique Ressources, groupes de ressources et types de ressources.

Option de montage Syncdir

L'option de montage syncdir peut être utilisée pour les systèmes de fichiers de cluster dont le système de fichiers sous-jacent est UFS. Toutefois, on constate une amélioration significative des performances lorsque syncdir n'est pas spécifié. Si vous spécifiez syncdir, les écritures sont garanties comme étant conformes à POSIX. Dans le cas contraire, vous aurez le même comportement qu'avec les systèmes de fichiers NFS. Par exemple, dans certains cas, sans syncdir, vous ne découvrirez que l'espace disponible est insuffisant qu'au moment où vous fermez 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. Il est rare que des problèmes se présentent si vous ne spécifiez pas syncdir, nous vous recommandons donc de ne pas spécifier cette option pour bénéficier des gains de performance.

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

Reportez-vous à la rubrique FAQ concernant les systèmes de fichiers pour consulter les questions fréquentes concernant les périphériques globaux et les systèmes de fichiers de cluster.

Contrôle de chemin de disque

La version actuelle du logiciel Sun Cluster prend en charge le contrôle de chemins de disques (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. Reportez-vous au document Sun Cluster System Administration Guide for Solaris OS pour de plus amples informations sur les procédures de contrôle, de désactivation du contrôle et de vérification du statut des chemins d'accès aux disques.

Le CCD n'est pas pris en charge par les nœuds exécutant des versions antérieures du Logiciel Sun Cluster 3.1 4/04. 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

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 intégrées à la commande scdpm vous permettent de contrôler les chemins d'accès aux disques d'un seul nœud ou de tous les nœuds du cluster. Reportez-vous à la page man scdpm( 1M) pour de plus amples informations sur les options de ligne de commande.

Les composants CCD sont installés à partir du package SUNWscu. Il est installé au cours de la procédure d'installation standard de Sun Cluster. Reportez-vous à la page man scinstall(1M) pour de plus amples informations sur l'interface d'installation. Le tableau suivant décrit l'emplacement d'installation par défaut des composants CCD :

Un démon CCD à multithread 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 survient, 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 rassemble les informations relatives aux chemins d'accès aux disques et aux noms des nœuds à partir du fichier d'état précédent ou à partir de la base de données du CCR. Reportez-vous à la rubrique Cluster Configuration Repository (CCR) pour de plus amples informations sur le 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 envoie une requête toutes les dix minutes, et teste l’état de chaque chemin d’accès aux disques inclu 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 notifie la structure d'évènement Sun Cluster et enregistre le nouveau statut du chemin à travers le mécanisme syslogd(1M) d'UNIX.

toutes les erreurs lié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 logique rendu visible par des pilotes multivoies tels que MPxIO, 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 aussi 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. Reportez-vous à la rubrique “ Administering Sun Cluster With the Graphical User Interfaces” du Sun Cluster System Administration Guide for Solaris OS pour de plus amples informations sur SunPlex Manager.

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 requis et est défini par défaut sur all s'il n'est pas 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. Reportez-vous à la page man 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 du 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 techniques conseillées pour 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 clusters est partitionnée.

Pour plus d'informations sur MAC, consultez “Appartenance au cluster” dans le manuel Présentation de Sun Cluster pour SE Solaris

Des partitions de cluster peuvent provoquer deux types de problèmes :

• 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 pense être unique car les nœuds d'une partition ne peuvent communiquer avec le nœud d'une 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 lorsque vous démarrez le cluster sur un nœud qui ne faisait pas partie de la dernière partition de cluster ayant fonctionné.

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 nœuds, 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 son vote 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 leurs votes en fonction du nombre de votes connectés au périphérique. Lorsque vous configurez un périphérique de quorum, le logiciel Sun Cluster lui attribue un nombre N-1 de votes où N est le nombre de votes connectés au périphérique de quorum. Par exemple, un périphérique de quorum connecté à deux nœuds 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.

La configuration des périphériques de quorum s'effectue au moment de l'installation, ou ultérieurement à l'aide des procédures décrites dans “Administration du quorum” dans le Guide d'administration du système 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, tous les nœuds ne peuvent pas 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 sous-ensemble ou partition peut croire qu'il/elle est le/la seul(e) à être propriétaire des périphériques multihôtes et à en posséder l'accès. Si plusieurs nœuds tentent d'écrire sur les disques, les données peuvent être altéré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 nœud 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 les périphériques multihôtes. Lorsqu'un membre du cluster fonctionnant comme nœud principal (propriétaire) du groupe de périphériques de disques échoue ou devient inaccessible, un nouveau nœud principal est choisi pour prendre le relais et accéder au groupe de périphériques de disques avec un minimum d'interruption. Au cours de ce processus, l'ancien nœud principal doit renoncer à l'accès aux périphériques avant 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.

Ce moyen, le système SunPlex le trouve dans la fonction de séparation en cas d'échec du mode de réservation des disques SCSI. 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.

Le système de réservation de disques SCSI-2 prend en charge un type de réservation pouvant soit donner accès à tous les nœuds reliés aux disques (lorsque aucune réservation n'est en place), soit restreindre l'accès à un seul nœud (détenant la réservation).

Lorsqu'un membre détecte qu'un autre nœud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le nœud d'accéder aux disques partagés. En présence d'une séparation en cas d'échec, il est normal que le nœud séparé panique et que des messages indiquant un « conflit de réservation » apparaissent sur sa console.

Le conflit de réservation a lieu parce qu'après qu'un nœud a été détecté comme n'appartenant plus au cluster, une réservation SCSI est placée sur l'ensemble des disques partagés entre ce nœud et les autres nœuds. Le nœud séparé n'est peut-être pas conscient de son état et s'il essaie d'accéder à un des disques partagés, il détecte la réservation et panique.

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

Le mécanisme par lequel le cluster assure qu'un nœud défectueux ne se réinitialise pas et ne commence pas à écrire sur le stockage partagé est appelé failfast .

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 disques, il donne au nœud la capacité de paniquer au cas où il ne pourrait accéder à un disque parce que ce dernier a été réservé par d'autres nœuds.

Avec MHIOCENFAILFAST, le pilote contrôle le retour d'erreur de toutes les opérations de lecture et d'écriture qu'un nœud réalise sur le disque pour le code d'erreur Reservation_Conflict. L'ioctl, en arrière-plan, lance périodiquement une opération de test sur le disque pour détecter la présence de Reservation_Conflict. Les chemins de flux de contrôle de premier plan et d'arrière plan paniquent tous deux 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 nœuds. Le mécanisme failfast fonctionne de la même manière avec 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 nœud faisant partie de la partition et pouvant atteindre un quorum place les réservations sur les disques partagés, et lorsque le nœud ne possédant pas de quorum tente d'accéder aux disques partagés, il reçoit un conflit de réservation et panique du fait de la présence du mécanisme failfast.

Après la panique, le nœud 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? avec eeprom(1M), à l'invite ok de la PROM OpenBoot sur un cluster SPARC ou avec l'utilitaire SCSI exécuté en option après l'initialisation du BIOS sur 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ù N périphériques de quorum sont chacun connectés à l'un des 1 à N nœuds et au nœud N+1, le cluster survit à la mort soit de tous les 1 à N nœuds, soit de l'un des N/ 2 nœuds. 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 mort de n'importe lequel des N- 1 nœuds. 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.

Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .

Respect des contraintes des périphériques de quorum

Vous devez respecter les conditions requises suivantes. Faute de quoi, vous risquez de compromettre la disponibilité de votre 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 SCSI-3 PGR

  • 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 à Figure 3–2.

Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .

Respect des techniques conseillées pour 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. Il est inutile de configurer un autre périphérique de quorum car vous disposez de la configuration 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 –

  Parfois, dans certains environnements particuliers, il peut être souhaitable de réduire la disponibilité globale du cluster pour répondre à 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 décrite dans Configurations de quorum atypiques , le cluster est moins disponible : Les votes du quorum excèdent les votes des nœuds. Le cluster se caractérise par le fait que si l'accès au stockage partagé entre les nœuds A et B est perdu, la totalité du cluster échouera.

  ---

  Pour les exceptions à cette règle, reportez-vous à 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. Reportez-vous à 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.

Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .

Configurations de quorum conseillées

Vous trouverez des exemples de configurations de quorum à éviter dans 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 venir des deux nœuds du cluster ou juste 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

Il est possible de configurer un cluster comportant plus de deux nœuds sans périphérique de quorum. Toutefois, dans ce cas, vous ne pourrez pas démarrer le cluster sans disposer de la majorité des nœuds du cluster.

Configurations de quorum atypiques

La Figure 3–3 suppose que vous exécutez des applications essentielles à une mission (base de données Oracle par exemple) sur les Nœud A et Nœud 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 les techniques conseillées en rapport avec cette exception, reportez-vous à Respect des techniques conseillées pour les périphériques de quorum.

Figure 3–3 Configuration atypique

Configurations de quorum déconseillées

De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .

Services de données

Le terme service de données décrit une application tierce telle que Sun Java System Web Server (anciennement Sun Java System Web Server) ou, pour les clusters SPARC, Oracle, 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émarrer

• l'arrêt ;

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

• Pour de plus amples informations sur les types de services de données, consultez la rubrique “Data Services” du Sun Cluster Overview for Solaris OS.

La Figure 3–4 compare une application fonctionnant sur un seul serveur d'applications (modèle de serveur unique) à la même application fonctionnant sur un cluster (modèle de serveur clusterisé). Notez que du point de vue de l'utilisateur, il n'y a aucune différence entre les deux configurations si ce n'est que l'application clusterisée peut être plus rapide et que son niveau de disponibilité est plus élevé.

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

Dans le modèle de serveur unique, l'application est configurée pour accéder au serveur à travers une interface de réseau public particulière (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 vous demandent de spécifier soit les noms d'hôtes logiques, soit les adresses partagées comme interfaces réseau : ils 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. Reportez-vous à l'installation et à la configuration de chaque service de données pour déterminer plus précisément le type d'interface que vous devez spécifier.

Une ressource réseau n'est pas associée à un serveur physique spécifique : elle peut se déplacer entre les serveurs physiques.

Une ressource réseau est initialement associée à un nœud, le nœud principal. Si ce nœud échoue, la ressource réseau et la ressource d'application basculent sur un autre nœud du cluster (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 aussi initialement associée à un nœud. Ce nœud s'appelle le nœud d'interface globale (ou nœud GIF). Une adresse partagée est utilisée comme interface de réseau unique vers le cluster. Elle est connue sous le nom d'interface globale.

La différence entre le modèle de nom d'hôte logique et le modèle de service évolutif est que dans ce dernier, chaque nœud possède aussi une adresse partagée activement configurée sur son interface de bouclage. Cette configuration permet d'avoir plusieurs instances d'un service de données actives sur plusieurs nœuds simultanément. 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 mise 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 de 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 de services de données

Le logiciel Sun Cluster intègre un ensemble de méthodes de gestion de services. Ces méthodes fonctionnent sous le contrôle du Resource Group Manager (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).

En plus des méthodes fournies par le logiciel Sun Cluster, le système SunPlex intègre également une API (interface de programme d'application) et plusieurs outils de développement de services de données. Ces outils permettent aux programmeurs de développer les méthodes de services de données nécessaires pour que les autres applications fonctionnent comme des services de données à haute disponibilité 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 les ressources des instances d'application et les 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 rencontre une erreur, il essaie soit de redémarrer l'instance sur le même nœud, soit de la démarrer sur un autre nœud (basculement), selon 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 deux groupes de ressources : un groupe de ressources évolutif contenant les ressources d'application, et un groupe de ressources de basculement contenant 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 services arrivent au cluster à travers une interface réseau unique (interface globale) et sont réparties entre les nœuds en fonction de l'un des algorithmes prédéfinis par la règle d'équilibrage de la charge. Le cluster peut utiliser cette règle pour équilibrer la charge de service entre plusieurs nœuds. Notez qu'il peut y avoir plusieurs interfaces globales sur des nœuds différents hébergeant 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 de fonctionnement é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é. Si aucun nœud n'est disponible, l'instance d'application continue de fonctionner sur les nœuds restants et peut ainsi entraîner une dégradation des performances du service.

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 montre un exemple de groupe de ressources évolutif et de groupe de ressources de basculement avec leurs dépendances dans le cadre de services évolutifs. Cet exemple présente trois groupes de ressources. Le groupe de ressources de basculement contient les ressources d'application des serveurs DNS à haute disponibilité et les ressources réseau utilisées à la fois par les serveurs DNS 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 qu'il existe des dépendances entre les groupes de ressources évolutifs et de basculement (lignes continues) et que toutes les ressources d'application Apache dépendent de la ressource réseau schost-2, qui est une adresse partagée (ligne en trait tireté).

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 et sticky. Sur un service pur, n'importe quelle instance peut répondre aux requêtes du client. Sur un service sticky, le client envoie les requêtes à 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 dans un cluster à trois nœuds, chaque nœud supporte une charge de 1. Chaque nœud servira 1/3 des requêtes d'un client pour le compte de ce service. Les charges peuvent être modifiées à tout moment par l'administrateur à l'aide de l'interface de la commande scrgadm(1M) ou de l'interface utilisateur graphique de gestion de SunPlex.

Un service sticky peut être de deux types : 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 connections TCP simultanées. Le client est dit « sticky » par rapport à cette instance de serveur écoutant sur un seul port. 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 en utilisant trois connexions TCP différentes, mais les connexions échangent entre elles des informations de session en mémoire cache lors de l'exécution du service.

La généralisation d'une règle sticky s'étend à plusieurs services évolutifs échangeant des informations de session en arrière-plan au même moment. Lorsque ces services échangent des informations de session en arrière plan au même moment, le client est dit « sticky » par rapport à ces multiples instances de serveur sur le même nœud écoutant sur des ports différents.

Par exemple, le client d'un site de commerce électronique remplit sa carte d'achats en utilisant le protocole HTTP ordinaire sur le port 80, mais il bascule vers le protocole SSL sur le port 443 pour envoyer les données sécurisées relatives au paiement de ces achats par carte de crédit.

Les services sticky joker utilisent des numéros de ports assignés de manière dynamique, mais attendent toujours des requêtes du client qu'elles aillent vers le même nœud. Le client est dit « sticky joker » sur les ports par rapport à la même adresse IP.

Un bon exemple de cette règle est le protocole FTP en mode passif. Un client se connecte à un serveur FTP sur le port 21 et est ensuite informé par le serveur de se connecter de nouveau à un serveur de ports d'écoute sur une plage de ports dynamiques. Toutes les requêtes pour cette adresse IP sont envoyées au même nœud ; celui que le serveur a désigné au client à travers les informations de contrôle.

Notez que pour chacune de ces règles sticky, la règle de la charge pondérée est activée par défaut, ainsi, la requête initiale d'un client est dirigée vers l'instance désignée par l'équilibreur de la charge. Après que le client a défini une affinité pour le nœud où fonctionne l'instance, les requêtes futures sont dirigées vers cette instance sous réserve que le nœud soit accessible et que la règle d'équilibrage de la charge ne soit pas modifiée.

Vous trouverez ci-après des détails complémentaires concernant des règles d'équilibrage de la charge spécifiques.

• 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 par la valeur équilibrage_lignes_pondéré de la propriété poids_équilibrage_lignes. 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. Si on a X = charge et A = la charge totale de tous les nœuds en activité, un nœud actif supportera approximativement X/A du total des nouvelles connexions, lorsque le nombre total de connexions est suffisamment élevé. Cette règle ne s'applique pas à des requêtes individuelles.

  Notez qu'elle ne fonctionne pas à tour de rôle. Si c'était le cas, chaque requête d'un client irait vers un nœud différent : la première requête 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 par la valeur équilibrage_lignes_sticky de la propriété de la ressource règle_équilibrage_charge.

• Sticky joker. Cette règle est un sur-ensemble de la règle « sticky » ordinaire. Dans 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 par la valeur équilibrage_lignes_sticky_joker de la propriété de la ressource règle_équilibrage_charge.

Paramètres de rétablissement

Les groupes de ressources basculent d'un nœud vers un autre nœud. Lorsque ce basculement se produit, le nœud secondaire d'origine devient principal. Les paramètres de rétablissement spécifient les actions qui auront lieu lorsque le nœud principal d'origine sera 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. L'option choisie peut être spécifiée à l'aide du paramètre rétablissement de la propriété du groupe de ressources.

Dans certains cas, si le nœud d'origine hébergeant le groupe de ressources échoue et se réinitialise souvent, la définition du paramètre de rétablissement pourrait réduire la disponibilité du groupe de ressources.

Détecteurs de pannes des services de données

Chaque service de données SunPlex intègre un détecteur de pannes sondant périodiquement le service de données 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. Sur la base des informations retournées par les sondes, des actions prédéfinies telles que le redémarrage des démons ou le déclenchement d'un basculement peuvent être initiées.

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 l'application que vous voulez faire fonctionner comme service évolutif ou de basculement ne fait pas partie de celles proposées par Sun, vous pouvez utiliser une API ou l'API DSET pour la configurer comme service évolutif ou de basculement.

Un ensemble de critères permet de déterminer si une application peut ou non devenir un service de basculement. Les critères spécifiques sont présentés dans la documentation SunPlex décrivant les API susceptibles d'être utilisées pour votre application.

Nous présentons ici quelques directives pour vous aider à déterminer si votre service peut ou non tirer profit d'une architecture de services de données évolutifs. Reportez-vous à la rubrique Services de données évolutifs pour de plus amples informations sur les services évolutifs.

Les nouveaux services remplissant les critères présentés ci-après peuvent utiliser les services évolutifs. Si un service existant ne correspond pas exactement à ces critères, certaines parties risquent de devoir être récrites.

Un service de données évolutifs a les caractéristiques suivantes : Premièrement, il est composé d'une ou 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.

Deuxièmement, si le service procure un stockage de données logique externe, l'accès simultané de plusieurs instances de serveur à ce stockage doit être synchronisé pour éviter de perdre des mises à jour ou de lire des données tandis qu'il est modifié. Notez que nous utilisons le terme « externe » pour distinguer le dispositif de stockage de la mémoire interne et le terme « logique » parce que le dispositif de stockage apparaît comme une entité unique, bien qu'il puisse lui-même être répliqué. En outre, ce stockage de données logique possède une propriété grâce à laquelle chaque fois qu'une instance de serveur met à jour les données stockées, la mise à jour est immédiatement vue par les autres instances.

Le système SunPlex fournit ce stockage externe à travers son système de fichiers de cluster et ses partitions de données 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. Lorsque plusieurs instances de ce service fonctionnent, chacune d'elles a accès à ce journal externe et elles peuvent y accéder simultanément. Les instances doivent alors synchroniser leur accès pour éviter toute interférence entre elles. Le service peut utiliser le système de verrouillage de fichiers ordinaire de Solaris via fcntl(2) et lockf(3C) pour effectuer cette synchronisation.

Les bases de données back-end, telles qu'Oracle grande disponibilité ou Oracle Real Application Clusters pour les clusters basés sur SPARC constituent un autre exemple de ce type de stockage. Notez que ce type de serveur de base de données back-end possède un dispositif de synchronisation muni d'un système de requêtes à la base de données ou de transactions de mises à jour ; ainsi les instances de serveur n'ont pas besoin d'implémenter leur propre synchronisation.

Le serveur Sun IMAP tel qu'il se présente à l'heure actuelle 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.

Enfin, notez que les instances peuvent avoir des données privées se détachant des données d'autres instances. Dans ce cas, le service n'a pas à se préoccuper de la synchronisation des accès, car les données sont privées et seule cette instance peut les manipuler. Vous devez alors prendre garde à ne pas stocker ces données privées sous le système de fichiers du cluster car elles ont la capacité de devenir globalement accessibles.

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

Le système SunPlex intègre les éléments suivants permettant de rendre les applications hautement disponibles :

• des services de données intégrés au système SunPlex ;

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

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

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

Le manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS explique comment installer et configurer les services de données fournis avec le système SunPlex. Le manuel Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) explique comment paramétrer d'autres applications pour les rendre hautement disponibles dans le cadre de la structure Sun Cluster.

Les API Sun Cluster permettent aux programmeurs de développer des détecteurs de pannes et des scripts démarrant et arrêtant les instances des services de données. Grâce à ces outils, une application peut devenir un service de données évolutif ou de basculement. En outre, le système SunPlex intègre un service de données « générique » pouvant être utilisé pour générer rapidement les méthodes de démarrage et d'arrêt d'une application afin de la faire fonctionner comme service évolutif ou de basculement.

Utilisation de l'interconnexion de cluster pour le trafic des 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 de clustering fait appel à de nombreuses interconnexions pour optimiser la disponibilité et les performances. Pour le trafic interne (par exemple, les données des systèmes de fichiers ou des services évolutifs), les messages sont répartis à tour de rôle sur toutes les interconnexions disponibles.

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, l'application doit adopter les noms d'hôtes privés configurés lors de l'installation du cluster. Par exemple, si le nom d'hôte privé pour le nœud 1 est clusternode1-priv, utilisez ce nom pour communiquer sur l'interconnexion de cluster vers le nœud 1. Les sockets TCP ouverts avec ce nom sont routés sur l'interconnexion de cluster et peuvent être reroutés de manière transparente en cas de panne réseau.

Veuillez noter que comme les noms d'hôte privés peuvent être configurés durant l'installation, l'interconnexion de cluster peut utiliser n'importe quel nom choisi à ce moment-là. Le nom réel peut être obtenu à l'aide de la commande scha_cluster_get(3HA) suivie de l'argument scha_privatelink_hostname_node.

Lors de l'utilisation de l'interconnexion du cluster pour les applications, une seule interconnexion est établie entre deux nœuds d'une paire, mais des interconnexions distinctes sont, si possible, utilisées entre les différentes paires de nœuds. Supposons par exemple qu'une application tournant sur trois nœuds SPARC communique sur l'interconnexion de cluster. La communication entre les nœuds 1 et 2 peut avoir lieu sur l'interface hme0 et la communication entre les nœuds 1 et 3 sur l'interface qfe1. Autrement dit, les communications d'une application entre deux nœuds sont limitées à une simple interconnexion, tandis que les communications sur cluster interne sont réparties sur toutes les interconnexions.

Veuillez noter que l'application partage l'interconnexion avec le trafic de cluster interne et, de ce fait, que la bande passante à la disposition de l'application dépend de la bande passante utilisée par le reste du trafic. En présence d'une défaillance, le trafic interne est acheminé tour à tour vers les autres interconnexions et les connexions des applications sont basculées vers une interconnexion en état de marche.

Deux types d'adresse prennent en charge l'interconnexion du cluster, et la commande gethostbyname(3N) sur un nom d'hôte privé renvoie normalement deux adresses IP. La première adresse est appelée adresse de paire logique et la seconde adresse logique par nœud.

Une adresse de paire logique distincte est attribuée à chaque paire de nœuds. Ce petit réseau logique prend en charge la reprise des connexions. Une adresse par nœud fixe est également attribuée à chaque nœud. Autrement dit, les adresses de paires logiques de clusternode1-priv sont différentes sur chaque nœud, tandis que l'adresse logique par nœud de clusternode1-priv est la même sur chaque nœud. Un nœud ne comporte toutefois pas d'adresse de paire logique le désignant, de ce fait, la commande gethostbyname(clusternode1-priv) sur le nœud 1 ne renvoie que l'adresse par nœud logique.

Veuillez noter que les applications acceptant des connexions sur l'interconnexion de cluster et vérifiant ensuite l'adresse IP pour des raisons de sécurité doivent procéder à une nouvelle vérification de toutes les adresses IP renvoyées par la commande gethostbyname, et non pas simplement la première.

Si vous avez besoin d'adresses IP cohérentes à tout moment dans votre application, configurez-la pour être liée à l'adresse par nœud du côté client et du côté serveur de sorte que toutes les connexions semblent provenir et se diriger vers cette adresse par nœud.

Ressources, groupes de ressources et types de ressources

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

Les services de données sont des types de ressource. Par exemple, Sun Cluster HA for Oracle est le type de ressource SUNW.oracle-server et Sun Cluster HA for Apache est le type de ressource SUNW.apache.

le type de ressources SUNW.oracle-server est uniquement utilisé sur les clusters SPARC.

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 de type SUNW.LogicalHostname ou SUNW.SharedAddress. Ces deux types de ressource sont préenregistrés dans le logiciel Sun Cluster.

Les types de ressources SUNW.HAStorage et HAStoragePlus servent à synchroniser le démarrage des ressources et les groupes de périphériques de disques dont dépendent les ressources. Vous avez ainsi l'assurance qu'avant qu'un service de données ne démarre, les chemins vers les points de montage du système de fichiers du cluster, les périphériques globaux et les noms des groupes de périphériques sont disponibles. Pour de plus amples informations, reportez-vous à la rubrique “Synchronizing the Startups Between Resource Groups and Disk Device Groups” du document Data Services Installation and Configuration Guide (le type de ressource HAStoragePlus est désormais disponible dans Sun Cluster 3.0 5/02 et intègre une autre fonction permettant aux systèmes de fichiers locaux d'être hautement disponibles ; pour de plus amples informations sur cette fonction, reportez-vous à la rubrique Type de ressource HAStoragePlus).

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

lorsque vous introduisez un groupe de ressources contenant des ressources d'application en ligne, l'application s'exécute. La méthode de démarrage du service de données attend que l'application soit lancée et qu'elle fonctionne 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. Reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples informations sur cette procédure.

Resource Group Manager (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 des 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.Sous l'action du RGM, les ressources et les groupes de ressources passent de l'état en ligne à l'état hors ligne. Vous trouverez une description complète des états et paramètres applicables aux ressources et groupes de ressources à la rubrique Paramètres et états des ressources et groupes de ressources. Reportez-vous au document Ressources, groupes de ressources et types de ressources pour de plus amples informations sur la procédure de lancement d'un projet de gestion de ressources sous le contrôle du gestionnaire du groupe de ressources.

Paramètres et états des ressources et 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 met les groupes de ressources à différents « é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 demander qu'un groupe de ressources soit géré ou non géré par 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 être géré avant que toute ressource placée dans le groupe ne devienne active.

  Dans certains serveurs de données comme les serveurs Web évolutifs, des tâches doivent être effectuées avant le démarrage et après l'arrêt des ressources réseau. 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ésident 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 le plus souvent utilisées pour les ressources réseau de services évolutifs, mais elles peuvent aussi être utilisées pour toute opération d'initialisation ou de nettoyage non faite 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, pour une raison ou une autre, vous souhaitez rendre cette ressource indisponible sur tous les nœuds du cluster, désactivez-la. 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 au cours des reconfigurations du cluster au moment des commutations et des basculements. Ils peuvent aussi être modifiés à travers des actions d'administration. La commande scswitch(1M) permet de mettre en ligne ou hors ligne une ressource ou 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 déconnecté, toutes ses ressources le sont aussi. Si un groupe de ressources est connecté, toutes ses ressources activées le sont aussi.

  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 attribuer des propriétés aux ressources et groupes de ressources de vos services de données SunPlex. 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 connaître le jeu de propriétés standard, reportez-vous à la rubrique “ Standard Properties” du document 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 de projets de services de données

Les services de données peuvent être configurés pour démarrer sous un nom de projet Solaris lorsqu'ils sont connectés à 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 correspondance entre votre ressource ou groupe de ressources et une ID de projet vous permet d'utiliser les outils de contrôle sophistiqués de l'environnement Solaris pour gérer les charges de travail et la consommation au sein du cluster.

cette configuration n'est possible que si la version actuelle du logiciel Sun Cluster fonctionne sous Solaris 9.

L'utilisation des fonctions de gestion de Solaris dans un environnement de cluster vous permet d'assurer que les applications les plus importantes gardent la priorité lorsqu'un nœud est partagé 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 fonctions de gestion décrites ci-dessus permettent d'améliorer la disponibilité d'une application critique en empêchant d'autres applications non prioritaires de consommer trop de ressources du système tel que le temps CPU.

la documentation Solaris se rapportant à cette fonction désigne le temps CPU, les processus, les tâches et les composants similaires sous le terme de « ressources ». La documentation Sun Cluster utilise quant à elle le terme de « ressources » pour désigner les entités sous le contrôle du RGM. Dans la rubrique suivante, on utilisera le terme de« ressource » en référence aux entités de Sun Cluster qui sont sous le contrôle du RGM et le terme de « ressources système » en référence au temps CPU, aux processus et aux tâches.

Cette rubrique 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é. Cette rubrique présente également plusieurs scénarios de basculement et des suggestions pour l'utilisation des fonctions de gestion de l'environnement Solaris. Pour consulter la documentation complète de la fonction de gestion, reportez-vous à la rubrique System Administration Guide: Resource Management and Network Services de la Solaris 9 System Administrator Collection.

Pour configurer des ressources ou groupes de ressources en vue de l'utilisation des fonctions de gestion Solaris dans un cluster, procédez de la manière suivante :

1. Configurez les applications dans la ressource.

2. Configurez les ressources dans le groupe de ressources.

3. Activez les ressources du groupe de ressources.

4. Mettez le groupe de ressource à l'état géré.

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

6. Configurez les 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 Nom_projet_ressource ou Nom_projet_GR afin d'associer l'ID de 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. Reportez-vous à la rubrique “Standard Properties” du Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples informations sur les propriétés. Reportez-vous aux documents r_properties(5) et rg_properties(5) pour de plus amples informations sur les propriétés.

Le nom de projet spécifié doit figurer dans la base de données des projets (/etc/project) et le superutilisateur doit être configuré comme membre du projet nommé. Reportez-vous à la rubrique “Projects and Tasks” du document System Administration Guide: Resource Management and Network Services de la collection Solaris 9 System Administratorpour de plus amples informations concernant la conception de la base données de noms de projets. Reportez-vous à la rubrique project( 4) pour consulter la description de la syntaxe des fichiers de projets.

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 de projet ne sera effectif qu'au moment où la ressource ou le groupe de ressources aura été mis hors ligne puis de nouveau 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. Reportez-vous à la rubrique dispadmin(1M) pour consulter la procédure de définition de FSS comme programmateur par défaut. Consultez également les documents priocntl(1), ps(1) et FSS(7) pour de plus amples informations.

• 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 les services de données pour l'utilisation des fonctions de contrôle de Solaris dans un environnement Sun Cluster, vous devez décider de la manière dont vous souhaitez contrôler et suivre les ressources au cours des commutations et des basculements. Veillez à identifier les dépendances au sein du 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. Pour identifier les priorités de la liste de nœuds de votre groupe de ressources, utilisez les propriétés de groupes de ressources liste_nœuds, rétablissement, éléments_principaux_max et éléments_principaux_souhaités configurées avec scrgadm(1M). Reportez-vous à la rubrique “Relationship Between Resource Groups and Disk Device Groups” du Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour obtenir une brève description des dépendances entre les groupes de ressources et les groupes de périphériques de disques dans la liste de nœuds. Pour obtenir une description détaillée des propriétés, reportez-vous à la rubrique rg_properties(5).

Pour déterminer les priorités des groupes de périphériques de disques dans la liste de nœuds, utilisez les propriétés prédilection et rétablissement configurées avec scrgadm( 1M) et scsetup( 1M). Pour des informations relatives à la procédure, reportez-vous à la rubrique “How To Change Disk Device Properties” de la section “ Administering Disk Device Groups” du Sun Cluster System Administration Guide for Solaris OS. Reportez-vous à la rubrique Les composants matériels et logiciels du système SunPlex pour obtenir des informations théoriques concernant la configuration des nœuds et le comportement des services de données évolutifs ou de basculement.

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 doivent être identiques pour toutes les applications dans les fichiers de configuration de tous les nœuds. Tous les projets associés à l'application doivent au moins être accessibles par la base de données du projet sur tous les maîtres potentiels de cette application. Supposons que l'application 1 est contrôlée par phys-schost-1 mais qu'elle peut être potentiellement commutée ou 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 projet peuvent être placées dans un fichier de base de données /etc/project local ou stockées dans la mappe NIS ou le service de répertoire LDAP.

L'environnement Solaris permet une configuration souple des paramètres d'utilisation et peu de restrictions 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. Reportez-vous à la rubrique rctladm( 1M) pour de plus amples informations sur la définition de la valeur de process.max-address-space.

Lorsque vous utilisez les fonctions de contrôle de gestion avec Sun Cluster, veillez à configurer les limites de la mémoire de manière à éviter les basculements intempestifs des applications et un effet « ping-pong » sur celles-ci. En général :

• 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 de cluster, une application est configurée dans la ressource et une ressource est configurée dans un groupe de ressources (GR). Lorsqu'un échec se produit, le groupe de ressources et ses applications 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 assurer que chaque hôte physique (phys-schost-1, phys-schost-2) fonctionne comme maître par défaut d'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 la base de données de projets des deux nœuds. Lorsque le cluster fonctionne normalement, chaque application tourne sur son maître par défaut, où le temps CPU 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 dans le fichier /etc/project spécifie que 4 parts sont attribuées à l'application 1 et 1 part à 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. Toutefois, le pourcentage de temps CPU disponible pour chaque application peut changer en fonction du nombre de parts attribuées à chaque processus demandant 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 et le deuxième hôte (phys-schost-2 ) comme maître par défaut des deux autres applications. 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 CPU parce que c'est la seule application qui demande du temps CPU sur ce nœud. Trois et deux parts sont respectivement allouées 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 produit et que l'application 1 bascule 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 CPU.

• 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 CPU.

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 la base de données de projets des nœuds principaux et secondaires ont la même configuration.

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 schéma suivant illustre le fonctionnement de cette configuration en situation normale et en cas de basculement, où GR-2 contenant 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 attribuées à chaque application demandant du temps CPU.

Adaptateurs de réseau public et IP Network Multipathing

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 IPMP (Internet Protocol Network Multipathing) Solaris de Sun Cluster intègre les mécanismes de base permettant le contrôle des adaptateurs de réseaux publics et le basculement des adresses IP d'un adaptateur à l'autre, lorsqu'une panne est détectée. Chaque nœud du cluster a sa propre configuration de IP Network Multipathing, pouvant être différente de celle des autres nœuds.

Les adaptateurs de réseau public sont organisés en groupes IPMP (groupes de multi-acheminement). Chaque groupe de multi-acheminement possède un ou plusieurs adaptateurs de réseau public. Chaque adaptateur d'un groupe de multi-acheminement peut être actif ; vous pouvez aussi configurer des interfaces de réserve qui restent inactives jusqu'au moment d'un basculement. Le démon de multi-acheminement in.mpathd utilise une adresse IP de test pour détecter les pannes et réparations. S'il détecte une panne sur l'un des adaptateurs, un basculement a lieu. Tous les accès réseau basculent de l'adaptateur défaillant sur un adaptateur en état de marche du groupe de multi-acheminement et la connexion du nœud au réseau public est ainsi maintenue. Si une interface de réserve a été configurée, le démon choisit l'interface de réserve. Sinon, in.mpathd choisit l'interface ayant le moins d'adresses IP. Le basculement se produisant au niveau de l'interface de l'adaptateur, les connexions de niveaux supérieurs telles que TCP ne sont pas affectées, sauf pendant un laps de temps très bref, au moment du basculement. Lorsque le basculement des adresses IP se fait dans de bonnes conditions, des diffusions ARP sont envoyées en supplément. La connexion aux clients distants est donc maintenue.

le protocole TCP possédant des fonctions de récupération des encombrements, ses extrémités peuvent souffrir de retards supplémentaires après un basculement réussi, car certains segments peuvent se perdre au cours du basculement et provoquer l'activation du mécanisme de contrôle des encombrements.

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 multi-acheminement 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 logique et d'adresse partagée, reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

le mécanisme de IP Network Multipathing a été conçu pour détecter et masquer les pannes des adaptateurs. Il n'est pas destiné à récupérer d'une erreur d'un administrateur utilisant la commande ifconfig(1M) pour supprimer une des adresses IP logiques (ou partagées). Le logiciel Sun Cluster affiche les adresses IP logiques et partagées comme des ressources gérées par le RGM. L'administrateur doit ajouter ou supprimer une adresse IP à l'aide de la commande scrgadm(1M) pour modifier le groupe de ressources contenant la ressource.

Pour de plus amples informations sur la fonction de multi-acheminement sur réseau IP de Solaris, reportez-vous à la documentation adéquate de l'environnement d'exploitation Solaris installé sur votre 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 4/04 est développée par phases successives. Cette rubrique propose des explications et des observations concernant la prise en charge de la fonction DR par Sun Cluster 3.1 4/04.

Notez que 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 de quiescence de l'environnement d'exploitation). Reportez-vous donc à la documentation relative à la DR de Solaris 8 avant d'utiliser la fonction DR du logiciel Sun Cluster. Relisez surtout les conditions applicables aux périphériques ES hors réseau dans le cadre d'une opération DR de détachement. 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 être téléchargés à l'adresse http://docs.sun.com.

SPARC: description générale de la reconfiguration dynamique

La fonction de reconfiguration dynamique permet de supprimer des éléments matériels sur des systèmes en cours de fonctionnement. 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. Elle affecte ainsi tous les composants de la 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.

La suppression d'une carte contenant des composants actifs entraînerait 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, la suppression d'une carte à l'aide de la DR n'est jamais risquée puisque le sous-système de la DR rejette l'opération si la carte contient des composants actifs.

Une opération d'ajout de carte avec la DR est également sans danger. Les CPU et la mémoire d'une nouvelle carte sont automatiquement mises en service par le système. Toutefois, l'administrateur système doit configurer manuellement le cluster pour pouvoir utiliser les composants de la nouvelle carte de manière active.

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. Toutefois, alors que le niveau inférieur décrit l'erreur, le niveau supérieur se contente d'indiquer « Unknown error ». Ce message doit être ignoré des administrateurs système.

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: Reconfiguration dynamique et CPU

Le logiciel Sun Cluster ne rejette pas une opération de suppression de carte par reconfiguration automatique en raison de la présence de 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: Reconfiguration dynamique et mémoire

Dans le cadre de la reconfiguration dynamique, il faut distinguer deux types de mémoire. Ces deux types ne diffèrent qu'au niveau de l'utilisation. Le matériel utilisé est le même.

La mémoire utilisée par le système d'exploitation est appelée panier de la mémoire du noyau. Le logiciel Sun Cluster ne prend pas en charge la suppression d'une carte contenant le panier de la mémoire du noyau, il rejette ce type d'opération. Lorsque l'opération de suppression concerne une autre mémoire, Sun Cluster ne rejette pas l'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: reconfiguration dynamique et 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 exécutées sur des lecteurs non actifs dans le nœud principal et sur n'importe quel lecteur du 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 obtenir des informations sur les périphériques de quorum et sur la procédure de reconfiguration dynamique les concernant, reportez-vous à la rubrique SPARC: reconfiguration dynamique et périphériques de quorum.

Reportez-vous à la rubrique “ Plan des tâches : reconfiguration dynamique avec périphériques de quorum” du Guide d'administration du système Sun Cluster pour SE Solaris pour des instructions détaillées sur l'exécution de ces tâches.

SPARC: reconfiguration dynamique et périphériques de quorum

Si l'opération de suppression de carte par reconfiguration dynamique concerne une carte contenant une interface vers un périphérique de quorum, Sun Cluster rejette l'opération et identifie le périphérique de quorum qui serait affecté par l'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.

Reportez-vous à la rubrique “ Plan des tâches : reconfiguration dynamique avec périphériques de quorum” Guide d'administration du système Sun Cluster pour SE Solaris pour des instructions détaillées sur l'exécution de ces tâches.

SPARC: reconfiguration dynamique et interfaces d'interconnexion de Cluster

Si l'opération de suppression de carte par reconfiguration dynamique concerne une carte contenant une interface d'interconnexion du cluster active, Sun Cluster rejette l'opération et identifie l'interface qui serait affectée par l'opération. Vous devez utiliser un outil d'administration de Sun Cluster pour désactiver l'interface active avant l'opération de reconfiguration dynamique (voir également les précautions à prendre répertoriées ci-dessous).

Reportez-vous à la rubrique “ Administration des interconnexions de cluster” dans le Guide d'administration du système Sun Cluster pour SE Solaris pour des instructions détaillées sur l'exécution de ces actions.

Sun Cluster exige que chaque nœud du cluster possède au moins un chemin fonctionnel vers les autres 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.

SPARC: reconfiguration dynamique et interfaces de réseau public

Si l'opération de suppression de carte par reconfiguration dynamique concerne une carte contenant une interface de réseau public active, Sun Cluster rejette l'opération et identifie l'interface qui serait affectée par l'opération. Avant de supprimer une carte où se trouve une interface de réseau active, tout le trafic sur cette interface doit être basculé vers une autre interface active du groupe de multi-acheminement à l'aide 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.

Reportez-vous à la rubrique “ Administration du réseau public” dans le Guide d'administration du système Sun Cluster pour SE Solaris pour des instructions détaillées sur l'exécution d'une suppression DR sur une interface de réseau public.