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 satisfaire certaines exigences pour pouvoir prétendre devenir une application à haut niveau de disponibilité (HA). La rubrique Analyse du caractère approprié de l'application répertorie ces exigences tandis que cette annexe fournit de plus amples détails sur certains éléments de cette liste.

Une application obtient un haut niveau de disponibilité par la configuration de ses ressources en groupes de ressources. Les données de l'application sont ainsi placées dans un système de fichiers global à haut niveau de disponibilité, de sorte qu'elles sont accessibles par un serveur opérationnel dans le cas où un serveur tombe en panne. Pour de plus amples informations sur les systèmes de fichiers de cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.

Pour permettre aux clients d'accéder au réseau, une adresse IP réseau logique est configurée 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.

Données multi-hôtes

Les ensembles de disques de systèmes de fichiers globaux à haut niveau de disponibilité sont multi-hôtes de sorte qu'en cas de panne d'un hôte physique, l'un des autres hôtes toujours opérationnels peut accéder au disque. Pour qu'une application atteigne un haut niveau de disponibilité, ses données doivent être hautement disponibles. Par conséquent, elles doivent résider dans les systèmes de fichiers globaux à haut niveau de disponibilité.

Le système de fichiers global est monté sur des groupes de disques créés comme des entités indépendantes. L'utilisateur peut choisir d'utiliser avec un service de données comme HA Oracle des groupes de disques en tant que systèmes de fichiers globaux montés et d'autres en tant que périphériques en mode caractères.

Une application peut contenir des commutateurs de ligne de commande ou des fichiers de configuration indiquant l'emplacement des fichiers de données. Si l'application utilise des noms de chemin d'accès câblés, vous pouvez les modifier par des liens symboliques désignant un système de fichiers global, sans modifier le code de l'application. Reportez-vous à la rubrique Utilisation de liens symboliques pour déterminer l'emplacement des données multi-hôtes pour plus de détails sur l'utilisation de ces liens symboliques.

Dans le pire des cas, vous devez modifier le code source de l'application pour disposer de quelques mécanismes permettant de spécifier l'emplacement réel des données. Pour ce faire, vous pouvez mettre en oeuvre des commutateurs de ligne de commande supplémentaires.

Sun Cluster prend en charge l'utilisation des systèmes de fichiers UFS d'UNIX et les périphériques en mode caractères à haut niveau de disponibilité configurés dans un gestionnaire de volumes. Lors de l'installation et de la configuration, l'administrateur système doit spécifier les ressources disques à utiliser avec les systèmes de fichiers UFS et les périphériques en mode caractères. En règle générale, les périphériques en mode caractères 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 parfois que les noms de chemin d'accès aux fichiers de données d'une application soient câblés et qu'aucun mécanisme ne permette de contourner ces noms. Le cas échéant, il est parfois possible d'utiliser des liens symboliques pour ne pas avoir à modifier le code de l'application.

Par exemple, supposons que l'application nomme son fichier de données en utilisant le nom de chemin d'accès câblé /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, vous pouvez définir le lien symbolique suivant : /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. Par exemple, supposons que l'application effectue une mise à jour en commençant par créer un nouveau fichier temporaire ( /etc/mydatafile.new), puis en le renommant pour obtenir le nom de fichier réel à l'aide de l'appel système rename(2) (ou du programme mv(1)). En créant le fichier temporaire, puis en le renommant en fichier réel, le service de données tente de garantir que le contenu de son fichier de données est toujours bien formé.

Malheureusement, l'action rename(2) supprime le lien symbolique. Le nom /etc/mydatafile devient un fichier standard et se trouve dans le même système de fichiers que le répertoire /etc et non dans le système de fichiers global 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 sous-jacent dans cette situation est que l'application existante ne prend pas en charge le lien symbolique et n'a pas été écrite en tenant compte de liens symboliques. 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 oeuvre de l'application doit adopter un comportement qui ne supprime pas les liens symboliques. Par conséquent, les liens symboliques ne résolvent pas complètement le problème de l'emplacement des données sur les systèmes de fichiers globaux 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é. Le cas échéant, il sera peut-être nécessaire de modifier le service de données pour utiliser un nom d'hôte logique (c'est-à-dire, un nom d'hôte configuré au sein d'une ressource de nom d'hôte logique résidant dans le même groupe de ressources que la ressource de l'application), plutôt que le nom d'un hôte physique.

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

Le terme hôte multihome décrit un hôte appartenant à plusieurs réseaux publics. Ce type d'hôtes a plusieurs noms d'hôte et adresses IP. Il possède, en fait, une paire nom d'hôte/adresse IP par 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 la même manière que le nom d'hôte physique possède plusieurs paires nom d'hôte/adresse IP, chaque groupe de ressources peut également en avoir plusieurs ; en fait, une par réseau public. Lorsque Sun Cluster déplace un groupe de ressources d'un hôte physique vers un autre, toutes les paires nom d'hôte logique/adresse IP de ce groupe sont également déplacées.

L'ensemble de paires nom d'hôte/adresse IP d'un groupe de ressources est configuré en tant que ressource de nom d'hôte logique appartenant à ce groupe. Ces ressources d'adresse réseau sont spécifiées par l'administrateur système à la création et à la configuration du groupe de ressources. L'interface API du service de données de Sun Cluster intègre des fonctions permettant de demander 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é à 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 connecte de façon efficace à toutes les adresses IP actuellement configurées sur la machine. Vous n'avez pas besoin de modifier le démon du service de données utilisant généralement INADDR_ANY pour qu'il prenne en charge les adresses réseau logiques de Sun Cluster.

Établissement d'une liaison à INADDR_ANY par opposition à une liaison aux 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. De fait, elle a une adresse IP pour son propre hôte physique et une autre pour chaque ressource d'adresse réseau (nom d'hôte logique) qu'elle gère actuellement. 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 au sein d'un environnement Sun Cluster s'ils sont liés à 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 Ressources_réseau_utilisées 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. Vous devez déclarer la propriété Ressources_réseau_utilisées dans le fichier RTR du type de ressources concerné pour les types de ressources exigeant cette fonctionnalité.

Lorsque le gestionnaire RGM connecte ou déconnecte le groupe de ressources, il suit un ordre spécifique de plombage, de déplombage et de configuration en amont et en aval des adresses réseau suivant le moment où il appelle les méthodes de ressource du service de données. Reportez-vous à la rubrique Choix des méthodes de Démarrage et d'Arrêt à utiliser.

Lorsque la méthode d'Arrêt du service de données est retournée, ce service doit avoir cessé d'utiliser les adresses réseau du groupe de ressources. De même, lorsque la méthode de Démarrage 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 les méthodes d'arrêt et de démarrage du service de données interrompent et redémarrent respectivement comme il se doit les démons du service de données, ce service s'arrête et redémarre à l'aide des adresses réseau au moment opportun.

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. Si l'application et le protocole 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.