Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tutoriel:pacemaker_configuration_ip_virtuelle_plus_script_lsb [Le 13/06/2012, 12:04] – [Cluster de deux machines ip virtuelle + supervision d'un service] Miam Miam
+++ tutoriel:pacemaker_configuration_ip_virtuelle_plus_script_lsb [Le 11/09/2022, 12:24] (Version actuelle) – Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892) moths-art
@@ Ligne 5: / Ligne 5: @@
-Ce tutoriel est une sous partie de la documentation pacemaker. Il décrit les différentes étapes de configuration du cluster par l'intermédiaire de la commande crm. Je vous conseille néanmoins de configurer les ressources avec l'interface java de Linbit.
+Ce tutoriel est une sous-partie de la documentation pacemaker. Il décrit les différentes étapes de configuration du cluster par l'intermédiaire de la commande crm. Je vous conseille néanmoins de configurer les ressources avec l'interface java de Linbit.
 Le but de cette configuration est de créer un cluster de serveur web (ou de reverse proxy) de deux machines. Une adresse virtuelle est partagée entre les deux machines, lorsque l'une d'entre elle est hors ligne l'autre machine peut prendre le relai automatiquement.
@@ Ligne 19: / Ligne 19: @@
 |              ^ Nom de poste                  ^ Adresse ip          ^
 ^ pc 1      | machine1            | 192.168.1.101    |
-^ pc 2      | machine2 |             192.168.1.102     |
+^ pc 2      | machine2            | 192.168.1.102    |
 ===== Pré-requis =====
   * Bien connaître le principe de fonctionnement de [[:pacemaker]].
-  * Comprendre le principe de norme LSB pour les scripts d'initialisation.
+  * Comprendre le principe de la norme LSB pour les scripts d'initialisation.
 <note>
-Les scripts d'initialisation sont ceux disponible dans le répertoire /etc/init.d/. Pacemaker va les utiliser pour démarrer, arrêter et superviser l'état du service. C'est pourquoi ces scripts doivent respecter les normes lsb. Pacemaker a par exemple besoin que les scripts possèdent un argument status. Pour plus d'informations visitez cette [[http://wiki.debian.org/LSBInitScripts|page]]
+Les scripts d'initialisation sont ceux disponibles dans le répertoire /etc/init.d/. Pacemaker va les utiliser pour démarrer, arrêter et superviser l'état du service. C'est pourquoi ces scripts doivent respecter les normes lsb. Pacemaker a par exemple besoin que les scripts possèdent un argument status. Pour plus d'informations visitez cette [[https://wiki.debian.org/LSBInitScripts|page]]
 </note>
   * Avoir effectué le tutoriel officiel en anglais est une bonne chose. [[http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html|lien]]
   * Ne pas avoir peur de lire la documentation officielle de pacemaker qui se trouve [[http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/index.html|ici]].
@@ Ligne 44: / Ligne 44: @@
 Premierement nous allons désactiver deux fonctionnalités inutile pour notre cluster
   * mode stonith "shot the other node in the head" permet lorsqu'une machine n'est plus joignable d'être sur que cette machine soit bien hors ligne
@@ Ligne 58: / Ligne 58: @@
   property no-quorum-policy=ignore
-Supervision d'un service grâce à son script situé dans le dossier /etc/init.d. Pacemaker s'assurera qu'il est bien lancé toutes les 5 secondes.
 ==== Paramétrage du service nginx ====
@@ Ligne 64: / Ligne 64: @@
 Avant toute chose pensez à désactiver le démarrage automatique du démon avec la commande ci dessous
   sudo update-rc.d -f nginx remove
 Ensuite nous allons indiquer à pacemaker de superviser le processus nginx. Pour cela il est nécessaire que le logiciel possède un script de démarrage et d'arrêt dans le répertoire /etc/init.d. Ce script doit en outre respecter les normes LSB (si il est est déjà présent il doit sûrement les respecter). A l'avenir c'est pacemaker qui démarrera nginx par intermédiaire de ce script.
-Instruction permettant indiquant pacemaker de superviser un programme par l'intermédiaire de son script systemV (init script)
+Instruction permettant à pacemaker de superviser un programme par l'intermédiaire de son script systemV (init script)
 Syntaxe de base
@@ Ligne 76: / Ligne 76: @@
   primitive <nom de la ressource (ce que vous voulez)> lsb::<nom du démon> op monitor interval=5s
 Dans notre cas
   primitive reverse-proxy lsb::nginx op monitor interval=5s
@@ Ligne 86: / Ligne 86: @@
   clone <nom de la ressource> <nom de la ressource à cloner>
 Dans notre cas
   clone clone_reverse_proxy reverse-proxy
@@ Ligne 100: / Ligne 100: @@
 explications:
 ^ Options         ^ explications           ^
 | target-role   | started ou stopped l'état dans lequel pacemaker doit maintenir la ressource     |
 | migration-threshold   | nombre maximal d'échec de la ressource, après lesquels la machine est déclarée inéligible pour recevoir la ressource     |
 | resource-stickiness   | Ce paramètre est utile lorsque l'on définit une règle "location" indiquant la machine élue par défaut pour héberger la ressource. Nous ferons une configuration de ce type plus tard. Ce paramètre empêche la ressource de retourner sur la machine élue par défaut après que celle ci est défaillit et soit revenue en ligne. La ressource devra être migrée manuellement.  La valeure numérique attribuée à ce paramètre doit être supérieure à celle attribuée dans la règle "location".   |
 Dans notre cas
 <code>
@@ Ligne 118: / Ligne 118: @@
 Par défaut pacemaker répartie les ressources entre les membres du cluster. Bien qu'ici une des ressources soit clonée il est préférable de créér un lien entre les deux ressources  //clone_reverse_proxy// et //ip_virtuelle//
 Syntaxe de base
   colocation link-ressources INFINITY: <nom de la deuxième ressource>  <nom de la première ressource>
 Dans notre cas
   colocation link-ressources INFINITY: ip_virtuelle clone_reverse_proxy
@@ Ligne 128: / Ligne 128: @@
 Il est aussi nécessaire d'établir un ordre de démarrage entre les ressources. En effet l'ip virtuelle ne doit être activée que si le démon nginx est lancée
 Syntaxe de base
   order <nom de la ressource> mandatory: <première ressource à lancer>  <deuxième ressource>
 Dans notre cas
   order demon_before mandatory: clone_reverse_proxy  ip_virtuelle
@@ Ligne 142: / Ligne 142: @@
   location <nom ressource> <nom de la ressource> <score>: <nom du poste>
 Dans notre cas
   location node-master ip_virtuelle 50: machine1
@@ Ligne 179: / Ligne 179: @@
   kill <numéro processus>
 Vous devriez voir que le compteur d'échec a été incrémenté
   Online: [ machine1 machine2 ]
@@ Ligne 186: / Ligne 186: @@
   ip_virtuelle	(ocf::heartbeat:IPaddr2):	Started machine1
   Migration summary:
   * Node machine2:
   * Node machine1:
      reverse-proxy:0: migration-threshold=1000000 fail-count=1
-et si vous effectué cette commande
+et si vous effectuez cette commande
   sudo /etc/init.d/nginx status
 Elle devrait vous retourner ce retour
   nginx is running
-Le processus a bien été redémarré après qu'il a été tué, Il n'y a pas eu de migration de l'adresse ip.
+Le processus a bien été redémarré après qu'il a été tué. Il n'y a pas eu de migration de l'adresse ip.
 ==== Blocage du redémarrage du serveur nginx ====
@@ Ligne 208: / Ligne 208: @@
   plop !
-tuer à nouveau le processus du démon nginx
+Tuer à nouveau le processus du démon nginx
 Vous devriez obtenir ce résultat
@@ Ligne 218: / Ligne 218: @@
   ip_virtuelle	(ocf::heartbeat:IPaddr2):	Started machine2
   Migration summary:
   * Node machine2:
   * Node machine1:
      reverse-proxy:0: migration-threshold=1000000 fail-count=1000000
-On peut voir que l'adresse ip virtuelle a été migrée vers la machine 2 et que le compteur d'échec à été fixé à sa valeur maximale.
+On peut voir que l'adresse ip virtuelle a été migrée vers la machine 2 et que le compteur d'échec a été fixé à sa valeur maximale.
 ===== Voir aussi =====

Différences

Outils pour utilisateurs

Outils du site

Outils de la page

Divers