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.

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 d'équilibrage de la charge équilibrage_charge_pondéré, 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 d'équilibrage de la charge qui restreint le trafic d'un client donné à une instance de l'application. Les règles d'équilibrage de la charge équilibrage_charge_sticky et équilibrage_charge_sticky_jocker 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 gestionnaire RGM les distribue entre les instances du service. Reportez-vous à la rubrique Mise en oeuvre 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 noeuds du cluster, vous ne procédez pas au développement sur un noeud 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. À la fin du développement (sur un noeud non-cluster), vous pouvez transférer le service de données terminé sur un cluster pour l'exécuter et le tester.

Remarque :

veillez à utiliser une version de développement de Solaris 5.8 ou supé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 décrit comment installer le package SUNWscdev et configurer les 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 noeuds 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 noeuds 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 ressource, la version, la version de l'interface API, etc., ainsi que les chemins d'accès aux méthodes de rappel. Le Tableau A–1 répertorie toutes les propriétés de types de ressources.

Les propriétés de ressources, telles que Mode_basculement et Intervalle_sonde_complet et les délais d'attente de la méthode définissent également la configuration statique de la ressource. Les propriétés de ressource dynamique, comme État_ressource et Statut, reflètent l'état actif d'une ressource gérée. Le Tableau A–2 présente les propriétés de ressources.

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 Type_ressource) 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 gestionnaire 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, Noeuds_installés 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 gestionnaire RGM est insensible à la casse dans les noms de propriétés. 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.
#
Type_ressource = "smpl";
id_fournisseur = SUNW;
Description_TR = "Sample Service on Sun Cluster";

Version_RT ="1.0";
Version_API = 2;
Basculement = VRAI;

noeuds_init = Éléments_principaux_GR;

rép_base_TR=/opt/SUNWsmpl/bin;

Démarrage = smpl_svc_start;
Arrêt = smpl_svc_stop;

Validation = smpl_validate;
Mise_à_jour = smpl_update;

Démarrage_détecteur = smpl_monitor_start;
Arrêt_détecteur = smpl_monitor_stop;
Contrôle_détecteur = smpl_monitor_check;
Astuce :

la propriété Type_ressource 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 :

Type_ressource et id_fournisseur

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é Type_ressources (smpl) uniquement ou en utilisant le préfixe id_fournisseur suivi d'un point “.” comme séparateur et du nom du type de ressources (SUNW.smpl), comme dans notre exemple. Si vous utilisez id_fournisseur, 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 gestionnaire 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.

Version_RT

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

Version_API

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

Basculement = VRAI

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

Démarrage, Arrêt, Validation, etc.

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

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

noeuds_init = Éléments_principaux_GR

Indique que le gestionnaire RGM n'appelle les méthodes Init, Initialisation, Fini et Validation que sur les noeuds pouvant gérer le service de données. Les noeuds spécifiés par Éléments_principaux_GR constituent un sous-ensemble de tous les noeuds sur lesquels le service de données est installé. Définissez la valeur sur noeuds_installés_TR pour indiquer que le gestionnaire RGM appelle ces méthodes sur tous les noeuds sur lesquels le service de données est installé.

Rép_base_TR

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.

Démarrage, Arrêt, Validation, etc.

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

Déclaration des propriétés de ressources

Comme pour les propriétés de type de ressources, vous déclarez des propriétés de ressources 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. Le Tableau A–4 répertorie les attributs permettant de modifier et de définir des propriétés de ressources. 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 ressource 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 ressource 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.
{
        PROPRIÉTÉ = Délai_démarrage;
MIN=60;
PAR DÉFAUT=300;
}
{
PROPRIÉTÉ = Délai_arrêt;
MIN=60;
PAR DÉFAUT=300;
}
{
PROPRIÉTÉ = Délai_validation;
MIN=60;
PAR DÉFAUT=300;
}
{
PROPRIÉTÉ = Délai_mise_à_jour;
MIN=60;
PAR DÉFAUT=300;
}
{
PROPRIÉTÉ = Délai_démarrage_détecteur;
MIN=60;
PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Délai_arrêt_détecteur;
MIN=60;
PAR DÉFAUT=300;
{
PROPRIÉTÉ = Délai_contrôle_détecteur;
MIN=60;
PAR DÉFAUT=300;
}

Le premier attribut de chaque déclaration de propriétés de ressources doit être le nom de la propriété (PROPRIÉTÉ = valeur). Vous pouvez configurer des propriétés de ressources 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. Reportez-vous au Tableau A–4 pour consulter la liste complète des attributs de propriétés de ressources.

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

{
        PROPRIÉTÉ = Mode_basculement;
PAR DÉFAUT=LOGICIEL;
RÉGLABLE = À_TOUT_MOMENT;
}
{
PROPRIÉTÉ = Intervalle_sonde_complet;
MIN=1;
MAX=3600;
PAR DÉFAUT=60;
RÉGLABLE = À_TOUT_MOMENT;
}

#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 noeud.
{
PROPRIÉTÉ = Nombre_nouvelles_tentatives;
MAX=10;
PAR DÉFAUT=2;
RÉGLABLE = À_TOUT_MOMENT;
}

# Configurez Intervalle_nouvelles_tentatives sur un multiple de 60 car ce paramètre est
# arrondi lors du convertissement des secondes en minutes. Par exemple, 50 secondes
# sera arrondi à 1 minute. Cette propriété vous permet de minuter le nombre
# de tentatives (Nombre_nouvelles_tentatives).
{
PROPRIÉTÉ = Intervalle_nouvelles_tentatives;
MAX=3600;
PAR DÉFAUT=300;
RÉGLABLE = À_TOUT_MOMENT;
}

{
PROPRIÉTÉ = Ressources_réseau_utilisées;
RÉGLABLE = LORSQU'ELLE EST DÉSACTIVÉE;
PAR DÉFAUT = "";
}
{
PROPRIÉTÉ = Évolutivité;
PAR DÉFAUT = FAUX;
RÉGLABLE = À_LA_CRÉATION;
}
{
PROPRIÉTÉ = Règle_équilibrage_charge;
PAR DÉFAUT = Équilibrage_charge_pondéré;
RÉGLABLE = À_LA_CRÉATION;
}
{
PROPRIÉTÉ = Poids_équilibrage_charge;
PAR DÉFAUT = "";
RÉGLABLE = À_TOUT_MOMENT;
}
{
PROPRIÉTÉ = Liste_ports;
RÉGLABLE = À_LA_CRÉATION;
PAR DÉFAUT = ;
}

Ces déclarations de propriétés de ressources créent l'attribut RÉGLABLE, qui restreint les occasions permettant à l'administrateur système de modifier leurs valeurs. À_LA_CRÉATION 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 de manuel r_properties(5)) :

Mode_basculement

Indique si le gestionnaire RGM doit relocaliser le groupe de ressources ou arrêter le noeud en cas d'échec d'une méthode Démarrage ou Arrêt.

Intervalle_sonde_complet, Nombre_nouvelles_tentatives, Intervalle_nouvelles_tentatives

Propriétés utilisées dans le système de détection des pannes. Réglable et À_tout_moment sont identiques de sorte que l'administrateur système peut les ajuster si le système de détection des pannes ne fonctionne pas de façon optimale.

Ressources_réseau_utilisées

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.

Évolutivité

Définissez cette propriété sur FAUX 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 Basculement définie sur VRAI 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 oeuvre des méthodes de rappel pour de plus amples informations sur l'utilisation de cette ressource.

Règle_équilibrage_charge, Poids_équilibrage_charge

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

Liste_ports

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).
{
PROPRIETE = Liste_répconf;
EXTENSION;
TABLEAU DE CHAÎNES DE CARACTÈRES;
RÉGLABLE = À_LA_CRÉATION;
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.
{
PROPRIÉTÉ = Nombre_nouvelles_tentatives_détecteur;
EXTENSION;
INT;
PAR DÉFAUT = 4;
RÉGLABLE = À_TOUT_MOMENT;
DESCRIPTION = "Nombre de redémarrages de PMF autorisé par le détecteur de panne.";
}
{
PROPRIÉTÉ = Intervalle_nouvelles_tentatives_détecteur;
EXTENSION;
INT;
PAR DÉFAUT = 2;
RÉGLABLE = À_TOUT_MOMENT;
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.
{
PROPRIÉTÉ = Délai_test;
EXTENSION;
INT;
PAR DÉFAUT = 120;
RÉGLABLE = À_TOUT_MOMENT;
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.
{
PROPRIÉTÉ = Niveau_de_contrôle_enfant;
EXTENSION;
INT;
PAR DÉFAUT = -1;
RÉGLABLE = À_TOUT_MOMENT;
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 :

Liste_rép_conf

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.

Nombre_nouvelles_tentatives_détecteur, Intervalle_nouvelles_tentatives_détecteur, Délai_test

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

Niveau_de_contrôle_enfant

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 oeuvre des méthodes de rappel

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

Accès aux informations sur les propriétés de ressources 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 de manuel 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 de manuel 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 ressources (à l'exception du paramétrage de Statut et msg_statut). 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 gestionnaire RGM appelle la méthode.)

Idempotence des méthodes

En règle générale, le gestionnaire 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 Démarrage échoue, le gestionnaire RGM peut appeler une méthode Arrêt sur une ressource même si cette dernière n'a jamais été exécutée. De même, le gestionnaire RGM peut exécuter la méthode Arrêt 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 Démarrage_détecteur et Arrêt_détecteur.

C'est pourquoi vous devez créer une relation d'idempotence entre les méthodes Arrêt et Arrêt_détecteur. Les appels répétés d'Arrêt ou Arrêt_détecteur 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 qu'Arrêt et Arrêt_détecteur doivent revenir à 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, Initialisation et Mise_à_jour doivent également être idempotentes. Il n'est pas nécessaire qu'une méthode Démarrage soit idempotente.

Service de données générique

Un service de données générique (GDS) est un mécanisme permettant de rendre hautement disponibles et évolutives des applications uniques en les connectant à la structure du gestionnaire 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 pour de plus amples informations.

Contrôle d'une application

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

Démarrage et arrêt d'une ressource

La mise en oeuvre d'un type de ressources requiert au minimum une méthode Démarrage et une méthode Arrêt. Le gestionnaire RGM appelle les programmes de méthode du type de ressources aux moments opportuns et sur les noeuds appropriés pour connecter ou déconnecter les groupes de ressources. Par exemple, après la défaillance d'un noeud de cluster, le gestionnaire RGM transfère les groupes de ressources gérés par ce noeud sur un autre noeud. Vous devez mettre en oeuvre une méthode Démarrage pour permettre au gestionnaire RGM de redémarrer chaque ressource sur le noeud hôte restant.

Une méthode Démarrage ne doit pas être retournée tant que la ressource n'a pas été exécutée et n'est pas disponible sur le noeud 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 Démarrage (configurez la propriété Délai_démarrage sur une valeur minimum dans le fichier d'enregistrement du type de ressources).

Vous devez mettre en oeuvre une méthode Arrêt lorsque le gestionnaire RGM déconnecte un groupe de ressources. Par exemple, supposons qu'un groupe de ressources est déconnecté du Noeud1 puis reconnecté au Noeud2. Tout en déconnectant le groupe de ressources, le gestionnaire RGM appelle la méthode Arrêt sur les ressources du groupe dont vous souhaitez arrêter toute activité sur le Noeud1. Une fois que les méthodes Arrêt ont été exécutées sur toutes les ressources du Noeud1, le gestionnaire RGM connecte le groupe de ressources au Noeud2.

Une méthode Arrêt ne doit pas être retournée tant que la ressource n'a pas cessé totalement toute activité au niveau du noeud local et qu'elle n'est pas complètement arrêtée. La mise en oeuvre la plus fiable d'une méthode Arrêt se traduit par l'achèvement de tous les processus sur le noeud 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 Arrêt. Définissez la propriété Délai_arrêt dans le fichier d'enregistrement du type de ressources.

Lorsqu'une méthode Arrêt é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 oeuvre des méthodes Arrêt et Arrêt_détecteur 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 noeud local.

Choix des méthodes Démarrage et Arrêt à utiliser

Cette rubrique présente des astuces permettant de savoir quand il est préférable d'utiliser les méthodes Démarrage et Arrêt par opposition aux méthodes Démarrage_avant_réseau et Arrêt_après_réseau. 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 Démarrage_avant_réseau et Arrêt_après_réseau permettent à la mise en oeuvre 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 gestionnaire RGM appelle les méthodes plombant les adresses réseau (sans les configurer en amont) avant d'appeler la méthode Démarrage_avant_réseau du service de données. Le gestionnaire RGM appelle les méthodes déplombant les adresses réseau après avoir appelé les méthodes Arrêt_après_réseau du service de données. Séquence applicable lorsque le gestionnaire RGM connecte un groupe de ressources :

  1. Plombage des adresses réseau.

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

  3. Configuration en amont des adresses réseau.

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

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

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

  2. Configuration en aval des adresses réseau.

  3. Appel de la méthode Arrêt_après_réseau du service de données (le cas échéant).

  4. Déplombage des adresses réseau.

Pour choisir les méthodes Démarrage,Arrêt, Démarrage_avant_réseau ou Arrêt_après_réseau à 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 gestionnaire RGM appelle des méthodes de configuration en amont des adresses réseau avant d'appeler les méthodes de ressources de Démarrage 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 Démarrage 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 gestionnaire RGM appelle des méthodes de configuration en aval des adresses réseau avant d'appeler les méthodes de ressources d'Arrêt 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 Arrêt 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 Démarrage et Arrêt.

Par contre, vous devez démarrer ou arrêter le service de données à l'aide des méthodes Démarrage_avant_réseau et Arrêt_après_réseau 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 oeuvre de clients peut nécessiter un minimum de tentatives, l'abandon survenant rapidement une fois que l'indisponibilité du port du service de données a été 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 Démarrage_avant_réseau plutôt qu'avec la méthode Démarrage.

Si vous utilisez la méthode Arrêt_après_réseau, 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 Arrêt_après_réseau 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.

La décision d'utiliser les méthodes Démarrage et Arrêt plutôt que les méthodes Démarrage_avant_réseau et Arrêt_après_réseau ou de combiner les deux, doit tenir compte des exigences et du comportement du client et du serveur.

Méthodes Init, Fini et Initialisation

Les trois méthodes facultatives d'Init, de Fini et d'Initialisation permettent au gestionnaire RGM d'exécuter un programme d'initialisation ou d'arrêt sur une ressource. Le gestionnaire 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 gestionnaire 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 gestionnaire RGM appelle la méthode Initialisation sur les noeuds 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 Initialisation 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 noeud local, le résultat d'Initialisation et Init est 0 (succès).

Contrôle d'une ressource

En règle générale, vous mettez en oeuvre 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 gestionnaire 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 gestionnaire RGM appelle la méthode Arrêt_détecteur pour arrêter le détecteur de la ressource sur les noeuds locaux avant d'arrêter la ressource elle-même. Lors de la connexion d'une ressource en ligne, le gestionnaire RGM appelle la méthode Démarrage_détecteur 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 noeud. La fonction scha_control () s'assure de la faisabilité de l'opération en exécutant notamment Contrôle_détecteur (si cette fonction est définie) pour déterminer si le noeud requis est suffisamment fiable pour gérer le groupe de ressources contenant la ressource. Si Contrôle_détecteur signale que le noeud n'est pas fiable ou que le délai d'attente de la méthode est dépassé, le gestionnaire RGM recherche un autre noeud pour honorer la requête de basculement. Si Contrôle_détecteur échoue sur tous les noeuds, le basculement est annulé.

Le détecteur de ressource peut définir les propriétés Statut et msg_Statut 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 Statut et msg_statut 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 oeuvre 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 oeuvre 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 oeuvre 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 de contrôle des processus :
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 oeuvre la fonctionnalité hatimerun.

Elle fournit également un ensemble de fonctions (scds_pmf_*) de mise en oeuvre 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 Validation et Mise_à_jour, afin que vous puissiez mettre en oeuvre ces actions.

Le gestionnaire RGM appelle la méthode Validation 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 Validation. Il appelle Validation sur l'ensemble des noeuds du cluster spécifiés par la propriété noeuds_init du type de ressources (reportez-vous à la rubrique Propriétés des types de ressources ou à la page de manuel rt_properties(5) pour de plus amples informations sur noeuds_init). Le gestionnaire RGM appelle Validation 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 noeud entraîne l'échec de la création ou de la mise à jour.

Il n'appelle Validation 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 Statut et msg_statut de la ressource.

Le gestionnaire RGM appelle la méthode Mise_à_jour facultative pour notifier à une ressource en cours d'exécution que des propriétés ont été modifiées. Il appelle Mise_à_jour 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 gestionnaire RGM appelle cette méthode sur les noeuds 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 oeuvre 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 noeud de cluster à l'autre lors du basculement ou de la commutation des services de données. Le gestionnaire RGM propose de nombreuses propriétés prenant en charge la mise en oeuvre d'une ressource de basculement.

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

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

La propriété de groupe de ressources Mode_GR permet à l'administrateur du cluster d'identifier un groupe de ressources comme étant évolutif ou de basculement. Si Mode_GR est défini sur BASCULEMENT, le gestionnaire RGM configure la propriété Éléments_principaux_max. du groupe sur 1 et limite la gestion du groupe de ressources à un seul noeud. Le gestionnaire RGM ne permet pas de créer une ressource dont la propriété Basculement est définie sur VRAI dans un groupe de ressources dont la propriété Mode_GR est définie sur ÉVOLUTIVITÉ.

La propriété de groupe de ressources Dépendances_réseau_implicites spécifie que le gestionnaire 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 Démarrage 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é Dépendances_réseau_implicites est définie par défaut sur VRAI.

Mise en oeuvre d'une ressource évolutive

Une ressource évolutive peut être en ligne sur plusieurs noeuds 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 gestionnaire RGM propose de nombreuses propriétés prenant en charge la mise en oeuvre d'une ressource évolutive.

Définissez la propriété booléenne du type de ressources Basculement sur FAUX pour autoriser la configuration d'une ressource dans un groupe pouvant être ligne sur plusieurs noeuds simultanément.

La propriété de ressource Évolutivité détermine si la ressource utilise la fonction d'adresse partagée du cluster. Définissez cette propriété sur VRAI 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é Mode_GR permet à l'administrateur du cluster d'identifier un groupe de ressources comme étant évolutif ou de basculement. Si la propriété Mode_GR est définie sur ÉVOLUTIVITÉ, le gestionnaire RGM permet de configurer Éléments_principaux_max sur une valeur supérieure à 1, ce qui signifie que le groupe peut être géré par plusieurs noeuds simultanément. Le gestionnaire RGM permet d'instancier une ressource dont la propriété Basculement est définie sur FAUX dans un groupe de ressources dont la propriété Mode_GR est définie sur ÉVOLUTIVITÉ.

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 Dépendances_groupe_ressources pour spécifier dans quel ordre les groupes de ressources sont connectés à un noeud 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é Dépendances_groupe_ressources (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é Évolutivité d'une ressource dans le fichier RTR, le gestionnaire RGM crée automatiquement l'ensemble des propriétés évolutives suivantes pour cette ressource :

Ressources_réseau_utilisées

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.

Règle_équilibrage_charge

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 Équilibrage_charge_pondéré). 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 Réglable de la propriété Règle_équilibrage_charge sur AUCUN ou FAUX dans le fichier RTR). Valeurs légales :

Équilibrage_charge_pondéré

La charge est répartie entre plusieurs noeuds en fonction des poids définis dans la propriété Poids_équilibrage_charge.

Équilibrage_charge_sticky

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

Équilibrage_charge_sticky_étendu

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 noeud du cluster, indépendamment du port vers lequel il est dirigé.

Dans le cadre d'un service évolutif défini sur Règle_équilibrage_charge Équilibrage_charge_sticky ou Équilibrage_charge_sticky_étendu, la modification de la propriété Poids_équilibrage_charge alors que le service est en ligne peut réinitialiser les affinités des clients existants. Le cas échéant, un autre noeud 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 noeud du cluster.

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

Poids_équilibrage_charge

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

Liste_ports

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 Basculement et la propriété de ressource Évolutivité sur FAUX dans le fichier RTR du service de données. Spécifiez à la création que la propriété Évolutivité est réglable.

La valeur de la propriété Basculement (FAUX) 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é Évolutivité sur VRAI 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é Basculement est définie sur FAUX, l'administrateur peut configurer la ressource dans un groupe de ressources de basculement pour mettre en oeuvre un service de basculement. L'administrateur ne modifie pas la valeur de la propriété Évolutivité (déjà définie sur FAUX). Pour prendre en charge cette éventualité, vous devez fournir un contrôle de la propriété Évolutivité dans la méthode Validation. Si la propriété Évolutivité est définie sur FAUX, 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 Sun Cluster Concepts Guide for Solaris OS.

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é est définie sur VRAI, le gestionnaire RGM valide diverses propriétés de ressources. Si les propriétés ne sont pas configurées correctement, le gestionnaire RGM rejette les tentatives de mise à jour ou de création. Le gestionnaire 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 averti 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-là.

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 oeuvre 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 de manuel 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 noeud 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 noeuds, 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 noeud 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 balise de propriété Dépendances_ressource dans scrgadm.

Si la ressource HA-ORACLE peut fonctionner sur un autre noeud 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 noeud. 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 Démarrage 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 Démarrage 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 noeuds tandis que la base de données Oracle reste indisponible.