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

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.

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:

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.