Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
heartbeat [Le 25/11/2008, 10:42]
Canigou 66 cluster; > cluster ;, machines; > machines ;, seconde; > seconde ;, maître; > maître ;, cluster; > cluster ;, d'autres; > d'autres ;, relancer; > relancer ;, rendez comtpe > rendez compte, assigner autant d'adresse > assigner autant d'adresses, L'ordre de recherches > L'ordre de recherche, un certain nombre de script > un certain nombre de scripts, nombre de nœud > nombre de nœuds
heartbeat [Le 11/09/2022, 11:07] (Version actuelle)
moths-art 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)
Ligne 1: Ligne 1:
-{{tag>Hoary Breezy Dapper ​serveur ​réseau haute-disponibilité cluster}}+{{tag>système sécurité ​serveur ​haute_disponibilité}}
  
 ---- ----
  
-====== Heartbeat ​: cluster de haute disponibilité actif/actif ou actif/​passif ​======+====== Heartbeat ======
  
 +Heartbeat (battement de cœur) permet de gérer différents services de [[wpfr>​haute disponibilité]] (High Availability : HA) au sein d'un cluster.
  
 +<​note>​[[http://​www.clusterlabs.org/#​2|Pacemaker]] est un gestionnaire de cluster. Il utilise soit heartbeat ou bien corosync pour contrôler les machines. Il est préférable d'​utiliser pacemaker car une interface java est disponible pour l'​installer et le configurer via un accès ssh.
  
 +Pour plus d'​information reportez-vous à la page du logiciel [[pacemaker]].
 +</​note>​
  
  
 +===== Pré-requis =====
  
 +  * Disposer des [[:​sudo|droits d'​administration]].
 +  * Disposer d'une connexion à Internet configurée et activée.
  
-===== Introduction ===== 
  
-L'​idée générale pour assurer la disponibilité d'un service est de faire fonctionner plusieurs machines (deux au minimum) en même temps. Ces machines forment ce qu'on appelle un //cluster// et chaque machine est un //node// du cluster. Chacune des machines va vérifier si les autres répondent toujours en prenant le pouls de chacune des autres. Si une machine cesse de fonctionner,​ les autres assurent le service.+===== Installation ===== 
 +[[:​tutoriel:​comment_installer_un_paquet|Installez le paquet]] **[[apt://heartbeat|heartbeat]]**.
  
-Une fois le //cluster// configuré, on y accède au travers d'une seule et unique adresse IP qui est celle du //cluster// ; qui lui-même est composé de plusieurs //nodes//.+===== Configuration ​et utilisation =====
  
-Pour pouvoir mettre en place ce genre de technique, nous allons utiliser l'​application HeartBeat qui va se charger ​de surveiller les machines ​et d'​appliquer une série ​de scripts définis par l'​utilisateur si cela s'​avère nécessaire (c'​est-à-dire si une machine ​//tombe//).+Il est conseillé ​de lire et de suivre la documentation du site officiel : 
 +  * introduction : http://www.linux-ha.org/LearningAboutHeartbeat 
 +  * tutoriel officiel : http://www.linux-ha.org/​HeartbeatTutorials
  
 +<​note>​ Ces liens pointent vers des adresses qui ne contiennent pas forcement des informations à jour. Le projet [[http://​www.linux-ha.org/​wiki/​Documentation|HA-Linux utilise maintenant un wiki]].</​note>​
  
-===== Préambule =====+Un exemple de configuration est proposé dans ce [[:​tutoriel:​mirroring_sur_deux_serveurs#​configuration1|tutoriel]].
  
-L'article qui suit se base sur une configuration de test identique à l'​article concernant [[:drbd|le RAID-1 over IP avec DRBD]].+==== Statut d'Heartbeat ====
  
-La configuration ​de tests se compose de deux machines modestes ; twin1 et twin2.+<​code>​cl_status rscstatus</​code>​ 
 +Nous affiche le statut des services du cluster :​ 
 +  * local (la machine ne gère que ses services) 
 +  * All (la machine gère tous les services du cluster) 
 +  * Foreign (la machine gère les services ​de l'​autre noeud) 
 +  * None (la machine ne gère aucun service)
  
-Le cluster sera accessible au travers de l'​adresse 192.168.252.205.+===== Désinstallation =====
  
 +Pour supprimer cette application,​ il suffit de [[:​tutoriel:​comment_supprimer_un_paquet|supprimer son paquet]]. La configuration de l'​application sera conservée ou supprimée selon la méthode de désinstallation que vous choisirez.
  
-=== Twin 1 ===+===== Voir aussi =====
  
 +  * **(en)** [[http://​www.linux-ha.org/​|Site officiel de Heartbeat et de la Haute Disponibilité sous GNU/Linux]]
 +  * **(fr)** [[:​tutoriel:​mirroring_sur_deux_serveurs|Tutoriel d'​utilisation conjointe avec DRBD et Samba]]
 +  * **(fr)** [[http://​www-igm.univ-mlv.fr/​~dr/​XPOSE2006/​JEREMIE_LEGRAND_HAUTE_DOSPO/​pratique2.htm|tutoriel]] configuration et utilisation de Heartbeat
 +  * **(en)** [[http://​www.clusterlabs.org/​wiki/​FAQ#​Which_Messaging_Layer_Should_I_Choose.3F|OpenAIS,​ Heartbeat and Pacemaker: what exactly are they now?]]
 +  * **(fr)** [[http://​www.it-connect.fr/​clustering-et-haute-disponibilite-sous-linux-avec-heartbeat%ef%bb%bf/​|Clustering et Haute Disponibilité avec Heartbeat]] sur IT-Connect
  
 +----
  
-  * Maître / Primaire 
-  * Pentium 3  -  500 MHz  -  128Mo RAM 
-  * Installation neuve de Hoary en mode minimaliste (option : ''​server''​ au boot du CD) 
-  * Mise à niveau de l'​image vers 2.6.10-5-686 (au lieu de 386) 
-  * IP : 192.168.252.200 
-  * Hostname : twin1 
-  * Disque de 13.5Go partagé en 5 partitions (''/''​ de 4.5Go, ''/​srv/​prod''​ de 3Go, ''/​srv/​intern''​ de 3Go, ''/​srv/​other''​ de 2Go et swap de 1Go) 
- 
-=== Twin 2 === 
- 
-  * Esclave / Secondaire 
-  * Pentium 3  -  700 MHz  -  128Mo RAM 
-  * Installation neuve de Hoary en mode minimaliste (option : ''​server''​ au boot du CD) 
-  * Mise à niveau de l'​image vers 2.6.10-5-686 (au lieu de 386) 
-  * IP : 192.168.252.201 
-  * Hostname : twin2 
-  * Disque de 10Go partagé en 4 partitions (''/''​ de 3Go, ''/​srv/​prod''​ de 3Go, ''/​srv/​intern''​ de 3Go et swap de 1Go) 
- 
-=== Etats des machines === 
- 
-Sur les deux machines, voici ce qui a été fait. 
- 
-  * Installation en mode ''​server''​ à partir du CD d'​installation x86 Hoary 5.04 et configuration réseau manuelle. 
- 
-  * Mise à jour de quelques paquets basiques via Internet. 
-<​code>​ 
-sudo apt-get update 
-sudo apt-get upgrade 
-</​code>​ 
-  * Mise à niveau du kernel pour profiter du Pentium 3 (pas nécessaire). Après la mise à niveau, un petit redémarrage pour prendre en compte le nouveau kernel. 
- 
-<​code>​ 
-sudo apt-get install linux-image-2.6.10-5-686 
-sudo reboot 
-</​code>​ 
- 
- 
-===== Installation d'​HeartBeat ===== 
- 
-HeartBeat s'​installe très simplement sur une Ubuntu Hoary. Le paquet se trouve dans les dépôts standards. Il vous suffit donc de lancer la commande suivante sur les deux machines (Twin 1 et Twin 2) : 
- 
-<​code>​ 
-sudo apt-get install heartbeat 
-</​code>​ 
- 
-Une fois le service installé, vous obtiendrez une erreur disant que le fichier de configuration ''​ha.cf''​ n'est pas présent. Ce qui est parfaitement normal. 
- 
-Voyons à présent la configuration basique de HeartBeat. 
- 
-===== Configuration basique ===== 
- 
-La configuration d'​HeartBeat repose sur 3 fichiers fondamentaux. Durant la configuration basique, je vais vous présenter une configuration minimaliste en vue de poursuivre deux buts : 
-   * fournir une base commune aux articles concernant la haute disponibilité sur le wiki. 
-   * fournir une base minimaliste que vous pourrez adapter à vos besoins au fil du temps. 
- 
-Les trois fichiers de configuration sont strictement identiques sur les deux machines ; chez vous, il convient donc de les copier sur chacune des machines du cluster. Dans notre exemple, il s'agit de Twin 1 et Twin 2. 
- 
-=== /​etc/​ha.d/​ha.cf === 
- 
- 
-<​code>​ 
-sudo vi /​etc/​ha.d/​ha.cf 
-</​code>​ 
- 
-Voici le fichier ''​ha.cf''​ que j'​utilise sur Twin 1 et Twin 2 : 
- 
-<​code>​ 
-bcast         eth0 
- 
-debugfile ​    /​var/​log/​ha-debug 
-logfile ​      /​var/​log/​ha-log 
-logfacility ​  ​local0 
- 
-keepalive ​    2 
-deadtime ​     10 
-warntime ​     6 
-initdead ​     60 
- 
-udpport ​      694 
-node          twin1 
-node          twin2 
- 
-auto_failback off 
-</​code>​ 
- 
-Examinons ce fichier de configuration en détails : 
-| ''​bcast''​ | indique l'​interface réseau par laquelle on va effectuer la prise de pouls. | 
-| ''​debugfile''​ | indique le fichier de déboguage à utiliser. | 
-| ''​logfile''​ | indique le log d'​activité à utiliser. | 
-| ''​logfacility''​ | indique que l'on utilise la facilité //syslog// en plus. | 
-| ''​keepalive''​ | indique le délai entre deux battements de pouls. Ce délai est donné par défaut en seconde ; pour utiliser les millisecondes,​ on ajoute le suffixe ''​ms''​. | 
-| ''​deadtime''​ | indique le temps nécessaire avant de considérer un nœud comme étant mort. Ce temps est donné par défaut en seconde ; pour utiliser les millisecondes,​ on ajoute le suffixe ''​ms''​. | 
-| ''​warntime''​ | indique le délai avant d'​envoyer un avertissement pour les pouls en retard. Ce délai est donné par défaut en seconde ; pour utiliser les millisecondes,​ on ajoute le suffixe ''​ms''​. | 
-| ''​initdead''​ | indique un ''​deadtime''​ spécifique pour les configurations où le réseau met un certain temps à démarrer. ''​initdead''​ est normalement deux fois plus grand que ''​deadtime''​ (au minimum). Ce délai est donné par défaut en seconde ; pour utiliser les millisecondes,​ on ajoute le suffixe ''​ms''​. | 
-| ''​udpport''​ | indique le port à utiliser pour la prise de pouls. | 
-| ''​node''​ | renseigne le nom des machines faisant partie du cluster. Ce nom doit être identique à celui retourné par la commande ''​uname -n''​. | 
-| ''​auto_failback''​ | indique le comportement à adopter si le node maître revient dans le cluster. Si on met la valeur ''​on'',​ lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier. Si on met la valeur ''​off'',​ les services continuent à tourner sur l'​esclave même lorsque le maître revient dans le cluster. Personnellement,​ je préfère la valeur ''​off''​ pour pouvoir faire un //retour à la normale// manuellement lorsque la charge de production est moins importante. De plus, si le node maître souffre d'un grave problème, on pourrait avoir une boucle de démarrage/​extinction qui entraînerait un relais des services de manière incessante. Ce qui peut devenir problématique. | 
- 
-=== /​etc/​ha.d/​haresources === 
- 
-Maintenant, nous allons définir le node maître, l'​adresse IP du cluster et les services devant être assurés. Dans un premier temps (configuration basique oblige), nous allons uniquement mettre en place l'​adresse IP du cluster. 
- 
-Pour configurer cet aspect de HeartBeat, nous [[:​tutoriel:​comment_editer_un_fichier|éditons le fichier]] **/​etc/​ha.d/​haresources**. 
- 
-<note warning>​Le fichier de configuration des ressources doit être **strictement** identique sur chacun des nœuds.</​note>​ 
- 
-Dans notre exemple, le fichier de configuration des ressources ressemble à ceci : 
- 
-<​code>​ 
-twin1 IPaddr::​192.168.252.205 
-</​code>​ 
- 
-C'​est-à-dire que nous définissons le node maître comme étant ''​twin1''​ et que l'​adresse IP du cluster est ''​192.168.252.205''​. Nous allons en rester là pour la configuration basique mais je vous invite à lire la section concernant la configuration avancée pour obtenir plus d'​informations. 
- 
-=== /​etc/​ha.d/​authkeys === 
- 
-Le fichier **/​etc/​ha.d/​authkeys** permet aux nodes de cluster de s'​identifier mutuellement. [[:​tutoriel:​comment_editer_un_fichier|Éditez-le]]. 
- 
-<note warning>​Le fichier de configuration des clés d'​authentification doit être **strictement** identique sur chacun des nœuds.</​note>​ 
- 
-Dans notre exemple, ce fichier ressemble à ceci : 
- 
-<​code>​ 
-auth 2 
-1 md5 "​cluster twin test" 
-2 crc 
-</​code>​ 
- 
-Le mot clé ''​auth''​ indique quel est le système d'​identification que l'on va utiliser. Si le lien n'est pas sûr physiquement,​ il est nécessaire d'​utiliser un chiffrement ''​md5''​ avec une chaîne de clé plus intelligente que celle-ci. ​ 
- 
-Dans notre cas, il n'y a que les deux twins sur un petit réseau local et donc nous utilisons le système ''​crc''​. 
- 
-Une fois le fichier édité, n'​oubliez pas de le protéger en introduisant la commande :  
- 
-<​code>​ 
-sudo chmod 600 /​etc/​ha.d/​authkeys 
-</​code>​ 
- 
-=== Mise en route et premiers essais === 
- 
-Avant de faire nos premiers essais, je vous suggère d'​installer un serveur SSH sur chacun des serveurs. [[:​ssh|Cette page]] vous guidera pour l'​installation du serveur SSH et l'​utilisation du client SSH. 
- 
-Vérifiez si les connexions SSH à chacun des nodes via leur adresse IP propre (192.168.252.200 et 192.168.252.201 dans notre exemple) fonctionnent. Si tel est le cas, nous pouvons faire un petit test. 
- 
-Lancez le service HeartBeat sur le node maître ; à savoir Twin 1 via la commande suivante : 
- 
-<​code>​ 
-sudo /​etc/​init.d/​heartbeat start 
-</​code>​ 
- 
-Ensuite, à l'aide de la même commande, activez HeartBeat sur Twin 2. 
- 
-Vous pouvez maintenant tenter une connexion SSH sur l'​adresse du cluster ; à savoir : 192.168.252.205 dans notre exemple. Une fois identifié, vous vous rendez compte que l'​invite de ligne de commande vous dit que vous êtes sur ''​twin1''​. 
- 
-Maintenant, retirez fermement le cordon d'​alimentation de Twin 1. 
- 
-Votre console SSH va vous signaler une erreur (normal... ;-) ). 
- 
-Relancez une connexion SSH sur l'​adresse du cluster ; à savoir : 192.168.252.205 dans notre exemple. Le service répond ! Or, Twin 1 est arrêté. Une fois identifié, vous vous rendez compte que l'​invite de ligne de commande indique : 
- 
-<​code>​ 
-ols@twin2:​~$ 
-</​code>​ 
- 
-Tout fonctionne. Maintenant, imaginons que Twin 1 revienne dans le cluster (remettez la prise de courant de Twin 1). 
- 
-Le cluster tourne toujours sur Twin 2. Pour forcer le basculement sur Twin 1 (vu que l'on est en mode ''​auto_failback off''​),​ on entre la commande suivante sur Twin 2 : 
- 
-<​code>​ 
-sudo /​etc/​init.d/​heartbeat restart 
-</​code>​ 
- 
-Et Twin 1 reprend automatiquement le relais. 
- 
- 
-===== Configuration avancée ===== 
- 
-La ligne de configuration du fichier ''/​etc/​ha.d/​haresources''​ telle que définie ci-dessus indique **uniquement** que le node maître est Twin 1 et que l'​adresse IP du cluster est 192.168.252.205. Selon cette configuration,​ HeartBeat fait le minimum, aucun script ou service n'est lancé ou arrêté sur les différents nodes composant le cluster. 
- 
-Voyons comment on peut configurer avec plus de finesse le fichier ''​haresources''​ pour certains besoins spécifiques. 
- 
-=== Octroyer plusieurs adresses IP pour le cluster === 
- 
-Nous avons écrit une ligne de ce type lors de la configuration de base : 
- 
-<​code>​ 
-twin1 IPaddr::​192.168.252.205 
-</​code>​ 
- 
-Ce qui signifie que l'on assigne au cluster l'​adresse IP ''​192.168.252.205''​. Cependant, on peut imaginer avoir besoin de plus d'une adresse IP pour accéder au cluster. C'​est-à-dire que l'on a plusieurs points d'​entrée vers le cluster et que chaque point d'​entrée (adresse IP) permettra d'​accéder au cluster. 
- 
- 
-Pour ce faire, nous configurons simplement les nodes avec le fichier ''/​etc/​ha.d/​haresources''​ suivant : 
- 
-<​code>​ 
-twin1 IPaddr::​192.168.252.205 IPaddr::​192.168.252.206 
-</​code>​ 
- 
-Et vous pouvez assigner autant d'​adresses IP supplémentaires que l'on désire. 
- 
-=== Spécifier les actions à effectuer === 
- 
-Une fois la configuration basique établie, c'est le node maître (si tout se passe bien) qui fournit les services pour l'​extérieur. Si tous vos noeuds sont configurés de manière exactement identique et font tourner les mêmes services en permanence, cela ne pose aucun problème. 
- 
-Si l'on veut être plus fin dans la configuration des nodes, on indique également les actions à entreprendre dans le cluster lorsqu'​un node tombe. Cet aspect est primordial si certains services doivent accéder à des ressources exclusives (c'​est-à-dire qu'un seul noeud à la fois peut utiliser une ressource particulière). C'est le cas des disques //​mirrorés//​ via le réseau (voir article [[:​drbd|RAID-1 over IP]]) où un seul node peut accéder au disque //​mirroré//​ en lecture-écriture. 
- 
-Pour pallier ce genre de problème, on peut spécifier des actions à entreprendre en complétant le fichier ''/​etc/​ha.d/​haresources''​. Pour spécifier ces actions, on utilise des scripts du style de l'Init System V (ou des scripts supplémentaire de HeartBeat ou encore des scripts fait-maison) pour indiquer ce que le cluster doit faire en cas de basculement d'un node vers un autre. 
- 
-Prenons un exemple simple (mais non moins intéressant ;-)) : le service ''​ssh''​. Le script Init de ce service se trouve dans ''/​etc/​init.d/''​ (ainsi que beaucoup d'​autres ; ''​apache'',​ ''​inetd'',​ ''​rsync'',​...). Nous configurons le fichier ''/​etc/​ha.d/​haresources''​ (sur chacun des nœuds, ne l'​oubliez pas !) de la manière suivante : 
- 
-<​code>​ 
-twin1 IPaddr::​192.168.252.205 ssh 
-</​code>​ 
- 
-Cette ligne indique à HeartBeat les informations suivantes : 
-  * Le node maître est ''​twin1''​. 
-  * L'​adresse IP du cluster est ''​192.168.252.205''​. 
-  * Les actions à entreprendre en cas de basculement sont : ''​ssh''​. 
- 
-Voyons en détail ce que signifie //Les actions à entreprendre sont...//. 
- 
-Les scripts utilisés par HeartBeat doivent répondre à 3 commandes : ''​start'',​ ''​stop''​ et ''​status''​. 
-Ces commandes sont appelées dans les cas suivants : 
-   * ''​start''​ : appelé sur le node sur lequel le cluster vient de basculer. 
-   * ''​stop''​ : appelé sur le node qui vient de tomber. 
- 
-Donc, imaginons que ce soit Twin 1 qui répond aux requêtes adressées au cluster. Si Twin 1 tombe, le démon HeartBeat qui tourne sur Twin1 y exécute ''​ssh stop''​ (si c'est possible évidemment),​ de même le démon HeartBeat qui tourne sur Twin2 s'​aperçoit que Twin1 ne répond plus ; il récupère l'IP du cluster et exécute ''​ssh start''​. 
- 
-Dans le cas ssh, cela n'a pas beaucoup d'​intérêt mais pour le montage des systèmes de fichiers ou pour simplement envoyer des emails, c'est indispensable. 
- 
-L'​ordre de recherche des scripts est le suivant : 
-  * ''/​etc/​ha.d/​resource.d/''​ : qui est installé par défaut et contient un certain nombre de scripts intéressants. 
-  * ''/​etc/​init.d/''​ : qui est le répertoire d'​usage pour le système d'Init System V. 
- 
-Vous pouvez ajouter des scripts personnels dans ''/​etc/​ha.d/​resource.d/''​ mais n'​oubliez pas qu'ils doivent être capables de répondre aux commandes ''​start'',​ ''​stop''​ et ''​status''​. 
- 
-N'​hésitez pas à regarder les quelques scripts se trouvant dans ''/​etc/​ha.d/​resource.d''​ pour vous en inspirer et savoir comment ils fonctionnent (syntaxiquement parlant). 
- 
- 
-===== Considérations pratiques ===== 
- 
-=== Concernant la liaison réseau === 
- 
-La solution décrite ci-dessus utilise la bande passante du réseau de manière intensive. Toutes les deux secondes (ou plus fréquemment encore suivant la configuration),​ chaque node va envoyer un paquet UDP sur chacun des autres nodes. En plus de cela, chaque node répondra à chacun des paquets envoyés. Je vous laisse imaginer le nombre de paquets transitant sur le réseau. 
- 
-L'​idéal est d'​avoir des machines avec plusieurs cartes réseaux. Par exemple, nous pouvons utiliser deux cartes réseaux : une carte réseau pour les prises de pouls et une carte réseau pour les services. 
- 
-Si votre cluster ne se compose que de deux nœuds, alors, il vaut mieux utiliser un câble croisé entre les deux machines afin de ne pas surcharger le réseau de production. 
- 
-Quoiqu'​il en soit, je vous conseille d'​utiliser un réseau dédié à la prise de pouls et au basculement des services. Dans le cas contraire, vous allez au devant d'une surcharge de votre réseau de production et les performances vont légèrement chuter. 
- 
-=== Concernant une liaison série complémentaire === 
- 
-Vous pouvez, en plus de la prise de pouls UDP, effectuer une prise de pouls directe via un câble série //null modem// qui connecte les deux machines. Cette prise de pouls est un complément efficace au réseau dans le cas où une interface réseau viendrait à tomber. 
- 
-Pour utiliser cette liaison série supplémentaire,​ vous devez introduire les deux lignes suivantes dans le fichier ''/​etc/​ha.d/​ha.cf''​ (juste après la ligne ''​bcast eth0''​) : 
- 
-<​code>​ 
-baud     19200 
-serial ​  /​dev/​ttyS0 
-</​code>​ 
- 
-Je n'irai pas plus loin concernant les liaisons séries car je n'ai pas eu l'​occasion de les expérimenter. 
- 
-=== Lors d'un changement de configuration... === 
- 
-Lors d'un changement de configuration du cluster (les 3 fichiers de configuration de HeartBeat), vous devez forcer les processus ''​heartbeat''​ à relire les fichiers de configuration. Veillez toujours à avoir des fichiers de configurations identiques sur les différents nœuds de vos serveurs, sans quoi, le clustering ne fonctionnerait pas. 
- 
-Pour forcer la relecture des fichiers de configuration,​ vous entrez la commande suivante sur chaque //node// du cluster en terminant par le node qui a le contrôle (normalement,​ le //node// maître sauf si vous êtes en situation catastrophe). Préparer les consoles et les commandes à l'​avance pour que le temps durant lequel les nœuds ont des configurations différentes soit le plus court possible ! : 
- 
-<​code>​ 
-sudo /​etc/​init.d/​heartbeat reload 
-</​code>​ 
- 
-Le solution la plus sûre étant de stopper tous les heartbeats, d'​appliquer les modifications et de les relancer ; mais parfois, les environnements de production ne permettent pas ce genre de chose. 
- 
-=== Plusieurs clusters sur un même réseau === 
- 
-Récemment, j'ai ajouté un cluster supplémentaire sur un réseau dans lequel il y avait déjà un cluster. Cela a posé quelques problèmes (rien de grave, juste des logs gigantesques). 
- 
-En fait, les noeuds du second cluster recevaient les paquets heartbeat broadcast et ne savaient pas les interpréter. Un message de warning dans la log de heartbeat donnait quelque chose ressemblant à ceci : 
- 
-<​code>​ 
-Aug  8 06:28:54 nodeprod1 heartbeat[6743]:​ ERROR: process_status_message:​ bad node [nodearch2] in message 
-Aug  8 06:28:54 nodeprod1 heartbeat[6743]:​ info: MSG: Dumping message with 9 fields 
-[...] 
-</​code>​ 
- 
-En fait, les noeuds s'​envoiaient des messages en broadcast les uns aux autres sans savoir quoi en faire. Pour résoudre ce problème, il fallait supprimer le //​broadcast//​ et utiliser soit l'//​unicast//,​ soit le //​multicast//​. 
- 
-Pour ce faire, il vous suffit de modifier le fichier « /​etc/​ha.d/​ha.cf » et mettre en commentaire la ligne ''​bcast <​interface>''​. Ensuite, suivant le nombre de nœuds de votre cluster (si vous n'avez que deux nœuds, l'​unicast est suffisant) vous modifier la configuration. 
- 
-Pour une configuration en unicast (toujours en suivant l'​exemple ci-dessus) sur Twin1, on ajoute la ligne :  
-<​code>​ 
-ucast eth1 192.168.252.201 
-</​code>​ 
- 
-Et pour Twin2, on ajoute la ligne : 
-<​code>​ 
-ucast eth1 192.168.252.200 
-</​code>​ 
- 
-Pour une configuration en multicast (plus facile pour maintenir les fichiers identiques ou si il y a plus de deux nœuds), on ajoute la ligne suivante (sur les deux nœuds) : 
-<​code>​ 
-mcast eth1 225.0.0.1 694 1 0 
-mcast <​interface>​ <groupe multicast>​ <udp port> <ttl> 0 
-</​code>​ 
- 
-Le groupe multicast est une adresse que vous choisissez comprise entre 224.0.0.0 et 239.255.255.255 par laquelle vos nœuds vont communiquer. Prenez garde à ne pas avoir d'​autres systèmes utilisant ce groupe //​multicast//​. 
-Le ttl indique le nombre de saut de réseau que le paquet peut effectuer (de 1 à 255). En général, les nœuds sont sur le même réseau et une valeur de 1 est parfaite. 
- 
-Le zéro qui termine la ligne est un bug dans heartbeat ;-). 
- 
----- 
  
-//​Contributeur : [[utilisateurs:​ostaquet]].//+//​Contributeur ​principaux ​: [[:​utilisateurs:​mrwaloo|MrWaloo]],​ [[:utilisateurs:​herrleiche|Herrleiche]].//
  • heartbeat.1227606144.txt.gz
  • Dernière modification: Le 25/11/2008, 10:42
  • par Canigou 66