test

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

Présentation du service GDS

Le GDS est un mécanisme par lequel de simples applications, compatibles réseau ou non, deviennent hautement disponibles ou évolutives du fait de leur connexion à l'infrastructure du gestionnaire de groupe de ressources (RGM) Sun Cluster. Avec ce mécanisme, vous évitez d'utiliser un agent de programmation, procédure généralement nécessaire pour rendre une application hautement disponible ou évolutive.

Le module GDS est un service de données unique, précompilé. Vous ne pouvez modifier ni un service de données précompilé et ses composants, ni les implémentations de la méthode de rappel (rt_callbacks (1HA)), ni le fichier d'enregistrement du type de ressources RTR (rt_reg( 4)).

Type de ressources précompilé

Le type de ressources du service de données générique SUNW.gds est inclus dans le package SUNWscgds. Ce dernier est installé par l'utilitaire scinstall lors de l'installation du cluster (voir la page man scinstall( 1M)). Le module logiciel SUNWscgds comprend les fichiers suivants :


# pkgchk -v SUNWscgds 

/opt/SUNWscgds 
/opt/SUNWscgds/bin 
/opt/SUNWscgds/bin/gds_monitor_check 
/opt/SUNWscgds/bin/gds_monitor_start 
/opt/SUNWscgds/bin/gds_monitor_stop 
/opt/SUNWscgds/bin/gds_probe 
/opt/SUNWscgds/bin/gds_svc_start 
/opt/SUNWscgds/bin/gds_svc_stop 
/opt/SUNWscgds/bin/gds_update 
/opt/SUNWscgds/bin/gds_validate 
/opt/SUNWscgds/etc 
/opt/SUNWscgds/etc/SUNW.gds

Avantages et inconvénients de l'utilisation du module GDS

Par rapport à l'utilisation du modèle de code source généré par SunPlex Agent Builder (voir la page man scdscreate( 1HA)) ou des commandes d'administration standard de Sun Cluster, le module GDS dispose des avantages suivants :

Bien que l'utilisation du module GDS comporte un certain nombre d'avantages, il existe certaines circonstances dans lesquelles elle n'est pas recommandée. Évitez donc de l'utiliser dans les cas suivants :

Création d'un service utilisant le module GDS

Vous pouvez créer un service utilisant le module GDS de deux façons :

Module GDS et SunPlex Agent Builder

Utilisez SunPlex Agent Builder et sélectionnez GDS comme type de code source généré. La saisie de l'utilisateur permet de générer un ensemble de scripts qui configurent les ressources de l'application donnée.

Module GDS et commandes standard d'administration de Sun Cluster

Cette méthode utilise le code de service de données précompilé dans le package SUNWscgds, mais elle requiert l'utilisation par l'administrateur système des commandes d'administration standard de Sun Cluster pour créer et configurer la ressource. Voir les pages man sur scrgadm( 1M) et scswitch( 1M).

Sélection d'une méthode de création d'un service basé sur GDS

Comme l'indiquent les procédures Utilisation des commandes d'administration de Sun Cluster afin de créer un service à haut niveau de disponibilité utilisant le module GDS et Utilisation des commandes d'administration de Sun Cluster afin de créer un service évolutif utilisant le module GDS, l'exécution des commandes scrgadm et scswitch nécessite un effort conséquent de saisie.

L'utilisation du module GDS avec SunPlex Agent Builder simplifie le processus car ce dernier génère les scripts exécutant les commandes scrgadm et scswitch à votre place.

Consignation d'événements avec le module GDS

Le module GDS vous permet de consigner les informations importantes qu'il transmet aux scripts avant de les lancer. Ces informations, dont l'état des méthodes de démarrage, d'arrêt et d'analyse et les variables des propriétés, permettent notamment de diagnostiquer des problèmes ou des erreurs dans vos scripts.

Pour définir le niveau ou le type de messages consignés par le GDS, vous devez utiliser la propriété Log_level, décrite sous la rubrique Propriété Log_level. Les valeurs disponibles pour cette propriété sont NONE, INFO ou ERR.

Fichiers journaux de GDS

Les deux fichiers journaux du module GDS sont placés dans le répertoire /var/cluster/logs/DS/nom_groupe_ressources/ nom_ressources.

L'exemple ci-dessous présente le type d'informations contenues dans le journal start_stop_log.txt : 

10/20/2004 12:38:05 phys-node-1 START-INFO> Start succeeded. [/home/brianx/sc/start_cmd]
10/20/2004 12:42:11 phys-node-1 STOP-INFO> Successfully stopped the application

L'exemple ci-dessous présente le type d'informations contenues dans le journal probe_log.txt : 

10/20/2004 12:38:15 phys-node-1 PROBE-INFO> The GDS monitor (gds_probe) has been started
10/20/2004 12:39:15 phys-node-1 PROBE-INFO> The probe result is 0
10/20/2004 12:40:15 phys-node-1 PROBE-INFO> The probe result is 0
10/20/2004 12:41:15 phys-node-1 PROBE-INFO> The probe result is 0

Propriétés requises par le module GDS

Si votre application n'est pas compatible avec le réseau, vous devez définir la propriété d'extension Start_command et la propriété Port_list. En revanche, si l'application est compatible réseau, vous devez uniquement indiquer la propriété Port_list.

Propriété d'extension Start_command

La commande de démarrage définie dans la propriété d'extension Start_command lance l'application. Il s'agit d'une commande UNIX dont les arguments peuvent être transmis directement à un shell pour démarrer l'application.

Propriété Port_list

La propriété Port_list identifie la liste des ports d'écoute de l'application. Elle doit figurer dans le script de démarrage créé par SunPlex Agent Builder ou dans la commande scrgadm, si vous utilisez les commandes d'administration standard de Sun Cluster.

Propriétés facultatives du module GDS

La liste ci-dessous répertorie les propriétés facultatives du module GDS :

Propriété >Network_resources_used

La valeur par défaut de cette propriété est Null. Vous devez impérativement spécifier cette propriété dès lors que l'application doit être liée à une ou plusieurs adresses spécifiques. Si cette propriété est omise ou si elle est paramétrée sur Null, l'application est supposée écouter sur toutes les adresses.

Avant de créer une ressource GDS, la ressource LogicalHostName ou SharedAddress doit également avoir été configurée. Reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples informations sur la procédure de configuration d'une ressource LogicalHostname ou SharedAddress.

Pour définir une valeur, indiquez un ou plusieurs noms de ressource. Chacun d'eux peut contenir une ou plusieurs valeurs LogicalHostname ou SharedAddress. Pour plus de détails, voir la page man sur r_properties (5).

Propriété Stop_command

La commande d'arrêt doit arrêter l'application et n'être retournée qu'une fois l'application totalement arrêtée. Il doit impérativement s'agir d'une commande UNIX complète qui peut être transmise directement à un shell pour arrêter l'application.

Si la propriété d'extension Stop_command est indiquée, la méthode d'arrêt du module GDS lance la commande d'arrêt avec 80% du délai d'arrêt imparti. Quel que soit le résultat de la commande d'arrêt, la méthode d'arrêt du module GDS envoie la commande SIGKILL avec 15% du délai d'arrêt imparti. Les 5% restants sont réservés au temps système de gestion interne.

Si la commande d'arrêt est omise, le module GDS tente d'arrêter l'application en utilisant le signal spécifié dans Stop_signal.

Propriété Probe_command

La commande de détection contrôle périodiquement l'état de l'application en question. Il s'agit d'une commande UNIX dont les arguments peuvent être transmis directement à un shell pour sonder l'application. Elle renvoie un état de sortie 0 si l'application est en bon état.

L'état de sortie de la commande de détection permet de déterminer le degré de gravité de la panne qui touche l'application. Appelé état de sondage, l'état de sortie doit être un entier compris entre 0 (succès) et 100 (échec total). Il peut également avoir la valeur spéciale de 201, ce qui provoque le basculement immédiat de l'application, à moins que la propriété Failover_enabled ne soit paramétrée sur FALSE. L'algorithme de vérification (voir la page man sur scds_fm_action(3HA)) utilise cet état pour prendre la décision de redémarrer l'application en local ou de la basculer sur un autre nœud. Si l'état de sortie est 201, l'application est immédiatement basculée.

Si la commande d'analyse est omise, le module GDS fournit sa propre sonde qui se connecte à l'application sur l'ensemble d'adresses IP issues de la propriété Network_resources_used ou de la liste scds_get_netaddr_list (voir la page man sur scds_get_netaddr_list(3HA)). Si la connexion réussit, le module GDS se déconnecte immédiatement. Si la connexion et la déconnexion réussissent, on considère que l'application fonctionne correctement.

Remarque –

la détection effectuée par le module GDS n'est qu'un simple substitut à la détection complète de l'application.

Propriété Start_timeout

Cette propriété détermine le délai de démarrage de la commande Start. Pour plus d'informations, voir la rubrique Propriété d'extension Start_command. La valeur par défaut de Start_timeout est de 300 secondes.

Propriété Stop_timeout

Cette propriété détermine le délai d'arrêt de la commande Stop. Pour plus d'informations, voir la rubrique Propriété Stop_command . La valeur par défaut de Stop_timeout est de 300 secondes.

Propriété Probe_timeout

Cette propriété détermine la valeur du délai de la commande d'analyse. Pour plus d'informations, voir la rubrique Propriété Probe_command. La valeur par défaut de Probe_timeout est de 30 secondes.

Propriété Child_mon_level

Remarque –

Cette option est disponible si vous utilisez les commandes d'administration standard de Sun Cluster, et non si vous utilisez SunPlex Agent Builder.

Cette propriété permet de contrôler les processus surveillés par la fonction PMF (Process Monitor Facility). Elle indique le niveau auquel les processus fils sont surveillés. Son fonctionnement est identique à celui de l'argument -C sur la commande pmfadm. Voir la page man sur pmfadm(1M).

L'omission de cette propriété ou l'attribution de la valeur par défaut, soit -1, revient à omettre l'option -C de la commande pmfadm : tous les enfants (et leurs descendants) seront surveillés.

Propriété Failover_enabled

Cette propriété d'extension de type booléen contrôle le comportement de basculement de la ressource. Si cette propriété d'extension est définie sur true, l'application est basculée dès lors que le nombre de redémarrages dépasse la valeur retry_count au cours du délai de retry_interval (en secondes).

Si cette propriété est paramétrée sur false, l'application ne redémarre pas ou n'est pas basculée sur un autre nœud, lorsque le nombre de tentatives de redémarrage dépasse la valeur de retry_count au cours du délai de retry_interval (en secondes).

Cette propriété peut être utilisée pour empêcher la ressource d'application de lancer le basculement du groupe de ressources. La valeur par défaut est true.

Propriété Stop_signal

Le module GDS utilise la valeur de cette propriété d'extension entière pour déterminer le signal utilisé pour arrêter l'application au moyen de la fonction PMF. Voir la page man sur signal( 3HEAD) pour obtenir la liste des valeurs entières proposées. La valeur par défaut est 15 ( SIGTERM).

Propriété Log_level

Cette propriété détermine le niveau ou le type des messages de diagnostic consignés par le module GDS. Vous pouvez lui attribuer la valeur NONE, INFO ou ERR. Lorsque vous choisissez NONE, les messages de diagnostic ne sont pas consignés par le module GDS. Lorsque vous choisissez INFO, seuls les messages d'informations sont consignés et lorsque vous choisissez ERR, seuls les messages d'erreur sont consignés. Par défaut, le module GDS ne consigne pas les messages de diagnostic (NONE).