Écriture et test des services de données

Cette rubrique fournit des informations sur l'écriture et la vérification de services de données.

Utilisation du mécanisme Keep-Alives

Côté serveur, l'utilisation du mécanisme Keep-Alives au niveau des connexions TCP protège le serveur contre les gaspillages de ressources système d'un client en aval (ou partitionné en réseau). Si ces ressources ne sont pas nettoyées (dans un serveur restant allumé suffisamment longtemps), elles finissent par s'étendre de façon illimitée lorsque les clients tombent en panne et sont réinitialisés.

Si les communications client-serveur passent par un flux TCP, le serveur et le client doivent activer le mécanisme Keep-Alives au niveau des connexions TCP. Cette disposition s'applique également dans le cas d'un serveur unique non-HA.

D'autres protocoles orientés connexion peuvent intégrer un mécanisme Keep-Alives.

Côté client, l'utilisation d'un mécanisme Keep-Alives au niveau des connexions TCP permet au client d'être notifié du basculement ou de la commutation d'une ressource d'adresse réseau d'un hôte physique vers un autre. Ce transfert de la ressource d'adresse réseau interrompt la connexion TCP. Pourtant, à moins que le client ait activé le mécanisme Keep-Alives, il n'est pas nécessairement informé de la déconnexion si la connexion est latente à ce moment.

Par exemple, supposons que le client attend une réponse du serveur à une requête longue durée, que le serveur a déjà reçu cette requête et qu'il en a déjà accusé réception au niveau de la couche TCP. Dans cette situation, le module TCP du client n'a pas besoin de continuer de transmettre la requête alors que l'application cliente est bloquée car elle attend la réponse.

Chaque fois que cela est possible, en plus d'utiliser le mécanisme Keep-Alives au niveau de la connexion TCP, l'application cliente doit également exécuter un mécanisme Keep-Alives périodique à son niveau. De fait, ce mécanisme n'est pas parfait dans tous les cas de limite possibles. L'utilisation d'un mécanisme Keep-Alives au niveau de l'application requiert généralement que le protocole client-serveur prenne en charge une opération Null ou au moins une opération de lecture seule efficace, telle une opération d'état.

Test d'un service de données à haut niveau de disponibilité

Cette rubrique apporte quelques suggestions quant aux procédures de test relatives à la mise en oeuvre d'un service de données dans un environnement à haut niveau de disponibilité. Les cas présentés sont suggestifs et non exhaustifs. Vous devez accéder à une configuration banc d'essai de Sun Cluster, afin que la procédure de test n'ait aucune répercussion sur les machines de production.

Vérifiez que votre service de données à haut niveau de disponibilité adopte un comportement approprié dans toutes les situations lorsqu'un groupe de ressources est déplacé d'un hôte physique vers un autre, y compris en cas de panne du système ou d'utilisation de la commande scswitch. Vérifiez que les machines clientes continuent de recevoir le service après ces événements.

Testez l'idempotence des méthodes. Par exemple, remplacez chaque méthode temporairement par un script shell court appelant la méthode d'origine au moins deux fois.

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.