Annexe E Exigences des applications ordinaires non prévues pour être utilisées avec un cluster

Une application ordinaire non prévue pour être utilisée avec un cluster doit répondre à des exigences particulières pour pouvoir prétendre devenir une application à haut niveau de disponibilité (HA). Ces exigences sont répertoriées dans la rubrique Analyse du caractère approprié de l'application. Cette annexe fournit de plus amples détails sur certains éléments de cette liste.

Pour assurer la haute disponibilité d'une application, l'on configure ses ressources en groupes de ressources. L'on place ensuite ses données dans un système de fichiers de cluster à haut niveau de disponibilité : ainsi, en cas de panne d'un serveur, elles seront accessibles aux serveurs opérationnels. Pour plus d'informations sur les systèmes de fichiers de cluster, voir Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Pour permettre aux clients d'accéder au réseau, on configure une adresse IP réseau logique dans les ressources de nom d'hôte logique contenues dans le même groupe de ressources que la ressource du service de données. La ressource de service de données et les ressources d'adresse réseau basculent en même temps. Par conséquent, les clients réseau du service de données peuvent accéder à la ressource du service de données sur le nouvel hôte.

Cette annexe aborde les points suivants :

• Données multi-hôtes

• Noms d'hôtes

• Hôtes multihome

• Liaison à INADDR_ANY et liaison à des adresses IP spécifiques

• Relance d'un client

Données multi-hôtes

Les ensembles de disques des systèmes de fichiers de clusters à haut niveau de disponibilité sont multi-hôtes. Ainsi, en cas de panne d'un hôte physique, l'un des hôtes opérationnels peut accéder au disque. Pour qu'une application présente un haut niveau de disponibilité, ses données doivent être hautement disponibles. Elles doivent donc se trouver dans des systèmes de fichiers accessibles depuis un grand nombre de nœuds du cluster. Sun Cluster prend en charge divers systèmes de fichiers à haut niveau de disponibilité, notamment les systèmes de fichiers HA globaux, le système FFS (Failover File System, système de fichiers de basculement) et, dans les environnements qui utilisent Oracle Real Application Clusters, le système de fichiers partagé QFS.

Le système de fichiers du cluster est monté sur des groupes de périphériques créés en tant qu'entités indépendantes. Vous pouvez utiliser certains de ces groupes de périphériques en tant que systèmes de fichiers de cluster montés et d'autres, comme périphériques de disques bruts à utiliser avec un service de données tel que HA Oracle.

Une application peut comporter des options de ligne de commande ou des fichiers de configuration pointant vers l'emplacement des fichiers de données. Si elle utilise des chemins codés en dur, vous pouvez les remplacer par des liens symboliques pointant vers un système de fichiers de cluster, sans modifier le code de l'application. Pour plus d'informations sur l'utilisation des liens symboliques, voir Utilisation de liens symboliques pour déterminer l'emplacement des données multi-hôtes .

Dans l'hypothèse la plus pessimiste, vous devrez modifier le code source de l'application afin d'y ajouter un mécanisme qui pointe vers l'emplacement réel des données et que vous implémenterez en créant des arguments de ligne de commande supplémentaires, par exemple.

Sun Cluster prend en charge les systèmes de fichiers UFS UNIX et les périphériques de disques bruts HA configurés dans un gestionnaire de volumes. Lors de l'installation et de la configuration du logiciel, l'administrateur du cluster doit définir les ressources de disque à utiliser pour les systèmes de fichiers UFS et pour les périphériques de disques bruts. En règle générale, les périphériques de disques bruts ne sont utilisés que par les serveurs de base de données et les serveurs multimédia.

Utilisation de liens symboliques pour déterminer l'emplacement des données multi-hôtes

Il arrive que les chemins des fichiers de données d'une application soient codés en dur, sans aucun mécanisme permettant de les ignorer. Pour ne pas avoir à modifier le code de l'application, vous pouvez utiliser des liens symboliques.

Supposons que l'application nomme son fichier de données en utilisant le nom de chemin codé en dur /etc/mydatafile. Vous pouvez remplacer ce nom par un lien symbolique dont la valeur désigne un fichier dans lequel figure les systèmes de fichiers de l'hôte logique. Par exemple, un lien symbolique vers /global/phys-schost-2/mydatafile.

Un problème peut survenir avec l'utilisation des liens symboliques si l'application, ou l'une de ses procédures administratives, modifie le nom du fichier de données, ainsi que son contenu. Supposons que l'application mette à jour un fichier en créant un nouveau fichier temporaire /etc/mydatafile.new, puis en lui donnant le nom du fichier initial, à l'aide de l'appel système rename() (ou de la commande mv). La démarche adoptée par le service de données (créer un fichier temporaire, puis le renommer) vise à garantir que le contenu de son fichier de données sera toujours bien formé.

Malheureusement, l'action rename() détruit le lien symbolique. Le nom /etc/mydatafile désigne alors un fichier standard qui réside sur le même système de fichiers que le répertoire /etc, et non dans le système de fichiers du cluster. Comme le système de fichiers /etc est propre à chaque hôte, les données ne sont pas disponibles après un basculement ou une commutation.

Le problème est le suivant : l'application ne « reconnaît » pas le lien symbolique – elle n'a d'ailleurs pas été écrite pour gérer ce type de lien. Pour rediriger un accès aux données au sein des systèmes de fichiers de l'hôte logique à l'aide de liens symboliques, la mise en œuvre de l'application doit adopter un comportement qui ne supprime pas les liens symboliques. Les liens symboliques ne constituent donc pas la solution parfaite au problème du stockage des données dans les systèmes de fichiers du cluster.

Noms d'hôtes

Vous devez déterminer si le service de données doit toujours connaître le nom d'hôte du serveur sur lequel il est exécuté. Si c'est le cas, il vous faudra peut-être le modifier pour qu'il cesse d'utiliser le nom d'hôte physique et se serve d'un nom d'hôte logique, c'est-à-dire d'un nom d'hôte configuré dans une ressource de noms d'hôtes logiques située dans le même groupe de ressources que la ressource d'application.

Il arrive parfois qu'au sein du protocole client-serveur d'un service de données, le serveur retourne son propre nom d'hôte au client comme élément de contenu d'un message qui lui est destiné. Pour ce type de protocoles, le client peut dépendre du nom d'hôte retourné, ce dernier devant être utilisé lors de la connexion au serveur. Pour que le nom d'hôte retourné soit utilisable après un basculement ou une commutation, ce doit être un nom d'hôte logique du groupe de ressources et non le nom d'un hôte physique. Le cas échéant, vous devez modifier le code du service de données pour renvoyer le nom d'hôte logique au client.

Hôtes multihome

On appelle hôte multihome un hôte situé sur plusieurs réseaux publics à la fois. Les hôtes de ce type ont plusieurs noms d'hôte et adresses IP : une paire nom d'hôte–adresse IP pour chaque réseau. Sun Cluster est conçu pour permettre à un hôte d'apparaître sur de nombreux réseaux, y compris un seul (le cas « non multihome »). De même qu'un nom d'hôte physique pourra correspondre à plusieurs paires nom d'hôte–adresse IP, chaque groupe de ressources pourra avoir plusieurs paires nom d'hôte–adresse IP (une pour chaque réseau public). Quand Sun Cluster déplace un groupe de ressources d'un hôte physique à l'autre, il transfère toutes les paires nom d'hôte–adresse IP du groupe de ressources.

Celles-ci sont configurées comme des ressources de nom d'hôte logique contenues dans le groupe de ressources. Elles sont définies par l'administrateur du cluster au moment de la création et de la configuration du groupe de ressources. L'API du service de données Sun Cluster propose des utilitaires permettant de rechercher ces paires nom d'hôte–adresse IP.

La plupart des démons de service de données disponibles dans le commerce et dédiés à l'origine à l'environnement Solaris gèrent également correctement les hôtes multihome. La plupart des services de données effectuent toutes leurs communications réseau en se connectant à l'adresse générique de Solaris INADDR_ANY. Du fait de cette liaison, les services de données sont automatiquement en mesure de gérer toutes les adresses IP de toutes les interfaces réseau. INADDR_ANY se lie efficacement à toutes les adresses IP actuellement configurées sur la machine. Ainsi, il ne sera généralement pas nécessaire de modifier un démon de service de données qui utilise INADDR_ANY pour la gestion des adresses réseau logiques Sun Cluster.

Liaison à INADDR_ANY et liaison à des adresses IP spécifiques

Même lorsque vous utilisez des hôtes non multihome, le concept des adresses réseau logiques de Sun Cluster permet à la machine de posséder plusieurs adresses IP. La machine a une adresse IP pour son propre hôte physique et des adresses IP supplémentaires pour les adresses réseau (noms d'hôtes logiques) qu'elle gère. Lorsqu'elle devient la machine maître d'une ressource d'adresse réseau, elle acquiert de façon dynamique d'autres adresses IP et lorsqu'elle perd son statut de maître, elle abandonne de façon dynamique des adresses IP.

Certains services de données ne peuvent pas fonctionner correctement dans un environnement Sun Cluster s'ils se lient à INADDR_ANY. Ces services doivent ainsi modifier de façon dynamique l'ensemble d'adresses IP auquel ils sont liés suivant que le groupe de ressources est géré ou non. L'une des stratégies de reliaison consiste à interrompre les méthodes de démarrage et d'arrêt de ces services de données et à redémarrer les démons du service de données.

La propriété de ressources >Network_resources_used permet à l'utilisateur final de configurer un ensemble spécifique de ressources d'adresse réseau auquel la ressource de l'application peut être liée. La propriété Network_resources_used doit être déclarée dans le fichier RTR des types de ressources qui ont besoin de cette option.

Lorsque le RGM met le groupe de ressources en ligne ou hors ligne, il respecte un ordre spécifique pour connecter, déconnecter et configurer les adresses réseau comme actives ou inactives, suivant le moment où il appelle les méthodes des ressources du service de données. Voir Choix des méthodes Start et Stop à utiliser.

Lorsque la méthode Stop du service de données est retournée, celui-ci doit s'être arrêté, à l'aide des adresses réseau du groupe de ressources. De même, lorsque la méthode Start est retournée, il doit avoir commencé à utiliser les adresses réseau.

Si le service de données se connecte à INADDR_ANY plutôt qu'aux adresses IP individuelles, l'ordre dans lequel les méthodes de ressource du service de données sont appelées n'est pas approprié.

Si ses méthodes d'arrêt et de démarrage arrêtent et redémarrent ses démons, le service de données s'arrête et démarre en utilisant les adresses réseau au bon moment.

Relance d'un client

Un basculement ou une commutation est considéré comme une panne de l'hôte logique suivie d'un redémarrage rapide au niveau d'un client du réseau. Dans l'idéal, l'application cliente et le protocole client-serveur sont structurés pour effectuer un certain nombre de relances. S'ils prennent déjà en charge le redémarrage d'un serveur tombé en panne, ils peuvent également gérer le basculement ou la commutation du groupe de ressources. Certaines applications peuvent effectuer des relances indéfiniment. Les applications plus complexes notifient l'utilisateur qu'un long processus de relance est en cours et lui permettent de choisir s'il souhaite continuer.