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

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.