test

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

Concepts de services de données génériques

Le GDS est un mécanisme permettant de rendre hautement disponibles ou évolutives des applications simples qui reconnaissent le réseau ou non, en les connectant à la structure du gestionnaire RGM de Sun Cluster. Ce mécanisme ne nécessite pas que vous codiez un service de données, ce qui est habituellement 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 pas modifier un service de données précompilé et ses composants, les mises en oeuvre de la méthode de rappel (rt_callbacks), et le fichier d'enregistrement du type de ressource (rt_reg).

Elle aborde les thèmes suivants:

Type de ressources précompilé

Le type de ressource SUNW.gds du service de données génériques est inclus dans le package SUNWscgds. L'utilitaire scinstall installe ce package lors de l'installation du cluster. Voir la page de manuel scinstall(1M). Le package 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

Le fait d'utiliser le GDS présente les avantages suivants par rapport à l'utilisation du code source généré par Agent Builder (voir la page de manuel scdscreate(1HA)) ou des commandes d'administration de Sun Cluster :

Bien que l'utilisation du GDS présente de nombreux avantages, il ne convient pas de l'utiliser dans les cas suivants :

Création d'un service utilisant le module GDS

Il existe deux moyens de créer un service utilisant le GDS :

Le GDS et Agent Builder

À l'aide de Agent Builder, sélectionnez un 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.

Le GDS et les commandes d'administration de Sun Cluster

Cette méthode utilise le code du service de données précompilé de SUNWscgds. Toutefois, l'administrateur du cluster doit utiliser les commandes d'administration de Sun Cluster pour créer et configurer la ressource. Voir les pages de manuel scrgadm(1M) et scswitch(1M).

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

De nombreuses données sont à saisir pour pouvoir exécuter les commandes scrgadm et scswitch appropriées. Vous trouverez des exemples aux sections 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'utilisation du GDS avec Agent Builder simplifie le processus car il génère les scripts qui exécutent les commandes scrgadm et scswitch à votre place.

Consignation d'événements avec le module GDS

Le GDS vous permet de consigner les informations importantes qui sont transmises du GDS aux scripts exécutés par le GDS. Ces informations incluent l'état des méthodes de démarrage, de détection et d'arrêt, ainsi que les variables de propriété. Vous pouvez utiliser ces informations pour diagnostiquer des problèmes ou des erreurs dans vos scripts, ou à d'autres fins.

Vous pouvez utiliser la propriété Log_level décrite à la section Propriété Log_level pour indiquer le niveau, ou le type, des messages que le GDS doit consigner. Vous pouvez spécifier NONE, INFO ou ERR.

Fichiers journaux de GDS

Les deux fichiers journaux de GDS suivants sont placés dans le répertoire /var/cluster/logs/DS/resource-group-name/resource-name :

L'exemple suivant montre les types d'informations que contient start_stop_log.txt : 

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

L'exemple suivant montre les types d'informations que contient probe_log.txt : 

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

Propriétés requises par le module GDS

Si votre application reconnaît le réseau, vous devez fournir à la fois la propriété d'extension Start_command et la propriété Port_list. Dans le cas contraire, vous ne devez fournir que la propriété d'extension Start_command.

Propriété d'extension Commande_démarrage

La commande de démarrage, que vous spécifiez dans la propriété d'extension Start_command, démarre l'application. Cette commande doit être une commande UNIX et ses arguments doivent pouvoir être transmis directement à un shell pour démarrer l'application.

Propriété Liste_ports

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

Propriétés facultatives du module GDS

Les propriétés facultatives du GDS incluent à la fois les propriétés définies par le système et les propriétés d'extension. Les propriétés définies par le système sont un ensemble de propriétés standard fournies par Sun Cluster. Les propriétés qui sont définies dans le fichier RTR sont appelées propriétés d'extension. Les propriétés facultatives du GDS sont les suivantes :

Propriété Network_resources_used

La valeur par défaut de cette propriété est nulle. 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 la ressource GDS, une ressource LogicalHostname ou SharedAddress doit déjà avoir été configurée. Reportez-vous à la section Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour en savoir plus sur la configuration d'une ressource LogicalHostname ou SharedAddress.

Pour définir une valeur, indiquez un ou plusieurs noms de ressource, chaque nom pouvant contenir une ou plusieurs ressources LogicalHostname ou SharedAddress. Reportez-vous à la page de manuel r_properties(5) pour plus de détails.

Propriété Stop_command

La commande d'arrêt doit arrêter l'application et ne renvoyer une valeur qu'une fois que l'application est complètement arrêtée. Cette commande doit exécuter une commande UNIX pouvant être transmise directement à un shell pour arrêter l'application.

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

En l'absence de la commande d'arrêt, le GDS essaie d'arrêter l'application à l'aide du signal spécifié dans Stop_signal.

Propriété Commande_sonde

La commande de détection vérifie régulièrement l'état de l'application. Cette commande doit être une commande UNIX et ses arguments doivent pouvoir être transmis directement à un shell pour sonder l'application. La commande de la sonde renvoie un état de sortie de 0 si l'application fonctionne correctement.

Cet état est utilisé pour déterminer le niveau de gravité de l'échec de l'application. L'état de sortie, également appelé statut de détection, doit être un nombre entier compris entre 0 (réussite) et 100 (échec total). Le statut de sonde peut également être une valeur spéciale de 201, ce qui entraîne un basculement immédiat de l'application, sauf si Failover_enabled est paramétré sur FALSE. L'algorithme de détection du GDS utilise le statut de détection pour déterminer s'il faut redémarrer l'application en local ou procéder à son basculement. Reportez-vous à la page de manuel scds_fm_action(3HA) pour en savoir plus. Si l'état de sortie est 201, l'application est immédiatement basculée.

En l'absence de la commande de détection, le GDS fournit sa propre sonde simple. Cette sonde se connecte à l'application sur le jeu d'adresses IP dérivé de la propriété Network_resources_used ou de la sortie de la fonction scds_get_netaddr_list(). Reportez-vous à la page de manuel scds_get_netaddr_list(3HA) pour en savoir plus. Si la connexion fonctionne, la déconnexion a lieu immédiatement. Si la connexion et la déconnexion réussissent, on considère que l'application fonctionne correctement.

Remarque –

La sonde fournie avec le GDS a uniquement pour but de remplacer la sonde complète spécifique à l'application.

Propriété Délai_démarrage

Cette propriété spécifie le délai de démarrage de la commande de démarrage. Reportez-vous à la section Propriété d'extension Commande_démarrage pour obtenir des informations complémentaires. La valeur par défaut de Start_timeout est de 300 secondes.

Propriété Stop_timeout

Cette propriété spécifie le délai d'arrêt de la commande d'arrêt. Reportez-vous à la section Propriété Stop_command pour obtenir des informations complémentaires. La valeur par défaut de Stop_timeout est de 300 secondes.

Propriété Probe_timeout

Cette propriété spécifie la valeur de délai d'attente de la commande de détection. Reportez-vous à la section Propriété Commande_sonde pour obtenir des informations complémentaires. La valeur par défaut de Probe_timeout est de 30 secondes.

Propriété Niveau_cont_fils

Remarque –

Si vous utilisez les commandes d'administration de Sun Cluster, vous pouvez utiliser la propriété Child_mon_level. Si vous utilisez Agent Builder, vous ne pouvez pas utiliser cette propriété.

Cette propriété permet de contrôler les processus gérés par le PMF. Cette propriété indique le niveau maximal de surveillance des processus fils. Son fonctionnement est identique à celui de l'argument -C sur la commande pmfadm. Reportez-vous à la page de manuel pmfadm(1M).

Omettre cette propriété, ou lui conférer la valeur par défaut de -1, revient à omettre l'option -C de la commande pmfadm, c'est-à-dire que tous les processus enfants et leurs descendants sont surveillés.

Propriété Basculement_activé

Cette propriété d'extension booléenne contrôle le comportement de basculement de la ressource. Si cette propriété d'extension est définie sur TRUE, l'application bascule lorsque le nombre de redémarrages dépasse le Retry_count au cours du nombre de secondes de Retry_interval.

Si elle est définie sur FALSE, l'application ne redémarre pas ou bascule sur un autre noeud lorsque le nombre de redémarrages dépasse le Retry_count au cours du nombre de secondes de Retry_interval.

Cette propriété peut être utilisée pour empêcher la ressource de l'application de basculer le groupe de ressources. La valeur par défaut de cette propriété est TRUE.

Propriété Stop_signal

Le GDS utilise la valeur de la propriété d'extension de ce nombre entier pour déterminer le signal utilisé pour arrêter l'application au moyen du PMF. Reportez-vous à la page de manuel signal(3HEAD) pour connaître la liste des valeurs de nombre entier que vous pouvez spécifier. La valeur par défaut est 15 (SIGTERM ).

Propriété Log_level

Cette propriété indique le niveau, ou le type, de messages de diagnostic qui sont consignés par le GDS. Vous pouvez spécifier NONE, INFO ou ERR pour cette propriété. Lorsque vous choisissez NONE, les messages de diagnostic ne sont pas consignés par le module GDS. Lorsque vous spécifiez INFO, seuls les messages à titre d'information sont consignés. Lorsque vous spécifiez ERR, seuls les messages d'erreur sont consignés. Par défaut, le module GDS ne consigne pas les messages de diagnostic (NONE).