Rechercher

1.4. Gestion des services à haute disponibilité

download PDF
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.
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.