Rechercher

Aperçu général de la Cluster Suite

download PDF
Red Hat Enterprise Linux 5

Red Hat Cluster Suite de Red Hat Enterprise Linux 5

Édition 3

Logo

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

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 :
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 HTML, 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. 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 Documentation-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.

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 :

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 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).

Note

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 clvmd daemon. For further information, refer to Section 1.6, « Gestionnaire de volumes logiques du cluster ».
  • 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.
Red Hat Cluster Suite Introduction

Figure 1.1. Red Hat Cluster Suite Introduction

Note

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. 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 "split-brain" 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.

Note

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.
CMAN/DLM Overview

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, 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. The 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.
Power Fencing Example

Figure 1.3. Power Fencing Example

Fibre Channel Switch 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.
The 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 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 »).
Fencing a Node with Dual Power Supplies

Figure 1.5. Fencing a Node with Dual Power Supplies

Fencing a Node with Dual Fibre Channel Connections

Figure 1.6. Fencing a Node with Dual Fibre Channel Connections

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

The 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 »).
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 »).
Accessing Configuration Information

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, rgmanager, 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 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 »).

Note

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.
Les domaines failover

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. The 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".
Web Server Cluster Service Example

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 gfs-content-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 à 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 :

Note

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. The 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.
GFS with a SAN

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.
GFS and GNBD with a SAN

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 failover can be fully automated with Red Hat Cluster Suite.
GFS et GNBD avec un stockage directement connecté

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.
The key component in CLVM is clvmd. clvmd is a daemon that provides clustering extensions to the standard LVM2 tool set and allows LVM2 commands to manage shared storage. clvmd 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 »).

Note

Le stockage partagé utilisé dans Red Hat Cluster Suite exige que vous exécutiez le démon du gestionnaire de volume logique du cluster (clvmd) or bien lesagents High Availability Logical Volume Management (HA-LVM). Si vous n'êtes pas en mesure d'utiliser le démon clvmd, ni HA-LVM 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.

Note

L'utilisation de CLVM requiert de mineurs changements dans /etc/lvm/lvm.conf afin de gérer le verrouillage à l'échelle du cluster.
CLVM Overview

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.
LVM Graphical User Interface

Figure 1.15. LVM Graphical User Interface

Conga LVM Graphical User Interface

Figure 1.16. Conga LVM Graphical User Interface

Creating Logical Volumes

Figure 1.17. Creating Logical Volumes

1.7. Périphérique bloc du réseau global (GNBD)

GNBD fournit un accès aux périphériques blocs à Red Hat GFS à travers TCP/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.
Aperçu de GNBD

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.
Components of a Running LVS Cluster

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 à 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. Toutefois, 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, « Two-Tier LVS Topology » shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The 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, « Two-Tier LVS Topology », 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. The 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.
Two-Tier LVS Topology

Figure 1.20. Two-Tier LVS Topology

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 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 HTTP peut être traité sur eth0:1 et le trafic FTP 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.
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 HTTPS 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.
The simple, two-tier configuration in Figure 1.20, « Two-Tier LVS Topology » 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, « Three-Tier LVS Topology » 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.
Three-Tier LVS Topology

Figure 1.21. Three-Tier LVS Topology

Cette topologie est bien adaptée aux serveurs FTP 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 Translation) 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.
LVS Implemented with NAT Routing

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. Tous 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 paquets entrants.
LVS Implemented with Direct Routing

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. The 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 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 FTP. 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 FTP. 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 HTTP sur le port 80 et sécuriser les connexions HTTPS 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. Toutefois, 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 :

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. Toutefois, 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 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.
L'onglet homebase de luci

Figure 1.24. L'onglet homebase de luci

L'onglet cluster luci

Figure 1.25. L'onglet cluster luci

L'onglet storage de luci

Figure 1.26. L'onglet storage de luci

1.9.2. Interface graphique d'administration du cluster

This section provides an overview of the system-config-cluster cluster administration graphical user interface (GUI) available with Red Hat Cluster Suite. The 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é »). The GUI consists of two major functions: the Cluster Configuration Tool and the Cluster Status Tool. The Cluster Configuration Tool provides the capability to create, edit, and propagate the cluster configuration file (/etc/cluster/cluster.conf). The Cluster Status Tool provides the capability to manage high-availability services. The following sections summarize those functions.
1.9.2.1. Cluster Configuration Tool
You can access the Cluster Configuration Tool (Figure 1.27, « Cluster Configuration Tool ») through the Cluster Configuration tab in the Cluster Administration GUI.
Cluster Configuration Tool

Figure 1.27. Cluster Configuration Tool

L'Cluster Configuration Tool 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 This Node) pour chaque noeud.
  • Ressources gérées — Affiche les domaines failover, les ressources et les services.
    • Failover Domains — 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 Domains. En utilisant les boutons de configuration en bas du cadre de droite (sous Properties), vous pouvez créer des domaines failover (lorsque Failover Domains est sélectionné) ou modifier les propriétés d'un domaine failover (lorsqu'il est 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).

      Note

      L'Cluster Configuration Tool 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 Tool
You can access the Cluster Status Tool (Figure 1.28, « Cluster Status Tool ») through the Cluster Management tab in Cluster Administration GUI.
Cluster Status Tool

Figure 1.28. Cluster Status Tool

Les noeuds et services affichés dans l'Cluster Status Tool sont déterminés par le fichier de configuration du cluster (/etc/cluster/cluster.conf). Vous pouvez utiliser l'Cluster Status Tool 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. The command line tools are used by the Cluster Administration GUI and init scripts supplied by Red Hat. Tableau 1.1, « Outils en ligne de commande » summarizes the command line tools.
Tableau 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, reportez-vous à la page de manuel ccs_tool(8).
cman_tool — Outil de gestion du cluster Cluster Infrastructure cman_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 d'informations à propos de cet outil, reportez-vous à la page 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, reportez-vous à 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 d'informations à propos de cet outil, reportez-vous à la page 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 Tool. L'Piranha Configuration Tool 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 Tool, le service piranha-gui doit être en cours d'exécution sur le routeur LVS actif. Vous pouvez accéder à l'Piranha Configuration Tool localement ou à distance avec un navigateur Web. Localement, utilisez l'adresse suivante : http://localhost:3636. Pour accéder à l'Piranha Configuration Tool à distance, utilisez le nom de domaine ou l'adresse IP réelle suivi de :3636. Si vous accédez à l'Piranha Configuration Tool à distance, vous devez diposer d'une connexion ssh vers le routeur LVS actif en tant que super-utilisateur (root).
Starting the Piranha Configuration Tool causes the Piranha Configuration Tool welcome page to be displayed (refer to Figure 1.29, « The Welcome Panel »). Logging in to the welcome page provides access to the four main screens or panels: CONTROL/MONITORING, GLOBAL SETTINGS, REDUNDANCY, and VIRTUAL SERVERS. In addition, the VIRTUAL SERVERS panel contains four subsections. The CONTROL/MONITORING panel is the first panel displayed after you log in at the welcome screen.
The Welcome Panel

Figure 1.29. The Welcome Panel

Les sections suivantes fournissent une brève description des pages de configuration de l'Piranha Configuration Tool.

1.10.1. CONTROL/MONITORING

Le panneau CONTROL/MONITORING 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.
The CONTROL/MONITORING Panel

Figure 1.30. The CONTROL/MONITORING 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 CONTROL/MONITORING.
Update information 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 Tool.

1.10.2. GLOBAL SETTINGS

The GLOBAL SETTINGS panel is where the LVS administrator defines the networking details for the primary LVS router's public and private network interfaces.
The GLOBAL SETTINGS Panel

Figure 1.31. The GLOBAL SETTINGS Panel

The top half of this panel sets up the primary LVS router's public and private network interfaces.
Primary server public IP
L'adresse IP réelle routable publiquement pour le noeud LVS primaire.
Primary 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.
The 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 netmask
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".
The REDUNDANCY Panel

Figure 1.32. The REDUNDANCY Panel

Redundant server public IP
L'adresse IP réelle publique pour le routeur LVS de sauvegarde.
Redundant server private IP
The 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.
Assume 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

Le panneau VIRTUAL 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.
The VIRTUAL SERVERS Panel

Figure 1.33. The VIRTUAL SERVERS Panel

Chaque serveur affiché dans le panneau VIRTUAL 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 DELETE.
Pour activer ou désactiver un serveur virtuel à partir du tableau, sélectionnez le bouton radio correspondant et cliquez sur le bouton (DE)ACTIVATE.
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 VIRTUAL SERVER.
1.10.4.1. La sous-section VIRTUAL SERVER
The VIRTUAL SERVER subsection panel shown in Figure 1.34, « The VIRTUAL 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.
The VIRTUAL SERVERS Subsection

Figure 1.34. The VIRTUAL SERVERS Subsection

Name
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 HTTP.
Application port
Le numéro de port à travers lequel l'application service écoutera.
Protocol
Donne le choix entre UDP et TCP, dans un menu déroulant.
Virtual IP Address
The 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 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 Time
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 Timeout
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 monitoring tool
Le routeur LVS peut surveiller la charge des différents serveurs réels en utilisant rup ou ruptime. Si vous sélectionnez rup à partir du menu déroulant, chaque serveur réel doit exécuter le service rstatd. Si vous sélectionnez ruptime, 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.
The REAL SERVER Subsection

Figure 1.35. The REAL SERVER Subsection

Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figure 1.36, « The REAL SERVER Configuration Panel ».
The REAL SERVER Configuration Panel

Figure 1.36. The REAL SERVER Configuration Panel

Ce panneau est composé de trois zones de texte :
Name
Un nom descriptif pour le serveur réel.

Note

Ce nom ne correspond pas au nom d'hôte de la machine, saisissez donc un nom facile à identifier.
Address
The 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. The value can be arbitrary, but treat it as a ratio in relation to other real servers.
1.10.4.3. EDIT MONITORING SCRIPTS Subsection
Cliquez sur le lien MONITORING SCRIPTS en haut de la page. La sous-section EDIT MONITORING SCRIPTS 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.
The EDIT MONITORING SCRIPTS Subsection

Figure 1.37. The EDIT MONITORING SCRIPTS Subsection

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 HTTPS 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.

Note

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 HTTP. 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 serveur virtuel est un service configuré pour écouter sur une adresse IP virtuelle spécifique.

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 :

2.1. Composants de cluster

Tableau 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 Tool system-config-cluster Commande utilisée pour gérer la configuration du cluster dans un mode graphique.
Gestionnaire de volumes logiques en cluster (CLVM) clvmd 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.
Système de configuration du cluster (CCS) 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.
Gestionnaire de cluster (CMAN) cman.ko Le module noyau pour CMAN.
cman_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.
dlm_controld Démon démarré par le script init de cman afin de gérer dlm dans le noyau ; il n'est pas encore utilisé par l'utilisateur.
gfs_controld Démon démarré par le script init de cman 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 cman_tool services fournissait dans RHEL 4.
groupd Démon démarré par le script init de cman afin de servir d'interface entre openais/cman et dlm_controld/gfs_controld/fenced; il n'est pas encore utilisé par l'utilisateur.
libcman.so.<version number> Bibliothèque pour les programmes ayant besoin d'interagir avec cman.ko.
Gestionnaire du groupe de ressources (rgmanager) 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.
clurgmgrd 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.
clurmtabd Démon utilisé pour traiter des tables de montage NFS clusterisées.
Fence fence_apc Agent fence pour le commutateur de courant APC.
fence_bladecenter Agent fence pour IBM Bladecenters avec l'interface Telnet.
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_ipmilan 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 WTI.
fence_brocade Agent fence pour le commutateur Brocade Fibre Channel
fence_mcdata 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_manual Agent fence pour une interaction manuelle. REMARQUE : ce composant n'est pas supporté dans les environnements de production.
fence_ack_manual Interface utilisateur pour l'agent fence_manual.
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_xvmd 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.
gfs_mkfs 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.
mount.gfs Assistant de montage appelé par mount(8); il n'est pas utilisé par l'utilisateur.
GNBD 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_import 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.
LVS pulse This 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 user-configurable 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.
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 Tool 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.
Disque quorum qdisk Un démon de quorum basé sur les disques pour CMAN / Linux-Cluster.
mkqdisk 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
    • 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 WTI 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
  • 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/.

Annexe A. Historique de révision

Historique des versions
Version 3-7.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 3-72012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 1.0-0Tue Jan 20 2008Paul Kennedy
Consolidation de points de notes de sortie

Index

C

cluster
displaying status, Cluster Status Tool
cluster administration
displaying cluster and service status, Cluster Status Tool
cluster component compatible hardware, Matériel compatible
cluster component man pages, Pages de manuel
cluster components table, Composants de cluster
Cluster Configuration Tool
accessing, Cluster Configuration Tool
cluster service
displaying status, Cluster Status Tool
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

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, Three-Tier LVS Topology

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 Tool
CONTROL/MONITORING, CONTROL/MONITORING
EDIT MONITORING SCRIPTS Subsection, EDIT MONITORING SCRIPTS Subsection
GLOBAL SETTINGS, GLOBAL SETTINGS
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
REDUNDANCY, REDUNDANCY
VIRTUAL SERVER subsection, VIRTUAL SERVERS
Firewall Mark , La sous-section VIRTUAL SERVER
Persistence , La sous-section VIRTUAL SERVER
Scheduling , La sous-section VIRTUAL SERVER
Virtual IP Address , La sous-section VIRTUAL SERVER
VIRTUAL SERVERS, VIRTUAL 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

Note légale

Copyright © 2009 Red Hat, Inc.
This 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, OpenShift, 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 Torvalds 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.
The 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.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.