Écriture et test des services de données

Utilisation du mécanisme Keep-Alive TCP pour protéger le serveur

Côté serveur, l'utilisation du mécanisme Keep-Alive TCP protège le serveur contre les gaspillages de ressources système d'un client hors service (ou partitionné en réseau). Si ces ressources ne sont pas nettoyées (sur un serveur en fonction suffisamment longtemps), elles finissent par s'étendre indéfiniment à mesure des arrêts inopinés, puis des réinitialisations des clients.

Si les communications client-serveur passent par un flux TCP, le serveur et le client doivent activer le mécanisme Keep-Alive 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 du mécanisme Keep-Alive 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 à 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-Alive TCP, l'application cliente doit également exécuter son propre Keep-Alive périodique à son niveau. De fait, le mécanisme keep-alive TCP n'est pas parfait dans tous les cas de limite possibles. L'utilisation d'un mécanisme Keep-Alive 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 œuvre 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 pouvoir accéder à une configuration de test 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 à haute disponibilité se comporte de façon adéquate dans tous les cas où un groupe de ressources est déplacé d'un hôte physique à 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 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.