Red Hat Enterprise Linux 5 Aperçu général de la Cluster Suite

Transcription

Red Hat Enterprise Linux 5
Aperçu général de la Cluster Suite
Red Hat Cluster Suite de Red Hat Enterprise Linux 5
Édition 3
Landmann
Red Hat Cluster Suite de Red Hat Enterprise Linux 5
Édition 3
Landmann
[email protected] m
Note légale
Copyright © 2009 Red Hat, Inc.
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus T orvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Résumé
L'aperçu de Red Hat Cluster Suite fournit un résumé de Red Hat Cluster Suite pour Red Hat Enterprise
Linux 5.3
Table des matières
Table des matières
.Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .
1. Conventions d'écriture
4
1.1. Conventions typographiques
5
1.2. Conventions pour citations mises en avant
6
1.3. Notes et avertissements
7
2. Commentaire
8
.Chapitre
. . . . . . . . .1.
. . Aperçu
. . . . . . . . de
. . . Red
. . . . .Hat
. . . . Cluster
. . . . . . . . Suite
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . .
1.1. Les bases d'un cluster
9
1.2. Red Hat Cluster Suite Introduction
10
1.3. Cluster Infrastructure
11
1.3.1. Gestion du cluster
11
1.3.2. Gestion du verrouillage
12
1.3.3. Fencing
13
1.3.4. Système de configuration du cluster
16
1.4. Gestion des services à haute disponibilité
17
1.5. Red Hat GFS
20
1.5.1. Performance et évolutivité supérieures
21
1.5.2. Performance, évolutivité, prix modéré
22
1.5.3. Économie et performance
22
1.6. Gestionnaire de volumes logiques du cluster
23
1.7. Périphérique bloc du réseau global (GNBD)
25
1.8. Serveur virtuel Linux
26
1.8.1. T wo-T ier LVS T opology
28
1.8.2. T hree-T ier LVS T opology
30
1.8.3. Méthodes de routage
31
1.8.3.1. Routage NAT
31
1.8.3.2. Routage direct
32
1.8.4. La persistance et les marques de pare-feu
34
1.8.4.1. Persistence
34
1.8.4.2. Marques de pare-feu
34
1.9. Outils d'administration du cluster
34
1.9.1. Conga
35
1.9.2. Interface graphique d'administration du cluster
37
1.9.2.1. Cluster Configuration T ool
37
1.9.2.2. Cluster Status T ool
39
1.9.3. Outils d'administration en ligne de commande
40
1.10. Interface utilisateur graphique d'administration du serveur virtuel Linux
41
1.10.1. CONT ROL/MONIT ORING
42
1.10.2. GLOBAL SET T INGS
43
1.10.3. REDUNDANCY
44
1.10.4. VIRT UAL SERVERS
45
1.10.4.1. La sous-section VIRT UAL SERVER
46
1.10.4.2. La sous-section REAL SERVER
48
1.10.4.3. EDIT MONIT ORING SCRIPT S Subsection
50
.Chapitre
. . . . . . . . .2.
. . Résumé
. . . . . . . . . des
. . . . composants
. . . . . . . . . . . . . de
. . . .Red
. . . . Hat
. . . . Cluster
. . . . . . . . Suite
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
............
2.1. Composants de cluster
52
2.2. Pages de manuel
57
2.3. Matériel compatible
59
. . . . . . . . . . . .de
Historique
. . .révision
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
............
1
.Index
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
............
C
60
F
60
I
60
L
61
M
61
N
61
O
61
P
61
R
62
T
62
2
Table des matières
3
Introduction
Ce document fournit un aperçu de haut niveau de Red Hat Cluster Suite pour Red Hat Enterprise Linux 5
et est organisé de la manière suivante :
Chapitre 1, Aperçu de Red Hat Cluster Suite
Chapitre 2, Résumé des composants de Red Hat Cluster Suite
Bien qu'il s'agisse d'un aperçu, vous devriez avoir des connaissances pratiques avancées de Red Hat
Enterprise Linux et comprendre les concepts de serveur informatique pour obtenir une bonne
compréhension du contenu de ce document.
Pour davantage d'informations sur l'utilisation de Red Hat Enterprise Linux, reportez-vous aux
ressources suivantes :
Guide d'installation de Red Hat Enterprise Linux — Fournit des informations à propos de l'installation
de Red Hat Enterprise Linux 5.
Guide de déploiement de Red Hat Enterprise Linux — Fournit des informations à propos du
déploiement, de la configuration et de l'administration de Red Hat Enterprise Linux 5.
Pour davantage d'informations à propos de Red Hat Cluster Suite pour Red Hat Enterprise Linux 5,
reportez-vous aux ressources suivantes :
Configuration et gestion d'un cluster Red Hat — Fournit des informations à propos de l'installation, la
configuration et la gestion des composants Red hat Cluster.
LVM Administrator's Guide: Configuration and Administration — Provides a description of the Logical
Volume Manager (LVM), including information on running LVM in a clustered environment.
Système de fichiers GFS : configuration et administration — Fournit des informations à propos de
l'installation, la configuration et la maintenance de Red Hat GFS (Red Hat Global File System).
Système de fichiers GFS 2 : configuration et administration — Fournit des informations à propos de
l'installation, la configuration et la maintenance de Red Hat GFS (Red Hat Global File System 2).
Utilisation de "Device-Mapper Multipath" — Fournit des informations à propos de l'utilisation de la
fonctionnalité "Device-Mapper Multipath" de Red Hat Enterprise Linux 5.
Utilisation de GNBD avec le système de fichiers GFS — Fournit un aperçu de l'utilisation de GNBD
(de l'anglais Global Network Block Device) avec Red Hat GFS.
Administration du serveur virtuel Linux — Fournit des informations à propos de la configuration de
systèmes et services à hautes performances avec le serveur virtuel Linux (LVS de l'anglais Linux
Virtual Server).
Notes de mise à jour de Red Hat Cluster Suite — Fournit des informations à propos de la version
courante de Red Hat Cluster Suite.
La documentation de Red Hat Cluster Suite et les autres documents de Red Hat sont disponibles en
version HT ML, PDF et RPM sur le CD-ROM de documentation de Red Hat Enterprise Linux et en ligne à
l'adresse suivante : http://www.redhat.com/docs/.
1. Conventions d'écriture
Ce manuel utilise plusieurs conventions pour souligner l'importance de certains mots ou expressions,
mais aussi en vue d'attirer l'attention sur certains passages d'informations précis.
Pour les éditions sur support papier et numérique (PDF), ce manuel utilise des caractères issus de
Liberation Fonts. La police de caractères Liberation Fonts est également utilisée pour les éditions HT ML
si elle est installée sur votre système. Sinon, des polices de caractères alternatives équivalentes sont
4
Introduction
utilisées. Notez que Red Hat Enterprise Linux 5 et versions supérieures contiennent la police Liberation
Fonts par défaut.
1.1. Conventions typographiques
Quatre conventions typographiques sont utilisées pour attirer l'attention sur certains mots et
expressions. Ces conventions et les circonstances auxquelles elles s'appliquent sont les suivantes.
Caractères gras à espacem ent fixe
Utilisé pour surligner certaines entrées du système, y compris les commandes shell, les noms de
fichiers et les chemins d'accès. Également utilisé pour surligner les touches et les combinaisons de
touches. Par exemple :
Pour consulter le contenu du fichier m on_nouvel_ouvrage_littéraire qui se situe
dans votre dossier courant, saisissez la commande cat
m on_nouvel_ouvrage_littéraire à la demande du terminal et appuyez sur Entrée
pour exécuter la commande.
L'exemple ci-dessus contient un nom de fichier, une commande shell et une touche, tous présentés
sous forme de caractères gras à espacement fixe et tous bien distincts grâce au contexte.
Les combinaisons de touches se distinguent des touches individuelles par le signe « plus », qui
connecte les différentes parties de la combinaison. Par exemple :
Appuyez sur Entrée pour exécuter la commande.
Appuyez sur Ctrl+Alt+F2 pour basculer sur un terminal virtuel.
Le premier exemple présente une touche particulière sur laquelle appuyer. Le second exemple affiche
une combinaison de touches : un ensemble de trois touches sur lesquelles il faut appuyer
simultanément.
Si le code source est mentionné, les noms de classes, les méthodes, les fonctions, les noms de
variables et les valeurs de retour citées dans un paragraphe seront présentées comme ci-dessus, en
caractères gras à espacem ent fixe. Par exemple :
Les classes de fichiers comprennent le nom de classe filesystem pour les noms de
fichier, file pour les fichiers et dir pour les dossiers. Chaque classe correspond à un
ensemble de permissions associées.
Caractères gras proportionnels
Cette convention marque le surlignage des mots ou phrases que l'on rencontre sur un système,
comprenant des noms d'application, des boîtes de dialogue textuelles, des boutons étiquettés, des
cases à cocher et des boutons d'options mais aussi des intitulés de menus et de sous-menus. Par
exemple :
Sélectionnez Système → Préférences → Souris à partir de la barre du menu principal
pour lancer les Préférences de la souris. À partir de l'onglet Boutons, cliquez sur la
case à cocher Pour gaucher puis cliquez sur Ferm er pour faire passer le bouton
principal de la souris de la gauche vers la droite (ce qui permet l'utilisation de la souris par
la main gauche).
Pour insérer un caractère spécial dans un fichier gedit, choisissez Applications →
Accessoires → T able des caractères depuis la barre du menu principal. Ensuite,
5
choisissez Recherche → T rouver… depuis la barre du menu T able des caractères,
saisissez le nom du caractère dans le champ Recherche puis cliquez sur Suivant. Le
caractère recherché sera surligné dans la T able des caractères. Double-cliquez sur
le caractère surligné pour le placer dans le champ T exte à copier, puis cliquez sur le
bouton Copier. Vous pouvez désormais revenir à votre document et choisir Modifier →
Coller depuis la barre du menu gedit.
Le texte ci-dessus contient des noms d'applications, des noms de menus et d'autres éléments
s'appliquant à l'ensemble du système, des boutons et textes que l'on trouve dans une interface
graphique. Ils sont tous présentés sous la forme gras proportionnel et identifiables en fonction du
contexte.
Italique gras à espacement fixe ou Italique gras proportionnel
Qu'ils soient en caractères gras à espacement fixe ou à caractères gras proportionnels, l'ajout de
l'italique indique la présence de texte remplaçable ou variable. Les caractères en italique indiquent la
présence de texte que vous ne saisissez pas littéralement ou de texte affiché qui change en fonction
des circonstances. Par exemple :
Pour se connecter à une machine distante en utilisant ssh, saisissez ssh nom
d'utilisateur@ domain.name (nom.domaine) après l'invite de commande de la console.
Si la machine distante est exem ple.com et que votre nom d'utilisateur pour cette machine
est john, saisissez ssh john@ exam ple.com .
La commande m ount -o rem ount système de fichiers monte le système de fichiers
nommé. Ainsi, pour monter /hom e dans le système de fichiers, la commande est m ount -o
rem ount /hom e.
Pour connaître la version d'un paquet actuellement installé, utilisez la commande rpm -q
paquet. Elle vous permettra de retourner le résultat suivant : version-de-paquet.
Remarquez que les mots en gras italique ci-dessus — username (nom d'utilisateur), domain.name
(nom.domaine), file-system (système de fichiers), package (paquetage), version et release (sortie
commerciale). Chaque mot est un espace réservé au texte, soit pour le texte que vous entrez lors de la
saisie d'une commande, soit pour le texte affiché par le système.
Mis à part l'utilisation habituelle de présentation du titre d'un ouvrage, les caractères italiques indiquent
l'utilisation initiale d'un terme nouveau et important. Ainsi :
Publican est un système de publication DocBook.
1.2. Conventions pour citations mises en avant
Les sorties de terminaux et les citations de code source sont mis en avant par rapport au texte
avoisinant.
Les sorties envoyées vers un terminal sont en caractères Rom ains à espacem ent fixe et
présentées ainsi :
books
books_tests
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
Les citations de code source sont également présentées en rom ains à espacem ent fixe mais
sont présentés et surlignés comme suit :
6
Introduction
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
struct kvm_assigned_pci_dev *assigned_dev)
{
int r = 0;
struct kvm_assigned_dev_kernel *match;
mutex_lock(&kvm->lock);
match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
assigned_dev->assigned_dev_id);
if (!match) {
printk(KERN_INFO "%s: device hasn't been assigned before, "
"so cannot be deassigned\n", __func__);
r = -EINVAL;
goto out;
}
kvm_deassign_device(kvm, match);
kvm_free_assigned_device(kvm, match);
out:
mutex_unlock(&kvm->lock);
return r;
}
1.3. Notes et avertissements
Enfin, nous utilisons trois styles visuels pour attirer l'attention sur des informations qui auraient pu être
normalement négligées :
Note
Une remarque est une forme de conseil, un raccourci ou une approche alternative par rapport à
une tâche à entreprendre. L'ignorer ne devrait pas provoquer de conséquences négatives, mais
vous pourriez passer à côté d'une astuce qui vous aurait simplifiée la vie.
Important
Les blocs d'informations importantes détaillent des éléments qui pourraient être facilement
négligés : des modifications de configurations qui s'appliquent uniquement à la session actuelle
ou des services qui ont besoin d'être redémarrés avant toute mise à jour. Si vous ignorez une
case étiquetée « Important », vous ne perdrez aucunes données mais cela pourrait être source
de frustration et d'irritation.
Avertissement
Un avertissement ne devrait pas être ignoré. Ignorer des avertissements risque fortement
d'entrainer des pertes de données.
7
2. Commentaire
Si vous trouvez des fautes de frappe ou si vous avez des suggestions pour améliorer ce manuel,
n'hésitez surtout pas à nous en faire part ! Veuillez envoyer vos remarques par l'entremise de Bugzilla
(http://bugzilla.redhat.com/bugzilla/) dans la rubrique Docum entation-cluster.
Be sure to mention the document's identifier:
Cluster_Suite_Overview(EN)-5 (2008-12-11T15:49)
By mentioning this document's identifier, we know exactly which version of the guide you have.
Si vous avez une suggestion afin d'améliorer cette documentation, essayez d'être le plus précis
possible. Si vous avez trouvé une erreur, veuillez inclure le numéro de section et quelques passages du
texte pour que nous puissions retrouver l'erreur facilement.
8
Chapitre 1. Aperçu de Red Hat Cluster Suite
Les systèmes en clusters offrent de la fiabilité, de l'évolutivité et de la disponibilité aux services de
production critiques. À l'aide de Red Hat Cluster Suite, vous pouvez créer un cluster en fonction de vos
besoins en matière de performance, haute disponibilité, répartition de charge, évolutivité, partage de
fichiers et économie. Ce chapitre fournit un aperçu des composants et fonctions de Red Hat Cluster
Suite à travers les sections suivantes :
Section 1.1, « Les bases d'un cluster »
Section 1.2, « Red Hat Cluster Suite Introduction »
Section 1.3, « Cluster Infrastructure »
Section 1.4, « Gestion des services à haute disponibilité »
Section 1.5, « Red Hat GFS »
Section 1.6, « Gestionnaire de volumes logiques du cluster »
Section 1.7, « Périphérique bloc du réseau global (GNBD) »
Section 1.8, « Serveur virtuel Linux »
Section 1.9, « Outils d'administration du cluster »
Section 1.10, « Interface utilisateur graphique d'administration du serveur virtuel Linux »
1.1. Les bases d'un cluster
Un cluster se compose d'un ou plusieurs ordinateurs (appelés noeuds ou membres) qui travaillent
ensemble afin d'effectuer une tâche. Il y a quatre types majeurs de cluster :
Stockage
Haute disponibilité
Répartition de charge
Haute performance
Les clusters de stockage fournissent une image consistante d'un système de fichiers à travers les
serveurs d'un cluster, permettant aux serveurs de lire et d'écrire de façon simultanée sur un système de
fichiers partagé. Un cluster de stockage simplifie l'administration du stockage en limitant l'installation et
l'application de correctifs à un seul système de fichiers. De plus, avec un système de fichiers au niveau
du cluster, les copies redondantes de données de l'application sont éliminées et la récupération de
sauvegardes et de pertes de données est simplifiée. Red Hat Cluster Suite fournit la mise en cluster du
stockage à travers Red Hat GFS.
Les clusters à haute disponibilité fournissent une disponibilité permanente des services en éliminant les
points de défaillance uniques et en passant les services d'un noeud du cluster à un autre lors de
l'échec d'un noeud. En règle générale, les services dans un cluster à haute disponibilité lisent et
écrivent les données (à partir de systèmes de fichiers montés en lecture-écriture). Par conséquent, un
cluster à haute disponibilité doit conserver l'intégrité des données étant donné qu'un noeud du cluster
prend le contrôle d'un service à partir d'un autre noeud. Les échecs de noeuds au sein d'un cluster à
haute disponibilité ne sont pas visibles par les clients en dehors du cluster (les clusters à haute
disponibilité sont parfois appelés des clusters failover). Red Hat Cluster Suite fournit la mise en cluster
à haute disponibilité à travers son composant de gestion des services à haute disponibilité.
Les clusters de répartition de charge distribuent les requêtes de service réseau vers plusieurs noeuds
du cluster afin de répartir la charge de ces requêtes. La répartition de charge fournit une évolutivité
rentable car vous pouvez faire correspondre le nombre de nœuds conformément aux exigences de
charge. Si le noeud d'un cluster de répartition de charge devient inopérant, le logiciel de répartition de
charge détecte l'échec et redirige les requêtes vers d'autres noeuds du cluster. Les échecs de noeuds
9
dans un cluster de répartition de charge ne sont pas visibles par les clients en dehors du cluster. Red
Hat Cluster Suite fournit la répartition de charge à travers LVS (de l'anglais Linux Virtual Server).
Les clusters à haute performance utilisent les nœuds du cluster pour effectuer des calculs simultanés.
Un cluster à haute performance permet aux applications de travailler en parallèle, ce qui accroît les
performances de l'application (les clusters à haute performance sont également appelés des clusters
de calcul ou des grilles informatique).
Remarque
Les types de cluster résumés dans le texte précédent reflètent les configurations de base ; vos
besoins pourraient exiger une combinaison des différents clusters décrits.
1.2. Red Hat Cluster Suite Introduction
Red Hat Cluster Suite (RHCS) est un ensemble intégré de composants logiciels pouvant être déployés
dans diverses configurations afin de répondre à vos besoins en termes de performance, haute
disponibilité, répartition de charge, évolutivité, partage de fichiers et économie.
RHCS consists of the following major components (refer to Figure 1.1, « Red Hat Cluster Suite
Introduction »):
Infrastructure de cluster — Fournit des fonctions fondamentales pour que les noeuds puissent
travailler ensemble afin de former un cluster : gestion des fichiers de configuration, gestion des
adhésions, gestion du verrouillage et fencing.
Gestion de services à haute disponibilité — Fournit un failover de services à partir du noeud d'un
cluster vers un autre lorsqu'un noeud devient inopérant.
Outils d'administration du cluster — Outils de configuration et de gestion pour le paramétrage, la
configuration et la gestion d'un cluster Red Hat. Les outils sont utilisés avec les composants
d'infrastructure de cluster, les composants à haute disponibilité et de gestion des services, et le
stockage.
Serveur virtuel Linux (LVS de l'anglais Linux Virtual Server) — Logiciel de routage qui fournit une
adresse IP de répartition de charge. LVS s'exécute dans une paire de serveurs redondants qui
distribuent les demandes des clients de façon égale vers des serveurs réels situés derrière les
serveurs LVS.
Vous pouvez compléter Red Hat Cluster Suite avec les composants suivants, qui font partie d'un
paquetage optionnel (ils ne font donc pas partie de Red Hat Cluster Suite) :
Red Hat GFS (de l'anglais Global File System) — Fournit un système de fichiers en cluster à utiliser
avec Red Hat Cluster Suite. GFS permet à plusieurs noeuds de partager le stockage au niveau bloc
comme si le stockage était connecté localement à chaque noeud du cluster.
Gestionnaire de volumes logiques en cluster (CLVM de l'anglais Cluster Logical Volume Manager) —
Fournit une gestion de volumes du stockage en cluster.
Note
When you create or modify a CLVM volume for a clustered environment, you must ensure that
you are running the clvm d daemon. For further information, refer to Section 1.6,
« Gestionnaire de volumes logiques du cluster ».
10
Périphérique bloc du réseau global (GNBD de l'anglais Global Network Block Device) — Un
composant auxiliaire de GFS qui exporte le stockage de niveau bloc vers Ethernet. Ceci est un
moyen économique permettant de rendre le stockage de niveau bloc disponible à Red Hat GFS.
For a lower level summary of Red Hat Cluster Suite components and optional software, refer to
Chapitre 2, Résumé des composants de Red Hat Cluster Suite.
Figure 1.1. Red Hat Cluster Suite Introduction
Remarque
Figure 1.1, « Red Hat Cluster Suite Introduction » includes GFS, CLVM, and GNBD, which are
components that are part of an optional package and not part of Red Hat Cluster Suite.
1.3. Cluster Infrastructure
L'infrastructure de cluster de Red Hat Cluster Suite fournit les fonctions de base pour que les
ordinateurs d'un groupe (appelés noeuds ou membres) travaillent ensemble afin de former un cluster.
Une fois qu'un cluster est établi en utilisant l'infrastructure de cluster, vous pouvez utiliser d'autres
composants de Red Hat Cluster Suite pour répondre à vos besoins en matière d'utilisation du cluster
(par exemple afin de configurer un cluster pour le partage de fichiers sur un système de fichiers GFS ou
pour paramétrer un service failover). L'infrastructure de cluster effectue les fonctions suivantes :
Gestion du cluster
Gestion du verrouillage
Fencing
Gestion de la configuration du cluster
1.3.1. Gestion du cluster
Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for
cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5.
11
CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed
across all nodes in the cluster (refer to Figure 1.2, « CMAN/DLM Overview »).
CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the
nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not
have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "splitbrain" condition — a condition where two instances of the same cluster are running. A split-brain
condition would allow each cluster instance to access cluster resources without knowledge of the other
cluster instance, resulting in corrupted cluster integrity.
Le quorum est déterminé par le biais de messages de communication entre les noeuds du cluster via
Ethernet. De façon facultative, le quorum peut être déterminé par une combinaison de messages qui
communiquent via Ethernet et à travers un disque quorum. Pour le quorum via Ethernet, le quorum se
compose de 50 pourcent des noeuds plus 1. Pour le quorum via le disque quorum, le quorum se
compose de conditions spécifiées par l'utilisateur.
Remarque
Par défaut, chaque noeud a un vote pour le quorum. De façon facultative, vous pouvez configurer
les noeuds du cluster afin qu'ils aient plus d'un vote.
CMAN assure le suivi des adhésions en analysant les messages des autres noeuds du cluster.
Lorsque les adhésions au cluster changent, le gestionnaire de cluster notifie les autres composants
d'infrastructure, qui ensuite effectuent une action appropriée. Par exemple, si le noeud A joint un cluster
et monte un système de fichiers GFS que les noeuds B et C ont déjà monté, un journal supplémentaire
et une gestion du verrouillage sont requis pour que le noeud A puisse utiliser ce système de fichiers. Si
un noeud du cluster ne transmet pas de message pendant une période de temps définie, le gestionaire
de cluster supprime le noeud du cluster et indique aux autres composants de l'infrastructure de cluster
que le noeud n'est plus un membre. Encore une fois, d'autres composants d'infrastructure de cluster
déterminent quelles sont les actions à effectuer suite à la notification indiquant que le noeud ne fait plus
partie du cluster. Par exemple, le composant Fencing déconnecterait le noeud qui n'est plus membre.
Figure 1.2. CMAN/DLM Overview
1.3.2. Gestion du verrouillage
Lock management is a common cluster-infrastructure service that provides a mechanism for other
cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster,
12
DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock
manager and runs in each cluster node; lock management is distributed across all nodes in the cluster
(refer to Figure 1.2, « CMAN/DLM Overview »). GFS and CLVM use locks from the lock manager. GFS
uses locks from the lock manager to synchronize access to file system metadata (on shared storage).
CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups
(also on shared storage).
1.3.3. Fencing
Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from
shared storage, thus ensuring data integrity. T he cluster infrastructure performs fencing through the
fence daemon, fenced.
Lorsque CMAN détermine l'échec d'un noeud, il le communique aux autres composants de
l'infrastructure de cluster. Lorsque fenced est averti de l'échec, il déconnecte le noeud qui a échoué.
D'autres composants d'infrastructure de cluster déterminent les actions à effectuer — autrement dit, ils
effectuent les récupérations qui doivent être faites. Par exemple, DLM et GFS, lorsqu'ils sont informés
d'un échec, suspendent toute activité jusqu'à ce que fenced ait terminé la déconnexion du noeud qui a
échoué. Suite à la confirmation de la déconnexion du noeud, DLM et GFS effectuent la récupération. DLM
libère les verrous du noeud ayant échoué et GFS récupère le fichier journal.
Le programme fencing détermine à partir du fichier de configuration du cluster le mode fencing à utiliser.
Deux éléments clés dans le fichier de configuration du cluster définissent le mode fencing : l'agent fence
et le périphérique fence. Le programme fencing effectue un appel sur l'agent fence spécifié dans le
fichier de configuration du cluster. L'agent fence, pour sa part, déconnecte le noeud via le périphérique
fence. Lorsque la déconnexion est terminée, le programme fencing notifie le gestionnaire de cluster.
Red Hat Cluster Suite fournit une grande variété de méthodes fencing :
Power fencing — Une méthode fencing qui utilise un contrôleur de courant pour éteindre un noeud
inopérant.
Fibre Channel switch fencing — Une méthode fencing qui désactive le port Fibre Channel connectant
le stockage à un noeud inopérant.
GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server.
Other fencing — D'autres méthodes fencing qui désactivent les E/S ou le courant d'un noeud
inopérant, y compris IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II et autres.
Figure 1.3, « Power Fencing Example » shows an example of power fencing. In the example, the fencing
program in node A causes the power controller to power off node D. Figure 1.4, « Fibre Channel Switch
Fencing Example » shows an example of Fibre Channel switch fencing. In the example, the fencing
program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D
from storage.
13
Figure 1.3. Power Fencing Example
Figure 1.4 . Fibre Channel Switch Fencing Example
Spécifier une méthode fencing consiste à éditer le fichier de configuration du cluster pour lui assigner le
nom d'une méthode fencing, l'agent fence et le périphérique fence de chaque noeud du cluster.
T he way in which a fencing method is specified depends on if a node has either dual power supplies or
multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must
specify at least two fencing devices — one fencing device for each power supply (refer to Figure 1.5,
« Fencing a Node with Dual Power Supplies »). Similarly, if a node has multiple paths to Fibre Channel
14
storage, then the fencing method for the node must specify one fencing device for each path to Fibre
Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method
should specify two fencing devices — one for each path to Fibre Channel storage (refer to Figure 1.6,
« Fencing a Node with Dual Fibre Channel Connections »).
Figure 1.5. Fencing a Node with Dual Power Supplies
Figure 1.6. Fencing a Node with Dual Fibre Channel Connections
15
Vous pouvez configurer un noeud avec une ou plusieurs méthodes fencing. Lorsque vous configurez un
noeud avec une méthode fencing, il s'agit de la seule méthode fencing disponible pour déconnecter ce
noeud. Lorsque vous configurez un noeud avec plusieurs méthodes fencing, les méthodes fencing sont
disposées en cascade, les unes après les autres, en fonction de l'ordre dans lequel elles apparaissent
dans le fichier de configuration du cluster. Si un noeud échoue, il est déconnecté en utilisant la première
méthode fencing spécifiée dans le fichier de configuration. Si la première méthode fencing ne réussit
pas, la méthode fencing suivante spécifiée pour ce noeud est utilisée. Si aucune des méthodes fencing
ne réussit, le processus recommence avec la première méthode fencing spécifiée et continue à
parcourir les autres méthodes fencing, en fonction de l'ordre dans lequel elles apparaissent dans le
fichier de configuration, jusqu'à ce qu'un des noeuds soit déconnecté.
1.3.4. Système de configuration du cluster
T he Cluster Configuration System (CCS) manages the cluster configuration and provides configuration
information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes
sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system
administrator updates the configuration file in Node A, CCS propagates the update from Node A to the
other nodes in the cluster (refer to Figure 1.7, « CCS Overview »).
Figure 1.7. CCS Overview
Other cluster components (for example, CMAN) access configuration information from the configuration
file through CCS (refer to Figure 1.7, « CCS Overview »).
16
Figure 1.8. Accessing Configuration Information
Le fichier de configuration du cluster (/etc/cluster/cluster.conf) est un fichier XML qui décrit les
caractéristiques suivantes du cluster :
Nom du cluster — Affiche le nom du cluster, le niveau de révision du fichier de configuration et des
propriétés de base du minutage fence utilisées lorsqu'un noeud joint un cluster ou qu'il est
déconnecté.
Cluster — Affiche chaque noeud du cluster, en spécifiant le nom du noeud, l'ID du noeud, le nombre
de votes du quorum et la méthode fencing pour ce noeud.
Périphérique fence — Affiche les périphériques fence du cluster. Les paramètres varient en fonction
du type de périphérique fence. Par exemple, pour un contrôleur de courant utilisé comme
périphérique fence, la configuration du cluster définit le nom du contrôleur de courant, son adresse
IP, son identifiant de connexion et son mot de passe.
Ressources gérées — Affiche les ressources nécessaires afin de créer les services cluster. Les
ressources gérées inclues la définition de domaines failover, les ressources (par exemple une
adresse IP) et les services. Ensemble, les ressources gérées définissent les services cluster et le
comportement failover des services cluster.
1.4. Gestion des services à haute disponibilité
La gestion de services à haute disponibilité permet de créer et gérer des services cluster à haute
disponibilité dans un cluster Red Hat. Le composant clé pour la gestion de services à haute disponibilité
dans un cluster Red Hat, rgm anager, implémente un failover "à froid" ("cold failover") pour les
applications "off-the-shelf". Dans un cluster Red Hat, une application est configurée avec d'autres
ressources de cluster pour former un service cluster à haute disponibilité. Un service cluster à haute
disponibilité peut, en cas d'échec, passer d'un noeud du cluster à un autre sans interruption apparente
pour les clients du cluster. Un failover de service cluster peut se produire si le noeud d'un cluster
échoue ou si un administrateur système de clusters déplace le service d'un noeud à un autre (par
exemple, en vue de l'arrêt d'un noeud du cluster).
Pour créer un service à haute disponibilité, vous devez le configurer dans le fichier de configuration du
cluster. Un service cluster comprend les ressources du cluster. Les ressource du cluster sont des blocs
17
de construction que vous créez et gérez dans le fichier de configuration du cluster — Par exemple, une
adresse IP, un script d'initialisation d'applications ou une partition partagée Red Hat GFS.
You can associate a cluster service with a failover domain. A failover domain is a subset of cluster
nodes that are eligible to run a particular cluster service (refer to Figure 1.9, « Les domaines failover »).
Remarque
Les domaines failover ne sont pas requis pour l'opération.
Un service cluster peut être démarré sur un seul noeud du cluster à la fois afin de maintenir l'intégrité
des données. Vous pouvez spécifier des priorités failover dans un domaine failover. La spécification des
priorités failover consiste à assigner un niveau de priorité à chaque noeud du domaine failover. Le
niveau de priorité détermine l'ordre failover — il détermine ainsi le noeud vers lequel un service cluster
devrait être dirigé. Si vous ne spécifiez pas de priorité failover, un service cluster peut, en cas d'échec,
être dirigé vers n'importe quel noeud de son domaine failover. Vous pouvez également spécifier si un
service cluster est restreint à démarrer seulement sur les noeuds de son domaine failover associé
(lorsqu'il est associé à un domaine failover sans restriction, un service cluster peut être démarré sur
n'importe quel noeud du cluster si aucun membre du domaine failover n'est disponible).
In Figure 1.9, « Les domaines failover », Failover Domain 1 is configured to restrict failover within that
domain; therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is
also configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover
Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If
Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing
over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that
Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover
Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in
the cluster.
18
Figure 1.9. Les domaines failover
Figure 1.10, « Web Server Cluster Service Example » shows an example of a high-availability cluster
service that is a web server named "content-webserver". It is running in cluster node B and is in a
failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a
failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover
domain. T he cluster service comprises these cluster resources:
Une ressource pour l'adresse IP — Adresse IP 10.10.10.201.
An application resource named "httpd-content" — a web server application init script
/etc/init.d/httpd (specifying httpd).
A file system resource — Red Hat GFS named "gfs-content-webserver".
19
Figure 1.10. Web Server Cluster Service Example
Les clients accèdent au service cluster à travers l'adresse IP 10.10.10.201, permettant l'interaction avec
l'application du serveur Web, httpd-content. L'application httpd-content utilise le système de fichiers gfscontent-webserver. Si le noeud B échoue, le service cluster content-webserver passe au noeud D. Si le
noeud D n'est pas disponible ou s'il échoue aussi, le service passe au noeud A. Le failover se produira
sans interruption apparente pour les clients du cluster. Le service cluster sera accessible à partir d'un
autre noeud du cluster à travers la même adresse IP que celle utilisée avant le failover.
1.5. Red Hat GFS
Red Hat GFS est un système de fichiers en cluster qui permet aux noeuds d'un cluster d'accéder en
même temps à un périphérique bloc partagé entre les noeuds. GFS est un système de fichiers natif qui
s'interface directement avec la couche VFS de l'interface du système de fichiers du noyau Linux. GFS
utilise des métadonnées distribuées et plusieurs fichiers journaux afin d'optimiser les opérations au
sein d'un cluster. Pour maintenir l'intégrité du système de fichiers, GFS utilise un gestionnaire de
verrouillage afin de coordonner les E/S. Lorsqu'un noeud change les données d'un système de fichiers
GFS, ce changement est immédiatement visible aux autres noeuds du cluster utilisant ce système de
fichiers.
En utilisant Red Hat GFS, vous pouvez atteindre une disponibilité maximale de l'application avec les
avantages suivants :
Simplification de votre infrastructure de données.
Installation et application de correctifs, une seule fois, pour l'ensemble du cluster.
Élimine le besoin de copies redondantes des données de l'application (duplication).
Active l'accès concurrent aux données en lecture/écriture par plusieurs clients.
Simplifie la récupération des sauvegardes et de pertes de données (un seul système de fichiers
20
à sauvegarder ou à restaurer).
Maximise l'utilisation des ressources de stockage ; minimise les coûts d'administration du stockage.
Permet de gérer le stockage dans sa globalité plutôt que par partition.
Diminue dans l'ensemble le stockage en éliminant le besoin de réplication des données.
Varie la dimension du cluster en ajoutant, à la volée, des serveurs ou du stockage.
Plus de stockage du partitionnement via des techniques complexes.
Ajoute, à la volée, des serveurs au cluster en les montant sur le système de fichiers commun.
Les noeuds qui démarrent Red Hat GFS sont configurés et gérés avec les outils de gestion et de
configuration de Red Hat Cluster Suite. La gestion de volumes est gérée par le biais du gestionnaire de
volumes logiques du cluster (CLVM de l'anglais Cluster Logical Volume Manager). Red Hat GFS fournit le
partage de fichiers entre les noeuds GFS d'un cluster Red Hat. GFS fournit une vue unique et cohérente
de l'espace de noms du système de fichiers sur les noeuds GFS d'un cluster Red Hat. GFS permet aux
applications d'être installées et démarrées sans trop de connaissances quant à l'infrastructure de
stockage sous-jacente. De plus, GFS fournit des fonctionnalités qui sont généralement requises dans
les environnements d'entreprise, telles que les quotas, de multiples fichiers journaux et la prise en
charge de "multipath".
GFS fournit une méthode versatile de stockage en réseau en fonction de vos besoins en matière de
performance, évolutivité et économie pour votre environnement de stockage. Ce chapitre fournit des
informations de base, concises pour vous aider à comprendre GFS.
You can deploy GFS in a variety of configurations to suit your needs for performance, scalability, and
economy. For superior performance and scalability, you can deploy GFS in a cluster that is connected
directly to a SAN. For more economical needs, you can deploy GFS in a cluster that is connected to a
LAN with servers that use GNBD (Global Network Block Device) or to iSCSI (Internet Small Computer
System Interface) devices. (For more information about GNBD, refer to Section 1.7, « Périphérique bloc
du réseau global (GNBD) ».)
Les sections suivantes fournissent des exemples sur la façon dont GFS peut être déployé afin de
répondre à vos besoins en matière de performance, évolutivité et économie :
Section 1.5.1, « Performance et évolutivité supérieures »
Section 1.5.2, « Performance, évolutivité, prix modéré »
Section 1.5.3, « Économie et performance »
Remarque
Les exemples de déploiement de GFS reflètent les configurations de base ; vos besoins peuvent
nécessiter une combinaison des configurations illustrées dans ces exemples.
1.5.1. Performance et évolutivité supérieures
You can obtain the highest shared-file performance when applications access storage directly. T he GFS
SAN configuration in Figure 1.11, « GFS with a SAN » provides superior file performance for shared files
and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or
storage servers to slow data access, performance is similar to individual Linux servers with directly
connected storage; yet, each GFS application node has equal access to all data files. GFS supports over
300 GFS nodes.
21
Figure 1.11. GFS with a SAN
1.5.2. Performance, évolutivité, prix modéré
Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Figure 1.12,
« GFS and GNBD with a SAN ». SAN block storage is presented to network clients as block storage
devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were
directly attached to the server in which the application is running. Stored data is actually on the SAN.
Storage devices and data can be equally shared by network client applications. File locking and sharing
functions are handled by GFS for each network client.
Figure 1.12. GFS and GNBD with a SAN
1.5.3. Économie et performance
Figure 1.13, « GFS et GNBD avec un stockage directement connecté » shows how Linux client
applications can take advantage of an existing Ethernet topology to gain shared access to all block
storage devices. Client data files and file systems can be shared with GFS on each client. Application
22
failover can be fully automated with Red Hat Cluster Suite.
Figure 1.13. GFS et GNBD avec un stockage directement connecté
1.6. Gestionnaire de volumes logiques du cluster
Le gestionnaire de volumes logiques du cluster (CLVM de l'anglais Cluster Logical Volume Manager)
fournit une version de LVM2 à l'échelle du cluster. CLVM fournit les mêmes capacités que LVM2 sur un
noeud unique mais rend les volumes disponibles à tous les noeuds d'un cluster Red Hat. Les volumes
logiques créés avec CLVM sont disponibles à tous les noeuds d'un cluster.
T he key component in CLVM is clvm d. clvm d is a daemon that provides clustering extensions to the
standard LVM2 tool set and allows LVM2 commands to manage shared storage. clvm d runs in each
cluster node and distributes LVM metadata updates in a cluster, thereby presenting each cluster node
with the same view of the logical volumes (refer to Figure 1.14, « CLVM Overview »). Logical volumes
created with CLVM on shared storage are visible to all nodes that have access to the shared storage.
CLVM allows a user to configure logical volumes on shared storage by locking access to physical
storage while a logical volume is being configured. CLVM uses the lock-management service provided by
the cluster infrastructure (refer to Section 1.3, « Cluster Infrastructure »).
Remarque
Le stockage partagé utilisé dans Red Hat Cluster Suite exige que vous exécutiez le démon du
gestionnaire de volume logique du cluster (clvm d) or bien lesagents High Availability Logical
Volume Management (HA-LVM). Si vous n'êtes pas en mesure d'utiliser le démon clvm d, ni HALVM pour des raisons opérationnelles, ou parce que vous ne possédez pas d'accès, vous ne
pouvez pas utiliser un instance-simple LVM sur le disque partagé, car cela pourrait aboutir à une
corruption des données. Si vous avez des questions, veuillez contacter votre représentant
commercial Red Hat.
23
Remarque
L'utilisation de CLVM requiert de mineurs changements dans /etc/lvm /lvm .conf afin de
gérer le verrouillage à l'échelle du cluster.
Figure 1.14 . CLVM Overview
You can configure CLVM using the same commands as LVM2, using the LVM graphical user interface
(refer to Figure 1.15, « LVM Graphical User Interface »), or using the storage configuration function of the
Conga cluster configuration graphical user interface (refer to Figure 1.16, « Conga LVM Graphical User
Interface ») . Figure 1.17, « Creating Logical Volumes » shows the basic concept of creating logical
volumes from Linux partitions and shows the commands used to create logical volumes.
Figure 1.15. LVM Graphical User Interface
24
Figure 1.16. Conga LVM Graphical User Interface
Figure 1.17. Creating Logical Volumes
1.7. Périphérique bloc du réseau global (GNBD)
25
GNBD fournit un accès aux périphériques blocs à Red Hat GFS à travers T CP/IP. GNBD est similaire
dans son concept à NBD ; cependant, GNBD est spécifique à GFS et personnalisé pour être utilisé
exclusivement avec GFS. GNBD est utile lorsque le besoin de technologies plus robustes, telles que
Fibre Channel ou un seul initiateur SCSI, n'est pas nécessaire ou à des prix excessifs.
GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a
node with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another
node and exports block-level storage from its local storage (either directly attached storage or SAN
storage). Refer to Figure 1.18, « Aperçu de GNBD ». Multiple GNBD clients can access a device
exported by a GNBD server, thus making a GNBD suitable for use by a group of nodes running GFS.
Figure 1.18. Aperçu de GNBD
1.8. Serveur virtuel Linux
LVS (de l'anglais Linux Virtual Server) est un ensemble de composants logiciels intégrés permettant de
répartir la charge IP à travers un ensemble de serveurs réels. LVS s'exécute sur une paire d'ordinateurs
ayant la même configuration : un routeur LVS actif et un routeur LVS de sauvegarde. Le routeur LVS actif
joue deux rôles :
Il répartit la charge à travers les serveurs réels.
Il vérifie l'intégrité des services sur chaque serveur réel.
Le routeur LVS de sauvegarde surveille le routeur LVS actif et prend le pas sur ce dernier s'il échoue.
Figure 1.19, « Components of a Running LVS Cluster » provides an overview of the LVS components
and their interrelationship.
26
Figure 1.19. Components of a Running LVS Cluster
Le démon pulse est exécuté sur les deux routeurs LVS actifs et passifs. Sur le routeur LVS de
sauvegarde, pulse envoie un signal heartbeat à l'interface publique du routeur actif afin de s'assurer
que le routeur LVS actif fonctionne correctement. Sur le routeur LVS actif, pulse démarre le démon lvs
et répond aux requêtes heartbeat du routeur LVS de sauvegarde.
Une fois démarré, le démon lvs appelle l'utilitaire ipvsadm afin de configurer et maintenir la table de
routage IPVS (de l'anglais IP Virtual Server) dans le noyau et démarre un processus nanny pour
chaque serveur virtuel configuré sur chaque serveur réel. Chaque processus nanny vérifie l'état d'un
service configuré sur un serveur réel et indique au démon lvs si le service sur ce serveur réel ne
fonctionne pas correctement. Si un dysfonctionnement est détecté, le démon lvs demande à l'utilitaire
ipvsadm de supprimer ce serveur réel de la table de routage IPVS.
Si le routeur LVS de sauvegarde ne reçoit pas de réponse à partir du routeur LVS actif, il initie un failover
en appelant send_arp afin de réassigner toutes les adresses IP virtuelles aux adresses matérielles
NIC (adresse MAC) du routeur LVS de sauvegarde. Il envoie également une commande au routeur LVS
actif via les interfaces réseau publiques et privées afin d'arrêter le démon lvs sur le routeur LVS actif et
démarre le démon lvs sur le routeur LVS de sauvegarde afin d'accepter les requêtes pour les serveurs
virtuels configurés.
Pour un utilisateur externe accédant à un service hôte (tel qu'un site Web ou une application de base de
données), LVS apparaît comme un serveur. Cependant, l'utilisateur accède aux serveurs réels derrière
les routeurs LVS.
Parce qu'il n'y a pas de composant intégré dans LVS pour partager les données à travers les serveurs
réels, vous disposez de deux options de base :
Synchroniser les données à travers les serveurs réels.
Ajouter une troisième couche à la topologie pour l'accès aux données partagées.
La première option est préférable pour les serveurs qui n'autorisent pas un grand nombre d'utilisateurs
27
à télécharger ou changer des données sur les serveurs réels. Si les serveurs réels autorisent un grand
nombre d'utilisateurs à modifier les données, par exemple un site Web de e-commerce, ajouter une
troisième couche est préférable.
Il existe de nombreuses façons pour synchroniser les données entre les serveurs réels. Vous pouvez
par exemple utiliser des scripts shell afin de poster simultanément des pages Web mises à jour sur les
serveurs réels. Vous pouvez également utiliser des programmes comme rsync pour répliquer les
données modifiées à travers tous les noeuds à un intervalle défini. T outefois, dans les environnements
où les utilisateurs téléchargent fréquemment des fichiers ou émettent des transactions avec la base de
données, l'utilisation de scripts ou de la commande rsync pour la synchronisation des données ne
fonctionne pas de façon optimale. Par conséquent, pour les serveurs réels avec un nombre élevé de
téléchargements, transactions de base de données, ou autre trafic similaire, une topologie trois tiers est
plus appropriée pour la synchronisation des données.
1.8.1. Two-Tier LVS Topology
Figure 1.20, « T wo-T ier LVS T opology » shows a simple LVS configuration consisting of two tiers: LVS
routers and real servers. T he LVS-router tier consists of one active LVS router and one backup LVS
router. T he real-server tier consists of real servers connected to the private network. Each LVS router
has two network interfaces: one connected to a public network (Internet) and one connected to a private
network. A network interface connected to each network allows the LVS routers to regulate traffic
between clients on the public network and the real servers on the private network. In Figure 1.20, « T woT ier LVS T opology », the active LVS router uses Network Address Translation (NAT) to direct traffic from
the public network to real servers on the private network, which in turn provide services as requested.
T he real servers pass all public traffic through the active LVS router. From the perspective of clients on
the public network, the LVS router appears as one entity.
Figure 1.20. T wo-T ier LVS T opology
Les requêtes de service arrivant au routeur LVS sont adressées à une adresse IP virtuelle (VIP de
l'anglais Virtual IP). Il s'agit d'une adresse routable publiquement que l'administrateur du site associe à
un nom de domaine pleinement qualifié, tel que www.exemple.com et qui est assignée à un ou plusieurs
28
serveurs virtuels [1] . Notez qu'une adresse VIP migre d'un routeur LVS à l'autre durant le failover, ainsi
cette adresse IP est toujours en présence d'un routeur (également appelée adresse IP flottante).
Les adresses VIP peuvent avoir un alias pour le même périphérique connectant le routeur LVS au
réseau public. Par exemple, si eth0 est connecté à Internet, plusieurs serveurs virtuels peuvent être
nommés eth0:1. De façon alternative, chaque serveur virtuel peut être associé à un périphérique
différent par service. Par exemple, le trafic HT T P peut être traité sur eth0:1 et le trafic FT P peut être
traité sur eth0:2.
Seul un routeur LVS peut être actif à un moment donné. Le rôle du routeur LVS actif est de rediriger les
requêtes de service, des adresses IP virtuelles vers les serveurs réels. La redirection est basée sur un
de ces huit algorithmes de répartition de charge :
Programmation Round-Robin — Distribue chaque requête consécutivement autour d'un pool de
serveurs réels. En utilisant cet algorithme, tous les serveurs réels sont traités de la même manière,
sans prendre en compte la capacité ou la charge.
Programmation Weighted Round-Robin — Distribue chaque requête consécutivement autour d'un
pool de serveurs réels mais donne plus de travail aux serveurs ayant une plus grande capacité. La
capacité est indiquée par un facteur de poids assigné par l'utilisateur, qui est ensuite ajusté en
fonction des informations de charge dynamiques. Cette option est préférée s'il y a des différences
sensibles entre la capacité des serveurs réels d'un pool de serveurs. Cependant, si la charge des
requêtes varie considérablement, un serveur très alourdi pourrait répondre à plus de requêtes qu'il
ne devrait.
Least-Connection — Distribue davantage de requêtes aux serveurs réels ayant moins de
connexions actives. Ceci est un genre d'algorithme de programmation dynamique. C'est une bonne
option s'il y a un degré de variation important au niveau de la charge des requêtes. Il s'agit de
l'algorithme qui correspond le mieux à un pool de serveurs où chaque noeud du serveur a
approximativement la même capacité. Si les serveurs réels ont des capacités différentes, la
programmation weighted least-connection constitue un meilleur choix.
Weighted Least-Connections (par défaut) — Distribue davantage de requêtes aux serveurs ayant
moins de connexions actives en fonction de leurs capacités. La capacité est indiquée par un facteur
de poids assigné par l'utilisateur, qui est ensuite ajusté en fonction des informations de charge
dynamiques. L'ajout de poids rend l'algorithme idéal lorsque le pool de serveurs réels contient du
matériel avec différentes capacités.
Programmation Locality-Based Least-Connection — Distribue davantage de requêtes aux serveurs
ayant moins de connexions actives en fonction de leur adresse IP de destination. Cet algorithme est
dédié à une utilisation au sein d'un cluster de serveurs proxy-cache. Il achemine les paquets d'une
adresse IP vers le serveur de cette adresse à moins que ce serveur soit au-delà de ses capacités,
auquel cas il assigne l'adresse IP au serveur réel le moins chargé.
Programmation Locality-Based Least-Connection avec programmation répliquée — Distribue
davantage de paquets aux serveurs ayant moins de connexions actives en fonction de leur adresse
IP de destination. Cet algorithme est également dédié à une utilisation au sein d'un cluster de
serveurs proxy-cache. Il diffère de la programmation Locality-Based Least-Connection car il mappe
l'adresse IP cible à un sous-groupe de noeuds de serveurs réels. Les requêtes sont ensuite routées
vers le serveur de ce sous-groupe ayant le moins de connexions. Si tous les noeuds pour l'adresse
IP de destination sont en-dessus de leurs capacités, il réplique un nouveau serveur pour cette
adresse IP de destination en ajoutant le serveur réel ayant le moins de connexions à partir du pool
entier de serveurs réels vers le sous-groupe de serveurs réels. Le noeud le plus chargé est ensuite
retiré du sous-groupe de serveurs réels pour éviter les excès de réplication.
Programmation Source Hash — Distribue les requêtes vers le pool de serveurs réels en cherchant
l'adresse IP source dans une table de hachage statique. Cet algorithme est dédié aux routeurs LVS
avec plusieurs pare-feu.
29
De plus, le routeur LVS contrôle dynamiquement la santé globale des services spécifiques sur les
serveurs réels à travers de simples scripts send/expect. Pour aider à détecter la santé de services
nécessitant des données dynamiques, tels que HT T PS ou SSL, vous pouvez également appeler des
exécutables externes. Si le service d'un serveur réel ne fonctionne plus correctement, le routeur LVS
actif arrête de lui envoyer des travaux jusqu'à ce qu'il fonctionne à nouveau.
Le routeur LVS de sauvegarde joue le rôle de système de secours. Régulièrement, les routeurs LVS
échangent des messages "heartbeat" à travers l'interface publique externe primaire et, en cas d'échec,
l'interface privée. Si le routeur LVS de sauvegarde ne reçoit pas de message "heartbeat" dans un
intervalle défini, il initie un failover et endosse le rôle de routeur LVS actif. Durant le failover, le routeur
LVS de sauvegarde récupère les adresses VIP desservies par le routeur ayant échoué en utilisant une
technique appelée ARP spoofing — où le routeur LVS de sauvegarde s'annonce lui-même comme
destinataire des paquets IP adressés au noeud défaillant. Lorsque le noeud ayant échoué fonctionne à
nouveau, le routeur LVS de sauvegarde reprend son rôle de routeur de sauvegarde.
T he simple, two-tier configuration in Figure 1.20, « T wo-T ier LVS T opology » is suited best for clusters
serving data that does not change very frequently — such as static web pages — because the
individual real servers do not automatically synchronize data among themselves.
1.8.2. Three-Tier LVS Topology
Figure 1.21, « T hree-T ier LVS T opology » shows a typical three-tier LVS configuration. In the example,
the active LVS router routes the requests from the public network (Internet) to the second tier — real
servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over
the private network.
30
Figure 1.21. T hree-T ier LVS T opology
Cette topologie est bien adaptée aux serveurs FT P occupés, où les données accessibles sont stockées
sur un serveur central, hautement disponible et accédées par chaque serveur réel via un répertoire NFS
exporté ou un partage Samba. Cette topologie est également recommandée pour les sites web qui
accèdent à une base de données centrale, à haute disponibilité pour réaliser des transactions. De plus,
en utilisant une configuration active-active avec un cluster Red Hat, vous pouvez configurer un cluster à
haute disponibilité afin qu'il remplisse ces deux rôles simultanément.
1.8.3. Méthodes de routage
Vous pouvez utiliser le routage de traduction d'adresses réseau (NAT de l'anglais Network Address
T ranslation) ou le routage direct avec LVS. Les sections suivantes décrivent brièvement le routage NAT
et le routage direct avec LVS.
1.8.3.1. Routage NAT
Figure 1.22, « LVS Implemented with NAT Routing », illustrates LVS using NAT routing to move requests
between the Internet and a private network.
31
Figure 1.22. LVS Implemented with NAT Routing
Dans cet exemple, il y a deux NIC dans le routeur LVS actif. La NIC pour Internet a une adresse IP réelle
sur eth0 et une adresse IP flottante possédant un alias sur eth0:1. La NIC pour l'interface réseau privée
a une adresse IP réelle sur eth1 et une adresse IP flottante possédant un alias sur eth1:1. En cas de
failover, l'interface virtuelle exposée à Internet et celle privée exposée à l'interface virtuelle sont
récupérées simultanément par le routeur LVS de sauvegarde. T ous les serveurs réels sur le réseau
privé utilisent l'adresse IP flottante pour le routeur NAT comme leur route par défaut afin de
communiquer avec le routeur LVS actif pour que leurs capacités à répondre aux requêtes Internet ne
soit pas détériorées.
In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are
aliased to two physical NICs. While it is possible to associate each floating IP address to its physical
device on the LVS router nodes, having more than two NICs is not a requirement.
En utilisant cette topologie, le routeur LVS actif reçoit la requête et la redirige vers le serveur approprié.
Le serveur réel traite ensuite la requête et retourne les paquets au routeur LVS. Le routeur LVS utilise la
traduction d'adresses réseau pour remplacer l'adresse du serveur réel dans les paquets avec l'adresse
VIP publique des routeurs LVS. Ce processus est appelé IP masquerading car les adresses IP
courantes des serveurs réels sont cachées des clients effectuant la requête.
En utilisant le routage NAT , un serveur réel peut être n'importe quel type d'ordinateur exécutant une
variété de systèmes d'exploitation. Le principal inconvénient du routage NAT est que le routeur LVS peut
devenir un goulet d'étranglement dans les grands déploiements car il doit traiter les requêtes entrantes
et sortantes.
1.8.3.2. Routage direct
Le routage direct offre des performances supérieures par rapport au routage NAT . Le routage direct
permet aux serveurs réels de traiter et router les paquets directement vers un utilisateur les demandant
plutôt que de passer les paquets sortants à travers le routeur LVS. Le routage direct réduit les risques
de problèmes de performance réseau en reléguant le travail du routeur LVS pour ne traiter que les
32
paquets entrants.
Figure 1.23. LVS Implemented with Direct Routing
Dans une configuration LVS classique de routage direct, un routeur LVS reçoit des requêtes serveur
entrantes par l'intermédiaire d'une adresse IP virtuelle (VIP) et utilise un algorithme de programmation
pour diriger les requêtes vers les serveurs réels. Chaque serveur réel traite les requêtes et envoie les
réponses directement aux clients sans passer par les routeurs LVS. Le routage direct permet une plus
grande évolutivité car les serveurs réels peuvent être ajoutés sans charge supplémentaire sur le
routeur LVS pour router les paquets sortants du serveur réel vers le client.
S'il existe de nombreux avantages à l'utilisation du routage direct dans LVS, il existe aussi des
limitations. Le problème le plus courant avec le routage direct et LVS est le Protocole de résolution
d'adresses (ARP de l'anglais Address Resolution Protocol).
In typical situations, a client on the Internet sends a request to an IP address. Network routers typically
send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP
requests are broadcast to all connected machines on a network, and the machine with the correct
IP/MAC address combination receives the packet. T he IP/MAC associations are stored in an ARP cache,
which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.
Le problème avec les requêtes ARP dans une configuration LVS de routage direct est que dans la
mesure où l'adresse IP d'une requête client doit être associée à une adresse MAC pour être traitée,
l'adresse virtuelle du routeur LVS doit également être associée à une adresse MAC. Cependant, parce
que le routeur LVS et les serveurs réels ont la même adresse VIP, la requête ARP est diffusée à tous
les noeuds associés à l'adresse VIP. Cela peut causer plusieurs problèmes, tels que l'adresse VIP
associée directement à un des serveurs réels et traitant les requêtes directement, sans passer par le
33
routeur LVS et ainsi allant à l'encontre du but de la configuration LVS. L'utilisation d'un routeur LVS avec
un CPU puissant qui répond rapidement aux requêtes clients ne résout pas forcément ce problème. Si le
routeur LVS est sous une charge élevée, il peut répondre à la requête ARP plus lentement qu'un
serveur réel sous-utilisé répondant plus rapidement et qui se fait attribuer l'adresse VIP dans le cache
ARP du client effectuant la requête.
Pour résoudre ce problème, les requêtes entrantes devraient uniquement associer l'adresse VIP au
routeur LVS, qui traitera correctement les requêtes et les enverra au pool de serveurs réels. Ceci peut
être fait en utilisant le pool de filtrage des paquets arptables.
1.8.4. La persistance et les marques de pare-feu
Dans certains cas il se peut qu'un client veuille se reconnecter plusieurs fois au même serveur réel,
plutôt que d'avoir un algorithme de répartition de charge qui envoie sa requête au meilleur serveur
disponible. Ceci est par exemple valable pour les formulaires Web ayant plusieurs pages, les cookies,
SSL et les connexions FT P. Dans ces cas un client ne fonctionne pas correctement à moins que les
transactions soient traitées par le même serveur afin de garder le contexte. LVS fournit deux
fonctionnalités différentes pour traiter cela : la persistance et les marques de pare-feu.
1.8.4 .1. Persistence
Lorsqu'elle est activée, la persistance agit comme un minuteur. Lorsqu'un client se connecte à un
service, LVS se souvient de sa dernière connexion pendant une période de temps spécifique. Si le client
se connecte à nouveau avec la même adresse IP avant la fin de cette période, le client est envoyé vers
le même serveur auquel il s'était connecté précédemment — sans passer par le mécanisme de
répartition de charge. Lorsqu'une connexion est effectuée après cette période, elle est traitée en
fonction des règles de programmation mises en place.
La persistance vous permet également de spécifier un masque de sous-réseau à appliquer sur
l'adresse IP du client afin de contrôler les adresses qui ont un plus haut niveau de persistance et ainsi
grouper les connexions vers ce sous-réseau.
Le groupement de connexions destinées à différents ports peut être important pour les protocoles qui
utilisent plus d'un port pour communiquer, tels que FT P. Cependant, la persistance n'est pas la façon la
plus efficace de gérer le problème de groupement de connexions destinées à différents ports. Dans de
telles situations, il est préférable d'utiliser les marques de pare-feu.
1.8.4 .2. Marques de pare-feu
Les marques de pare-feu sont un moyen simple et efficace pour grouper les ports utilisés par un
protocole ou un groupe de protocoles connexes. Par exemple, si LVS est déployé pour exécuter un site
de e-commerce, les marques de pare-feu peuvent être utilisées pour empaqueter les connexions HT T P
sur le port 80 et sécuriser les connexions HT T PS sur le port 443. En assignant la même marque de
pare-feu au serveur virtuel pour chaque protocole, les informations d'état de la transaction peuvent être
préservées car le routeur LVS redirige toutes les requêtes vers le même serveur réel après qu'une
connexion soit ouverte.
Parce qu'elles sont simples à utiliser et efficaces, les administrateurs LVS devraient utiliser, dès que
possible, les marques de pare-feu afin de grouper les connexions. T outefois, vous devriez toujours
ajouter la persistance aux serveurs virtuels conjointement aux marques de pare-feu pour vous assurer
que les clients soient reconnectés au même serveur pendant une période désirée.
1.9. Outils d'administration du cluster
Red Hat Cluster Suite fournit une variété d'outils pour configurer et gérer votre cluster Red Hat. Cette
section fournit un aperçu des outils d'administration disponibles avec Red Hat Cluster Suite :
34
Section 1.9.1, « Conga »
Section 1.9.2, « Interface graphique d'administration du cluster »
Section 1.9.3, « Outils d'administration en ligne de commande »
1.9.1. Conga
Conga est un ensemble intégré de composants logiciels qui fournit une configuration et une gestion
centralisées des clusters et du stockage Red Hat. Conga fournit les fonctionnalités principales
suivantes :
Une interface Web pour la gestion du cluster et du stockage
Un déploiement automatisé des données du cluster et des paquetages de support
Une Intégration facile avec les clusters existants
Il n'est pas nécessaire de s'authentifier à nouveau
L'intégration du statut et des fichiers journaux du cluster
Un contrôle minutieux des autorisations des utilisateurs
Les principaux composants de Conga sont luci et ricci. Ils peuvent être installés séparément. luci est
un serveur qui s'exécute sur un ordinateur et qui communique avec plusieurs clusters et ordinateurs via
ricci. ricci est un agent qui est démarré sur chaque ordinateur (un membre du cluster ou un ordinateur
autonome) géré par Conga.
luci est accessible via un navigateur Web et fournit trois fonctionnalités principales qui sont accessibles
à travers les onglets suivants :
homebase — Fournit des outils pour l'ajout et la suppression d'ordinateurs et d'utilisateurs. Ces
outils vous permettent également de configurer les privilèges des utilisateurs. Seul un administrateur
système peut accéder à cet onglet.
cluster — Fournit des outils pour la création et la configuration des clusters. Chaque instance de
luci liste les clusters qui ont été configurés avec ce serveur luci. Un administrateur système peut
administrer tous les clusters listés sur cet onglet. Les autres utilisateurs peuvent seulement
administrer les clusters pour lesquels ils ont des privilèges (accordés par un administrateur).
storage — Fournit des outils pour l'administration à distance du stockage. Avec ces outils, vous
pouvez gérer le stockage des ordinateurs qu'ils appartiennent à un cluster ou pas.
Pour administrer un cluster ou le stockage, un administrateur ajoute (ou enregistre) un cluster ou un
ordinateur au serveur luci. Lorsqu'un cluster ou un ordinateur est enregistré avec luci, le nom de
domaine FQDN ou l'adresse IP de chaque ordinateur est stocké dans une base de données luci.
Vous pouvez peupler la base de données d'une instance luci à partir d'une autre instance luci. Cela
vous offre la possibilité de répliquer une instance de serveur luci et fournit un chemin d'accès de test et
de mise à niveau efficace. Quand vous installez une instance luci, sa base de données est vide.
T outefois, vous pouvez importer une partie ou la totalité d'une base de données luci à partir d'un
serveur luci existant lors du déploiement d'un nouveau serveur luci.
Chaque instance luci dispose d'un utilisateur lors de l'installation initiale — admin. Seul l'utilisateur
admin peut ajouter des systèmes à un serveur luci. De plus, l'utilisateur admin peut créer des comptes
utilisateur supplémentaires et déterminer les utilisateurs qui sont autorisés à accéder aux clusters et
ordinateurs enregistrés dans la base de données luci. Il est possible d'importer des utilisateurs avec
une opération batch dans un nouveau serveur luci, tout comme il est possible d'importer des clusters
ou des ordinateurs.
Lorsqu'un ordinateur est ajouté à un serveur luci pour être administré, l'authentification est effectuée
35
qu'une seule fois. Aucune authentification n'est nécessaire par la suite (sauf si le certificat utilisé est
révoqué par un CA). Ensuite, vous pouvez configurer et gérer à distance les clusters et le stockage à
travers l'interface utilisateur luci. luci et ricci communiquent ensemble via XML.
Les figures suivantes illustrent des exemples d'affichage des trois onglets principaux de luci :
homebase, cluster et storage.
Pour davantage d'informations à propos de Conga, reportez-vous à la Configuration et gestion d'un
cluster Red Hat et à l'aide en ligne disponibles avec le serveur luci.
Figure 1.24 . L'onglet homebase de luci
Figure 1.25. L'onglet cluster luci
36
Figure 1.26. L'onglet storage de luci
1.9.2. Interface graphique d'administration du cluster
T his section provides an overview of the system -config-cluster cluster administration graphical
user interface (GUI) available with Red Hat Cluster Suite. T he GUI is for use with the cluster
infrastructure and the high-availability service management components (refer to Section 1.3, « Cluster
Infrastructure » and Section 1.4, « Gestion des services à haute disponibilité »). T he GUI consists of two
major functions: the Cluster Configuration T ool and the Cluster Status T ool. T he Cluster
Configuration T ool provides the capability to create, edit, and propagate the cluster configuration file
(/etc/cluster/cluster.conf). T he Cluster Status T ool provides the capability to manage highavailability services. T he following sections summarize those functions.
Section 1.9.2.1, « Cluster Configuration T ool »
Section 1.9.2.2, « Cluster Status T ool »
1.9.2.1. Cluster Configuration T ool
You can access the Cluster Configuration T ool (Figure 1.27, « Cluster Configuration T ool ») through
the Cluster Configuration tab in the Cluster Administration GUI.
37
Figure 1.27. Cluster Configuration T ool
L'Cluster Configuration T ool représente les composants de configuration du cluster au sein du
fichier de configuration (/etc/cluster/cluster.conf) avec un affichage graphique hiérarchique
dans le panneau de gauche. Un icône en forme de triangle à gauche du nom d'un composant indique
que le composant possède un ou plusieurs composants de second niveau. En cliquant sur cet icône
vous pouvez agrandir et réduire la partie de l'arborescence située sous le composant. Les composants
affichés dans l'interface utilisateur graphique sont structurés de la manière suivante :
Cluster Nodes — Affiche les noeuds du cluster. Les neuds sont représentés par nom en tant
qu'éléments de second niveau sous le composant Cluster Nodes.
Fence Devices — Affiche les périphériques fence. Les périphériques fence sont représentés en
tant qu'éléments de second niveau sous le composant Fence Devices. En utilisant les boutons de
configuration situés en bas du cadre de droite (sous Properties), vous pouvez ajouter des
périphériques fence, en supprimer et modifier leurs propriétés. Les périphériques fence doivent être
définis avant que vous puissiez configurer le fencing (avec le bouton Manage Fencing For
T his Node) pour chaque noeud.
Ressources gérées — Affiche les domaines failover, les ressources et les services.
Failover Dom ains — Pour la configuration d'un ou plusieurs sous-groupes de noeuds du
cluster utilisés pour exécuter un service à haute disponibilité en cas d'échec d'un noeud. Les
domaines failover sont représentés en tant qu'éléments de second niveau sous sous le
composant Failover Dom ains. En utilisant les boutons de configuration en bas du cadre de
droite (sous Properties), vous pouvez créer des domaines failover (lorsque Failover
Dom ains est sélectionné) ou modifier les propriétés d'un domaine failover (lorsqu'il est
38
sélectionné).
Resources — Pour la configuration de ressources partagées à utiliser avec les services à
haute disponibilité. Les ressources partagées sont constituées de systèmes de fichiers,
d'adresses IP, d'exports et de montages NFS et de scripts utilisateur disponibles pour un service
à haute disponibilité au sein du cluster. Les ressources sont représentées en tant qu'éléments
de second niveau sous sous le composant Resources. En utilisant les boutons de configuration
en bas du cadre de droite (sous Properties), vous pouvez créer des ressources (lorsque
Resources est sélectionné) ou modifier les propriétés d'une ressource (lorsqu'une ressource
est sélectionnée).
Remarque
L'Cluster Configuration T ool offre également la possibilité de configurer des
ressources privées. Une ressource privée est une ressource qui est configurée pour être
utilisée avec un seul service. Vous pouvez configurer une ressource privée au sein d'un
composant Service avec l'interface utilisateur graphique.
Services — Pour la création et la configuration de services à haute disponibilité. Un service est
configuré en lui assignant des ressources (partagées ou privées), un domaine failover et une
politique de récupération. Les services sont représentés en tant qu'éléments de niveau
secondaire sous Services. En utilisant les boutons de configuration en bas du cadre de droite
(sous Properties), vous pouvez créer des services (lorsque Services est sélectionné) ou
modifier les propriétés d'un service (lorsqu'un service est sélectionné).
1.9.2.2. Cluster Status T ool
You can access the Cluster Status T ool (Figure 1.28, « Cluster Status T ool ») through the Cluster
Management tab in Cluster Administration GUI.
39
Figure 1.28. Cluster Status T ool
Les noeuds et services affichés dans l'Cluster Status T ool sont déterminés par le fichier de
configuration du cluster (/etc/cluster/cluster.conf). Vous pouvez utiliser l'Cluster Status
T ool pour activer, désactiver, redémarrer ou déplacer un service à haute disponibilité.
1.9.3. Outils d'administration en ligne de commande
In addition to Conga and the system -config-cluster Cluster Administration GUI, command line
tools are available for administering the cluster infrastructure and the high-availability service
management components. T he command line tools are used by the Cluster Administration GUI and init
scripts supplied by Red Hat. T ableau 1.1, « Outils en ligne de commande » summarizes the command
line tools.
40
T ableau 1.1. Outils en ligne de commande
Outil en ligne de
commande
Utilisé avec
Utilité
ccs_tool —
Outil système de
configuration du
cluster
Cluster
Infrastructure
ccs_tool est un programme permettant d'effectuer des
mises à jour en ligne du fichier de configuration du cluster. Il
offre la possibilité de créer et modifier les composants
d'infrastructure du cluster (par exemple, la création d'un
cluster, l'ajout et la suppression d'un noeud). Pour
davantage d'informations à propos de cet outil, reportezvous à la page de manuel ccs_tool(8).
cm an_tool —
Outil de gestion
du cluster
Cluster
Infrastructure
cm an_tool est un programme qui contrôle le gestionnaire
de cluster CMAN. Il offre la possibilité de joindre un cluster,
quitter un cluster, supprimer un noeud ou changer les votes
quorum attendus d'un noeud du cluster. Pour davantage
d'informations à propos de cet outil, reportez-vous à la page
de manuel cman_tool(8).
fence_tool —
Outil Fence
Cluster
Infrastructure
fence_tool est un programme utilisé pour joindre ou
quitté le domaine fence par défaut. Plus précisément, il
démarre le démon fence (fenced) pour joindre le domaine
et arrête fenced pour quitter le domaine. Pour davantage
de manuel fence_tool(8).
clustat —
Utilitaire de statut
du cluster
Composants de
gestion des
services à haute
disponibilité
La commande clustat indique le statut du cluster. Elle
affiche les informations d'appartenance, le mode du quorum
et l'état de tous les services utilisateur configurés. Pour
davantage d'informations à propos de cet outil, reportezvous à la page de manuel clustat(8).
clusvcadm —
Utilitaire
d'administration
des services
utilisateur du
cluster
Composants de
gestion des
services à haute
disponibilité
La commande clusvcadm vous permet d'activer,
désactiver, déplacer et redémarrer les services à haute
disponibilité au sein d'un cluster. Pour davantage
de manuel clusvcadm(8).
1.10. Interface utilisateur graphique d'administration du serveur
virtuel Linux
Cette section fournit un aperçu de l'outil de configuration LVS disponible avec Red Hat Cluster Suite —
L'Piranha Configuration T ool. L'Piranha Configuration T ool est une application Web qui offre une
approche structurée afin de créer le fichier de configuration pour LVS —
/etc/sysconfig/ha/lvs.cf.
Pour accéder à l'Piranha Configuration T ool, le service piranha-gui doit être en cours d'exécution
sur le routeur LVS actif. Vous pouvez accéder à l'Piranha Configuration T ool localement ou à
distance avec un navigateur Web. Localement, utilisez l'adresse suivante : http://localhost:3636.
Pour accéder à l'Piranha Configuration T ool à distance, utilisez le nom de domaine ou l'adresse IP
réelle suivi de :3636. Si vous accédez à l'Piranha Configuration T ool à distance, vous devez
diposer d'une connexion ssh vers le routeur LVS actif en tant que super-utilisateur (root).
41
Starting the Piranha Configuration T ool causes the Piranha Configuration T ool welcome page to
be displayed (refer to Figure 1.29, « T he Welcome Panel »). Logging in to the welcome page provides
access to the four main screens or panels: CONT ROL/MONIT ORING, GLOBAL SET T INGS,
REDUNDANCY, and VIRT UAL SERVERS. In addition, the VIRT UAL SERVERS panel contains four
subsections. T he CONT ROL/MONIT ORING panel is the first panel displayed after you log in at the
welcome screen.
Figure 1.29. T he Welcome Panel
Les sections suivantes fournissent une brève description des pages de configuration de l'Piranha
Configuration T ool.
1.10.1. CONTROL/MONITORING
Le panneau CONT ROL/MONIT ORING affiche l'état d'exécution. Il affiche le statut du démon pulse, de la
table de routage LVS et des processus nanny créés par LVS.
42
Figure 1.30. T he CONT ROL/MONIT ORING Panel
Auto update
Permet à l'affichage des états d'être mis à jour automatiquement à un intervalle de temps
configurable par l'utilisateur et défini dans la zone de texte Update frequency in
seconds (la valeur par défaut est 10 secondes).
Il n'est pas recommandé de paramétrer la mise à jour automatique à un intervalle inférieur à 10
secondes. Cela peut rendre la reconfiguration de l'intervalle Auto update difficile car la page
sera mise à jour trop fréquemment. Si vous rencontrez ce problème, cliquez sur un autre
panneau et retournez ensuite sur CONT ROL/MONIT ORING.
Update inform ation now
Permet de mettre à jour manuellement les informations d'état.
CHANGE PASSWORD
En cliquant sur ce bouton vous affichez une page d'aide qui vous indique comment modifier le
mot de passe administrateur de l'Piranha Configuration T ool.
1.10.2. GLOBAL SETTINGS
T he GLOBAL SET T INGS panel is where the LVS administrator defines the networking details for the
primary LVS router's public and private network interfaces.
Figure 1.31. T he GLOBAL SET T INGS Panel
43
T he top half of this panel sets up the primary LVS router's public and private network interfaces.
Prim ary server public IP
L'adresse IP réelle routable publiquement pour le noeud LVS primaire.
Prim ary server private IP
L'adresse IP réelle pour une interface réseau alternative sur le noeud LVS primaire. Cette
adresse est seulement utilisée en tant que canal "hearbeat" alternatif par le routeur de
sauvegarde.
Use network type
Selection du routage NAT .
T he next three fields are specifically for the NAT router's virtual network interface connected the private
network with the real servers.
NAT Router IP
Il s'agit de l'adresse IP flottante privée. Cette adresse IP flottante devrait être utilisée comme la
passerelle pour les serveurs réels.
NAT Router netm ask
If the NAT router's floating IP needs a particular netmask, select it from drop-down list.
NAT Router device
Définit le nom du périphérique de l'interface réseau pour l'adresse IP flottante, par exemple
eth1:1.
1.10.3. REDUNDANCY
Le panneau REDUNDANCY vous permet de configurer le noeud du routeur LVS de sauvegarde et de
définir plusieurs options d'analyse "hearbeat".
44
Figure 1.32. T he REDUNDANCY Panel
Redundant server public IP
L'adresse IP réelle publique pour le routeur LVS de sauvegarde.
Redundant server private IP
T he backup router's private real IP address.
Le reste du panneau permet de configurer le canal "hearbeat" qui est utilisé par le noeud de
sauvegarde pour surveiller le nœud primaire en cas d'échec.
Heartbeat Interval (seconds)
Définit le nombre de secondes entre les messages "hearbeat" — l'intervalle utilisé par le noeud
de sauvegarde pour vérifier l'état fonctionnel du noeud LVS primaire.
Assum e dead after (seconds)
Si le noeud LVS primaire ne répond pas après ce nombre de secondes, le noeud du routeur
LVS de sauvegarde initiera un failover.
Heartbeat runs on port
Définit le port utilisé par le message "hearbeat" pour communiquer avec le noeud LVS primaire.
Le port par défaut est 539 si cette zone de texte est vide.
1.10.4. VIRTUAL SERVERS
45
Le panneau VIRT UAL SERVERS affiche des informations sur les serveurs virtuels actuellement définis.
Chaque entrée du tableau indique le statut du serveur virtuel, le nom du serveur, l'adresse IP virtuelle
assignée au serveur, le masque de réseau de l'adresse IP virtuelle, le numéro de port avec lequel le
service communique, le protocole utilisé et l'interface périphérique virtuelle.
Figure 1.33. T he VIRT UAL SERVERS Panel
Chaque serveur affiché dans le panneau VIRT UAL SERVERS peut être configuré sur les écrans ou
sous-sections suivantes.
Pour ajouter un service, cliquez sur le bouton ADD. Pour supprimer un service, sélectionnez le bouton
radio correspondant et cliquez sur le bouton DELET E.
Pour activer ou désactiver un serveur virtuel à partir du tableau, sélectionnez le bouton radio
correspondant et cliquez sur le bouton (DE)ACT IVAT E.
Après avoir ajouté un serveur virtuel, vous pouvez le configurer en sélectionnant le bouton radio
correspondant et en cliquant sur le bouton EDIT afin d'afficher la sous-section VIRT UAL SERVER.
1.10.4 .1. La sous-section VIRT UAL SERVER
T he VIRT UAL SERVER subsection panel shown in Figure 1.34, « T he VIRT UAL SERVERS
Subsection » allows you to configure an individual virtual server. Links to subsections related specifically
to this virtual server are located along the top of the page. But before configuring any of the subsections
related to this virtual server, complete this page and click on the ACCEPT button.
46
Figure 1.34 . T he VIRT UAL SERVERS Subsection
Nam e
Il s'agit d'un nom descriptif pour identifier le serveur virtuel. Ce nom ne correspond pas au nom
d'hôte de la machine, saisissez donc un nom facile à identifier. Vous pouvez même référencer
le protocole utilisé par le serveur virtuel, par exemple HT T P.
Application port
Le numéro de port à travers lequel l'application service écoutera.
Protocol
Donne le choix entre UDP et T CP, dans un menu déroulant.
Virtual IP Address
T he virtual server's floating IP address.
Virtual IP Network Mask
Le masque de réseau pour ce serveur virtuel, dans un menu déroulant.
Firewall Mark
Permet de saisir une valeur entière de marque de pare-feu lors du groupement de protocoles
multiports ou de la création d'un serveur virtuel multiports pour des protocoles distincts mais
liés.
Device
Le nom du périphérique réseau auquel vous voulez lier l'adresse IP flottante définie dans la
47
zone de texte Virtual IP Address.
Vous devriez créer un alias pour l'adresse IP flottante publique à l'interface Ethernet connectée
au réseau public.
Re-entry T im e
Une valeur entière qui définit le nombre de secondes avant que le routeur LVS actif essaie
d'utiliser un serveur réel suite à l'échec du serveur réel.
Service T im eout
Une valeur entière qui définit le nombre de secondes avant qu'un serveur réel soit considéré
comme étant inactif et indisponible.
Quiesce server
Lorsque le bouton radio Quiesce server est sélectionné, à chaque fois qu'un nouveau
noeud de serveur réel est connecté, la table least-connections est remise à zéro pour que le
routeur LVS actif dirige les requêtes comme si tous les serveurs réels venaient d'être ajoutés
au cluster. Cette option empêche au nouveau serveur de s'enliser avec un nombre élevé de
connexions suite à son arrivée au sein du cluster.
Load m onitoring tool
Le routeur LVS peut surveiller la charge des différents serveurs réels en utilisant rup ou
ruptim e. Si vous sélectionnez rup à partir du menu déroulant, chaque serveur réel doit
exécuter le service rstatd. Si vous sélectionnez ruptim e, chaque serveur réel doit exécuter
le service rwhod.
Scheduling
Permet de sélectionner l'algorithme de programmation préféré à partir de ce menu déroulant. La
valeur par défaut est Weighted least-connection.
Persistence
Peut être utilisé si vous avez besoin de connexions persistantes sur le serveur virtuel durant
les transactions client. Spécifie, par l'intermédiaire de ce champ, le nombre de secondes
d'inactivité autorisé avant qu'une connexion expire.
Persistence Network Mask
Pour limiter la persistance à un sous-réseau particulier, sélectionnez le masque réseau
approprié à partir du menu déroulant.
1.10.4 .2. La sous-section REAL SERVER
Cliquez sur le lien de la sous-section REAL SERVER en haut du panneau pour afficher la sous-section
EDIT REAL SERVER. Cette sous-section affiche le statut des hôtes du serveur physique pour un
service virtuel particulier.
48
Figure 1.35. T he REAL SERVER Subsection
Click the ADD button to add a new server. T o delete an existing server, select the radio button beside it
and click the DELET E button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in
Figure 1.36, « T he REAL SERVER Configuration Panel ».
Figure 1.36. T he REAL SERVER Configuration Panel
49
Ce panneau est composé de trois zones de texte :
Nam e
Un nom descriptif pour le serveur réel.
Remarque
Ce nom ne correspond pas au nom d'hôte de la machine, saisissez donc un nom facile à
identifier.
Address
T he real server's IP address. Since the listening port is already specified for the associated
virtual server, do not add a port number.
Weight
An integer value indicating this host's capacity relative to that of other hosts in the pool. T he
value can be arbitrary, but treat it as a ratio in relation to other real servers.
1.10.4 .3. EDIT MONIT ORING SCRIPT S Subsection
Cliquez sur le lien MONIT ORING SCRIPT S en haut de la page. La sous-section EDIT MONIT ORING
SCRIPT S permet à l'administrateur de spécifier une séquence de caractères send/expect afin de
vérifier que le service pour le serveur virtuel soit fonctionnel sur chaque serveur réel. C'est également ici
que l'administrateur peut spécifier des scripts personnalisés pour vérifier les services nécessitant des
données qui changent dynamiquement.
Figure 1.37. T he EDIT MONIT ORING SCRIPT S Subsection
50
Sending Program
Pour une vérification de service plus avancée, vous pouvez utiliser ce champ afin de spécifier
le chemin d'accès d'un script de vérification de service. Cette fonction est particulièrement utile
pour les services qui requièrent que les données soient changées dynamiquement, par
exemple HT T PS ou SSL.
Pour utiliser cette fonctionnalité, vous devez écrire un script qui retourne une réponse textuelle.
Paramétrez le script pour qu'il soit exécutable et saisissez son chemin d'accès dans le champ
Sending Program .
Remarque
Si un programme externe est saisi dans le champ Sending Program , le champ Send
est ignoré.
Send
Saisissez dans ce champ une chaîne de caractères que le démon nanny enverra à chaque
serveur réel. Par défaut le champ d'envoi est configuré pour HT T P. Vous pouvez modifier cette
valeur selon vos besoins. Si vous laissez ce champ vide, le démon nanny essaie d'ouvrir le
port et, s'il réussit, suppose que le service est en cours d'exécution.
Une seule séquence send est autorisée dans ce champ et elle ne peut contenir que des
caractères imprimables, ASCII ainsi que les caractères d'échappement suivants :
\n pour une nouvelle ligne.
\r pour un retour à la ligne.
\t pour un onglet.
\ pour échapper le caractère qui suit.
Expect
La réponse textuelle que le serveur devrait retourner s'il fonctionne correctement. Si vous avez
écrit votre propre programme d'envoi, saisissez la réponse désirée.
[1] Un s erveur virtuel es t un s ervic e c o nfig uré p o ur éc o uter s ur une ad res s e IP virtuelle s p éc ifiq ue.
51
Chapitre 2. Résumé des composants de Red Hat Cluster Suite
Ce chapitre fournit un résumé des composants de Red Hat Cluster Suite et se compose des sections
suivantes :
Section 2.1, « Composants de cluster »
Section 2.2, « Pages de manuel »
Section 2.3, « Matériel compatible »
2.1. Composants de cluster
T ableau 2.1, « Composants du sous-système logiciel de Red Hat Cluster Suite » summarizes Red Hat
Cluster Suite components.
52
T ableau 2.1. Composants du sous-système logiciel de Red Hat Cluster Suite
Fonction
Composant
Description
Conga
luci
Système de gestion à distance - Station
de gestion.
ricci
Système de gestion à distance - Station
gérée.
Cluster
Configuration T ool
system -config-cluster
Commande utilisée pour gérer la
configuration du cluster dans un mode
graphique.
Gestionnaire de
volumes logiques en
cluster (CLVM)
clvm d
Il s'agit du démon qui distribue les mises
à jour de métadonnées LVM au sein du
cluster. Il doit être exécuté sur tous les
noeuds du cluster et renverra une erreur
si un noeud du cluster n'exécute pas ce
démon.
lvm
Outils LVM2. Fournit les outils en ligne de
commande pour LVM2.
system -config-lvm
Fournit une interface utilisateur
graphique pour LVM2.
lvm .conf
Le fichier de configuration LVM. Le
chemin d'accès complet est
/etc/lvm /lvm .conf.
ccs_tool
ccs_tool fait partie du système de
configuration du cluster (CCS). Il est
utilisé pour effectuer des mises à jour en
ligne des fichiers de configuration CCS.
De plus, il peut être utilisé pour mettre à
niveau les fichiers de configuration du
cluster à partir des archives CSS créées
avec GFS 6.0 (et les versions
précédentes) au format XML utilisé avec
cette version de Red Hat Cluster Suite.
ccs_test
Commande de diagnostique et de test
utilisée pour récupérer des informations
à partir des fichiers de configuration à
travers le démon ccsd.
ccsd
Démon CCS exécuté sur tous les noeuds
du cluster qui fournit des données du
fichier de configuration au logiciel cluster.
cluster.conf
Il s'agit du fichier de configuration du
cluster. Le chemin d'accès complet est
/etc/cluster/cluster.conf.
cm an.ko
Le module noyau pour CMAN.
cm an_tool
Il s'agit de la partie frontale de
l'administration de CMAN. Cet outil
démarre et arrête CMAN et peut changer
certains paramètres internes tels que les
votes.
Système de
configuration du cluster
(CCS)
Gestionnaire de cluster
(CMAN)
53
Gestionnaire du groupe
de ressources
(rgmanager)
Fence
54
dlm _controld
Démon démarré par le script init de cm an
afin de gérer dlm dans le noyau ; il n'est
pas encore utilisé par l'utilisateur.
gfs_controld
afin de gérer gfs dans le noyau ; il n'est
pas encore utilisé par l'utilisateur.
group_tool
Utilisé afin d'obtenir une liste des
groupes liés au fencing, DLM, GFS, ainsi
que des informations de débogage ; Cet
outil inclut également ce que cm an_tool
services fournissait dans RHEL 4.
groupd
afin de servir d'interface entre
openais/cm an et
dlm _controld/gfs_controld/fenc
ed; il n'est pas encore utilisé par
l'utilisateur.
libcm an.so.<version
number>
Bibliothèque pour les programmes ayant
besoin d'interagir avec cm an.ko.
clusvcadm
Commande utilisée pour activer,
désactiver, déplacer et redémarrer
manuellement les services utilisateur
dans un cluster.
clustat
Commande utilisée pour afficher le statut
du cluster, y compris l'adhésion aux
noeuds et les services en cours
d'exécution.
clurgm grd
Démon utilisé pour traiter les requêtes
des services utilisateur y compris le
démarrage, la désactivation, le
déplacement et le redémarrage d'un
service.
clurm tabd
Démon utilisé pour traiter des tables de
montage NFS clusterisées.
fence_apc
Agent fence pour le commutateur de
courant APC.
fence_bladecenter
Agent fence pour IBM Bladecenters avec
l'interface T elnet.
fence_bullpap
Agent fence pour l'interface du
processeur d'administration de la
plateforme (PAP de l'anglais Platform
Administration Processor) Bull
Novascale.
fence_drac
Agent fence pour la carte d'accès à
distance Dell.
fence_ipm ilan
Agent fence pour les machines
contrôlées par l'interface de gestion
intelligente de matériel (IPMI de l'anglais
Intelligent Platform Management
Interface) sur un LAN.
fence_wti
Agent fence pour le commutateur de
courant WT I.
fence_brocade
Agent fence pour le commutateur
Brocade Fibre Channel
fence_m cdata
Agent fence pour le commutateur McData
Fibre Channel.
fence_vixel
Agent fence pour le commutateur Vixel
Fibre Channel.
fence_sanbox2
Agent fence pour le commutateur
SANBox2 Fibre Channel.
fence_ilo
Agent fence pour les interfaces HP ILO
(formerly fence_rib).
fence_rsa
Agent fence d'E/S pour IBM RSA II.
fence_gnbd
Agent fence utilisé avec le stockage
GNBD.
fence_scsi
Agent fence d'E/S pour les réservations
SCSI persistances.
fence_egenera
Agent fence utilisé avec le système
Egenera BladeFrame.
fence_m anual
Agent fence pour une interaction
manuelle. REMARQUE : ce composant
n'est pas supporté dans les
environnements de production.
fence_ack_m anual
Interface utilisateur pour l'agent
fence_m anual.
fence_node
Un programme qui effectue des E/S
fence sur un seul noeud.
fence_xvm
Agent fence d'E/S pour les machines
virtuelles Xen.
fence_xvm d
Agent hôte fence d'E/S pour les
machines virtuelles Xen.
fence_tool
Un programme pour joindre et quitter le
domaine fence.
fenced
Le démon fence d'E/S
DLM
libdlm .so.<version
number>
Bibliothèque pour la prise en charge du
gestionnaire de verrouillage distribué
(DLM de l'anglais Distributed Lock
Manager).
GFS
gfs.ko
Module noyau qui implémente le système
de fichiers GFS et qui est chargé sur les
noeuds du cluster GFS.
gfs_fsck
Commande qui répare un système de
fichiers GFS qui n'est pas monté.
gfs_grow
Commande qui incrémente un système
de fichiers GFS monté.
gfs_jadd
Commande qui ajoute des fichiers
journaux dans un système de fichiers
GFS.
55
GNBD
LVS
56
gfs_m kfs
Commande qui crée un système de
fichiers GFS sur un périphérique de
stockage.
gfs_quota
Commande qui gère les quotas sur un
système de fichiers GFS monté.
gfs_tool
Commande qui configure ou règle un
système de fichiers monté. Cette
commande peut également regrouper
une variété d'informations à propos du
système de fichiers.
m ount.gfs
Assistant de montage appelé par
m ount(8); il n'est pas utilisé par
l'utilisateur.
gnbd.ko
Module noyau qui implémente le pilote de
périphérique GNBD sur les clients.
gnbd_export
Commande permettant de créer, exporter
et gérer les GNBD sur un serveur GNBD.
gnbd_im port
Commande permettant d'importer et
gérer les GNBD sur un client GNBD.
gnbd_serv
Un démon serveur qui permet à un
noeud d'exporter le stockage local à
travers le réseau.
pulse
T his is the controlling process which
starts all other daemons related to LVS
routers. At boot time, the daemon is
started by the
/etc/rc.d/init.d/pulse script. It
then reads the configuration file
/etc/sysconfig/ha/lvs.cf. On the
active LVS router, pulse starts the LVS
daemon. On the backup router, pulse
determines the health of the active router
by executing a simple heartbeat at a
user-configurable interval. If the active
LVS router fails to respond after a userconfigurable interval, it initiates failover.
During failover, pulse on the backup
LVS router instructs the pulse daemon
on the active LVS router to shut down all
LVS services, starts the send_arp
program to reassign the floating IP
addresses to the backup LVS router's
MAC address, and starts the lvs
daemon.
lvsd
Le démon lvs s'exécute sur le routeur
LVS actif une fois qu'il est appelé par
pulse. Il lit le fichier de configuration
/etc/sysconfig/ha/lvs.cf, appelle
l'utilitaire ipvsadm pour construire et
maintenir la table de routage IPVS et
assigne un processus nanny à chaque
service LVS configuré. Si nanny reporte
une panne sur un serveur réel, lvs
indique à l'utilitaire ipvsadm de
supprimer le serveur réel de la table de
routage IPVS.
Disque quorum
ipvsadm
Ce service met à jour la table de routage
IPVS dans le noyau. Le démon lvs
configure et administre LVS en appelant
ipvsadm pour ajouter, changer ou
supprimer les entrées dans la table de
routage IPVS.
nanny
Le démon d'analyse nanny est démarré
sur le routeur LVS actif. À travers ce
démon, le routeur LVS actif détermine
l'état de fonctionnement de chaque
serveur réel et, éventuellement, analyse
sa charge de travail. Un processus
séparé est démarré pour chaque service
défini sur chaque serveur réel.
lvs.cf
Il s'agit du fichier de configuration LVS. Le
chemin d'accès complet pour le fichier
est /etc/sysconfig/ha/lvs.cf.
Directement ou indirectement, tous les
démons obtiennent leurs informations de
configuration à partir de ce fichier.
Piranha Configuration T ool
Il s'agit de l'outil Web pour analyser,
configurer et administrer LVS. Il s'agit de
l'outil par défaut pour maintenir le fichier
de configuration LVS
/etc/sysconfig/ha/lvs.cf.
send_arp
Ce programme envoie les diffusions ARP
lorsque l'adresse IP flottante change d'un
nœud à un autre durant le failover.
qdisk
Un démon de quorum basé sur les
disques pour CMAN / Linux-Cluster.
m kqdisk
Utilitaire pour le disque quorum du
cluster.
qdiskd
Démon pour le disque quorum du cluster.
2.2. Pages de manuel
Cette section répertorie les pages de manuel qui sont pertinentes à Red Hat Cluster Suite, comme une
ressource supplémentaire.
Infrastructure de cluster
ccs_tool (8) - L'outil utilisé pour effectuer des mises à jour en ligne de fichiers de configuration
CSS
ccs_test (8) - L'outil de diagnostique pour un système de configuration du cluster en cours
d'exécution
57
ccsd (8) - Le démon utilisé pour accéder aux fichiers de configuration du cluster CCS
ccs (7) - Système de configuration du cluster
cman_tool (8) - Outil de gestion du cluster
cluster.conf [cluster] (5) - Le fichier de configuration pour les produits du cluster
qdisk (5) - Un démon de quorum basé sur les disques pour CMAN / Linux-Cluster
mkqdisk (8) - Utilitaire pour le disque quorum du cluster
qdiskd (8) - Démon pour le disque quorum du cluster
fence_ack_manual (8) - Programme exécuté par un opérateur dans le cadre d'un fence d'E/S
manuel
fence_apc (8) - Agent fence d'E/S pour APC MasterSwitch
fence_bladecenter (8) - Agent fence d'E/S pour IBM Bladecenter
fence_brocade (8) - Agent fence d'E/S pour les commutateurs Brocade FC
fence_bullpap (8) - Agent fence d'E/S pour l'architecture Bull FAME contrôlée par une console de
gestion PAP
fence_drac (8) - Agent fence pour la carte d'accès à distance Dell
fence_egenera (8) - Agent fence d'E/S pour le BladeFrame Egenera
fence_gnbd (8) - Agent fence d'E/S pour les clusters GFS basés sur GNBD
fence_ilo (8) - Agent fence d'E/S pour la carte HP Integrated Lights Out
fence_ipmilan (8) - Agent fence d'E/S pour les machines contrôlées par IPMI à travers un LAN
fence_manual (8) - programme exécuté par fenced dans le cadre du fence d'E/S manuel.
fence_mcdata (8) - Agent fence d'E/S pour les commutateurs McData FC
fence_node (8) - Un programme qui effectue des opérations fence d'E/S sur un seul noeud
fence_rib (8) - I/O Agent fence pour la carte Compaq Remote Insight Lights Out
fence_rsa (8) - I/O Agent fence d'E/S pour IBM RSA II
fence_sanbox2 (8) - Agent fence d'E/S pour les commutateurs QLogic SANBox2 FC
fence_scsi (8) - Agent fence d'E/S pour les réservations SCSI persistantes
fence_tool (8) - Un programme pour joindre et quitter le domaine fence.
fence_vixel (8) - Agent fence d'E/S pour les commutateurs Vixel FC
fence_wti (8) - Agent fence d'E/S pour le commutateur WT I Network Power
fence_xvm (8) - Agent fence d'E/S pour les machines virtuelles Xen
fence_xvmd (8) - Agent hôte fence d'E/S pour les machines virtuelles Xen.
fenced (8) - Le démon fence d'E/S
Gestion des services à haute disponibilité
clusvcadm (8) - Utilitaire d'administration des services utilisateur du cluster
clustat (8) - Utilitaire de statut du cluster
Clurgmgrd [clurgmgrd] (8) - Démon du gestionnaire de groupes de ressources (service cluster)
clurmtabd (8) - Démon de la table de montage distante NFS du cluster
GFS
gfs_fsck (8) - Vérificateur de système de fichiers GFS hors ligne
gfs_grow (8) - Agrandit un système de fichiers GFS
gfs_jadd (8) - Ajoute des fichiers journaux à un système de fichiers.
gfs_mount (8) - Options de montage GFS
gfs_quota (8) - Manipule les quotas des disques GFS
gfs_tool (8) - interface pour les appels gfs ioctl
58
Gestionnaire de volumes logiques du cluster
clvmd (8) - Démon LVM du cluster
lvm (8) - Outils LVM2
lvm.conf [lvm] (5) - Fichier de configuration pour LVM2
lvmchange (8) - Change les attributs du gestionnaire de volumes logiques
pvcreate (8) - Initialise un disque ou une partition pour utiliser avec LVM
lvs (8) - Reporte des informations à propos de volumes logiques
Périphérique bloc de réseau global
gnbd_export (8) - L'interface pour exporter les GNBD
gnbd_import (8) - Manipule les périphériques blocs GNBD sur un client
gnbd_serv (8) - Démon serveur gnbd
LVS
pulse (8) - Démon émettant des signaux ("heartbeat") afin d'analyser le bon fonctionnement des
noeuds du cluster.
lvs.cf [lvs] (5) - fichier de configuration pour lvs
lvscan (8) - Scanne (tous les disques) pour les volumes logiques
lvsd (8) - Démon pour contrôler les services Red Hat de mise en cluster
ipvsadm (8) - Administration du serveur virtuel Linux
ipvsadm-restore (8) - Restaure le tableau IPVS à partir de stdin
ipvsadm-save (8) - Enregistre le tableau IPVS vers stdout
nanny (8) - Outil pour l'analyse du statut des services du cluster
send_arp (8) - Outil pour informer le réseau d'une nouvelle correspondance adresse IP/adresse
MAC
2.3. Matériel compatible
Pour obtenir des informations à propos du matériel compatible avec les composants Red Hat Cluster
Suite (par exemple les périphériques fence supportés, les périphériques de stockage et les
commutateurs Fibre Channel), reportez-vous aux instructions de configuration du matériel à l'adresse
suivante : http://www.redhat.com/cluster_suite/hardware/.
59
Historique de révision
Version 3-7.4 00
Rebuild with publican 4.0.0
2013-10-31
Rüdiger Landmann
Version 3-7
Rebuild for Publican 3.0
2012-07-18
Anthony T owns
Version 1.0-0
T ue Jan 20 2008
Consolidation de points de notes de sortie
Paul Kennedy
Index
C
cluster
- displaying status, Cluster Status T ool
cluster administration
- displaying cluster and service status, Cluster Status T ool
cluster component compatible hardware, Matériel compatible
cluster component man pages, Pages de manuel
cluster components table, Composants de cluster
Cluster Configuration T ool
- accessing, Cluster Configuration T ool
cluster service
- displaying status, Cluster Status T ool
command line tools table, Outils d'administration en ligne de commande
compatible hardware
- cluster components, Matériel compatible
Conga
- overview, Conga
Conga overview, Conga
F
feedback, Commentaire
I
60
Historique de révision
introduction, Introduction
- other Red Hat Enterprise Linux documents, Introduction
L
LVS
- direct routing
- requirements, hardware, Routage direct
- requirements, network, Routage direct
- requirements, software, Routage direct
- routing methods
- NAT , Méthodes de routage
- three tiered
- high-availability cluster, T hree-T ier LVS T opology
M
man pages
- cluster components, Pages de manuel
N
NAT
- routing methods, LVS, Méthodes de routage
network address translation (voir NAT )
O
overview
- economy, Red Hat GFS
- performance, Red Hat GFS
- scalability, Red Hat GFS
P
Piranha Configuration T ool
- CONT ROL/MONIT ORING, CONT ROL/MONIT ORING
- EDIT MONIT ORING SCRIPT S Subsection, EDIT MONIT ORING SCRIPT S Subsection
- GLOBAL SET T INGS, GLOBAL SET T INGS
- login panel, Interface utilisateur graphique d'administration du serveur virtuel Linux
- necessary software, Interface utilisateur graphique d'administration du serveur virtuel
Linux
- REAL SERVER subsection, La sous-section REAL SERVER
61
- REDUNDANCY, REDUNDANCY
- VIRT UAL SERVER subsection, VIRT UAL SERVERS
- Firewall Mark , La sous-section VIRT UAL SERVER
- Persistence , La sous-section VIRT UAL SERVER
- Scheduling , La sous-section VIRT UAL SERVER
- Virtual IP Address , La sous-section VIRT UAL SERVER
- VIRT UAL SERVERS, VIRT UAL SERVERS
R
Red Hat Cluster Suite
- components, Composants de cluster
T
table
- cluster components, Composants de cluster
- command line tools, Outils d'administration en ligne de commande
62

Red Hat Enterprise Linux 5 Aperçu général de la Cluster Suite

Transcription

Documents pareils

SPRI ALF 2009 ( Cast.-Fr. ).indd

cluster logistique - Logistics Cluster

Lors de la configuration du cluster en DRS, j`obtiens l`erreur

Participant(e)s

Coordination Air Transport Road Transport Rail transport Sea

Open Source Job Scheduler

Télécharger l`article au format PDF