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

• Quorum et périphériques de quorum

• Gestionnaires de volumes

• 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 multi-acheminement sur réseau IP

• Prise en charge de la reconfiguration dynamique

Administration du cluster et développement d'applications

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 de fond pour l'installation, la configuration et l'administration du logiciel de cluster. Les développeurs d'applications y trouveront les informations nécessaires à la compréhension de l'environnement de cluster dans lequel ils travailleront.

La figure suivante présente une vue d'ensemble des correspondances entre les notions fondamentales d'administration du cluster et son architecture.

Figure 3–1 Architecture du logiciel Sun Cluster

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 certaines tâches du cluster. Reportez-vous au chapitre d'introduction du Guide d'administration système de Sun Cluster 3.1 pour obtenir une description complète des interfaces d'administration.

Heure du cluster

L'heure entre tous les noeuds du cluster doit être synchronisée. La synchronisation éventuelle des noeuds 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 noeuds.

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 noeud du cluster, vous avez la possibilité de modifier la date et l'heure par défaut du noeud. 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 noeud installé) établissant une relation d'homologues entre tous les noeuds du cluster, un noeud étant désigné comme le « préféré ». Les noeuds sont identifiés par leurs noms d'hôtes privés et la synchronisation de l'heure a lieu à travers l'interconnexion de cluster. Vous trouverez les instructions concernant la configuration du cluster pour NTP dans le Guide d'installation du logiciel Sun Cluster 3.1.

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 celle était mal définie lors de l'installation de l'environnement d'exploitation Solaris et que vous souhaitez la modifier, vous trouverez des directives dans le Guide d'administration système de Sun Cluster 3.1.

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

Le tableau suivant présente 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 noeud et crée un nouveau serveur équivalent pour les ressources de la structure sur un autre noeud. Les ressources de la structure ne sont toutes indisponibles à aucun moment. Celles n'ayant pas été affectées par l'échec d'un noeud sont totalement disponibles durant la récupération. En outre, celles du noeud 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 noeud. Les applications ne s'aperçoivent simplement pas que le serveur de la ressource a été déplacé vers un autre noeud. L'échec d'un seul noeud est totalement transparent pour les programmes sur les autres noeuds utilisant les fichiers, les périphériques et les volumes de disques rattachés à ce noeud, tant qu'il existe un autre chemin d'accès matériel aux disques depuis un autre noeud. On peut par exemple utiliser des disques multihôtes ayant des ports connectés à plusieurs noeuds.

Moniteur d'appartenance au cluster (MAC)

Le moniteur d'appartenance au cluster (MAC) est un ensemble d'agents répartis (un agent par membre du cluster). Ces agents échangent des messages sur l'interconnexion du cluster pour :

• appliquer une vue cohérente de l'appartenance sur tous les noeuds (quorum) ;

• piloter une reconfiguration synchronisée en réponse aux modifications d'appartenance, à l'aide de rappels enregistrés ;

• gérer le partitionnement du cluster (split brain , amnésie) ;

• assurer la connectivité totale entre tous les membres du cluster.

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

Appartenance au cluster

La fonction principale du MAC est d'établir des accords au niveau du cluster entre tous les noeuds participant à l'activité du cluster à un moment donné. Cette contrainte s'appelle l'appartenance au cluster.

Pour déterminer l'appartenance au cluster et finalement assurer l'intégrité des données, le moniteur d'appartenance au cluster :

• Comptabilise les modifications d'appartenance au cluster, telles qu'un noeud rejoignant ou quittant le cluster.

• Veille à ce qu'un « mauvais » noeud quitte le cluster.

• Veille à ce qu'un « mauvais » noeud reste en dehors du cluster tant qu'il n'a pas été réparé.

• Empêche le cluster de se partitionner en sous-ensembles de noeuds.

Reportez-vous à la rubrique Quorum et périphériques de quorum pour obtenir de plus amples informations sur la manière dont le cluster se protège lui-même des partitions en plusieurs clusters.

Reconfiguration du moniteur d'appartenance au cluster

Pour assurer que les données ne s'altèrent pas, tous les noeuds 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 noeuds 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.

Mécanisme failfast

Si le MAC détecte un problème critique sur un noeud, il fait appel à la structure du cluster pour arrêter le noeud 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 noeud de deux manières.

• Si un noeud quitte le cluster puis tente de démarrer un nouveau cluster sans avoir de quorum, il est « séparé » pour être empêché d'accéder aux disques partagés. Reportez-vous à la rubrique 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 noeud 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 noeud peut soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBoot^TM (OBP). L'action retenue est déterminée par la définition du paramètre auto-boot? de l'OBP.

Cluster Configuration Repository (CCR)

Le Cluster Configuration Repository (CCR) est une base de données privée sur le l'ensemble du cluster pour le stockage d'informations relatives à la configuration et à l'état du cluster. C'est une base de données distribuée. Chaque noeud maintient une copie complète de la base de données. Le CCR garantit que tous les noeuds ont une vue cohérente du « monde » du cluster. Pour éviter l'altération des données, chaque noeud a besoin de connaître l'état en cours des ressources du cluster.

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 noeuds. Une mise à jour manuelle de ces fichiers peut provoquer l'arrêt d'un noeud 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 noeud, indépendamment de l'emplacement auquel est physiquement rattaché le périphérique. En général, si un noeud 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 noeud 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 noeud.

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 noeuds 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 noeuds 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 noeud à l'autre, modifiant ainsi les conventions d'attribution de nom des périphériques Solaris. Le noeud 1 peut par exemple considérer un disque multihôte comme c1t2d0, et le noeud 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 noeuds utilisent. Ainsi, chaque noeud 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 de plus amples informations, reportez-vous aux pages de manuel correspondantes.

Groupes de périphériques de disques

Dans le système SunPlex, tous les disques multihôtes doivent être sous le contrôle de Sun Cluster. Vous créez d'abord les groupes de disques du gestionnaire de volumes (ensembles de disques Solaris Volume Manager ou groupes de disques VERITAS Volume Manager) 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 noeud 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 noeud 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 noeud 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 noeud 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 au chapitre de présentation du document Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur l'association de groupes de périphériques de disques et de groupes de ressources.

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 noeud 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é à plus d'un noeud, tous les groupes de périphériques de ce boîtier sont accessibles via un autre chemin en cas d'échec du noeud 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–2 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_noeuds_secondaires . La propriété prédilection permet de déterminer l'ordre dans lequel les noeuds tentent de prendre le contrôle en cas de basculement. La propriété nombre_noeuds_secondaires permet de définir le nombre souhaité de noeuds secondaires d'un groupe de périphériques.

Un système à haute disponibilité est considéré comme défectueux lorsque le noeud principal tombe en panne et qu'aucun noeud 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 noeud secondaire est sélectionné en fonction de l'ordre de priorité de la liste de noeuds. La liste de noeuds définit l'ordre dans lequel les noeuds vont tenter d'endosser le rôle de noeud principal ou de passer de noeud de réserve à noeud 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 noeuds secondaires sont contrôlés par le noeud principal au cours du fonctionnement normal. Dans une configuration de disques à accès multiples, le contrôle de chaque noeud secondaire entraîne une dégradation des performances et une surconsommation de mémoire. La prise en charge de noeuds 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 noeud principal et un noeud secondaire. Les autres noeuds disponibles apparaîtront en ligne à l'état de noeud de réserve. En cas de basculement, le noeud secondaire devient principal et le noeud prioritaire sur la liste de noeuds devient secondaire.

Le nombre souhaité de noeuds secondaires peut être égal à n'importe quel nombre entier compris entre un et le nombre de noeuds 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_noeuds_secondaires.

Le nombre souhaité de noeuds secondaires par défaut pour les services de périphériques est un. Le nombre réel de noeuds secondaires maintenu par la structure de réplication correspond au nombre souhaité, à moins que le nombre de noeuds non principaux opérationnels soit inférieur à ce nombre. Si vous ajoutez ou supprimez des noeuds de votre configuration, vous devrez modifier la propriété nombre_noeuds_secondaires et vérifier deux fois la liste de noeuds. La maintenance de la liste de noeuds et du nombre souhaité de noeuds secondaires empêche les conflits entre le nombre de noeuds secondaires configurés et le nombre réel autorisé par la structure. L'utilisation conjointe de la commande scconf(1M) pour les groupes de périphériques de disques VxVM ou de la commande metaset (1M) pour les groupes de périphériques de Solaris Volume Manager et des paramètres des propriétés prédilection et nombre_noeuds_secondaires permet de gérer l'ajout et la suppression de noeuds de votre configuration. Reportez-vous à la rubrique “ Administering Global Devices and Cluster File Systems” in Sun Cluster 3.1 System Administration Guide 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 noeud physiquement connecté aux disques multihôtes fournit un chemin d'accès aux périphériques de stockage à n'importe quel noeud du cluster.

 Habituellement, les espaces de noms du gestionnaire de volumes se trouvent dans les répertoires /dev/md/ensemble_disques/dsk (et rdsk), pour Solaris Volume Manager ; et dans les répertoires /dev/vx/dsk/ groupe_disques et /dev/vx/rdsk/ groupe_disques pour VxVM. 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 noeud de périphérique pour chaque métapériphérique ou volume de cet ensemble ou groupe de disques.

Dans le système SunPlex, chaque noeud de périphérique de l'espace de noms du gestionnaire de volumes local est remplacé par un lien symbolique vers un noeud de périphérique du système de fichiers /global/.devices/node@ ID_noeud, où ID_noeud est un nombre entier représentant les noeuds 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 noeud du cluster.

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

• Chaque noeud 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 une correspondance pour obtenir son nom global.

Exemple d'espaces de noms locaux et globaux

Le tableau suivant montre les correspondances 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

Un système de fichiers de cluster est un proxy entre le noyau d'un noeud, son système de fichiers sous-jacent et le gestionnaire de volumes fonctionnant sur un noeud ayant une connexion physique au(x) disque(s).

Les systèmes de fichiers de cluster dépendent des périphériques globaux (disques, bandes, CD) ayant des connections physiques à un ou plusieurs noeuds. Les périphériques globaux sont accessibles à partir de n'importe quel noeud du cluster à travers le même nom de fichier (par exemple, /dev/global/), que le noeud ait ou non une connexion physique au périphérique de stockage. Un périphérique global peut être utilisé comme tout autre périphérique, c'est-à-dire qu'il est possible d'y créer un système de fichiers à l'aide des commandes newfs et/ou mkfs.

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 noeud et à travers 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 ensembles de disques Solaris Volume Manager, des groupes de disques VxVM ou des disques individuels n'étant pas sous le contrôle d'un gestionnaire de 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é à plus d'un noeud. Ainsi, un système de fichiers local (système de fichiers stocké sur le disque local d'un noeud) élaboré à 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 :

  # 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 noeuds. 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 :

  /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 politique 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. Reportez-vous au Guide d'installation du logiciel Sun Cluster 3.1 et au Guide d'administration système de Sun Cluster 3.1 pour de plus amples informations.

Caractéristiques d'un système 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 noeuds 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 noeuds.

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

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 aux chapitres concernant les services de données individuels du document Data Services Installation and Configuration Guide ou à la rubrique “Enabling Highly Available Local File Systems” du chapitre 14 “Administering Data Services Resources” pour de plus amples informations sur l'utilisation du type de ressources 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.

L'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 le spécifier pour bénéficier des gains de performance.

VxFS n'intègre pas d'option de montage équivalente à l'option syncdir du système de fichiers UNIX. VxFS se comporte comme le système de fichiers UNIX lorsque syncdir n'est pas spécifiée.

Reportez-vous à la rubrique Questions récurrentes 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 chemins de disques

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 3.1 9/03 System Administration Guide 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 noeuds dont la version est antérieure à Logiciel Sun Cluster 3.1 5/03. N'utilisez pas les commandes de CCD au cours d'une mise à niveau progressive. Après la mise à niveau de tous les noeuds, ces derniers doivent être en ligne pour pouvoir utiliser les commandes de CCD.

Présentation générale

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 noeud ou de tous les noeuds du cluster. Reportez-vous à la page de manuel 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 de manuel 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 à multifile tourne sur chaque noeud. Le démon CCD ( scdpmd) est lancé par un script rc.d lorsqu'un noeud 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 noeuds à 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 pingue, toutes les dix minutes, l'état de chaque chemin d'accès aux disques inclus dans la liste contrôlée à l'aide des commandes scsi_inquiry. Chaque entrée est verrouillée pour empêcher l'interface de communication d'accéder au contenu d'une entrée en cours de modification.

4. Le démon CCD 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 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” in Sun Cluster 3.1 9/03 System Administration Guide 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 noeud.

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 noeud actif. L'argument chemin de disque est toujours constitué d'un nom de noeud et d'un nom de disque. Le nom de noeud n'est pas obligatoire et il est défini par défaut sur all si aucun nom n'est spécifié. Le tableau présenté ci-après décrit les conventions d'attribution de noms applicables aux chemins d'accès aux disques.

l'utilisation du nom du chemin de disque global est fortement conseillée, car il est consistant dans tout le cluster. Le nom du chemin de disque UNIX ne l'est pas. Il peut varier d'un noeud du cluster à l'autre. Il peut par exemple être c1t0d0 sur un noeud et c2t0d0 sur un autre. Si vous utilisez les noms des chemins de disques UNIX, exécutez la commande scdidadm -L afin d'établir une correspondance entre le nom du chemin UNIX et celui du chemin global avant d'utiliser les commandes CCD. Reportez-vous à la page de manuel 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

Les noeuds partageant des données et des ressources, il est important que le cluster ne soit jamais divisé en plusieurs partitions actives en même temps. Le moniteur d'appartenance au cluster (MAC) garantit qu'un seul cluster est en fonctionnement, même si l'interconnexion de cluster est partitionnée.

Des partitions de cluster peuvent provoquer deux types de problèmes : le split brain et l'amnésie. Un split brain se produit lorsque l'interconnexion entre les noeuds du cluster est perdue et que celui-ci se partitionne en sous-clusters, tous persuadés d'être une partition unique. Ce phénomène est dû à des problèmes de communication entre les noeuds du cluster. Une amnésie survient lorsque le cluster redémarre après un arrêt avec des données antérieures au moment de l'arrêt. Cette situation peut apparaître si plusieurs versions des données sont stockées sur le disque et qu'une nouvelle représentation du cluster est lancée alors que la dernière version n'est pas disponible.

Le split brain et l'amnésie peuvent être évités en donnant un vote à chaque noeud et en attribuant une majorité de votes à un autre cluster opérationnel. Une partition dotée d'une majorité de votes possède un quorum et est autorisée à fonctionner. Ce mécanisme de votes majoritaires fonctionne bien tant qu'il y a plus de deux noeuds dans le cluster. Dans un cluster à deux noeuds, la majorité est deux. Si ce cluster est partitionné, un vote externe est nécessaire aux partitions pour obtenir un quorum. Ce vote externe est alors fourni par un périphérique de quorum. Un périphérique de quorum peut être n'importe quel disque partagé entre les deux noeuds. Les disques utilisés comme périphériques de quorum peuvent contenir des données utilisateur.

Le Tableau 3–4 décrit comment le logiciel Sun Cluster utilise le quorum pour éviter le split brain et l'amnésie.

L'algorithme de quorum fonctionne de manière dynamique : comme ce sont les événements du cluster qui déclenchent son calcul, les résultats peuvent varier au cours de la durée de vie du cluster.

Nombre de votes de quorum

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

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

Vous pouvez configurer les périphériques de quorum au cours de l'installation du cluster ou ultérieurement à l'aide des procédures décrites dans le Guide d'administration système de Sun Cluster 3.1.

un périphérique de quorum ne participe au compte de votes que si au moins un des noeuds auquel il est rattaché est un membre du cluster. Ainsi, durant l'initialisation du cluster, un périphérique de quorum ne participe au compte que si au moins un des noeuds auquel il est rattaché s'initialise et était un membre du dernier cluster initialisé lorsqu'il a été arrêté.

Configurations du quorum

Les configurations du quorum dépendent du nombre de noeuds du cluster.

• Clusters à deux noeuds : deux votes de quorum sont nécessaires pour former un cluster à deux noeuds. Ces deux votes peuvent venir des deux noeuds du cluster ou juste d'un seul noeud et d'un périphérique de quorum. Néanmoins, un périphérique de quorum doit être configuré dans un cluster à noeuds pour assurer qu'un seul noeud puisse continuer si l'autre tombe en panne.

• Clusters à plus de deux noeuds : vous devez spécifier un périphérique de quorum entre chaque paire de noeuds partageant l'accès à un boîtier de stockage de disques. Prenez par exemple un cluster à trois noeuds similaire à celui présenté dans la Figure 3–3. Sur cette figure, le noeudA et le noeudB partagent l'accès au même boîtier de disques, et le noeudB et le noeudC partagent l'accès à un autre boîtier de disques. Il y a un total de cinq votes de quorum, trois venant du noeud et deux des périphériques de quorum partagés entre les noeuds. Un cluster a besoin de la majorité des votes de quorum pour être formé.

  La spécification d'un périphérique de quorum entre chaque paire de noeuds partageant un accès à un boîtier de stockage de disques n'est pas requise par Sun Cluster ni obligatoire. Toutefois, elle peut apporter les votes de quorum requis lorsqu'une configuration N+1 dégénère en cluster à deux noeuds et que le noeud ayant accès aux deux boîtiers de disques tombe également en panne. Si vous avez configuré des périphériques de quorum entre toutes les paires, le noeud restant peut encore fonctionner comme cluster.

  Reportez-vous à la Figure 3–3 pour consulter des exemples de ces configurations.

Figure 3–3 Exemples de configurations de périphériques de quorum

Directives s'appliquant au quorum

Pour installer des périphériques de quorum, suivez les directives suivantes :

• Établissez un périphérique de quorum entre tous les noeuds rattachés au même boîtier de stockage de disques. Ajoutez un disque comme périphérique de quorum dans le boîtier partagé pour assurer, en cas d'échec d'un noeud, que les autres peuvent maintenir le quorum et contrôler les groupes de périphériques de disques du boîtier partagé.

• Vous devez connecter le périphérique de quorum à au moins deux noeuds.

• Un périphérique de quorum peut être n'importe quel disque SCSI-2 ou SCSI-3 utilisé comme périphérique de quorum à deux accès. Les disques connectés à plus de deux noeuds doivent prendre en charge la réservation de groupe persistante (PGR) de SCSI-3, qu'ils soient ou non utilisés comme périphériques de quorum. Reportez-vous au chapitre concernant la planification dans le Guide d'installation du logiciel Sun Cluster 3.1 pour de plus amples informations.

• Un disque contenant des données utilisateur peut être utilisé comme périphérique de quorum.

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 noeuds ne peuvent pas communiquer, ainsi, des noeuds individuels ou des sous-ensembles de noeuds risquent de tenter de former des clusters individuels ou des sous-ensembles. Chaque sous-ensemble ou partition peut croire qu'elle est la seule à être propriétaire des disques multihôtes et à en posséder l'accès. Si plusieurs noeuds 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 noeuds aux disques multihôtes en les empêchant physiquement d'accéder aux disques. Lorsqu'un noeud quitte le cluster (parce qu'il a échoué ou a été partitionné), la séparation en cas d'échec assure qu'il ne peut plus accéder aux disques. Seuls les membres actuels des noeuds 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 disques multihôtes. Lorsqu'un membre du cluster fonctionnant comme noeud principal (propriétaire) du groupe de périphériques de disques échoue ou devient inaccessible, un nouveau noeud 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 noeud principal doit renoncer à l'accès aux périphériques avant que le nouveau noeud 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 noeud de libérer les périphériques dont il était le noeud 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 noeuds défectueux sont « isolés » à l'extérieur des disques 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 noeuds reliés aux disques (lorsqu'aucune réservation n'est en place), soit restreindre l'accès à un seul noeud (détenant la réservation).

Lorsqu'un membre détecte qu'un autre noeud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le noeud d'accéder aux disques partagés. En présence d'une séparation en cas d'échec, il est normal que le noeud 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 noeud 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 noeud et les autres noeuds. Le noeud 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 noeud défectueux ne se réinitialise pas et ne commence pas à écrire sur le stockage partagé est appelé failfast .

Les noeuds 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 noeud 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 noeuds.

Avec MHIOCENFAILFAST, le pilote contrôle le retour d'erreur de toutes les opérations de lecture et d'écriture qu'un noeud 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 noeuds. Pour les disques SCSI-3 dotés de la fonction PGR (réservation de groupe persistante), les informations de réservation sont stockées sur le disque et persistent après réinitialisation des noeuds. Le mécanisme failfast fonctionne de la même manière avec des disques SCSI-2 ou SCSI-3.

Si un noeud perd la connectivité aux autres noeuds 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 noeud. Un autre noeud faisant partie de la partition et pouvant atteindre un quorum place les réservations sur les disques partagés, et lorsque le noeud 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 noeud peut soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBoot (OBP). L'action retenue est déterminée par la définition du paramètre auto-boot? de l'OBP.

Gestionnaires de volumes

Le système SunPlex utilise un logiciel de gestion de volumes pour accroître la disponibilité des données à l'aide de miroirs et de disques de remplacement à chaud et pour gérer les pannes et remplacements des disques.

Il ne possède pas de gestionnaire de volumes propre, mais s'appuie sur les gestionnaires suivants :

• Solaris Volume Manager ;

• VERITAS Volume Manager.

Un gestionnaire de volumes au sein d'un cluster assure :

• la gestion des basculements des noeuds défectueux ;

• un support multivoie à partir de différents noeuds ;

• un accès distant transparent aux groupes de périphériques.

Lorsque les objets de la gestion de volumes arrivent sous le contrôle du cluster, ils deviennent des groupes de périphériques de disques. Pour de plus amples informations sur les gestionnaires de volumes, reportez-vous à la documentation de votre logiciel de gestion de volumes.

lorsque vous planifiez vos ensembles de disques ou groupes de disques, il est important de comprendre comment leurs groupes de périphériques de disques associés sont liés aux ressources d'application (données) au sein du cluster. Reportez-vous au Guide d'installation du logiciel Sun Cluster 3.1 et au Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur ces sujets.

Services de données

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

• le démarrage ;

• l'arrêt ;

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

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 noeud, le noeud principal. Si le noeud principal échoue, la ressource réseau et la ressource d'application basculent sur un autre noeud du cluster (noeud secondaire). Lorsque la ressource réseau bascule, la ressource d'application continue de fonctionner sur le noeud 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 noeuds 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 noeud. Ce noeud s'appelle le noeud d'interface globale (ou noeud GIF) . Une adresse partagée est utilisée comme interface de réseau simple 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 noeud 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 noeuds simultanément. Le terme « service évolutif » signifie que vous pouvez augmenter la puissance de calcul de l'application en ajoutant des noeuds de cluster supplémentaires afin d'améliorer les performances.

En cas d'échec du noeud GIF, l'adresse partagée peut être mise sur un autre noeud où tourne aussi une instance de l'application (faisant ainsi de cet autre noeud le nouveau noeud GIF). L'adresse partagée peut également basculer sur un autre noeud 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 noeuds. 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 Gestionnaire du groupe de ressources (RGM), qui les utilise pour démarrer, arrêter et contrôler l'application sur les noeuds du cluster. Ces méthodes, avec les logiciels de cluster et les disques 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 noeud sur lequel le service de données fonctionne (noeud principal) échoue, le service est déplacé vers un autre noeud 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 noeud puis automatiquement retirées pour être configurées sur un autre noeud.

Avec les services de données, les instances d'application ne tournent que sur un seul noeud. Si le détecteur de pannes rencontre une erreur, il essaie soit de redémarrer l'instance sur le même noeud, soit de la démarrer sur un autre noeud (basculement), selon la configuration du service de données.

Services de données évolutifs

Le service de données évolutif permet d'avoir des instances fonctionnant sur plusieurs noeuds. 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 noeuds, permettant ainsi à plusieurs instances du service de fonctionner en même temps. Le groupe de ressources de basculement hébergeant les adresses partagées ne peut être connecté qu'à un seul noeud à la fois. Tous les noeuds 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 noeuds 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 noeuds. Notez qu'il peut y avoir plusieurs interfaces globales sur des noeuds différents hébergeant d'autres adresses partagées.

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

S'il lui est impossible de redémarrer sur le même noeud et qu'un autre noeud non utilisé est configuré pour exécuter le service, celui-ci bascule sur le noeud non utilisé. Si aucun noeud n'est disponible, l'instance d'application continue de fonctionner sur les noeuds 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 noeud contenant l'instance et non sur le noeud d'interface globale. Ainsi, l'échec du noeud 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é. 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 Exemple de groupe de ressources évolutif et de basculement

Architecture de service évolutif

L'objectif principal d'un réseau en cluster est de fournir de l'évolutivité aux services de données. L'évolutivité signifie qu'en dépit de l'accroissement de la charge offerte à un service, celui-ci peut maintenir un temps de réponse constant grâce à l'ajout de nouveaux noeuds au cluster et à l'exécution de nouvelles instances de serveur. Ce service est appelé service de données évolutif. Un service Web est un bon exemple de ce type de service. Un service de données est généralement composé de plusieurs instances tournant chacune sur des noeuds différents du cluster. Ensemble, ces instances se comportent comme un service unique du point de vue d'un client distant et implémentent la fonctionnalité du service. On peut par exemple avoir un service Web évolutif composé de plusieurs démons httpd fonctionnant sur des noeuds différents. Chaque démon httpd peut servir une requête client. Le démon servant la requête dépend d'une règle d'équilibrage de la charge. La réponse au client semble venir du service, et non du démon servant la requête, et l'apparence d'un service unique est ainsi préservée.

Un service évolutif comporte :

• la prise en charge d'infrastructures de réseau pour les services évolutifs ;

• l'équilibrage de la charge ;

• la prise en charge de services de données et de gestion de réseaux (à l'aide du Gestionnaire du groupe de ressources).

La figure suivante représente l'architecture d'un service de données évolutif :

Figure 3–8 Architecture d'un service de données évolutif

Les noeuds n'étant pas hébergés par l'interface globale (noeuds proxy) hébergent l'adresse partagée sur leur interface de bouclage. Les paquets arrivant dans l'interface globale sont distribués à d'autres noeuds du cluster en fonction des règles d'équilibrage de la charge configurables. Les différentes règles d'équilibrage de la charge sont décrites ci-dessous.

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 noeuds, chaque noeud supporte une charge de 1. Chaque noeud 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 noeud é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 noeud. 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 noeud ; 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 noeud où fonctionne l'instance, les requêtes futures sont dirigées vers cette instance sous réserve que le noeud 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 noeuds 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 noeud 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 noeud particulier. Si on a X = charge et A = la charge totale de tous les noeuds en activité, un noeud 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 noeud différent : la première requête vers le noeud 1, la seconde vers le noeud 2, etc.

• Sticky. Avec cette règle, l'ensemble 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 noeud vers un autre noeud. Lorsque ce basculement se produit, le noeud secondaire d'origine devient principal. Les paramètres de rétablissement spécifient les actions qui auront lieu lorsque le noeud principal d'origine sera de nouveau en ligne. Vous pouvez soit autoriser le noeud principal d'origine à reprendre son rôle (rétablissement), soit permettre au noeud 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 noeud 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 noeud différent du cluster et plusieurs instances du même service ne peuvent pas fonctionner sur le même noeud.

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.

Une base de données back-end, telle les bases de données à haute disponibilité Oracle ou Oracle Parallel Server/Real Application Clusters est 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 document Sun Cluster 3.1 Data Services Installation and Configuration Guide décrit la procédure d'installation et de configuration des services de données intégrés au système SunPlex. Le document Sun Cluster 3.1 Data Services Developer's Guide explique la façon de rendre d'autres applications hautement disponibles dans le cadre de 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 noeuds 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 noeuds. Par exemple, une application répartie peut avoir des composants exécutés sur différents noeuds 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 à l'installation du cluster. Par exemple, si le nom d'hôte privé du noeud 1 est clusternode1-priv , il faut utiliser ce nom pour communiquer sur l'interconnexion de cluster vers le noeud 1. Les sockets TCP ouverts à l'aide de ce nom sont dirigés vers l'interconnexion de cluster et peuvent être redirigés de manière transparente en cas de panne du réseau.

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 noeuds d'une paire, mais des interconnexions distinctes sont, si possible, utilisées entre les différentes paires de noeuds. Supposons par exemple qu'une application tournant sur trois noeuds communique sur l'interconnexion de cluster. La communication entre les noeuds 1 et 2 peut avoir lieu sur l'interface hme0 et la communication entre les noeuds 1 et 3 sur l'interface qfe1. Autrement dit, les communications d'une application entre deux noeuds 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 noeud.

Une adresse de paire logique distincte est attribuée à chaque paire de noeuds. Ce petit réseau logique prend en charge la reprise des connexions. Une adresse par noeud fixe est également attribuée à chaque noeud. Autrement dit, les adresses de paires logiques de clusternode1-priv sont différentes sur chaque noeud, tandis que l'adresse logique par noeud de clusternode1-priv est la même sur chaque noeud. Un noeud ne comporte toutefois pas d'adresse de paire logique le désignant, de ce fait, la commande gethostbyname(clusternode1-priv) sur le noeud 1 ne renvoie que l'adresse par noeud 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 noeud du côté client et du côté serveur de sorte que toutes les connexions semblent provenir et se diriger vers cette adresse par noeud.

Ressources, groupes de ressources et types de ressources

Les services de données utilisent plusieurs types de ressources : les applications telles que le serveur Web Apache ou le serveur Web Sun ONE utilisent des adresses de 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 pour Oracle est le type de ressource SUNW.oracle-server et Sun Cluster HA pour Apache est le type de ressource SUNW.apache.

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

Les ressources réseau sont 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 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur cette méthode.

Gestionnaire du groupe de ressources (RGM)

Le gestionnaire du groupe de ressources (RGM) contrôle les services de données (applications) comme des ressources gérées par des implémentations de type de ressource. Ces implémentations peuvent être fournies par Sun ou créées par un développeur à l'aide d'un modèle de service de données générique, l'API de la bibliothèque de développement d'un service de données (API BDSD) ou l'API de la gestion de ressources (API GR). L'administrateur du cluster crée et gère des ressources dans des conteneurs appelés groupes de ressources. Le RGM arrête et démarre les groupes de ressources des noeuds 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. Ces paramètres et états sont 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 au cours d'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éside les ressources est à l'état « géré ».

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

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

  Les méthodes INIT et FINI sont 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 noeuds du cluster, vous devez la désactiver. 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 une ressource ou un groupe de ressources en ligne ou hors ligne.

  Une ressource de basculement ou un groupe de ressources ne peuvent être connectés qu'à un seul noeud à la fois. Une ressource évolutive ou un groupe de ressources peuvent être en ligne sur certains noeuds 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 noeud puis reconnectés à un autre noeud.

  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. Les propriétés standard sont décrites en annexe du document Sun Cluster 3.1 Data Services Installation and Configuration Guide.

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 au chapitre individuel consacré au service de données du document Sun Cluster 3.1 Data Services Installation and Configuration Guide.

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 noeud est partagé avec d'autres applications. Il arrive que les applications partagent un noeud 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 UC.

la documentation Solaris se rapportant à cette fonction désigne le temps UC, 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 UC, 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. Pour consulter les définitions des propriétés, reportez-vous à la rubrique “Standard Properties” dans le document Sun Cluster 3.1 Data Services Installation and Configuration Guide. 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 figuré 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 UC 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 UC 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 noeuds de votre groupe de ressources, utilisez les propriétés de groupes de ressources liste_noeuds, 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” dans le document Sun Cluster 3.1 Data Services Installation and Configuration Guide 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 noeuds. 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 noeuds, 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 “ Administering Disk Device Groups” dans le document Sun Cluster 3.1 System Administration Guide. Reportez-vous à la rubrique Les composants matériels du système SunPlex pour obtenir des informations théoriques concernant la configuration des noeuds et le comportement des services de données évolutifs ou de basculement.

Si vous configurez tous les noeuds du cluster de la même façon, les limites d'utilisation sont appliquées de manière identique aux noeuds principaux et aux noeuds secondaires. Les paramètres de configuration des projets doivent être identiques pour toutes les applications dans les fichiers de configuration de tous les noeuds. 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 noeuds (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 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 noeuds principaux et des noeuds 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 noeud secondaire ayant une limite de mémoire identique. Définissez une limite de mémoire légèrement supérieure sur le noeud 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 noeuds avec deux applications“ et “Cluster à deux noeuds avec trois applications“, présentent des scénarios de basculement de noeuds 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 noeud. 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 noeuds 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 UC alloué à chaque application change après un basculement. Ce pourcentage dépend du nombre d'applications tournant sur le noeud 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 noeuds.

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

Cluster à deux noeuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux noeuds 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 noeud 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 noeuds. Lorsque le cluster fonctionne normalement, chaque application tourne sur son maître par défaut, où le temps UC lui est attribué par la fonction de gestion.

Lorsqu'un basculement ou une commutation a lieu, les deux applications tournent sur un seul noeud, 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 UC disponible pour chaque application peut changer en fonction du nombre de parts attribuées à chaque processus demandant du temps UC.

Cluster à deux noeuds avec trois applications

Sur un cluster à deux noeuds 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 noeud. Le fichier de base de données des projets ne change pas lorsqu'un basculement ou une commutation a lieu.

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

Lorsque le cluster fonctionne normalement, 5 parts sont allouées à l'application 1 sur son maître par défaut, phys-schost-1. Ce nombre équivaut à 100 pour cent du temps UC parce que c'est la seule application qui demande du temps UC sur ce noeud. 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 UC et l'application 3 reçoit 40 pour cent du temps UC 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 UC sont allouées en fonction du fichier de la base de données des projets.

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

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

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

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

Basculement du groupe de ressources uniquement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, un groupe de ressources (et ses applications associées) peuvent basculer ou commuter sur un noeud 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 noeud secondaire. Dans cet exemple, les fichiers de la base de données de projets des noeuds 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 UC disponible pour chaque application peut varier en fonction du nombre de parts assignées à chaque application nécessitant du temps UC.

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

Les clients adressent des requêtes de données au cluster à travers le réseau public. Chaque noeud 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 noeud du cluster a sa propre configuration de multi-acheminement sur réseau IP , pouvant être différente de celle des autres noeuds.

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 noeud 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 noeuds du cluster au réseau public. Sur un noeud, 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 de plus amples informations sur les ressources de nom d'hôtes logiques et d'adresses partagées, reportez-vous au document Sun Cluster 3.1 Data Services Installation and Configuration Guide.

le mécanisme de multi-acheminement sur réseau IP 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.

Prise en charge de la reconfiguration dynamique

La prise en charge de la fonction de reconfiguration dynamique (DR) par Sun Cluster 3.1 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.

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 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 tous deux être téléchargés à l'adresse http://docs.sun.com.

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 l'unité centrale, 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 unités centrales 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.” Cette dernière doit être ignorée 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.

Reconfiguration dynamique et unités centrales

Le logiciel Sun Cluster ne rejette pas une opération de suppression de carte par reconfiguration automatique en raison de la présence d'unités centrales.

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

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.

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 noeud principal. Ces opérations peuvent être exécutées sur des lecteurs non actifs dans le noeud principal et sur n'importe quel lecteur du noeud secondaire. Après l'opération DR, l'accès aux données du 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 Reconfiguration dynamique et périphériques de quorum.

Reportez-vous au Guide d'administration système du logiciel Sun Cluster 3.1 pour des directives détaillées concernant la réalisation de ces actions.

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 au Guide d'administration système du logiciel Sun Cluster 3.1 pour des directives détaillées concernant la réalisation de ces actions.

Reconfiguration dynamique et interfaces d'interconnexion du 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 au Guide d'administration système du logiciel Sun Cluster 3.1 pour des directives détaillées concernant la réalisation de ces actions.

Sun Cluster exige que chaque noeud du cluster possède au moins un chemin fonctionnel vers les autres noeuds du cluster. Ne désactivez pas une interface d'interconnexion privée prenant en charge le dernier chemin d'accès à un noeud du cluster.

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 au Guide d'administration système du logiciel Sun Cluster 3.1 pour obtenir des directives détaillées sur la procédure de suppression par reconfiguration dynamique d'une interface de réseau public.