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.