Solution de Clustering Linux

( ou comment assurer la disponibilité d'un service )

I. Objectif de cet article

II. Principe de fonctionnement

Le serveur ( Linux ) sur lequel tourne Apache ou Samba ( ou d'autres ), vient de tomber ( panne materiel, coupure de courant, etc ...).

Grace à heartbeat , les utilisateurs connectés à ces service ne vont même pas se rendre compte de l'incident.

Les services interrompus vont automatiquement être activés sur la 2ème machine.

Cette machine va assurer la continuité de ces services.

Mais l'adresse IP ? Faudra-t-il intervenir sur chacun des postes clients pour la modifier ?

Ce n'est bien sur, ni envisageable , ni acceptable.

Heartbeat gère une adresse IP virtuelle qui est associée au noeud actif :

le premier seveur est encore en état de fonctionnement, c'est lui qui détient cette adresse vituelle.

Il tombe en panne, le 2ème serveur qui l'écoutait se rend compte que « son coeur ne bat plus »,

il va monter la même adresse IP virtuelle que celle associée initialement au premier serveur et va monter les services http et smb, les clients n'en « sauront rien »

Mais, et les données ?

Ce n'est pas le problème de heartbeat, il ne gère que le lancement des services devenus indisponibles sur le premier serveur.

Alors ? Et bien, il faudra gérer la redondance des données d'une autre manière. De nombreuses solutions existent qui vont de la synchonisation de fichiers entre 2 serveurs à des solutions de mirroring entre deux disques par le réseau.

Ce que sait ne sait pas faire heartbeat :

Heartbeat ne permet pas de surveiller la défaillance des services. Il est donc toujours possible d’utiliser Mon pour indiquer au système heartbeat qu’il y a défaillance.

Pour arriver à ce résultat et déclencher avec Mon le basculement des resources, il suffit tout simplement d’appeler le script d’initialisation Heartbeat avec l’argument stop. Quand Heartbeat est arrété, l’esclave déclare la mort du maitre et donc reprend les ressources.

Il faut donc utiliser Mon pour détecter les interruptions des services nécessitant une bascule.C'est ensuite hearbeat qui s'occupe de basculer les ressources.

( Cet aspect n'est pas traité dans cet article.)

III . Contexte matériel, réseau et logiciel

L'une s'appelle fedora1 :

[root@fedora1 ~]# uname -a

Linux fedora1.linux.tux 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 19:15:16 EST 2007 i686 athlon i386 GNU/Linux

sa configuration IP initiale :

[root@fedora1 ~]# ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:11:2F:6D:55:E8

inet adr:192.168.0.5 Bcast:192.168.0.255 Masque:255.255.255.0

Les services Apache et Samba sur fedora1 :

[root@fedora1 ~]# /etc/init.d/httpd status

httpd (pid 28128 28127 28126 28125 28124 28123 28122 28121 3260) en cours d'exécution...

[root@fedora1 ~]# /etc/init.d/smb status

smbd (pid 22472 2942 2939) en cours d'exécution...

nmbd (pid 2943) en cours d'exécution...

[root@fedora3 ~]# uname -a

Linux fedora3.linux.tux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 athlon i386 GNU/Linux

sa configuration IP initiale :

[root@fedora3 ~]# ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:18:F3:DF:B5:7A

inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0

adr inet6: fe80::218:f3ff:fedf:b57a/64 Scope:Lien

Les services Apache et Samba sur fedora3 :

[root@fedora3 ~]# /etc/init.d/smb status

nmbd est arrêté

[root@fedora3 ~]# /etc/init.d/httpd status

httpd est arrêté

IV. Installation de hearbeat

# yum install heartbeat

Loading "installonlyn" plugin

Setting up Install Process

Setting up repositories

Reading repository metadata in from local files

Parsing package install arguments

Resolving Dependencies

--> Populating transaction set with selected packages. Please wait.

---> Downloading header for heartbeat to pack into transaction set.

heartbeat-2.0.8-1.fc6.i38 100% |=========================| 98 kB 00:01

---> Package heartbeat.i386 0:2.0.8-1.fc6 set to be updated

--> Running transaction check

Dependencies Resolved

============================================================================

Package Arch Version Repository Size

=============================================================================

Installing:

heartbeat i386 2.0.8-1.fc6 extras 1.5 M

Transaction Summary

=============================================================================

Install 1 Package(s)

Update 0 Package(s)

Remove 0 Package(s)

Total download size: 1.5 M

Is this ok [y/N]: y

Downloading Packages:

(1/1): heartbeat-2.0.8-1. 100% |=========================| 1.5 MB 00:11

Running Transaction Test

Finished Transaction Test

Transaction Test Succeeded

Running Transaction

Installing: heartbeat ######################### [1/1]

Installed: heartbeat.i386 0:2.0.8-1.fc6

Complete!

Pour les autres distributions ou pour faire une installation à partir des sources :

http://www.linux-ha.org/DownloadSoftware

Installation à faire sur les deux machines.

V. Configuration

Ceux que nous allons modifier sont au nombre de 3 :

ha.cf : configuration du service heatbeat

haressource : definition des services gérés par heartbeat

authkeys : mécanisme d'autentification utilisé par les serveurs

Les informations et paramètres sont largement commentées dans ces fichiers ( comme d'habitude sous Linux )

Je ne ferais apparaître ici que le stricte nécessaire pour que ce service fonctionne( un peu plus ...)

[root@fedora1 ha.d]# cat /etc/ha.d/ha.cf

# File to write debug messages to

debugfile /var/log/ha-debug

# File to write other messages to

logfile /var/log/ha-log

# Facility to use for syslog()/logger

logfacility local0

# keepalive: how long between heartbeats?

# deadtime: how long-to-declare-host-dead?

deadtime 10

# warntime: how long before issuing "late heartbeat" warning?

# See the FAQ for how to use warntime to tune deadtime.

# Very first dead time (initdead)

#

# On some machines/OSes, etc. the network takes a while to come up

# and start working right after you've been rebooted. As a result

# we have a separate dead time for when things first come up.

# It should be at least twice the normal dead time.

#

initdead 60

udpport 694 ( commentaire : penser à ouvrir le port au niveau des firewall )

#

# Baud rate for serial ports...

#

#baud 19200

#

# serial serialportname ...

#serial /dev/ttyS0 # Linux ( commentaire : possibilité de mettre un lien série entre les 2 machines pour le hearbeat , non utilisé ici )

# What interfaces to broadcast heartbeats over?

#

bcast eth0 # Linux ( commentaire : définit sur quelle interface heartbeat écoute )

# Tell what machines are in the cluster

# node nodename ... -- must match uname -n

node fedora1.linux.tux

node fedora3.linux.tux

[root@fedora1 ha.d]# cat /etc/ha.d/haresources

fedora1.linux.tux IPaddr2::192.168.0.100/24/eth0:0 httpd smb

Cette ( seule ) ligne est particulièrement importante, elle définit :

quel serveur est maitre : fedora1.linux.tux

l'adresse IP virtuel qui sera basculé du serveur en panne vers le serveur actif : 192.168.0.100 ( a exclure de votre plage d'adresse si vous avez un serveur DHCP )

le(s) service(s) que heartbeat devra lancer sur le serveur secondaire quand il prendra la main, ici : httpd et smb

[root@fedora1 ha.d]# cat /etc/ha.d/authkeys

# Authentication file. Must be mode 600

auth 1

1 crc

La configuration étant exactement semblable sur les 2 machines, il suffit de les recopier tel quel sur l'autre serveur et ....

de démarrer ce service sur chacune des machines :

[root@fedora1 ha.d]# /etc/init.d/heartbeat start

Starting High-Availability services:

eth0:0: warning: name may be invalid

2007/03/27_15:50:45 INFO: Resource is stopped

[ OK ]

Le service est actif :

[root@fedora1 ha.d]# /etc/init.d/heartbeat status

heartbeat OK [pid 26172 et al] is running on fedora1.linux.tux [fedora1.linux.tux]...

Sur fedora1, la machine maitre, une nouvelle interface réseau a été monté :

eth0:0 Link encap:Ethernet HWaddr 00:11:2F:6D:55:E8

inet adr:192.168.0.100 Bcast:192.168.0.255 Masque:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Interruption:20

Les postes clients http et samba doivent maintenant pointer sur cette adresse.

Sur fedora3 , la machine secondaire, ou en est-on ?

Vous avez lancé le service heartbeat :

[root@fedora3 ~]# /etc/init.d/heartbeat start

Les services httpd et samba ne sont pas actifs

( penser à les désactiver pour qu'il ne soit plus activé automatiquement au démarrage de ce serveur :

[root@fedora3 ~]# chkconfig --level httpd off

[root@fedora3 ~]# chkconfig --level smb off )

[root@fedora3 ~]# /etc/init.d/heartbeat status

heartbeat OK [pid 2330 et al] is running on fedora3.linux.tux [fedora3.linux.tux]...

[root@fedora3 ~]# /etc/init.d/smb status

smbd est arrêté

nmbd est arrêté

[root@fedora3 ~]# /etc/init.d/httpd status

httpd est arrêté

eth0 Link encap:Ethernet HWaddr 00:18:F3:DF:B5:7A

inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0

adr inet6: fe80::218:f3ff:fedf:b57a/64 Scope:Lien

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:778883 errors:0 dropped:0 overruns:0 frame:0

TX packets:624100 errors:6 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:1000

RX bytes:149044687 (142.1 MiB) TX bytes:107799923 (102.8 MiB)

Interruption:201 Adresse de base:0x6000

lo Link encap:Boucle locale

inet adr:127.0.0.1 Masque:255.0.0.0

adr inet6: ::1/128 Scope:Hôte

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:244718 errors:0 dropped:0 overruns:0 frame:0

TX packets:244718 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:0

RX bytes:27837738 (26.5 MiB) TX bytes:27837738 (26.5 MiB)

VI. A l'usage

fedora1 vient de planter ( pas le système bien sur , çà c'est du Linux, çà ne plante jamais ...j'ai débranché le PC , ou plus soft j'ai débranché le cable réseau, ... )

fedora3, la machine secondaire, a monté son interface réseau virtuel :

[root@fedora3 ~]# ifconfig

eth0 Link encap:Ethernet HWaddr 00:18:F3:DF:B5:7A

inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0

adr inet6: fe80::218:f3ff:fedf:b57a/64 Scope:Lien

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:780283 errors:0 dropped:0 overruns:0 frame:0

TX packets:625344 errors:6 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:1000

RX bytes:149264680 (142.3 MiB) TX bytes:107995010 (102.9 MiB)

Interruption:201 Adresse de base:0x6000

eth0:0 Link encap:Ethernet HWaddr 00:18:F3:DF:B5:7A

inet adr:192.168.0.100 Bcast:192.168.0.255 Masque:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Interruption:201 Adresse de base:0x6000

lo Link encap:Boucle locale

inet adr:127.0.0.1 Masque:255.0.0.0

adr inet6: ::1/128 Scope:Hôte

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:245094 errors:0 dropped:0 overruns:0 frame:0

TX packets:245094 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:0

RX bytes:27872384 (26.5 MiB) TX bytes:27872384 (26.5 MiB)

[root@fedora3 ~]# /etc/init.d/httpd status

httpd (pid 30032 30031 30030 30029 30028 30025 30024 30023 30006) en cours d'exécution...

[root@fedora3 ~]# /etc/init.d/smb status

smbd (pid 30056 30055) en cours d'exécution...

nmbd (pid 30059) en cours d'exécution...

sans aucune intervention manuelle.

Les clients qui utilisent l'interface virtuelle continue à travailler.

fedora1 revient en ligne , il récupère automatiquement ( si on a conservé le paramétrage du service heartbeat par defaut ) son statut de maitre :

il récupère l'adresse IP virtuelle et relance les services gérés par heartbeat

fedora3 arrête son interface virtuelle et les services Apache et Samba

VII. Et mes données ?

Pour Samba , c'est la même chose ( même configuration , même répertoires partagés ) sauf que le problème est un peu plus délicat dans la mesure où les fichiers sont manipulés.

Une solution basique ( mais néanmoins efficace ) consiste à utiliser rsync couplé à cron pour assurer la synchronisation des repertoires et des fichiers concernés par Samba, entre les deux machines.

( Avec cron , la synchronisation ne pourra pas descendre en dessous de la minute )

Attention :

A partir du moment ou le serveur secondaire prend la main, les utilisateurs Samba vont venir modifier ou créer de nouveaux fichiers sur ce serveur.

Au moment ou le serveur primaire va reprendre la main, les utilisateurs vont pointer sur les repertoires partagés du serveur maitre et ne verront donc plus les fichiers qu'ils ont eventuellement créé sur le serveur secondaire.

Il va donc falloir mettre à jour le serveur maitre pour qu'il prenne en compte les modicications réalisées sur le secondaire pendant qu'il était hors service et donc synchroniser les fichiers dans le sens : serveur secondaire vers serveur maitre.

Le paramètre auto_failback définit dans /etc/ha.d/ha.cf est à gérer dans cette situation :

en le mettant à off ( ce qui n'est pas sa valeur par défaut ) , on evitera que le serveur maitre ne reprenne automatiquement la main lors de sa remise en service.

# auto_failback: determines whether a resource will
# automatically fail back to its "primary" node, or remain
# on whatever node is serving it until that node fails, or
# an administrator intervenes.
#
# The possible values for auto_failback are:
# on - enable automatic failbacks
# off - disable automatic failbacks
# legacy - enable automatic failbacks in systems
# where all nodes do not yet support
# the auto_failback option.

1) le serveur maitre redémarre ( mais le secondaire secondaire garde la main sur les services gérés par heartbeat )

2) L'administrateur effectue une synchronisation des fichiers dans le sens Secondaire vers Maitre

3) Une fois la synchronisation terminée , l'administrateur lance, sur le serveur secondaire :

[root@fedora3 ha.d]# /etc/init.d/heartbeat restart

ce qui a pour effet de repositionner le serveur maitre dans son rôle initial.

Penser également, concernant Samba à mettre en oeuvre exactement la même gestion des utilisateurs si on gére localement les comptes à chaque machine. ( assurer l'équivalence de sambapasswd sur chaque machine )

VIII. En cas de problèmes

Les logs , si vous les avez activé dans /etc/ha.d/ha.cf

# File to write debug messages to

debugfile /var/log/ha-debug

# File to write other messages to

logfile /var/log/ha-log

# Facility to use for syslog()/logger

logfacility local0

Les pièges à éviter :

la gestion des firewalls de chaque machine : ouvrir le port UDP définit dans /etc/ha.d/ha.cf

les noms de machines doivent être très précisemment ceux retournés par la commande hostname de chaque machine.

Date de création : 27/03/2007 @ 17:05
Dernière modification : 28/03/2007 @ 11:46
Catégorie :
Page lue 5703 fois

 Prévisualiser la page      Imprimer la page