Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Dernière révision Les deux révisions suivantes | ||
heartbeat [Le 10/09/2008, 17:55] 195.68.7.58, 127.0.0.1 |
heartbeat [Le 23/02/2017, 15:46] 81.63.154.242 [Statut d'Heartbeat] |
||
---|---|---|---|
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 comtpe 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'adresse 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 recherches des scripts est le suivant : | ||
- | * ''/etc/ha.d/resource.d/'' : qui est installé par défaut et contient un certain nombre de script 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œud 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]].// |