test

Guide des développeurs pour les services de données Sun Cluster pour SE Solaris

Chapitre 2 Développement d'un service de données

Ce chapitre fournit des informations détaillées sur le développement d'un service de données.

Ce chapitre contient les rubriques suivantes :

Analyse du caractère approprié de l'application

La première étape de création d'un service de données consiste à s'assurer que l'application répond effectivement aux conditions requises en matière de haute disponibilité et d'évolutivité. Si l'application ne satisfait pas toutes les conditions requises, vous devez être en mesure de modifier son code source pour pallier le problème.

La liste indiquée ci-après présente brièvement les exigences requises pour qu'une application soit hautement disponible ou évolutive. Pour obtenir de plus amples informations ou si vous devez modifier le code source de l'application, reportez-vous à l'Annexe B, Liste des exemples de codes de service de données.

Remarque –

pour être hautement disponible, un service évolutif doit remplir toutes les conditions suivantes, ainsi que certains critères supplémentaires.

De plus, les services évolutifs doivent satisfaire les conditions suivantes :

Dans le cadre d'un service évolutif, les caractéristiques de l'application déterminent également la règle d'équilibrage de la charge. Par exemple, la règle >LB_WEIGHTED, qui permet à n'importe quelle instance de répondre aux requêtes des clients, ne fonctionne pas avec une application utilisant une mémoire cache d'entrée sur le serveur pour les connexions client. Dans ce cas, vous devez spécifier une règle qui restreint le trafic d'un client donné à une instance de l'application. Les règles d'équilibrage de la charge LB_STICKY et LB_STICKY_WILD transmettent à plusieurs reprises toutes les requêtes d'un client à la même instance de l'application où elles peuvent utiliser la mémoire cache d'entrée. Notez que si plusieurs requêtes client proviennent de différents clients, le RGM les distribue entre les instances du service. Reportez-vous à la rubrique Mise en œuvre d'une ressource de basculement pour de plus amples informations sur le paramétrage de la règle d'équilibrage de la charge des services de données évolutifs.

Détermination de l'interface à utiliser

Le package de support développeur de Sun Cluster (SUNWscdev) intègre deux ensembles d'interfaces de codage des méthodes de services de données :

Ce package comprend également SunPlex Agent Builder, un outil d'automatisation de la création d'un service de données.

Approche recommandée pour développer un service de données :

  1. Choisir le type de code, C ou korn shell, à utiliser. Si vous choisissez d'utiliser le code korn shell, vous ne pouvez pas utiliser la bibliothèque BDSD qui fournit uniquement une interface C.

  2. Exécuter Agent Builder, indiquer les entrées demandées et générer un service de données qui comprend un code source et exécutable, un fichier RTR et un package.

  3. Si le service de données généré doit être personnalisé, vous pouvez ajouter un code BDSD aux fichiers sources générés. Agent Builder indique, à l'aide de commentaires, les emplacements spécifiques où vous pouvez ajouter votre propre code dans les fichiers sources.

  4. S'il est nécessaire de personnaliser davantage le code pour prendre en charge l'application cible, vous pouvez ajouter des fonctions API GR au code source existant.

Dans la pratique, de nombreuses approches vous permettent de créer un service de données. Par exemple, plutôt que d'ajouter votre propre code aux emplacements spécifiques générés par Agent Builder dans le code source, vous pouvez remplacer l'intégralité d'une des méthodes générées ou le programme détecteur généré par un programme que vous avez écrit à l'aide des fonctions BDSD ou API GR. Quelle que soit votre façon de procéder, commencer par utiliser Agent Builder n'est pas dénué de sens pour les raisons suivantes :

Remarque –

contrairement à l'interface API GR fournissant un ensemble de fonctions C et un ensemble de commandes à utiliser dans les scripts, la bibliothèque BDSD n'offre qu'une interface de fonction C. Par conséquent, si vous spécifiez une sortie korn shell (ksh) dans Agent Builder, le code source généré appelle l'interface API GR car il n'y a pas de commande BDSD ksh.

Paramétrage d'un environnement de développement dédié à l'écriture d'un service de données

Avant de développer un service de données, vous devez installer le package de développement de Sun Cluster (SUNWscdev) pour accéder aux fichiers d'en-tête et de bibliothèque de Sun Cluster. Bien que ce package soit déjà installé sur tous les nœuds du cluster, vous ne procédez pas au développement sur un nœud du cluster mais sur une machine de développement distincte n'appartenant pas au cluster. Dans ce cas, vous devez utiliser pkgadd pour installer le package SUNWscdev sur la machine de développement.

Lors de la compilation et de la liaison du code, vous devez définir un ensemble d'options spécifiques pour identifier les fichiers d'en-tête et de bibliothèque.

Remarque –

Vous ne pouvez pas mélanger du code C++ compilé en mode compatibilité avec du code C++ compilé en mode standard dans le système d'exploitation Solaris et dans les produits Sun Cluster. Par conséquent, si vous envisagez de créer un service de données basé sur du code C++ et de l'utiliser avec Sun Cluster, vous devez le compiler comme suit :

À la fin du développement (sur un nœud n'appartenant pas à un cluster), vous pouvez transférer le service de données terminé sur un cluster pour l'exécuter et le tester.

Remarque –

Vérifiez que vous utilisez le groupe de logiciels (distribution complète ou développeur) du système d'exploitation Solaris 5.8, ou version ultérieure.

Les procédures décrites dans cette rubrique permettent de réaliser les actions suivantes :

Paramétrage de l'environnement de développement

Cette procédure l'installation du package SUNWscdev et la configuration des options du compilateur et de l'éditeur de liens pour développer le service de données.

  1. Connectez-vous en tant que superutilisateur ou équivalent et remplacez le répertoire par le répertoire du CD de votre choix. 


    # cd Répertoire_CD

  2. Installez le package SUNWscdev dans le répertoire courant. 


    # pkgadd -d . SUNWscdev

  3. Dans le fichier Makefile, indiquez les options du compilateur et de l'éditeur de liens identifiant les fichiers inclus et de bibliothèque de votre code de service de données.

    Utilisez l'option -I pour identifier les fichiers d'en-tête de Sun Cluster, l'option -L pour spécifier le chemin de recherche de la bibliothèque de compilation sur le système de développement et l'option -R pour indiquer le chemin de recherche de la bibliothèque à l'éditeur de liens d'exécution sur le cluster. 

    # Fichier Makefile d’un service de données modèle... 

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

Transfert d'un service de données sur un cluster

Lorsque vous avez terminé de développer un service de données sur une machine de développement, vous devez le transférer sur un cluster pour le tester. Pour réduire les risques d'erreur, le meilleur moyen de réaliser ce transfert est encore de constituer un package avec le code du service de données et le fichier RTR, puis de l'installer sur tous les nœuds du cluster.

Remarque –

que vous installiez le service de données avec pkgadd ou de quelque autre façon que ce soit, vous devez placer le service de données sur tous les nœuds du cluster. Agent Builder crée automatiquement un package avec le fichier RTR et le code du service de données.

Paramétrage des propriétés de ressources et de types de ressources

Sun Cluster propose un ensemble de propriétés de ressources et de types de ressources servant à définir la configuration statique d'un service de données. Les propriétés de types de ressources spécifient le type de ressources, la version, la version de l'interface API, etc., ainsi que les chemins d'accès aux méthodes de rappel. La rubrique Propriétés des types de ressources répertorie toutes les propriétés de type de ressources.

Les propriétés de ressources, telles que Failover_mode et Thorough_probe_interval et les délais d’attente des méthodes définissent également la configuration statique de la ressource. Les propriétés de ressource dynamique, comme Resource_state et Status, reflètent l’état actif d’une ressource gérée. La rubrique Propriétés des ressources présente les propriétés de ressource.

Vous déclarez les propriétés de ressources et de types de ressources dans le fichier RTR. Ce fichier est un élément indispensable d'un service de données. Le fichier RTR définit la configuration d'origine du service de données au moment où l'administrateur du cluster l'enregistre sous Sun Cluster.

Nous vous recommandons d'utiliser Agent Builder pour générer le fichier RTR de votre service de données car cette application déclare l'ensemble des propriétés qui sont à la fois utiles et requises pour n'importe quel service de données. Par exemple, certaines propriétés (comme Resource_type) doivent être déclarées dans le fichier RTR car, dans le cas contraire, l'enregistrement du service de données échoue. Bien que cela ne soit pas indispensable, d'autres propriétés ne seront pas accessibles par l'administrateur système si vous ne les déclarez pas dans le fichier RTR tandis que d'autres propriétés sont disponibles que vous les déclariez ou non car le RGM les définit et leur octroie une valeur par défaut. Pour éviter de gérer un tel niveau de complexité, il vous suffit d'utiliser Agent Builder pour garantir la génération d'un fichier RTR correct que vous pouvez éditer ultérieurement pour modifier des valeurs spécifiques si nécessaire.

À la fin de cette rubrique, vous trouverez un modèle de fichier RTR créé par Agent Builder.

Déclaration des propriétés de type de ressources

L'administrateur du cluster ne peut pas configurer les propriétés de type de ressources que vous déclarez dans le fichier RTR. Ces propriétés font partie intégrante de la configuration permanente du type de ressources.

Remarque –

seule une propriété de type de ressources, Installed_nodes est configurable par l'administrateur système. En fait, elle ne peut être configurée que par un administrateur système. Vous ne pouvez pas la déclarer dans le fichier RTR.

Syntaxe de déclaration des types de ressources : 


nom_propriété = valeur;
Remarque –

le RGM est insensible à la casse dans les noms de propriété. Les fichiers RTR fournis par Sun sont basés sur la convention suivante : la première lettre du nom est en majuscules tandis que toutes les autres sont en minuscules. Cette convention s'applique aux noms de propriété mais pas aux noms de méthode. Les noms de méthodes et les attributs de propriété sont en majuscules.

Voici les déclarations de type de ressources contenues dans le fichier RTR d'un service de données (smpl) échantillon : 

# Sun Cluster Data Services Builder template version 1.0
# Enregistrement de données et de ressources pour smpl
#
#REMARQUE : les mots clés sont insensibles à la casse. Cela signifie
que vous pouvez utiliser les minuscules
#ou les majuscules au choix.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Exemple de service sur Sun Cluster";

RT_version ="1.0"; 
API_version = 2;
Failover = TRUE;

Init_nodes = RG_PRIMARIES;

RT_basedir=/opt/SUNWsmpl/bin;

Start = smpl_svc_start;
Stop = smpl_svc_stop;

Validate = smpl_validate;
Update = smpl_update;

Monitor_start = smpl_monitor_start;
Monitor_stop = smpl_monitor_stop;
Monitor_check = smpl_monitor_check;
Astuce –

la propriété Resource_type doit être déclarée en tant que première entrée dans le fichier RTR. Dans le cas contraire, l'enregistrement du type de ressources échoue.

Le premier ensemble de déclarations de type de ressources fournit des informations élémentaires sur le type de ressources :

Resource_type et Vendor_id

Indique le nom du type de ressources. Vous pouvez spécifier le nom du type de ressources de deux façons : au moyen de la propriété Resource_type (smpl) uniquement ou en utilisant le préfixe Vendor_id suivi d'un point “.” comme séparateur et du nom du type de ressources (SUNW.smpl), comme dans notre exemple. Si vous utilisez Vendor_id, définissez le type de ressources à l'aide du symbole boursier de l'entreprise. Le nom du type de ressources doit être unique sur le cluster.

Remarque –

les noms de types de ressources (Type_ressourcesId_fournisseur) sont traditionnellement utilisés comme nom de package. Les noms de package ne peuvent pas contenir plus de 9 caractères. C'est pourquoi il est préférable de limiter le nombre total de caractères à 9 maximum lorsque vous attribuez un nom à ces deux propriétés bien que le RGM n'impose pas cette restriction. Par contre, comme Agent Builder génère explicitement le nom du package à partir du nom du type de ressources, il impose cette restriction.

RT_version

Identifie la version du service de données échantillon.

API_Version

Identifie la version de l'interface API. Par exemple, API_version = 2 signifie que le service de données fonctionne sous Sun Cluster, version 3.0.

>Failover = TRUE

Indique qu'il est impossible d'exécuter le service de données dans un groupe de ressources pouvant être en ligne simultanément sur plusieurs nœuds car il s'agit d'un service de données de basculement. Reportez-vous à la rubrique Transfert d'un service de données sur un cluster pour de plus amples informations.

Start, Stop, Validate, etc.

Indiquent les chemins d'accès aux programmes de méthode de rappel correspondants que le RGM appelle. Ces chemins d'accès dépendent du répertoire spécifié par RT_basedir.

Les autres déclarations de type de ressources fournissent des informations sur la configuration :

Init_nodes = RG_PRIMARIES

Indique que le RGM n'appelle les méthodes Init, Boot, Fini et Validate que sur les nœuds pouvant gérer le service de données. Les nœuds spécifiés par RG_PRIMARIES constituent un sous-ensemble de tous les nœuds sur lesquels le service de données est installé. Définissez la valeur sur >RT_INSTALLED_NODES pour indiquer que le RGM appelle ces méthodes sur tous les nœuds sur lesquels le service de données est installé.

RT_basedir

Sélectionnez le chemin d'accès au répertoire /opt/SUNWsample/bin pour compléter les chemins relatifs, comme les chemins d'accès aux méthodes de rappel.

Start, Stop, Validate, etc.

Indiquent les chemins d'accès aux programmes de méthode de rappel correspondants que le RGM appelle. Ces chemins d'accès dépendent du répertoire spécifié par RT_basedir.

Déclaration des propriétés de ressource

Comme pour les propriétés de type de ressources, vous déclarez des propriétés de ressource dans le fichier RTR. Les déclarations de propriétés de ressources suivent traditionnellement les déclarations de type de ressources dans le fichier RTR. Les déclarations de ressource sont rédigées sous la forme d'un ensemble de paires de valeur d'attribut entre crochets :


{
    Attribut = Valeur;
    Attribut = Valeur;
             .
             .
             .
    Attribut = Valeur;
}

Vous pouvez modifier, dans le fichier RTR, les attributs spécifiques aux propriétés de ressources fournies par Sun Cluster et appelées propriétés définies par le système. Par exemple, Sun Cluster fournit des propriétés de délai d'attente pour chaque méthode de rappel en précisant des valeurs par défaut. Vous pouvez modifier ces valeurs dans le fichier RTR.

Vous pouvez également y définir de nouvelles propriétés de ressource, appelées propriétés d'extension, à l'aide d'un ensemble d'attributs de propriété fourni par Sun Cluster. La rubrique Attributs des propriétés de ressources répertorie les attributs permettant de modifier et de définir des propriétés de ressource. Les déclarations de propriété d'extension suivent les déclarations de propriété définies par le système dans le fichier RTR.

Le premier ensemble de propriétés de ressource définies par le système indique le délai d'attente des méthodes de rappel : 

...

# Les déclarations de propriétés de ressources apparaissent sous
# la forme d’une liste d’entrées entre crochets après les déclarations
# de type de ressources. Le premier attribut suivant le crochet
# d’ouverture d’une entrée de propriété de ressources doit être la
# déclaration du nom de la propriété.
#
# Définissez les délais d’attente minimum et par défaut de la méthode.
{
        PROPERTY = Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
{
        PROPERTY = Monitor_Check_timeout;
        MIN=60;
        DEFAULT=300;
}

Le premier attribut de chaque déclaration de propriétés de ressource doit être le nom de la propriété (PROPERTY = valeur). Vous pouvez configurer des propriétés de ressource conformément aux limites définies par les attributs de propriété figurant dans le fichier RTR. Par exemple, le délai d'attente par défaut de chaque méthode est de 300 secondes dans notre exemple. Un administrateur peut modifier cette valeur, sachant cependant que la valeur minimum autorisée, conformément à l’attribut MIN, est de 60 secondes. La rubrique Attributs des propriétés de ressources contient la liste des attributs de propriété de ressource.

L'ensemble de propriétés de ressource suivant définit les propriétés ayant une utilisation spécifique dans le service de données. 

{
        PROPERTY = Failover_mode;
        DEFAULT=SOFT;
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

#Nombre de tentatives à exécuter dans une période donnée avant de conclure
# qu’il est impossible de démarrer l'application avec succès sur ce nœud.
{
        PROPERTY = Retry_Count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME;  
}

# Configurez Retry_interval sur un multiple de 60 car ce paramètre est
# arrondi lors de la conversion des secondes en minutes. Par exemple, 50 secondes
# sera arrondi à 1 minute. Cette propriété vous permet de minuter le nombre
# de tentatives (Retry_count).
{
        PROPERTY = Retry_Interval;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = WHEN_DISABLED;
        DEFAULT = "";
}
{
        PROPERTY = Scalable;
        DEFAULT = FALSE;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_policy;
        DEFAULT = LB_WEIGHTED;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_weights;
        DEFAULT = "";
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Port_list;
        TUNABLE = AT_CREATION;
        DEFAULT = ;
}

Ces déclarations de propriétés de ressource créent l'attribut TUNABLE, qui restreint les occasions permettant à l'administrateur système de modifier leurs valeurs. AT_CREATION signifie que l'administrateur ne peut spécifier la valeur qu'à la création de la ressource et qu'il ne pourra pas la modifier ultérieurement.

Vous pouvez accepter les valeurs par défaut qu'Agent Builder génère pour la plupart de ces propriétés à moins d'avoir une raison de les modifier. Vous trouverez ci-après de plus amples informations sur ces propriétés (vous pouvez également vous reportez à la rubrique Propriétés des ressources ou à la page man r_properties(5)) :

Failover_mode

Indique si le RGM doit relocaliser le groupe de ressources ou arrêter le nœud en cas d'échec d'une méthode Start ou Stop.

Thorough_probe_interval, Retry_count, Retry_interval

Propriétés utilisées dans le système de détection des pannes. L'attribut Tunable est paramétré sur ANYTIME, si bien qu'un administrateur système peut les ajuster si le détecteur de pannes ne fonctionne pas d'une manière optimale.

Network_resources_used

Liste des ressources (noms d'hôte logique et adresses partagées) utilisées par le service de données. Agent Builder déclare cette propriété, afin qu'un administrateur système puisse spécifier une liste de ressources, le cas échéant, lors de la configuration du service de données.

Scalable

Définissez cette propriété sur FALSE pour indiquer que la ressource correspondante n'utilise pas la fonction de gestion de réseaux du cluster (adresse partagée). Ce paramétrage est compatible avec la propriété de type de ressources Failover définie sur TRUE pour indiquer qu'il s'agit d'un service de basculement. Reportez-vous aux rubriques Transfert d'un service de données sur un cluster et Mise en œuvre des méthodes de rappel pour de plus amples informations sur l'utilisation de cette ressource.

Load_balancing_policy, Load_balancing_weights

Déclarent automatiquement ces propriétés, sinon elles ne sont pas utilisées dans un type de ressources de basculement.

Port_list

Identifie la liste des ports de réception du serveur. Agent Builder déclare cette propriété, afin qu'un administrateur système puisse identifier une liste de ports lors de la configuration du service de données.

Déclaration des propriétés d'extension

Les propriétés d'extension se trouvent à la fin du fichier RTR échantillon, comme indiqué dans la liste ci-après. 

# Propriétés d'extension 
# 

# L'administrateur du cluster doit définir la valeur de cette propriété pour désigner 
# le répertoire contenant les fichiers de configuration utilisés par l'application. 
# Pour cette application, smpl, indiquez le chemin d'accès du fichier de configuration sur 
# PXFS (généralement named.conf). 
{ 
       PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "Chemin(s) répertoire de configuration"; 
}

 # Les deux propriétés suivantes contrôlent le redémarrage du système de détection des pannes. 
{ 
       PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Nombre de redémarrages de PMF autorisé par le détecteur de pannes."
} 
{ 
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Fenêtre de temps (en minutes) relative au redémarrage du détecteur de pannes."
} 
# Délai d'attente en seconde pour la détection. 
{ 
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Valeur du délai imparti au test (en secondes)"; 
}
 # Niveau de contrôle du processus enfant de PMF (option -C de pmfadm). 
# La valeur par défaut -1 signifie qu'il ne faut pas utiliser l'option -C de pmfadm. 
# Une valeur égale ou supérieure à 0 indique le niveau souhaité de contrôle 
# du processus enfant. 
{ 
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Niveau de contrôle enfant pour PMF";
}
# Code utilisateur ajouté -- DÉBUT VVVVVVVVVVVV
# Code utilisateur ajouté -- FIN ^^^^^^^^^^^^

Agent Builder crée quelques propriétés d'extension qui sont utiles à la plupart des services de données. Les voici :

Confdir_list

Indique le chemin d’accès au répertoire de configuration de l’application. Cette information est utile pour la plupart des applications. L'administrateur peut indiquer l'emplacement de ce répertoire lors de la configuration du service de données.

Monitor_retry_count, Monitor_retry_interval , Probe_timeout

Contrôlent les redémarrages du système de détection des pannes et non du démon du serveur.

Child_mon_level

Définit le niveau de contrôle que la fonction PMF doit effectuer. Reportez-vous à pmfadm(1M) pour de plus amples informations.

Vous pouvez créer d'autres propriétés d'extension dans les emplacements délimités par les commentaires Code ajouté par l'utilisateur.

Mise en œuvre des méthodes de rappel

Cette rubrique fournit des informations sur la mise en œuvre des méthodes de rappel, en règle générale.

Accès aux informations sur les propriétés de ressource et de groupe de ressources

En règle générale, les méthodes de rappel doivent accéder aux propriétés de la ressource. L'interface API GR fournit des commandes shell et des fonctions C que vous pouvez utiliser dans les méthodes de rappel pour accéder aux propriétés d'extension définies par l'utilisateur des ressources. Reportez-vous aux pages man scha_resource_get(1HA) et scha_resource_get(3HA).

La bibliothèque BDSD fournit un ensemble de fonctions C (une par propriété) pour accéder aux propriétés définies par le système et une fonction d'accès aux propriétés d'extension. Reportez-vous aux pages man scds_property_functions(3HA) et scds_get_ext_property(3HA).

Vous ne pouvez pas utiliser le mécanisme de propriété pour enregistrer des données d'état dynamiques pour un service de données car aucune fonction API n'est disponible pour paramétrer les propriétés de ressource (à l'exception du paramétrage de Status et Status_msg). Le cas échéant, il est préférable d'enregistrer les données d'état dynamiques dans des fichiers globaux.

Remarque –

l’administrateur du cluster peut définir certaines propriétés de ressources à l’aide de la commande scrgadm, d’une commande administrative graphique disponible ou d’une interface administrative graphique. Par contre, n'appelez pas scrgadm à partir d'une méthode de rappel car cette commande échoue pendant la reconfiguration du cluster (c'est-à-dire lorsque le RGM appelle la méthode.)

Idempotence des méthodes

En règle générale, le RGM n'appelle pas successivement plus d'une fois une méthode sur la même ressource avec les mêmes arguments. Par contre, si une méthode Start échoue, le RGM peut appeler une méthode Stop sur une ressource même si cette dernière n'a jamais été exécutée. De même, le RGM peut exécuter la méthode Stop sur le démon d'une ressource qui s'est pourtant interrompu de lui-même. Les mêmes scénarios s'appliquent aux méthodes Monitor_start et Monitor_stop.

C'est pourquoi vous devez créer une relation d'idempotence entre les méthodes Stop et Monitor_stop. Les appels répétés de Stop ou Monitor_stop sur la même ressource en utilisant les mêmes paramètres fournissent les mêmes résultats qu'un appel unique.

L'idempotence se caractérise notamment par le fait que Stop et Monitor_stop doivent retourner 0 (succès) même si la ressource ou le détecteur sont déjà arrêtés ou qu'aucun travail n'est effectué.

Remarque –

les méthodes Init, Fini, Boot et Update doivent également être idempotentes. Il n'est pas nécessaire qu'une méthode Start soit idempotente.

Service de données générique

Un service de données générique (GDS, Generic Data Service) est un mécanisme permettant de rendre hautement disponibles et évolutives des applications uniques en les connectant à la structure du RGM de Sun Cluster. Ce mécanisme évite l'utilisation d'un agent de programmation, procédure habituelle pour rendre une application hautement disponible ou évolutive.

Le modèle GDS s'appuie sur un type de ressources précompilées, SUNW.gds, pour assurer l'interaction avec la structure RGM.

Reportez-vous au Chapitre 10, Services de données génériques pour de plus amples informations.

Contrôle d'une application

Les méthodes de rappel permettent au RGM de contrôler les ressources sous-jacentes (application) chaque fois que des nœuds sont liés au processus d'entrée/sortie du cluster.

Démarrage et arrêt d'une ressource

La mise en œuvre d'un type de ressources requiert au minimum une méthode Start et une méthode Stop. Le RGM appelle les programmes de méthode du type de ressources aux moments opportuns et sur les nœuds appropriés pour connecter ou déconnecter les groupes de ressources. Par exemple, après la défaillance d'un nœud de cluster, le RGM transfère les groupes de ressources gérés par ce nœud sur un autre nœud. Vous devez mettre en œuvre une méthode Start pour permettre au RGM de redémarrer chaque ressource sur le nœud hôte restant.

Une méthode Start ne doit pas être retournée tant que la ressource n'a pas été exécutée et n'est pas disponible sur le nœud local. Veillez à ce que les types de ressources nécessitant une longue période d'initialisation disposent d'un délai d'attente suffisant dans la méthode Start (configurez la propriété Start_timeout sur une valeur minimum dans le fichier d'enregistrement du type de ressources).

Vous devez mettre en œuvre une méthode Stop lorsque le RGM déconnecte un groupe de ressources. Par exemple, supposons qu’un groupe de ressources est déconnecté du nœud1 puis reconnecté au nœud2. Tout en déconnectant le groupe de ressources, le RGM appelle la méthode Stop sur les ressources du groupe dont vous souhaitez arrêter toute activité sur le nœud1. Une fois les méthodes Stop exécutées sur toutes les ressources du nœud1, le RGM connecte le groupe de ressources au nœud2.

Une méthode Stop ne doit pas être retournée tant que la ressource n'a pas cessé totalement toute activité au niveau du nœud local et qu'elle n'est pas complètement arrêtée. La mise en œuvre la plus fiable d'une méthode Stop se traduit par l'achèvement de tous les processus sur le nœud local lié à la ressource. Pour les types de ressources mettant longtemps à s'arrêter, il est nécessaire de définir un délai d'attente suffisamment long dans leur méthode Stop. Définissez la propriété Stop_timeout dans le fichier d'enregistrement du type de ressources.

Lorsqu'une méthode Stop échoue ou dépasse le délai imparti, le groupe de ressources bascule dans un mode d'erreur requérant l'intervention de l'opérateur. Pour éviter cela, les mises en œuvre des méthodes Stop et Monitor_stop doivent tenter une récupération à partir de toutes les conditions d'erreur possibles. Dans l'idéal, la fermeture de ces méthodes doit s'accompagner d'un état d'erreur nul (succès) signifiant que les méthodes ont réussi à interrompre correctement toutes les activités de la ressource et de son détecteur sur le nœud local.

Choix des méthodes Start et Stop à utiliser

Cette rubrique présente des astuces permettant de savoir quand il est préférable d'utiliser les méthodes Start et Stop par opposition aux méthodes Prenet_start et Postnet_stop. Pour déterminer les méthodes à utiliser, vous devez posséder une connaissance approfondie du client et du protocole de gestion des réseaux client-serveur du service de données.

Par ailleurs, il est possible qu'avec les services utilisant des ressources d'adresse réseau, les étapes de démarrage et d'arrêt doivent être exécutées dans un ordre précis dépendant de la configuration de l'adresse du nom d'hôte logique. Les méthodes de rappel en option Prenet_start et Postnet_stop permettent à la mise en œuvre d'un type de ressources d'effectuer des actions de démarrage et d'arrêt spéciales avant et après la configuration en amont ou en aval des adresses réseau dans le même groupe de ressources.

Le RGM appelle les méthodes plombant les adresses réseau (sans les configurer en amont) avant d’appeler la méthode Prenet_start du service de données. Le RGM appelle les méthodes déplombant les adresses réseau après avoir appelé les méthodes Postnet_stop du service de données. Séquence applicable lorsque le RGM connecte un groupe de ressources :

  1. Plombage des adresses réseau.

  2. Appel de la méthode Prenet_start du service de données (le cas échéant).

  3. Configuration en amont des adresses réseau.

  4. Appel de la méthode Start du service de données (le cas échéant).

Séquence applicable lorsque le RGM déconnecte un groupe de ressources (séquence inverse de la précédente) :

  1. Appel de la méthode Stop du service de données (le cas échéant).

  2. Configuration en aval des adresses réseau.

  3. Appel de la méthode Postnet_stop du service de données (le cas échéant).

  4. Déplombage des adresses réseau.

Pour choisir les méthodes Start,Stop, Prenet_start ou Postnet_stop à utiliser, considérez tout d'abord le côté serveur. Lors de la connexion d'un groupe de ressources contenant des ressources d'adresse réseau et d'application de service de données, le RGM appelle des méthodes de configuration en amont des adresses réseau avant d'appeler les méthodes de ressources Start du service de données. Par conséquent, si un service de données requiert des adresses configurées en amont à son démarrage, utilisez la méthode Start pour le démarrer.

De même, lors de la déconnexion d'un groupe de ressources contenant des ressources d'adresse réseau et de service de données, le RGM appelle des méthodes de configuration en aval des adresses réseau avant d'appeler les méthodes de ressources Stop du service de données. Par conséquent, si un service de données requiert des adresses configurées en amont à son arrêt, utilisez la méthode Stop pour l'arrêter.

Par exemple, pour démarrer ou arrêter un service de données, vous devrez peut-être exécuter ses bibliothèques ou ses utilitaires d'administration. Le service de données contient parfois des bibliothèques ou des utilitaires d'administration utilisant une interface de gestion de réseaux client-serveur pour accomplir les tâches administratives. Le cas échéant, un utilitaire d'administration appelle le démon du serveur. L'adresse réseau doit donc être en amont pour utiliser la bibliothèque ou l'utilitaire d'administration. Dans ce cas, utilisez les méthodes Start et Stop.

Par contre, vous devez démarrer ou arrêter le service de données à l'aide des méthodes Prenet_start et Postnet_stop si son démarrage ou son arrêt nécessite que les adresses réseau soient configurées en aval. Vous devez tenir compte du fait que les logiciels clients peuvent réagir différemment suivant que l'adresse réseau ou le service de données se connecte en premier après la reconfiguration d'un cluster (soit scha_control() avec l'argument SCHA_GIVEOVER ou une commutation avec scswitch). Par exemple, la mise en œuvre de clients peut nécessiter un minimum de tentatives, l'abandon survenant rapidement une fois l'indisponibilité du port du service de données détectée.

Si le service de données ne requiert pas qu'une adresse réseau soit configurée en amont, démarrez-le avant de configurer l'interface réseau en amont. Vous avez ainsi l'assurance que le service de données peut répondre immédiatement aux requêtes des clients dès que l'adresse réseau a été configurée en amont. Par conséquent, les clients sont moins susceptibles d'interrompre leurs tentatives. Dans ce cas, démarrez le service de données à l'aide de la méthode Prenet_start plutôt qu'avec la méthode Start.

Si vous utilisez la méthode Postnet_stop, la ressource de service de données se trouve encore en amont lors de la configuration en aval de l'adresse réseau. La méthode Postnet_stop n’est donc appelée qu’après la configuration en aval de l’adresse réseau. En conclusion, le port du service TCP ou UDP du service de données (ou son numéro de programme RPC) semble toujours disponible aux clients du réseau, hormis lorsque l'adresse réseau elle-même ne répond pas.

Remarque –

Si vous installez un service RPC (appel de procédure à distance) sur le cluster, ce service ne doit pas utiliser les numéros de programmes suivants : 100141, 100142 et 100248. Ces numéros sont réservés respectivement aux démons Sun Cluster rgmd_receptionist, fed et pmfd. Si le service RPC installé utilise l'un de ces numéros, vous devez le modifier de façon qu'il en utilise un autre.

La décision d'utiliser les méthodes Start et Stop plutôt que les méthodes Prenet_start et Postnet_stop ou de combiner les deux, doit tenir compte des exigences et du comportement du client et du serveur.

Méthodes Init, Fini et Boot

Les trois méthodes facultatives Init, Fini et Boot permettent au RGM d'exécuter un programme d'initialisation ou d'arrêt sur une ressource. Le RGM appelle la méthode Init pour exécuter l'initialisation unique d'une ressource qui devient gérée soit parce que le groupe de ressources auquel elle appartient bascule d'un état non géré à un état géré ou parce qu'elle est créée dans un groupe de ressources déjà géré.

Le RGM appelle la méthode Fini pour supprimer la ressource qui devient non gérée soit parce que le groupe de ressources auquel elle appartient bascule d'un état géré à un état non géré ou parce qu'elle est supprimée d'un groupe de ressources géré. La suppression doit être idempotente. Par conséquent, si la suppression a déjà été effectuée, le résultat de Fini est 0 (succès).

Le RGM appelle la méthode Boot sur les nœuds qui viennent de se connecter au cluster, c'est-à-dire, qui viennent d'être initialisés ou réinitialisés.

L'initialisation induite par les méthodes Boot et Init est généralement identique. Elle doit être idempotente. Par conséquent, si la ressource a déjà été initialisée sur le nœud local, le résultat de Boot et de Init est 0 (succès).

Contrôle d'une ressource

En règle générale, vous mettez en œuvre des moyens de contrôle pour procéder périodiquement à une recherche de pannes sur les ressources, afin de déterminer si elles fonctionnent correctement. En cas d'échec, le détecteur peut tenter un redémarrage local ou transmettre une requête de basculement du groupe de ressources concerné en exécutant les fonctions API GR scha_control () ou BDSD scds_fm_action().

Vous pouvez également surveiller les performances d'une ressource et régler ou signaler les performances. Il n'est absolument pas nécessaire d'écrire un système de détection des pannes propre au type de ressources puisque même si vous le faites, le type de ressources bénéficie de la surveillance de base du cluster par Sun Cluster lui-même. Sun Cluster détecte les pannes du matériel hôte, les défaillances majeures du système d'exploitation de l'hôte et les échecs de connexion de l'hôte aux réseaux publics.

Bien que le RGM n'appelle pas un détecteur de ressource directement, il doit pouvoir le faire pour démarrer automatiquement des détecteurs pour les ressources. Lors de la déconnexion d'une ressource, le RGM appelle la méthode Monitor_stop pour arrêter le détecteur de la ressource sur les nœuds locaux avant d'arrêter la ressource elle-même. Lors de la connexion d'une ressource en ligne, le RGM appelle la méthode Monitor_start après le démarrage de la ressource.

Les fonctions API GR scha_control() et BDSD scds_fm_action() (qui appelle scha_control ()) permettent aux détecteurs de ressource de demander le basculement d'un groupe de ressources sur un autre nœud. La fonction scha_control () s'assure de la faisabilité de l'opération en exécutant notamment Monitor_check (si cette fonction est définie) pour déterminer si le nœud requis est suffisamment fiable pour gérer le groupe de ressources contenant la ressource. Si Monitor_check signale que le nœud n'est pas fiable ou que le délai d'attente de la méthode est dépassé, le RGM recherche un autre nœud pour satisfaire la requête de basculement. Si Monitor_check échoue sur tous les nœuds, le basculement est annulé.

Le détecteur de ressource peut définir les propriétés Status et Status_msg pour refléter l'affichage de l'état de la ressource sur le détecteur. Définissez ces propriétés à l'aide de la fonction API GR scha_resource_setstatus(), de la commande scha_resource_setstatus ou de la fonction BDSD scds_fm_action().

Remarque –

bien que l'utilisation de Status et Status_msg soient propres à un détecteur de ressource, n'importe quel programme peut définir ces propriétés.

La rubrique Définition d'un détecteur de pannes présente un exemple de système de détection des pannes mis en œuvre avec l'interface API GR. La rubrique Détecteur de pannes SUNW.xfnts présente un exemple de système de détection des pannes mis en œuvre avec la bibliothèque BDSD. Reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples informations sur les systèmes de détection des pannes créés à l'intérieur des systèmes de données fournis par Sun.

Ajout d'un journal de messages à une ressource

Si vous souhaitez enregistrer des messages d'état dans le même fichier journal que les autres messages du cluster, utilisez la fonction scha_cluster_getlogfacility(). Très pratique, elle permet d'extraire le numéro de fonction utilisé pour consigner les messages du cluster.

Utilisez ensuite ce numéro avec la fonction syslog() standard de Solaris pour consigner des messages dans le journal du cluster. Vous pouvez également accéder au contenu du journal du cluster à l'aide de l'interface scha_cluster_get() générique.

Gestion des processus

L'interface API GR et la BDSD offrent des fonctions de gestion des processus pour mettre en œuvre des détecteurs et des rappels de contrôle des ressources. L'interface API GR définit les fonctions suivantes (reportez-vous aux pages de manuel pour de plus amples informations sur chaque commande et programme) :

Fonction PMF : pmfadm et rpc.pmfd

La fonction PMF (Process Monitor Facility) offre un moyen de contrôler les processus et leurs descendants et de redémarrer les processus s'ils sont arrêtés. Elle comprend la commande pmfadm pour démarrer et contrôler les processus gérés et le démon rpc.pmfd.

halockrun

Programme d’exécution d’un programme enfant sans déverrouiller le fichier. Cette commande est pratique à utiliser dans les scripts shell.

hatimerun

Programme d'exécution d'un programme enfant suivant un délai d'attente. Cette commande est pratique à utiliser dans les scripts shell.

La BDSD intègre la fonction scds_hatimerun permettant de mettre en œuvre la fonctionnalité hatimerun.

Elle fournit également un ensemble de fonctions (scds_pmf_*) de mise en œuvre de la fonctionnalité PMF. Reportez-vous à la rubrique Fonctions PMF. Elle présente brièvement la fonctionnalité PMF de la bibliothèque PMF et contient une liste des fonctions individuelles.

Support administratif d'une ressource

Entre autres actions administratives possibles sur les ressources figurent le paramétrage et la modification des propriétés de ressources. L'interface API définit les méthodes de rappel de Validate et de Update, afin que vous puissiez mettre en œuvre ces actions.

Le RGM appelle la méthode Validate facultative lorsqu'une ressource est créée et qu'une action administrative met à jour les propriétés de la ressource ou de son groupe. Il transfère la valeur de propriété de cette ressource ou de son groupe à la méthode Validate. Il appelle la méthode Validate sur l'ensemble des nœuds du cluster spécifiés par la propriété Init_nodest du type de ressources (reportez-vous à la rubrique Propriétés des types de ressources ou à la page man rt_properties (5) pour de plus amples informations sur la propriété Init_nodes). Le RGM appelle Validate avant que la création ou la mise à jour ne soit appliquée. Par conséquent, l'échec d'un code de sortie d'une méthode sur n'importe quel nœud entraîne l'échec de la création ou de la mise à jour.

Il n'appelle Validate que lorsque les propriétés de la ressource ou du groupe sont modifiées par une opération de l'administrateur, et non lorsque le RGM définit des propriétés, ou lorsqu'un détecteur définit les propriétés Status et Status_msg de la ressource.

Le RGM appelle la méthode Update facultative pour notifier à une ressource en cours d'exécution que des propriétés ont été modifiées. Il appelle Update après l'exécution réussie d'une action administrative de paramétrage des propriétés d'une ressource ou de son groupe. Le RGM appelle cette méthode sur les nœuds sur lesquels cette méthode est en ligne. Cette méthode peut utiliser les fonctions d'accès de l'interface API pour lire les valeurs de propriété pouvant affecter une ressource active et régler les ressources en cours d'exécution en conséquence.

Mise en œuvre d'une ressource de basculement

Un groupe de ressources de basculement contient des adresses réseau (par exemple, le nom d'hôte logique et l'adresse partagée des types de ressources intégrés) et des ressources de basculement (ressources d'application de service de données dédiées à un service de données de basculement par exemple). Les ressources d'adresse réseau, et leurs ressources de service de données dépendantes passent d'un nœud de cluster à l'autre lors du basculement ou de la commutation des services de données. Le RGM propose de nombreuses propriétés prenant en charge la mise en œuvre d'une ressource de basculement.

Définissez la propriété booléenne du type de ressources Failover sur TRUE pour empêcher la configuration d'une ressource dans un groupe pouvant être en ligne sur plusieurs nœuds simultanément. Cette propriété est définie sur FALSE par défaut. Vous devez donc la déclarer comme TRUE dans le fichier RTR lorsqu'il s'agit d'une ressource de basculement.

La propriété de ressource Scalable détermine si la ressource utilise la fonction d'adresse partagée du cluster. Pour une ressource de basculement, définissez Scalable sur FALSE car elle ne doit pas utiliser d'adresses partagées.

La propriété de groupe de ressources RG_mode permet à l'administrateur du cluster d'identifier un groupe de ressources comme étant évolutif ou de basculement. Si RG_mode est défini sur FAILOVER, le RGM configure la propriété Maximum_primaries du groupe sur 1 et limite la gestion du groupe de ressources à un seul nœud. Le RGM ne permet pas de créer une ressource dont la propriété Failover est définie sur TRUE dans un groupe de ressources dont la propriété RG_mode est définie sur SCALABLE.

La propriété de groupe de ressources Implicit_network_dependencies spécifie que le RGM doit appliquer les dépendances implicites fortes des ressources d'adresse non prévues pour être utilisées en réseau à toutes les ressources d'adresse réseau (nom d'hôte logique et adresse partagée) au sein du groupe. Cela signifie que les méthodes Start des ressources d'adresse non prévues pour être utilisées en réseau ne sont pas appelées tant que les adresses réseau du groupe ne sont pas configurées en amont. La propriété Implicit_network_dependencies est définie par défaut sur TRUE.

Mise en œuvre d'une ressource évolutive

Une ressource évolutive peut être en ligne sur plusieurs nœuds simultanément. Les ressources évolutives comprennent les services de données comme Sun Cluster HA for Sun One Web Server (précédemment Sun Cluster HA for Sun ONE Web Server) et Sun Cluster HA for Apache.

Le RGM propose de nombreuses propriétés prenant en charge la mise en œuvre d'une ressource évolutive.

Définissez la propriété booléenne du type de ressources Failover sur FALSE pour autoriser la configuration d'une ressource dans un groupe pouvant être ligne sur plusieurs nœuds simultanément.

La propriété de ressource Scalable détermine si la ressource utilise la fonction d'adresse partagée du cluster. Définissez cette propriété sur TRUE car une ressource évolutive utilise une ressource d'adresse partagée pour que les multiples instances du service évolutif soient présentées comme un service unique au client.

La propriété RG_mode permet à l'administrateur du cluster d'identifier un groupe de ressources comme étant évolutif ou de basculement. Si la propriété RG_mode est définie sur SCALABLE, le RGM permet de configurer Maximum_primaries sur une valeur supérieure à 1, ce qui signifie que le groupe peut être géré par plusieurs nœuds simultanément. Le RGM permet d'instancier une ressource dont la propriété Failover est définie sur FALSE dans un groupe de ressources dont la propriété RG_mode est définie sur SCALABLE.

L'administrateur du cluster crée un groupe de ressources évolutives pour contenir les ressources de service évolutives et un groupe de ressources de basculement pour contenir les ressources d'adresse partagée dont la ressource évolutive dépend.

L'administrateur du cluster utilise la propriété de groupe de ressources RG_dependencies pour spécifier dans quel ordre les groupes de ressources sont connectés à un nœud et en sont déconnectés. Cet ordre est important dans le cadre d'un service évolutif car les ressources évolutives et les ressources d'adresse partagée dont elles dépendent se trouvent dans des groupes différents. Un service de données évolutif nécessite que son adresse réseau (adresse partagée) soit configurée en amont avant d'être démarré. Par conséquent, l'administrateur doit définir la propriété RG_dependencies (du groupe de ressources contenant le service évolutif) pour inclure le groupe de ressources contenant les ressources d'adresse partagée.

Lorsque vous déclarez la propriété Scalable d'une ressource dans le fichier RTR, le RGM crée automatiquement l'ensemble des propriétés évolutives suivantes pour cette ressource :

Network_resources_used

Identifie les ressources d'adresse partagée utilisées par cette ressource. Cette propriété est définie par défaut sur une chaîne de caractères vide. Par conséquent, l'administrateur du cluster doit fournir la liste réelle des adresses partagées que le service évolutif utilise lors de la création de la ressource. La commande scsetup et SunPlex Manager offrent des fonctions permettant de paramétrer automatiquement les ressources et les groupes requis pour les services évolutifs.

Load_balancing_policy

Spécifie la règle d'équilibrage de la charge de la ressource. Vous pouvez explicitement définir cette règle dans le fichier RTR (ou activer la valeur par défaut LB_WEIGHTED). Dans tous les cas, l'administrateur du cluster peut modifier la valeur lors de la création de la ressource (à moins que vous ne définissiez la valeur Tunable de la propriété Load_balancing_policy sur NONE ou FALSE dans le fichier RTR). Valeurs valides :

LB_WEIGHTED

La charge est répartie entre plusieurs nœuds en fonction des poids définis dans la propriété >Load_balancing_weights.

LB_STICKY

Un client donné (identifié par son adresse IP) du service évolutif est toujours envoyé au même nœud du cluster.

LB_STICKY_WILD

Un client donné (identifié par son adresse IP), connecté à l'adresse IP d'un service sticky à caractère joker est toujours envoyé sur le même nœud du cluster, indépendamment du port vers lequel il est dirigé.

Dans le cadre d’un service évolutif défini sur >Load_balancing_policy LB_STICKY ou LB_STICKY_WILD, la modification de la propriété Load_balancing_weights alors que le service est en ligne peut réinitialiser les affinités des clients existants. Le cas échéant, un autre nœud peut prendre en charge une requête ultérieure du client, même si ce dernier était précédemment géré par un autre nœud du cluster.

Le redémarrage d'une nouvelle instance du service sur un cluster peut également réinitialiser les affinités des clients existants.

Load_balancing_weights

Spécifie la charge à envoyer à chaque nœud. Format : poids@nœud, poids@nœud, poids correspondant à un nombre entier reflétant la part relative de la charge distribuée au nœud spécifié. La fraction de la charge distribuée à un nœud correspond au poids de ce nœud divisé par la somme de tous les poids des instances actives. Par exemple, 1@1,3@2 indique que le nœud 1 reçoit 1/4 de la charge et que le nœud 2 en reçoit les 3/4.

Port_list

Identifie les ports d'écoute du serveur. Cette propriété est définie par défaut sur une chaîne de caractères vide. Vous pouvez fournir une liste des ports dans le fichier RTR. Sinon, l'administrateur du cluster doit fournir la liste réelle des ports lors de la création de la ressource.

Vous pouvez créer un service de données que l'administrateur pourra configurer en tant que service de basculement ou évolutif. Pour ce faire, déclarez la propriété de type de ressources Failover et la propriété de ressource Scalable sur FALSE dans le fichier RTR du service de données. Spécifiez à la création que la propriété Scalable est réglable.

La valeur de la propriété Failover (FALSE) permet de configurer la ressource dans un groupe de ressources évolutives. L'administrateur peut activer les adresses partagées en définissant la valeur de la propriété Scalable sur TRUE lors de la création de la ressource, créant ainsi un service évolutif.

D'un autre côté, même si la propriété Failover est définie sur FALSE, l'administrateur peut configurer la ressource dans un groupe de ressources de basculement pour mettre en œuvre un service de basculement. L'administrateur ne modifie pas la valeur de la propriété Scalable (déjà définie sur FALSE). Pour prendre en charge cette éventualité, vous devez fournir un contrôle de la propriété Scalable dans la méthode Validate. Si la propriété Scalable est définie sur FALSE, vérifiez que la ressource est configurée dans un groupe de ressources de basculement.

Vous trouverez de plus amples informations sur les ressources évolutives dans le Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Contrôles de validation des services évolutifs

Chaque fois qu'une ressource est créée et mise à jour alors que la propriété d'évolutivité (Scalable)est définie sur TRUE, le RGM valide diverses propriétés de ressources. Si les propriétés ne sont pas configurées correctement, le RGM rejette les tentatives de mise à jour ou de création. Le RGM effectue les contrôles suivants :

Écriture et test des services de données

Cette rubrique fournit des informations sur l'écriture et la vérification de services de données.

Utilisation du mécanisme Keep-Alives

Côté serveur, l'utilisation du mécanisme Keep-Alives au niveau des connexions TCP protège le serveur contre les gaspillages de ressources système d'un client en aval (ou partitionné en réseau). Si ces ressources ne sont pas nettoyées (dans un serveur restant allumé suffisamment longtemps), elles finissent par s'étendre de façon illimitée lorsque les clients tombent en panne et sont réinitialisés.

Si les communications client-serveur passent par un flux TCP, le serveur et le client doivent activer le mécanisme Keep-Alives au niveau des connexions TCP. Cette disposition s'applique également dans le cas d'un serveur unique non-HA.

D'autres protocoles orientés connexion peuvent intégrer un mécanisme Keep-Alives.

Côté client, l'utilisation d'un mécanisme Keep-Alives au niveau des connexions TCP permet au client d'être notifié du basculement ou de la commutation d'une ressource d'adresse réseau d'un hôte physique vers un autre. Ce transfert de la ressource d'adresse réseau interrompt la connexion TCP. Pourtant, à moins que le client ait activé le mécanisme Keep-Alives, il n'est pas nécessairement informé de la déconnexion si la connexion est latente à ce moment.

Par exemple, supposons que le client attend une réponse du serveur à une requête longue durée, que le serveur a déjà reçu cette requête et qu'il en a déjà accusé réception au niveau de la couche TCP. Dans cette situation, le module TCP du client n'a pas besoin de continuer de transmettre la requête alors que l'application cliente est bloquée car elle attend la réponse.

Chaque fois que cela est possible, en plus d'utiliser le mécanisme Keep-Alives au niveau de la connexion TCP, l'application cliente doit également exécuter un mécanisme Keep-Alives périodique à son niveau. De fait, ce mécanisme n'est pas parfait dans tous les cas de limite possibles. L'utilisation d'un mécanisme Keep-Alives au niveau de l'application requiert généralement que le protocole client-serveur prenne en charge une opération Null ou au moins une opération de lecture seule efficace, telle une opération d'état.

Test d'un service de données à haut niveau de disponibilité

Cette rubrique apporte quelques suggestions quant aux procédures de test relatives à la mise en œuvre d'un service de données dans un environnement à haut niveau de disponibilité. Les cas présentés sont suggestifs et non exhaustifs. Vous devez accéder à une configuration banc d'essai de Sun Cluster, afin que la procédure de test n'ait aucune répercussion sur les machines de production.

Vérifiez que votre service de données à haut niveau de disponibilité adopte un comportement approprié dans toutes les situations lorsqu'un groupe de ressources est déplacé d'un hôte physique vers un autre, y compris en cas de panne du système ou d'utilisation de la commande scswitch. Vérifiez que les machines clientes continuent de recevoir le service après ces événements.

Testez l'idempotence des méthodes. Par exemple, remplacez chaque méthode temporairement par un script shell court appelant la méthode d'origine au moins deux fois.

Coordination des dépendances entre les ressources

Il arrive parfois qu'un service de données client-serveur transmette des requêtes à un autre service de données client-serveur tout en exécutant une requête pour un client. Plus simplement, un service de données A dépend d'un service de données B ; par conséquent, pour que A puisse fournir son service, B doit fournir le sien. Pour satisfaire à cette exigence, Sun Cluster autorise la configuration de dépendances entre les ressources au sein d'un groupe de ressources. Les dépendances affectent l'ordre dans lequel Sun Cluster démarre et arrête les services de données. Reportez-vous à la page man scrgadm(1M) pour de plus amples informations.

Si les ressources de votre type de ressources dépendent des ressources d'un autre type, vous devez notifier à l'utilisateur de configurer les ressources et les groupes de ressources de façon appropriée ou fournir des scripts ou des outils permettant de les configurer correctement. Si la ressource dépendante doit être exécutée sur le même nœud que la ressource dont d'autres dépendent, vous devez configurer ces deux ressources dans le même groupe.

Déterminez si vous souhaitez utiliser des dépendances explicites entre les ressources ou les omettre, puis testez la disponibilité du ou des autres services de données dans le code de votre service de données à haut niveau de disponibilité. Si la ressource dépendante/dont d'autres dépendent est exécutable sur différents nœuds, configurez chaque ressource dans un groupe distinct. Le cas échéant, une interrogation est requise car il est impossible de configurer ce type de dépendance entre les groupes.

Certains services de données ne sauvegardent directement aucune donnée. Pour ce faire, ils dépendent d'un autre service de données back-end. Un tel service de données convertit toutes les requêtes de lecture et de mise à jour en appels au service de données back-end. Par exemple, considérons un service d'agenda client-serveur hypothétique conservant toutes ses données dans une base de données SQL comme Oracle. Ce service possède son propre protocole réseau client-serveur. Par exemple, son protocole a pu être défini au moyen d'un langage RPC, comme ONC RPC.

Dans l'environnement Sun Cluster, vous pouvez utiliser HA-ORACLE pour rendre hautement disponible la base de données Oracle back-end, puis écrire des méthodes simples de démarrage et d'arrêt du démon d'agenda. L'utilisateur final enregistre le type de ressource d'agenda avec Sun Cluster.

Si l'application d'agenda doit fonctionner sur le même nœud que la base de données Oracle, l'utilisateur final configure la ressource d'agenda dans le même groupe de ressources que la ressource HA-ORACLE. Ensuite, il fait dépendre la ressource d'agenda de la ressource HA-ORACLE. Cette dépendance est spécifiée à l'aide de la propriété Resource_dependencies dans scrgadm.

Si la ressource HA-ORACLE peut fonctionner sur un autre nœud que la ressource d'agenda, l'utilisateur final les configure dans deux groupes de ressources distincts. Il peut définir la dépendance du groupe de ressources d'agenda sur le groupe de ressources Oracle. Cependant, les dépendances entre les groupes de ressources ne sont effectives que si vous démarrez ou arrêtez simultanément ces deux groupes sur le même nœud. Par conséquent, après avoir été démarré, le démon du service de données d'agenda doit attendre que la base de données Oracle devienne disponible. La méthode Start du type de ressources d'agenda doit juste retourner qu'elle a réussi dans ce cas. De fait, si elle est indéfiniment bloquée, son groupe de ressources bascule en mode occupé et il devient impossible d'en modifier l'état (édition, basculement ou commutation notamment). En outre, si la méthode Start de la ressource d'agenda dépasse le délai d'attente ou se ferme avec une valeur différente de zéro, le groupe de ressources risque de basculer continuellement entre plusieurs nœuds tandis que la base de données Oracle reste indisponible.