Coordination des dépendances entre les ressources

Il arrive parfois qu'un service de données client-serveur transmette des requêtes à un autre service de données client-serveur tout en exécutant une requête pour un client. Plus simplement, un service de données A dépend d'un service de données B ; par conséquent, 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 de plus amples informations.

Si les ressources de votre type de ressources dépendent des ressources d'un autre type, vous devez notifier à l'utilisateur de configurer les ressources et les 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 noeud que la ressource dont d'autres dépendent, 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 testez la disponibilité du ou des autres services de données dans le code de votre service de données à haut niveau de disponibilité. Si la ressource dépendante/dont d'autres dépendent est exécutable sur différents noeuds, 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 les 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 d'agenda client-serveur hypothétique conservant toutes ses données dans une base de données SQL comme 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 d'agenda. L'utilisateur final enregistre le type de ressource d'agenda avec Sun Cluster.

Si l'application d'agenda doit fonctionner sur le même noeud que la base de données Oracle, l'utilisateur final configure la ressource d'agenda dans le même groupe de ressources que la ressource HA-ORACLE. Ensuite, il fait dépendre la ressource d'agenda de la ressource HA-ORACLE. Cette dépendance est spécifiée à l'aide de la balise de propriété Dépendances_ressource dans scrgadm.

Si la ressource HA-ORACLE peut fonctionner sur un autre noeud que la ressource d'agenda, l'utilisateur final les configure dans deux groupes de ressources distincts. Il peut définir la dépendance du groupe de ressources d'agenda sur le 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 noeud. Par conséquent, après avoir été démarré, le démon du service de données d'agenda doit attendre que la base de données Oracle devienne disponible. La méthode de Démarrage du type de ressources d'agenda doit juste retourner qu'elle a réussi dans ce cas. De fait, si elle est indéfiniment bloquée, son groupe de ressources bascule en mode occupé et il devient impossible d'en modifier l'état (édition, basculement ou commutation notamment). En outre, si la méthode de Démarrage de la ressource d'agenda dépasse le délai d'attente ou se ferme avec une valeur différente de zéro, le groupe de ressources risque de basculer continuellement entre plusieurs noeuds tandis que la base de données Oracle reste indisponible.