Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
tutoriel:pacemaker_configuration_ip_virtuelle_plus_script_lsb [Le 02/07/2010, 20:42] – Miam Miam | tutoriel:pacemaker_configuration_ip_virtuelle_plus_script_lsb [Le 07/03/2020, 17:20] (Version actuelle) – [Cluster de deux machines ip virtuelle + supervision d'un service] 5.51.84.115 | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | {{tag> | ||
+ | ---- | ||
+ | |||
+ | ====== Cluster de deux machines ip virtuelle + supervision d'un service====== | ||
+ | |||
+ | |||
+ | Ce tutoriel est une sous-partie de la documentation pacemaker. Il décrit les différentes étapes de configuration du cluster par l' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | Détail des étapes de la configuration: | ||
+ | |||
+ | - Adresse ip virtuelle partagée entre les deux membres du cluster ici 192.168.1.100 | ||
+ | - Lancement, arrêt et supervision d'un service par l' | ||
+ | - Clonage du service, nginx sera démarré sur les deux machines | ||
+ | - Ordonnancement des ressources le service, nginx devra être démarré pour que l' | ||
+ | |||
+ | |||
+ | | ^ Nom de poste ^ Adresse ip ^ | ||
+ | ^ pc 1 | machine1 | ||
+ | ^ pc 2 | machine2 | ||
+ | |||
+ | ===== Pré-requis ===== | ||
+ | |||
+ | * Bien connaître le principe de fonctionnement de [[: | ||
+ | * Comprendre le principe de la norme LSB pour les scripts d' | ||
+ | | ||
+ | |||
+ | < | ||
+ | Les scripts d' | ||
+ | </ | ||
+ | * Avoir effectué le tutoriel officiel en anglais est une bonne chose. [[http:// | ||
+ | * Ne pas avoir peur de lire la documentation officielle de pacemaker qui se trouve [[http:// | ||
+ | |||
+ | ===== Configuration ===== | ||
+ | |||
+ | |||
+ | |||
+ | Entrer dans le mode de configuration du cluster | ||
+ | |||
+ | sudo crm configure | ||
+ | | ||
+ | ==== Paramétrage des options générales ==== | ||
+ | |||
+ | | ||
+ | Premierement nous allons désactiver deux fonctionnalités inutile pour notre cluster | ||
+ | |||
+ | * mode stonith "shot the other node in the head" permet lorsqu' | ||
+ | * quorum indique le nombre minimal de membres pour prendre une décision. Ce paramètre est utile pour les cluster de plus de deux machines | ||
+ | |||
+ | |||
+ | Désactivation du mode stonith | ||
+ | |||
+ | property stonith-enabled=false | ||
+ | |||
+ | Désctivation du paramètre quorum | ||
+ | |||
+ | property no-quorum-policy=ignore | ||
+ | |||
+ | |||
+ | |||
+ | ==== Paramétrage du service nginx ==== | ||
+ | |||
+ | |||
+ | |||
+ | 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' | ||
+ | |||
+ | Instruction permettant à pacemaker de superviser un programme par l' | ||
+ | |||
+ | Syntaxe de base | ||
+ | |||
+ | primitive <nom de la ressource (ce que vous voulez)> lsb::< | ||
+ | |||
+ | Dans notre cas | ||
+ | |||
+ | primitive reverse-proxy lsb::nginx op monitor interval=5s | ||
+ | | ||
+ | Clonage de la ressource pour que le démon nginx soit démarré sur les deux machines en même temps. Cela permet une migration plus rapide. Pacemaker n' | ||
+ | |||
+ | Syntaxe de base | ||
+ | |||
+ | clone <nom de la ressource> | ||
+ | |||
+ | Dans notre cas | ||
+ | | ||
+ | clone clone_reverse_proxy reverse-proxy | ||
+ | | ||
+ | ==== Paramétrage de l'ip virtuelle ==== | ||
+ | |||
+ | | ||
+ | Création d'une ip virtuelle partagée entre les deux membres du cluster | ||
+ | < | ||
+ | primitive <nom de la ressource> | ||
+ | op monitor interval="< | ||
+ | </ | ||
+ | explications: | ||
+ | |||
+ | ^ Options | ||
+ | | target-role | ||
+ | | migration-threshold | ||
+ | | resource-stickiness | ||
+ | |||
+ | |||
+ | |||
+ | Dans notre cas | ||
+ | |||
+ | < | ||
+ | primitive ip_virtuelle ocf: | ||
+ | op monitor interval=" | ||
+ | </ | ||
+ | ==== Lien entre les ressources ==== | ||
+ | |||
+ | |||
+ | 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 | ||
+ | |||
+ | Syntaxe de base | ||
+ | |||
+ | colocation link-ressources INFINITY: <nom de la deuxième ressource> | ||
+ | | ||
+ | Dans notre cas | ||
+ | |||
+ | colocation link-ressources INFINITY: ip_virtuelle clone_reverse_proxy | ||
+ | | ||
+ | Il est aussi nécessaire d' | ||
+ | |||
+ | Syntaxe de base | ||
+ | |||
+ | order <nom de la ressource> | ||
+ | |||
+ | Dans notre cas | ||
+ | |||
+ | order demon_before mandatory: clone_reverse_proxy | ||
+ | | ||
+ | Il peut aussi être intéressant de choisir une machine préférée pour accueillir la ressource. Ici nous voulons que l' | ||
+ | |||
+ | Syntaxe de base | ||
+ | |||
+ | location <nom ressource> | ||
+ | | ||
+ | Dans notre cas | ||
+ | |||
+ | location node-master ip_virtuelle 50: machine1 | ||
+ | |||
+ | ==== Vérification et application de la configuration ==== | ||
+ | |||
+ | Vérifier que votre configuration est correcte, normalement l' | ||
+ | |||
+ | verify | ||
+ | | ||
+ | Puis appliquez votre configuration au cluster | ||
+ | |||
+ | commit | ||
+ | |||
+ | ==== Afficher l' | ||
+ | |||
+ | Affichage de l' | ||
+ | |||
+ | sudo crm_mon -1f | ||
+ | | ||
+ | Vous devriez voir un résultat semblable | ||
+ | |||
+ | Online: [ machine1 machine2 ] | ||
+ | Clone Set: clone_reverse_proxy | ||
+ | | ||
+ | ip_virtuelle (ocf:: | ||
+ | |||
+ | ===== Tester sa configuration ===== | ||
+ | |||
+ | Vous pouvez facilement vous rendre compte des migrations de ressources dans le cluster en personnalisant les pages internet des serveurs webs nginx. Le chemin de la page d' | ||
+ | ==== Meurtre du processus nginx ==== | ||
+ | |||
+ | Effectuer les commandes sur le poste hébergeant l' | ||
+ | |||
+ | ps -aux | grep nginx | ||
+ | kill <numéro processus> | ||
+ | | ||
+ | Vous devriez voir que le compteur d' | ||
+ | |||
+ | Online: [ machine1 machine2 ] | ||
+ | Clone Set: clone_reverse_proxy | ||
+ | | ||
+ | ip_virtuelle (ocf:: | ||
+ | Migration summary: | ||
+ | * Node machine2: | ||
+ | * Node machine1: | ||
+ | | ||
+ | |||
+ | et si vous effectuez cette commande | ||
+ | |||
+ | sudo / | ||
+ | | ||
+ | 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' | ||
+ | |||
+ | ==== Blocage du redémarrage du serveur nginx ==== | ||
+ | |||
+ | Cette fois ci nous allons être un peu plus pervers. Nous allons empêcher le serveur nginx de redémarrer. Normalement l' | ||
+ | |||
+ | Éditer le fichier / | ||
+ | |||
+ | plop ! | ||
+ | | ||
+ | Tuer à nouveau le processus du démon nginx | ||
+ | |||
+ | Vous devriez obtenir ce résultat | ||
+ | |||
+ | Online: [ machine1 machine2 ] | ||
+ | Clone Set: clone_reverse_proxy | ||
+ | | ||
+ | | ||
+ | ip_virtuelle (ocf:: | ||
+ | Migration summary: | ||
+ | * Node machine2: | ||
+ | * Node machine1: | ||
+ | | ||
+ | |||
+ | On peut voir que l' | ||
+ | |||
+ | ===== Voir aussi ===== | ||
+ | |||
+ | * **(fr)** [[: | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | // | ||
+ | |||