test

Guide du développeur de services de données Sun Cluster pour SE Solaris

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

Ce chapitre explique comment rendre une application hautement disponible et évolutive et fournit des informations détaillées relatives au 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 pour pouvoir être rendue hautement disponible et évolutive. Si l’application ne satisfait pas toutes les conditions requises, vous pourrez modifier son code source pour la rendre hautement disponible et évolutive.

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 à 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 indiqués à la suite de la liste.

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 chargeLb_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 d'équilibrage de la charge qui restreint le trafic d'un client donné à une instance de l'application. Les règles d'équilibrage de charge Lb_sticky et Lb_sticky_wild transmettent de manière répétée toutes les requêtes d'un client à la même instance de l'application, où elles pourront exploiter 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 obtenir de plus amples informations sur le paramétrage de la règle d'équilibrage de 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 DSDL 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 comprenant un code source et un code 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 DSDL 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 APIGR 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 DSDL ou APIGR. Quelle que soit votre façon de procéder, il est généralement conseillé de commencer par utiliser Agent Builder pour les raisons suivantes :

Remarque –

contrairement à l'interface APIGR fournissant un ensemble de fonctions C et un ensemble de commandes à utiliser dans les scripts, la bibliothèque DSDL 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 APIGR car il n'y a pas de commande DSDL ksh.

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

Avant de commencer à développer un service de données, vous devez installer le package de développement Sun Cluster (SUNWscdev) pour pouvoir 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 la commande 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 souhaitez créer un service de données basé sur C++ à utiliser sur Sun Cluster, vous devez compiler ce service de données comme suit :

À la fin du développement (sur un nœud non-cluster), vous pouvez transférer le service de données terminé sur un cluster pour le tester.

Remarque –

Veillez à utiliser une version de développement ou le groupe de logiciels complet de distribution du système d'exploitation Solaris 8 ou une version ultérieure.

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

ProcedureParamé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.

Étapes

  1. Connectez-vous en tant que superutilisateur ou prenez un rôle équivalent.

  2. Changez de répertoire en allant sur le CD-ROM dans le répertoire voulu. 


    # cd cd-rom-directory

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

    • Pour le système d'exploitation Solaris 10 dans un environnement de zones, en tant qu'administrateur général de la zone globale, entrez la commande suivante : 


      # pkgadd -G -d . SUNWscdev

      Le package SUNWscdev s'ajoute à la zone globale à condition que le contenu de SUNWscdev n'ait aucune incidence sur les parties de la zone globale partagées avec une zone non globale.

    • Pour toute autre version du système d'exploitation Solaris ou pour le système d'exploitation Solaris 10 sans environnement de zones, entrez la commande suivante : 


      # pkgadd -d . SUNWscdev

  4. Dans le fichier makefile, indiquez les options du compilateur et de l'éditeur de liens identifiant les fichiers inclus et de bibliothèque du code de votre 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 dans 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

Une fois le service de données terminé sur une machine de développement, vous devez transférer le service de données sur un cluster afin de 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. Remarque : Agent Builder crée automatiquement ce package.

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'API, ainsi que les chemins d'accès aux méthodes de rappel. Propriétés des types de ressources répertorie toutes les propriétés de types de ressources.

Les propriétés de ressources, telles que Failover_mode, Thorough_probe_interval et les délais d'attente de la méthode, définissent également la configuration statique de la ressource. Les propriétés de ressources dynamiques, telles que Resource_state et Status, reflètent l'état actif d'une ressource gérée. Propriétés des ressources 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 un service de données. Par exemple, certaines propriétés, telles que 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 à 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 –

Seul un administrateur du cluster peut configurer la propriété de type de ressources Installed_nodes. Vous ne pouvez pas déclarer Installed_nodes dans le fichier RTR.

Syntaxe des déclarations de type de ressources : 

property-name = value;
Remarque –

Les noms de propriété des groupes de ressources, des ressources et des types de ressources ne sont pas sensibles à la casse. Vous pouvez associer les majuscules et les minuscules dans le nom des propriétés.

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

# Sun Cluster Data Services Builder template version 1.0
# Enregistrement de données et de ressources for 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é 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 .

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, utilisez-le comme symbole boursier de la société qui définit le type de ressources. Le nom du type de ressources doit être unique sur le cluster.

Remarque –

Les noms de type de ressources (vendoridApplicationname) sont traditionnellement utilisés comme nom de package. À commencer par le nom du système d'exploitation Solaris 9, l'association de l'ID fournisseur et du nom de l'application peut dépasser neuf caractères. Toutefois, si vous utilisez une version antérieure du système d'exploitation Solaris, l'association de l'ID fournisseur et du nom de l'application ne doit pas dépasser neuf caractères, 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.

RT_description

Décrit en quelques mots le type de ressources.

RT_version

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

Version_API

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. API_version = 5 indique que le service de données fonctionne sous Sun Cluster, à commencer par la version Sun Cluster 3.1 9/04. Toutefois, API_version = 5 indique également que le service de données ne peut pas fonctionner sur n'importe quelle version de Sun Cluster diffusée avant Sun Cluster 3.1 9/04. Cette propriété est décrite en détail sous l'entrée API_version dans Propriétés des types de ressources.

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 nœuds car il s'agit d'un service de données de basculement. Cette propriété est décrite en détail sous l'entrée Failover dans Propriétés des types de ressources.

Start, Stop et Validate

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

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

Init_nodes = RG_PRIMARIES

Indique que le gestionnaire 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 gestionnaire 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, et Validate

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 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 : 

{
    attribute = value;
    attribute = value;
             .
             .
             .
    attribute = value;
}

Vous pouvez modifier, dans le fichier RTR, les attributs spécifiques aux propriétés de ressource 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.

VVous 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. 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 ressources définies par le système indique le délai d'attente des méthodes de rappel. 

...

# Resource property declarations appear as a list of bracketed
# entries after the resource type declarations. The property
# name declaration must be the first attribute after the open
# curly bracket of a resource property entry.
#
# Set minimum and default for method timeouts.
{
        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 = value). 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'attributMIN, est de 60 secondes. Reportez-vous à Attributs des propriétés de ressources pour consulter la liste complète des attributs de propriétés 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;
}

# The number of retries to be done within a certain period before concluding
# that the application cannot be successfully started on this node.
{
        PROPERTY = Retry_count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME;
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of
# retries (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 = ANYTIME;
        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. Par exemple, la valeur 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 reporter à 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 nœud en cas d'échec d'une méthode Start ou Stop.

Thorough_probe_interval, Retry_count , et Retry_interval

Propriétés utilisées dans le détecteur de pannes. Tunable et ANYTIME sont identiques de sorte que l'administrateur du cluster peut les ajuster si le détecteur de pannes ne fonctionne pas de façon 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.

Évolutivité

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). Si vous réglez cette propriété sur FALSE, la propriété de type de ressources Failover doit être réglée 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 obtenir de plus amples informations sur l'utilisation de cette propriété.

Load_balancing_policy et Load_balancing_weights

Déclare 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 que l'administrateur du cluster puisse identifier une liste de ports lorsqu'il configure le 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. 

# Extension Properties
#

# The cluster administrator must set the value of this property to point to the
# directory that contains the configuration files used by the application.
# For this application, smpl, specify the path of the configuration file on
# PXFS (typically named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# The following two properties control restart of the fault monitor.
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Number of PMF restarts allowed for fault monitor.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time window (minutes) for fault monitor restarts.";
}
# Time out value in seconds for the probe.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# Child process monitoring level for PMF (-C option of pmfadm).
# Default of -1 means to not use the -C option of pmfadm.
# A value of 0 or greater indicates the desired level of child-process.
# monitoring.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Child monitoring level for PMF";
}
# User added code -- BEGIN VVVVVVVVVVVV
# User added code -- END   ^^^^^^^^^^^^

Agent Builder crée les propriétés d'extension suivantes, utiles pour la plupart des services de données.

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 du cluster peut indiquer l'emplacement de ce répertoire lorsqu'il configure le service de données.

Monitor_retry_count, Monitor_retry_interval , et Probe_timeout

Contrôlent les redémarrages du détecteur de pannes et non du démon serveur.

Child_mon_level

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

Vous pouvez créer d'autres propriétés d'extension dans la zone délimitée par les commentaires User added code.

Mise en œuvre des méthodes de rappel

Cette rubrique fournit des informations d'ordre général sur la mise en œuvre des méthodes de rappel.

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 APIGR 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 DSDL fournit un ensemble de fonctions C (une par propriété) permettant d'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 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 ressource à l'aide de la commande scrgadm ou par l'intermédiaire d'une interface administrative graphique. Cependant, 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 Start échoue, le gestionnaire RGM peut appeler une méthode Stop sur une ressource même si cette dernière n'a jamais été démarrée. De même, le gestionnaire RGM peut exécuter la méthode Stop sur le démon d'une ressource, même si celui-ci s'était déjà arrêté de lui-même. Les mêmes scénarios s'appliquent aux méthodes Monitor_start et Monitor_stop.

C'est pourquoi vous devez intégrer le principe d'idempotence dans vos méthodes Stop et Monitor_stop. Les appels répétés de Stop ou Monitor_stop sur la même ressource avec les mêmes arguments fournissent les mêmes résultats qu'un appel unique.

L'idempotence se caractérise notamment par le fait que l'Arrêt et l'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, Boot et Update 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 ne nécessite pas le codage d'un service de données, 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 obtenir 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 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 gestionnaire 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 gestionnaire 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 leur méthode Start (configurez la propriété Start_timeout dans le fichier RTR).

Vous devez mettre en œuvre 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 Nœud1 puis reconnecté au Nœud2. Tout en déconnectant le groupe de ressources, le gestionnaire RGM appelle la méthode Stop sur les ressources du groupe dont vous souhaitez arrêter toute activité sur le Nœud1. Une fois que les méthodes Stop ont été exécutées sur toutes les ressources du Nœud1, le gestionnaire 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 sûre d'une méthode Stop met fin, sur le nœud local, à tous les processus liés à 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 RTR.

Lorsqu'une méthode Stop échoue ou dépasse le délai imparti, le groupe de ressources bascule dans un état d'erreur requérant l'intervention de l'administrateur du cluster. Pour éviter cela, les mises en œuvre des méthodes d'Arrêt et d'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 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 avoir une connaissance approfondie du client et du protocole réseau 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 de 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 comme actives ou inactives 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 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 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 gestionnaire RGM appelle des méthodes afin de configurer l'activation des adresses réseau avant d'appeler les méthodes Start des ressources 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 gestionnaire RGM appelle des méthodes afin de configurer la désactivation 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 que des adresses réseau soient actives à 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 s'il requiert que les adresses réseau passent à l'état désactivé à son démarrage ou à son arrêt. 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, soit 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 activée, démarrez-le avant d'activer l'interface réseau. 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é activée. 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 de 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 appelée qu'après la configuration de la désactivation de l'adresse réseau. Par conséquent, 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 dans le cluster, le service ne doit pas utiliser les numéros de programme suivants : 100141, 100142 et 100248. Ces numéros sont réservés aux démons Sun Cluster rgmd_receptionist, fed et pmfd. Si le service RPC que vous installez utilise l'un de ces numéros, modifiez le numéro de programme de ce service RPC.

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

Le gestionnaire RGM appelle la méthode Fini à des fins de nettoyage lorsque la ressource devient non gérée

Le nettoyage doit être idempotent. Autrement dit, si le nettoyage a déjà été effectué, le résultat de Fini est 0 (succès).

Le gestionnaire 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 d'Initialisation et d'Init est généralement identique. Elle doit être idempotente. Autrement dit, si la ressource a déjà été initialisée sur le nœud local, le résultat de Boot et 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 APIGR scha_control() ou DSDL 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 détecteur de 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 offre un mécanisme permettant de démarrer automatiquement des détecteurs pour les ressources. Lors de la déconnexion d'une ressource, le gestionnaire RGM appelle la méthode d'Arrêt_détecteur 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 gestionnaire RGM appelle la méthode Monitor_start après le démarrage de la ressource.

Les fonctions APIGR scha_control() et DSDL 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 gestionnaire RGM recherche un autre nœud pour honorer 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 APIGR scha_resource_setstatus(), de la commande scha_resource_setstatus ou de la fonction DSDL 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 détecteur de pannes mis en œuvre avec l'interface APIGR. la rubrique Détecteur de pannes SUNW.xfnts présente un exemple de détecteur de pannes mis en œuvre avec la bibliothèque DSDL. Reportez-vous au Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour obtenir de plus amples informations sur les détecteurs de pannes intégrés aux services 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 APIGR et la DSDL offrent des fonctions de gestion des processus pour mettre en œuvre des détecteurs et des rappels de contrôle des ressources. L'interface APIGR définit les fonctions suivantes :

Process Monitor Facility (PMF) : pmfadm et rpc.pmfd

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.

La DSDL fournit un ensemble de fonctions (précédées par le nom scds_pmf_ ) de mise en œuvre de la fonctionnalité PMF. Reportez-vous à la rubrique Fonctions PMF. Elle présente brièvement la fonctionnalité PMF et contient une liste des fonctions individuelles.

Les pages man pmfadm(1M) et rpc.pmfd(1M) fournissent une description détaillée de cette commande et de ce démon.

halockrun

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

La page man halockrun(1M) fournit une description détaillée de cette commande.

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 DSDL intègre la fonction scds_hatimerun() permettant de mettre en œuvre la fonctionnalité hatimerun.

La page man hatimerun(1M) fournit une description détaillée de cette commande.

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 ressource. L'interface API définit les méthodes de rappel Validate et Update afin que vous puissiez mettre en œuvre ces actions.

Le gestionnaire RGM appelle la méthode Validate lorsqu'une ressource est créée ou 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 Validate pour l'ensemble des nœuds du cluster spécifiés par la propriété Init_nodes du type de ressources (reportez-vous à la rubrique Propriétés des types de ressources ou à la page man rt_properties(5) pour obtenir de plus amples informations sur Init_nodes. Le gestionnaire RGM appelle Validate avant que la création ou la mise à jour ne soit appliquée. Par conséquent, un code de sortie d'échec de la méthode sur n'importe quel nœud entraîne l'échec de la création ou de la mise à jour.

Le gestionnaire RGM n'appelle Validate qu'en cas de modification des propriétés d'une ressource ou de son groupe au moyen d'une action administrative. Cette méthode n'est donc pas appelée lorsqu'il définit des propriétés ou lorsqu'un détecteur configure les propriétés de ressource Status et Status_msg.

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 gestionnaire 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, LogicalHostname et SharedAddress 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 gestionnaire 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 TRUEpour 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 une telle ressource 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, tle gestionnaire RGM configure la propriété Maximum_primaries du groupe sur 1 et limite la gestion du groupe de ressources à un seul nœud. Le gestionnaire 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 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 (LogicalHostname et SharedAddress) dans le 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 pour passer à l'état actif. 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 gestionnaire 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 en 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 (de sorte 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é RG_mode est définie sur SCALABLE, le gestionnaire 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 gestionnaire 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 Dépendances_groupe_ressources 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 gestionnaire 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 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 admises :

Équilibrage_charge_pondéré

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.

Équilibrage_charge_sticky_étendu

Un client donné (identifié par l'adresse IP du client), qui se connecte à une adresse IP d'un service "sticky", est toujours envoyé au même nœud du cluster, quel que soit le numéro de port sur lequel il arrive.

Dans le cadre d'un service évolutif avec une propriété Load_balancing_policy définie sur 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.

Poids_équilibrage_charge

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é. Cette part correspond au poids du 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éfinissez a 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é Évolutivité 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 afin de mettre en œuvre un service de basculement. L'administrateur du cluster 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é est définie sur VRAI, le gestionnaire RGM valide diverses propriétés de ressource. 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

Utilisation du mécanisme Keep-Alive TCP pour protéger le serveur

Côté serveur, l'utilisation du mécanisme Keep-Alive TCP protège le serveur contre les gaspillages de ressources système d'un client hors service (ou partitionné en réseau). Si ces ressources ne sont pas nettoyées (sur un serveur en fonction suffisamment longtemps), elles finissent par s'étendre indéfiniment à mesure des arrêts inopinés, puis des réinitialisations des clients.

Si les communications client-serveur passent par un flux TCP, le serveur et le client doivent activer le mécanisme Keep-Alive 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 du mécanisme Keep-Alive 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 à 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-Alive TCP, l'application cliente doit également exécuter son propre Keep-Alive périodique à son niveau. De fait, le mécanisme keep-alive TCP n'est pas parfait dans tous les cas de limite possibles. L'utilisation d'un mécanisme Keep-Alive 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 pouvoir accéder à une configuration de test 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 à haute disponibilité se comporte de façon adéquate dans tous les cas où un groupe de ressources est déplacé d'un hôte physique à 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 que dans le cadre du traitement d'une requête pour un client, un service de données client-serveur transmette des requêtes à un autre service de données client-serveur. Par exemple, un service de données A dépend d'un service de données B si, 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 obtenir de plus amples informations.

Si les ressources de votre type de ressources dépendent de ressources d'un autre type, vous devez indiquer à l'administrateur du cluster de configurer les ressources et 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 elle “dépend”, 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 tester la disponibilité du ou des autres services de données dans le code de votre service de données à haute 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 des 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 de calendrier client-serveur hypothétique conservant toutes ses données dans une base de données SQL de type 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 de calendrier. L'administrateur du cluster enregistre le type de ressource de calendrier avec Sun Cluster.

Si l'application de calendrier doit fonctionner sur le même nœud que la base de données Oracle, l'administrateur du cluster configure la ressource de calendrier dans le même groupe de ressources que la ressource HA-ORACLE et rend la ressource de calendrier dépendante de la ressource HA-ORACLE. Cette dépendance est spécifiée à l'aide de la balise de propriété Resource_dependencies dans scrgadm.

Si la ressource HA-ORACLE peut fonctionner sur un autre nœud que la ressource de calendrier, l'administrateur du cluster les configure dans deux groupes de ressources distincts. L'administrateur du cluster peut définir une dépendance du groupe de ressources de calendrier vis-à-vis du 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 de calendrier doit attendre que la base de données Oracle devienne disponible. Dans ce cas, la méthode Start du type de ressources de calendrier renvoie généralement un code de succès. Cependant, si elle est indéfiniment bloquée, son groupe de ressources bascule à l'état occupé et toute autre modification d'état devient impossible (édition, basculement ou commutation sur le groupe notamment). En outre, si la méthode Start de la ressource de calendrier dépasse le délai d'attente ou se termine avec un état différent de zéro, le groupe de ressources risque de basculer continuellement d'un nœud à un autre tant que la base de données Oracle reste indisponible.