2.2. Apprendre à configurer le basculement

PDF

La procédure suivante constitue une introduction à la création d'une grappe Pacemaker exécutant un service qui basculera d'un nœud à l'autre lorsque le nœud sur lequel le service s'exécute devient indisponible. En suivant cette procédure, vous apprendrez à créer un service dans une grappe à deux nœuds et vous pourrez ensuite observer ce qui arrive à ce service lorsqu'il tombe en panne sur le nœud sur lequel il s'exécute.

Cet exemple de procédure configure un cluster Pacemaker à deux nœuds exécutant un serveur HTTP Apache. Vous pouvez ensuite arrêter le service Apache sur un nœud pour voir comment le service reste disponible.

Dans cet exemple :

Les nœuds sont z1.example.com et z2.example.com.
L'adresse IP flottante est 192.168.122.120.

Conditions préalables

Deux nœuds fonctionnant sous RHEL 9 et pouvant communiquer l'un avec l'autre
Une adresse IP flottante qui réside sur le même réseau que l'une des adresses IP attribuées de manière statique au nœud
Le nom du nœud sur lequel vous travaillez se trouve dans votre fichier /etc/hosts

Procédure

Sur les deux nœuds, installez les paquetages logiciels Red Hat High Availability Add-On à partir du canal High Availability, puis démarrez et activez le service pcsd.
```
# dnf install pcs pacemaker fence-agents-all
...
# systemctl start pcsd.service
# systemctl enable pcsd.service
```
Si vous exécutez le démon firewalld, activez sur les deux nœuds les ports requis par le Red Hat High Availability Add-On.
```
# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --reload
```
Sur les deux nœuds du cluster, définissez un mot de passe pour l'utilisateur hacluster.
```
# passwd hacluster
```
Authentifiez l'utilisateur hacluster pour chaque nœud du cluster sur le nœud à partir duquel vous exécuterez les commandes pcs.
```
# pcs host auth z1.example.com z2.example.com
```
Créez un cluster nommé my_cluster avec les deux nœuds comme membres du cluster. Cette commande crée et démarre la grappe en une seule étape. Vous ne devez l'exécuter qu'à partir d'un seul nœud de la grappe, car les commandes de configuration de pcs s'appliquent à l'ensemble de la grappe.
Sur un nœud de la grappe, exécutez la commande suivante.
```
# pcs cluster setup my_cluster --start z1.example.com z2.example.com
```
Un cluster Red Hat High Availability nécessite que vous configuriez la clôture pour le cluster. Les raisons de cette exigence sont décrites dans la section Clôture dans un cluster Red Hat High Availability. Pour cette introduction, cependant, afin de montrer uniquement comment le basculement fonctionne dans cette configuration, désactivez la clôture en définissant l'option stonith-enabled cluster sur false
Avertissement
L'utilisation de stonith-enabled=false est totalement inappropriée pour un cluster de production. Elle indique au cluster de simplement prétendre que les nœuds défaillants sont clôturés en toute sécurité.
```
# pcs property set stonith-enabled=false
```

Après avoir créé une grappe et désactivé la clôture, vérifiez l'état de la grappe.

Note

Lorsque vous exécutez la commande pcs cluster status, il se peut que la sortie diffère légèrement des exemples au fur et à mesure que les composants du système démarrent.

# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
 Last updated: Thu Oct 11 16:11:18 2018
 Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z1.example.com
 2 nodes configured
 0 resources configured

PCSD Status:
  z1.example.com: Online
  z2.example.com: Online

Sur les deux nœuds, configurez un navigateur web et créez une page web pour afficher un simple message texte. Si vous exécutez le démon firewalld, activez les ports requis par httpd.
Note
N'utilisez pas systemctl enable pour permettre aux services qui seront gérés par le cluster de démarrer au démarrage du système.
```
# dnf install -y httpd wget
...
# firewall-cmd --permanent --add-service=http
# firewall-cmd --reload

# cat <<-END >/var/www/html/index.html
<html>
<body>My Test Site - $(hostname)</body>
</html>
END
```
Pour que l'agent de ressources Apache puisse obtenir l'état d'Apache, sur chaque nœud du cluster, créez l'ajout suivant à la configuration existante pour activer l'URL du serveur d'état.
```
# cat <<-END > /etc/httpd/conf.d/status.conf
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
END
```
Créez les ressources IPaddr2 et apache pour le cluster à gérer. La ressource "IPaddr2" est une adresse IP flottante qui ne doit pas être déjà associée à un nœud physique. Si le périphérique NIC de la ressource "IPaddr2" n'est pas spécifié, l'adresse IP flottante doit résider sur le même réseau que l'adresse IP statiquement assignée utilisée par le nœud.
Vous pouvez afficher une liste de tous les types de ressources disponibles à l'aide de la commande pcs resource list. Vous pouvez utiliser la commande pcs resource describe resourcetype pour afficher les paramètres que vous pouvez définir pour le type de ressource spécifié. Par exemple, la commande suivante affiche les paramètres que vous pouvez définir pour une ressource de type apache:
```
# pcs resource describe apache
...
```
Dans cet exemple, la ressource adresse IP et la ressource apache sont toutes deux configurées comme faisant partie d'un groupe nommé apachegroup, ce qui garantit que les ressources sont conservées ensemble pour fonctionner sur le même nœud.
Exécutez les commandes suivantes à partir d'un nœud de la grappe :
```
# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.120 --group apachegroup

# pcs resource create WebSite ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" --group apachegroup

# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
Last updated: Fri Oct 12 09:54:33 2018
Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com

2 nodes configured
2 resources configured

Online: [ z1.example.com z2.example.com ]

Full list of resources:

Resource Group: apachegroup
    ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
    WebSite    (ocf::heartbeat:apache):        Started z1.example.com

PCSD Status:
  z1.example.com: Online
  z2.example.com: Online
...
```
Notez que dans cet exemple, le service apachegroup est exécuté sur le nœud z1.example.com.
Accédez au site web que vous avez créé, arrêtez le service sur le nœud sur lequel il s'exécute et notez comment le service bascule sur le deuxième nœud.
1. Dirigez un navigateur vers le site web que vous avez créé à l'aide de l'adresse IP flottante que vous avez configurée. Celui-ci doit afficher le message textuel que vous avez défini, en indiquant le nom du nœud sur lequel le site web est exécuté.
2. Arrêtez le service web apache. L'utilisation de killall -9 simule une panne au niveau de l'application.
```
# killall -9 httpd
```
  Vérifiez l'état de la grappe. Vous devriez constater que l'arrêt du service web a provoqué un échec, mais que le logiciel du cluster a redémarré le service sur le nœud sur lequel il s'exécutait et que vous devriez toujours pouvoir accéder au navigateur web.
```
# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
Last updated: Fri Oct 12 09:54:33 2018
Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com

2 nodes configured
2 resources configured

Online: [ z1.example.com z2.example.com ]

Full list of resources:

Resource Group: apachegroup
    ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
    WebSite    (ocf::heartbeat:apache):        Started z1.example.com

Failed Resource Actions:
* WebSite_monitor_60000 on z1.example.com 'not running' (7): call=31, status=complete, exitreason='none',
    last-rc-change='Fri Feb  5 21:01:41 2016', queued=0ms, exec=0ms
```
  Effacez l'état d'échec une fois que le service est à nouveau opérationnel.
```
# pcs resource cleanup WebSite
```
3. Mettez le nœud sur lequel le service s'exécute en mode veille. Notez que, puisque nous avons désactivé la clôture, nous ne pouvons pas simuler efficacement une défaillance au niveau du nœud (comme le retrait d'un câble d'alimentation), car la clôture est nécessaire pour que le cluster se rétablisse dans de telles situations.
```
# pcs node standby z1.example.com
```
4. Vérifiez l'état de la grappe et notez où le service s'exécute maintenant.
```
# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
Last updated: Fri Oct 12 09:54:33 2018
Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com

2 nodes configured
2 resources configured

Node z1.example.com: standby
Online: [ z2.example.com ]

Full list of resources:

Resource Group: apachegroup
    ClusterIP  (ocf::heartbeat:IPaddr2):       Started z2.example.com
    WebSite    (ocf::heartbeat:apache):        Started z2.example.com
```
5. Accédez au site web. Il ne devrait pas y avoir de perte de service, mais le message d'affichage devrait indiquer le nœud sur lequel le service est maintenant exécuté.
Pour restaurer les services de cluster sur le premier nœud, sortez le nœud du mode veille. Cela ne ramènera pas nécessairement le service sur ce nœud.
```
# pcs node unstandby z1.example.com
```
Pour le nettoyage final, arrêtez les services de cluster sur les deux nœuds.
```
# pcs cluster stop --all
```

2.2. Apprendre à configurer le basculement

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links