Le module GDS (generic data service) est un mécanisme qui permet de rendre de simples applications réseau hautement disponibles ou modulaires, en les connectant à la structure de gestion des groupes de ressources de Sun Cluster. Ce mécanisme évite l'utilisation d'un agent de programmation, procédure habituelle pour rendre une application hautement disponible ou modulaire.
Le module GDS est un service de données unique, précompilé. Dans cette approche, le service de données précompilé et ses composants, les implémentations à rappel automatique (rt_callbacks(1HA)) et le fichier d'enregistrement du type de ressource (rt_reg(4)), ne sont pas modifiables.
Le type de ressource du module générique de services de données, SUNW.gds, est inclus dans le module SUNWscgds. L'utilitaire scinstall(1M) installe ce module pendant l'installation de la grappe. 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 |
Voici les avantages que présente le module GDS par rapport au modèle de code source généré par SunPlex Agent Builder (reportez-vous à scdscreate(1HA)) ou aux commandes standard d'administration de Sun Cluster :
Le module GDS est simple à utiliser.
Le module GDS et ses méthodes sont précompilés et ne sont donc pas modifiables.
SunPlex Agent Builder peut servir à générer des scripts moteur pour votre application, qui sont intégrés dans un module compatible avec Solaris et réutilisable sur plusieurs grappes.
Il existe 2 méthodes de création d'un service utilisant GDS :
A l'aide de SunPlex Agent Builder
A l'aide des commandes standard d'administration de Sun Cluster
Utilisez SunPlex Agent Builder et sélectionnez GDS comme type de code source généré. La saisie de l'utilisateur sert à générer un ensemble de scripts moteur qui configurent les ressources de l'application en question.
Cette méthode utilise le code de services de données précompilé dans SUNWscgds mais impose à l'administrateur système d'utiliser les commandes standard d'administration de Sun Cluster (scrgadm(1M) et scswitch(1M)) pour créer et configurer la ressource.
Comme l'indiquent les procédures "Commandes d'administration standard de Sun Cluster permettant de créer un service à haut niveau de disponibilité basé sur le module GDS" et "Commandes d'administration standard de Sun Cluster permettant de créer un service modulaire basé sur le module GDS", l'exécution des commandes scrgadm et scswitch nécessitent un effort conséquent de saisie.
L'utilisation de GDS avec SunPlex Agent Builder simplifie le processus car le module GDS génère des scripts moteur qui exécutent les commandes scrgadm et scswitch à votre place.
Si l'utilisation du module GDS présente de nombreux avantages, son utilisation n'est pas toujours conseillée. Le module GDS ne convient pas :
Lorsque l'opérateur a besoin d'un plus grand contrôle que celui proposé par le type de ressource précompilé, notamment s'il doit ajouter des propriétés d'extension ou changer celles par défaut.
Lorsque le code source doit être modifié pour y ajouter des fonctions spéciales.
Lorsque vous souhaitez utiliser plusieurs arborescences de processus.
Lorsque vous souhaitez utiliser des applications non prévues pour être utilisées en réseau.
Les propriétés suivantes sont requises :
Start_command (propriété d'extension)
Port_list
La commande de démarrage, spécifiée par la propriété Start_command, lance l'application. Cette commande UNIX et ses arguments peuvent être passés directement à un shell pour démarrer l'application.
La commande Port_list identifie la liste des ports utilisés par l'application. La propriété Port_list doit figurer dans le script de démarrage créé par SunPlex Agent Builder ou dans la commande scrgadm si vous utilisez les commandes standard d'administration de Sun Cluster.
Les saisies suivantes sont facultatives :
Network_resources_used
Stop_command (propriété d'extension)
Probe_command (propriété d'extension)
Start_timeout
Stop_timeout
Probe_timeout
Child_mon_level (propriété d'extension utilisée uniquement avec les commandes standard d'administration)
Failover_enabled (propriété d'extension)
Stop_signal (propriété d'extension)
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 spécifiée comme nulle, on considère que l'application écoute 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 Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide pour de plus amples informations sur la configuration d'une ressource LogicalHostname ou SharedAddress.
Pour spécifier une valeur, spécifiez le nom d'une ou plusieurs ressources ; chaque nom de ressource peut comporter un ou plusieurs noms d'hôte logiques ou une ou plusieurs adresses partagées. Reportez-vous à r_properties(5) pour plus de détails.
La commande d'arrêt doit arrêter l'application et ne réapparaître qu'une fois l'application définitivement 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.
En présence de Stop_command, la méthode d'arrêt du module GDS lance la commande d'arrêt avec 80 % du délai imparti à l'arrêt. 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 imparti à l'arrêt. 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.
La commande de détection vérifie périodiquement le bon état de l'application concernée. Cette commande UNIX et ses arguments peuvent être transmis directement à un shell pour sonder l'application. La commande de détection renvoie un statut de sortie égal à 0 si l'application est en bon état.
Le statut de sortie de la commande de détection permet de déterminer le degré de gravité de la panne qui touche l'application. Ce statut de sortie, appelé statut de détection, doit être un nombre entier compris entre 0 (réussite) et 100 (panne intégrale). Le statut de détection peut également correspondre à une valeur spéciale de 201 qui entraîne un basculement immédiat de l'application sauf si Failover_enabled est défini sur false. L'algorithme de détection du module GDS (reportez-vous à scds_fm_action(3HA)) se base sur le statut de détection pour prendre la décision de redémarrer l'application en local ou de la basculer sur un autre noeud ; si le statut de sortie est 201, le basculement de l'application est immédiat.
Si la commande de détection est omise, le module GDS effectue sa propre détection et se connecte à l'application sur l'ensemble des adresses IP dérivées de la propriété Newtork_resources_used ou de la sortie descds_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.
La détection effectuée par le module GDS n'est qu'un simple substitut à la détection complète de l'application.
Cette propriété spécifie le délai imparti au démarrage de la commande de démarrage (reportez-vous à "Start_command" pour de plus amples informations). La valeur par défaut de Start_timeout est de 300 secondes.
Cette propriété spécifie le délai imparti à l'arrêt de la commande d'arrêt (reportez-vous à "Stop_command" pour de plus amples informations). La valeur par défaut de Stop_timeout est de 300 secondes.
Cette propriété spécifie la valeur du délai imparti de la commande de détection (reportez-vous à "Probe_command" pour de plus amples informations). La valeur par défaut de Probe_timeout est de 30 secondes.
Cette propriété permet de contrôler quels processus sont surveillés par le contrôleur de processus (PMF). Elle indique le niveau auquel les processus fils sont surveillés. Cette propriété est similaire à l'argument -C de la commande 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 fils (et leurs descendants) seront surveillés. Reportez-vous à la page de manuel pmfadm(1M) pour de plus amples détails.
Cette option peut être spécifiée à l'aide des commandes d'administration standard de Sun Cluster. Vous ne pouvez pas spécifier cette option si vous utilisez SunPlex Agent Builder.
Cette propriété d'extension booléenne contrôle la fonction 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_countau cours du délai en secondes retry_interval.
Si cette propriété d'extension est définie sur false, l'application ne redémarre pas et ne bascule pas sur un autre noeud lorsque le nombre de redémarrages dépasse la valeur retry_count au cours du délai en secondes retry_interval.
Cette propriété d'extension peut être utilisée pour empêcher la ressource d'application de basculer un groupe de ressources. La valeur par défaut est true.
Le module GDS utilise la valeur du nombre entier correspondant à cette propriété d'extension pour déterminer quel signal utiliser pour arrêter l'application par le biais de PMF. Reportez-vous à signal(3head) pour connaître la liste des nombres entiers qu'il est possible de spécifier comme valeur. La valeur par défaut est 15 (SIGTERM).