Chapitre 3. Administration des services

Les sections suivantes décrivent la manière d'afficher, activer, désactiver, modifier, déplacer et supprimer un service ainsi que la façon de traiter des services qui ne démarrent pas. Des exemples de configuration de types spécifiques de services sont fournis.

3.1. Configuration d'un service

Après la configuration du stockage disque et l'installation d'applications à gérer par le cluster, vous pouvez configurer les services afin de gérer ces applications et ressources à l'aide de l'Outil de configuration du cluster.

Pour configurer un service, suivez les étapes suivantes

  1. S'il y a lieu, créez un script qui démarrera, arrêtera et vérifiera le statut de l'application utilisée dans le service. Consultez la Section 3.1.2 pour plus d'informations.

  2. Rassemblez des informations sur les ressources et propriétés du service. Consultez la Section 3.1.1 pour des informations sur le sujet.

  3. Installez les systèmes de fichiers ou périphériques bruts que le service utilisera. Consultez la Section 3.1.3 pour des informations sur le sujet.

  4. Assurez-vous que le logiciel de l'application peut tourner sur chaque membre (soit dans le domaine de failover associé, si il est utilisé, soit dans le cluster) et que le script du service, le cas échéant, peut démarrer et arrêter l'application du service. Consultez la Section 3.1.4 pour des instructions sur la mise à niveau.

  5. Si vous effectuez une mise à niveau à partir d'un cluster existant, faites une copie de sauvegarde du fichier /etc/cluster.conf. Consultez la Section 7.5 pour des instructions sur la mise à niveau.

  6. Lancez l'Outil de configuration du cluster et ajoutez des services, en spécifiant les informations sur les ressources et propriétés des services obtenues lors de l'étape 2.

  7. Enregistrez votre configuration. Les paramètres enregistrés sur un membre du cluster seront automatiquement appliqués aux autres membres du cluster.

Pour plus d'informations sur l'ajout d'un service de cluster, consultez les références ci-dessous :

3.1.1. Collecte d'informations sur le service

Avant de configurer un service, rassemblez toutes les informations disponibles sur les ressources et propriétés du service. Dans certains cas, il est possible de spécifier des ressources multiples pour un service (par exemple, des adresses IP et des périphériques disques multiples).

Les propriétés et ressources du service que l'utilisateur peut spécifier à l'aide de l'Outil de configuration du cluster sont décrites dans le Tableau 3-1.

PropriétéDescription
Nom du serviceChaque service doit avoir un nom unique. Le nom d'un service peut consister d'un nombre de caractères entre 1 et 63 et doit comprendre une combinaison de lettres (majuscules ou minuscules), de nombres entiers, de soulignages, de points et de tirets. Ceci étant, le nom d'un service doit obligatoirement commencer avec une lettre ou un soulignage.
Domaine de failover

Identifiez les membres sur lesquels exécuter le service en associant le service avec un domaine de failover existant.
Lorsque le failover est activé, si le membre sur lequel le service tourne, échoue, le service est automatiquement déplacé sur le membre suivant dans la liste de membres ordonnée. (L'ordre de préférence est établi par la séquence de noms de membre dans la liste de domaines de failover.) Reportez-vous à la Section 2.9 pour davantage d'informations.

Intervalle de surveillanceSpécifiez la fréquence (en secondes) à laquelle le membre contrôlera la santé de l'application associée au service. Par exemple, lorsque vous spécifiez un intervalle de surveillance différent de zéro pour un service NFS ou Samba, le Gestionnaire de cluster de Red Hat vérifiera que les démons NFS ou Samba nécessaires tournent bien. Pour des types de services supplémentaires, le Gestionnaire de cluster de Red Hat consiste à examiner le statut reçu suite à l'appel de la clause status du script du service de l'application. Par défaut, la valeur de l'intervalle de surveillance est 0, indiquant que le contrôle de services est désactivé.
Scripts utilisateurLe cas échéant, précisez le nom entier du chemin d'accès pour le script qui est utilisé pour démarrer et arrêter le service. Consultez la Section 3.1.2 pour plus d'informations.
Adresse IP

Une ou plusieurs adresse(s) (IP) de protocole Internet peuvent être assignées à un service. Cette adresse IP (parfois appelée adresse IP "flottante") est différente de l'adresse IP associée à l'interface Ethernet du nom d'hôte d'un membre, parce qu'elle est automatiquement relogée en même temps que les ressources du service dans une situation de failover. Si des clients utilisent cette adresse IP pour accéder au service, ils ne sauront pas quel membre fait tourner le service. Dans de telles conditions, la procédure de failover est transparente pour les clients.
Notez que les membres du cluster doivent avoir des cartes d'interface réseau configurées dans le sous-réseau IP de chaque adresse IP utilisée dans un service.
Les adresses du masque réseau et de diffusion pour chaque adresse IP peuvent également être spécifiées ; si elles ne le sont pas, alors le cluster utilisera les adresses du masque réseau et de diffusion de l'interconnexion réseau dans le sous-réseau.

Fichier spécial de périphériqueSpécifiez chaque partition du disque partagé utilisée dans un service.
Options de système de fichiers et de partage

Si le service utilise un système de fichiers, spécifiez le type de système de fichiers, le point de montage et toute option de montage. Les options de montage standards de systèmes de fichiers qui peuvent être spécifiées sont décrites dans la page de manuel relative à mount(8). Il n'est pas nécessaire de fournir des informations de montage pour les périphériques bruts (s'ils sont utilisés dans un service). Les systèmes de fichiers ext2 et ext3 sont pris en charge pour un cluster.
Spécifiez si vous désirez ou non activer le démontage forcé d'un système de fichiers. Un démontage forcé permet à l'infrastructure de gestion du service de cluster de démonter un système de fichiers avant un déplacement ou failover, même si le système de fichiers est 'occupé'. Ceci est effectué en mettant fin à toute application accédant au système de fichiers.
Vous pouvez également spécifier si vous souhaitez exporter le système de fichiers via des permissions d'accès NFS. Pour plus d'informations, reportez-vous à la Section 5.1.
Spécifiez si vous voulez ou non que le système de fichiers soit accessible aux clients SMB via Samba en fournissant un nom de partage Samba.

Tableau 3-1. Informations sur les propriétés et ressources du service

3.1.2. Création de scripts pour les services

L'infrastructure du cluster démarre et arrête des applications spécifiées en lançant des scripts spécifiques au service. Aussi bien pour les scripts NFS que pour les scripts Samba, les scripts associés sont incorporés à l'infrastructure des services du cluster. Par conséquent, lorsque vous lancez l'Outil de configuration du cluster pour configurer les services NFS et Samba, laissez le champ User Script (script d'utilisateur) vierge. Pour d'autres types d'applications, il est nécessaire de désigner un script pour le service. Par exemple, lors de la configuration d'une application de base de données, spécifiez le nom du chemin d'accès entièrement qualifié du script de démarrage de la base de données correspondante.

Le format des scripts pour les services se conforme aux conventions suivies dans les scripts init de System V. Cette convention impose aux scripts des clauses start, stop et status. Ces dernières devraient renvoyer un statut de sortie de 0, dans le cas d'une opération réussie.

Lorsqu'un service n'arrive pas à démarrer sur un membre du cluster, le Gestionnaire de cluster de Red Hat essaiera de lancer le service sur d'autres membres du cluster. Si les autres membres du cluster échouent également, le Gestionnaire de cluster de Red Hat essaiera d'arrêter le service sur tous les membres. Si il échoue pour une raison quelconque, l'infrastructure du cluster placera le service dans l'état Échoué. Les administrateurs doivent alors lancer l'Outil de statut du cluster, sélectionner le service échoué et cliquer sur Désactiver avant de pouvoir activer le service.

En plus de leur fonction d'arrêt et de démarrage, les scripts sont également utilisés pour surveiller le statut d'un service d'applications. Cette tâche est effectuée en appelant la clause status du script du service. Afin de permettre la surveillance des services, spécifiez une valeur supérieure à zéro dans le champ Intervalle de surveillance lorsque vous spécifiez les propriétés du service avec l'Outil de configuration du cluster. Si une valeur supérieure à zéro est reçue suite à une requête de vérification de statut lancée vers le script d'un service, alors l'infrastructure du cluster essaiera d'abord de redémarrer l'application sur le membre où elle tournait auparavant. Les fonctions de statut ne doivent pas être obligatoirement implémentées dans les scripts des services. Si aucun contrôle réel n'est effectué par le script, alors il devrait exister une clause status pour le tronçon afin qu'il renvoie un message positif.

Les opérations effectuées à l'intérieur de la clause 'status' d'une application peuvent être déterminées de façon à répondre le mieux possible aux besoins des applications et aux paramètres spécifiques du site. Par exemple, un simple contrôle de statut pour une base de données consisterait à vérifier que le processus de la base de données tourne toujours. Un contrôle plus approfondi consisterait en une interrogation pour recevoir un tableau sur la base de données.

Le répertoire /usr/share/cluster/doc/services/examples/ contient, en plus des exemples de scripts, un modèle qui peut être utilisé pour créer des scripts pour les services. Pour des exemples de scripts, reportez-vous à la Section 4.1, la Section 4.3 et le Chapitre 6.

3.1.3. Configuration du stockage disque des services

Avant de créer un service, installez les systèmes de fichiers partagés et les périphériques bruts que le service utilisera. Pour plus d'informations, consultez la Section 1.4.4.

Si vous utilisez des périphériques bruts dans un service de cluster, il est possible d'utiliser le fichier /etc/sysconfig/rawdevices pour relier les périphériques au moment de l'amorçage. Éditez le fichier et spécifiez les périphériques d'entrée-sortie de caractères bruts et les périphériques blocs bruts qui doivent être liés chaque fois que le membre démarre. Pour plus d'informations, consultez la Section 2.5.

Notez bien que le logiciel RAID et le logiciel RAID basé sur un hôte ne sont pas utilisés pour le stockage disque partagé. Seules les cartes certifiées RAID SCSI basées sur des adaptateurs peuvent être utilisées pour le stockage disque partagé.

Vous devriez respecter les recommandations suivantes concernant le stockage disque des services :

  • Pour des performances optimales, utilisez un bloc d'une taille de 4 Ko lors de la création des systèmes de fichiers. Notez bien que certains utilitaires incorporés aux systèmes de fichiers mkfs ont par défaut un bloc d'une taille de 1 Ko, ce qui peut rallonger la durée des opérations de fsck.

  • Pour que les opérations de failover prennent le moins de temps possible, il est recommandé d'utiliser le système de fichiers ext3. Pour plus d'informations, reportez-vous à la Section 1.4.4.6.

  • Pour des systèmes de fichiers volumineux, utilisez l'option nocheck pour passer outre le code qui vérifie tous les groupes de blocs sur la partition. En spécifiant l'option nocheck, la durée nécessaire au montage d'un système de fichiers volumineux peut être considérablement réduite.

3.1.4. Vérification des logiciels des applications et des scripts des services

Avant de configurer un service, installez toute application qui sera utilisée dans le service sur chaque membre du cluster (ou chaque membre du domaine de failover, si il est utilisé). Après l'installation de l'application sur ces membres, vérifiez que cette dernière tourne bien et peut accéder au stockage disque partagé. Afin d'éviter toute corruption de données, ne faites pas tourner l'application simultanément sur plus d'un membre.

Si vous utilisez un script pour démarrer et arrêter l'application du service, installez et testez le script sur tous les membres du cluster et vérifiez qu'il peut bien être utilisé pour démarrer et arrêter l'application. Pour plus d'informations, consultez la Section 3.1.2.