Clustering Linux avec Postfix et Debian - Guides informatiques

Navigation :

Le 21-09-2007 17:34
par ludovic
(845 lectures)

Clustering Linux - Postfix

Introduction

Je pars d'une Debian déjà configurée avec soit un deuxième disque dur, soit une partition qui sera identique entre les 2 machines.

Il s'agit d'un cluster de type Maitre / Esclave : si le Maître tombe, l'esclave prend le relais.

Voici le fonctionnement de notre cluster qui va gèrer l'envoi massif de mail : lors d'un envoi de mail, les programmes d'envoi utilisent l'adresse IP du cluster (ainsi, si l'un tombe, l'autre prend le relais et les programmes continuent d'envoyer des mails sans problème).
Seul le Maître possède la partition montée et écrit sur le disque. DRDB s'occupe de recopier les données sur la partition du serveur Esclave.
Heartbeat vérifie que les 2 serveurs fonctionnent, si le Maître ne répond l'Esclave prend le relais en montant la partition et reprend le travail du Maître.

Puisque nous utilisons l'IP aliasé du cluster, nous ne verrons pas la coupure. Il va simplement falloir indiquer à PostFix d'utiliser l'espace disque surveillé et dupliqué par DRDB pour avoir les mêmes données sur les 2 serveurs.

Place à la configuration !

Il aurait été possible d'utiliser une baie SAN mais au vue des coûts nous avons adopter du RAID 1 entre les disques durs des serveurs et donc dupliqués par le réseau.

J'utilise donc deux serveurs : tonton le Maître et tonton_fils l'Esclave.

Les réplications réseaux se font sur l'IP 192.168.1.X sur eth0 et les serveurs sont accessibles sur 192.168.0.X sur eth1.

Création de l'IP du cluster

Sur le serveur 1, il faut créer une IP aliasée :

ifconfig eth1:0 192.168.0.10 netmask 255.255.255.0

Installation et configuration de HeartBeat

apt-get install heartbeat // Erreur car ha.cf n'est pas présent -> normal

Configuration de « heartbeat »

nano /etc/ha.d/ha.cf

#interface pour le heartbeat : il vaut mieux unicast que broadcast

ucast eth0 192.168.1.2 # sur tonton
ucast eth0 192.168.1.1 # sur tonton_fils

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0

# délai entre deux battements de pouls
keepalive 2
# temps nécessaire avant de considérer un noeud comme étant mort
deadtime 10
# délai avant d'envoyer un avertissement pour les pouls en retard
warntime 6
# deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer
initdead 60

# port à utiliser pour la prise de pouls
udpport 694

# uname -n pour connaitre le nom des 2 serveurs
node tonton
node tonton_fils

# met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier
auto_failback off

Jke conseille auto_failback off pour éviter que le Maitre ne reprenne le contrôle de l'Esclave. Par exemple, si le Maître a un souci d'alimentation et qu'il redémarre sans cesse, il se verra réatribuer l'envoi de courrier or il sera peut-etre à nouveau victime de défaillances et après une dizaine de transfert de ressources, notre cluster ne fonctionnerait plus !
Donc à off, se sera à nous de redonner les droits de Maître au serveur Maitre et l'on évitera tout problême.

Définition du noeud maître

nano /etc/ha.d/haresources

Définition du noeud maître : il faut mettre le même dans le fichier haresources

tonton IPaddr::192.168.0.10

Système d'identification que l'on va utiliser

nano /etc/ha.d/authkeys

auth 2
1 md5 "cluster twin test"
2 crc

Protection du fichier :

chmod 600 /etc/ha.d/authkeys

TEST avec SSH

Se connecter en SSH sur les 2 serveurs et lancer la commande :

/etc/init.d/heartbeat start

Connexion sur 192.168.0.10 -> normalement connecté sur serveur1.
Coupure de tonton -> erreur de Putty
Reconnexion sur 192.168.0.10 -> tonton_fils prend le relais

Pour que le serveur1 reprenne le relais, il faut taper cela sur tonton_fils:

/etc/init.d/heartbeat restart

Réplication de donnée avec DRBD

Création partition

cfdisk /dev/hdb // a adapter suivant le disque dur ou partition à dupliquer
mkfs.ext3 /dev/hdb1

Compilation du noyau et inclure drbd-0.7

apt-get install drbd0.7-utils drbd0.7-module-source
apt-get install linux-headers-$(uname -r) build-essential

module-assistant
SELECT
Drbd-0.7
BUILD

nano /etc/drbd.conf

#
# drbd.conf
#
resource r0 {
protocol C;
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";

startup {
degr-wfc-timeout 120; # 2 minutes.
}

disk {
on-io-error detach;
}

syncer {
rate 650M;
group 1;
al-extents 257;
}

on tonton {
device /dev/drbd0;
disk /dev/sda6;
address 192.168.1.1:7788;
meta-disk internal;
}

on tonton_fils {
device /dev/drbd0;
disk /dev/sda6;
address 192.168.1.2:7788;
meta-disk internal;
}
}

/etc/init.d/drbd start #sur les 2 noeuds

Affiche l’état de drbd :

cat /proc/drbd

Les 2 sont trop différents pour être synchronisés : « inconsistent ».

tonton:/# cat /proc/drbd
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by root@tonton, 2007-08-07 19:45:30
0: cs:Connected st:Secondary/Secondary ld:Inconsistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

Sur le serveur tonton, spécifiez le disque maître :

drbdsetup /dev/drbd0 primary --do-what-I-say

tonton:~# cat /proc/drbd
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by root@tonton, 2007-08-07 19:45:30
0: cs:SyncSource st:Primary/Secondary ld:Consistent
ns:16511304 nr:0 dw:0 dr:16512048 al:0 bm:3039 lo:0 pe:29 ua:186 ap:0
[===================>] sync'ed: 99.3% (131/16255)M
finish: 0:00:18 speed: 7,116 (6,548) K/sec

mkfs.ext3 /dev/drbd0

Procédure manuelle pour un test

mkdir /mnt/test
mount -t ext3 /dev/drbd0 /mnt/test

Lors d'une coupure du serveur tonton, on bascule le rôle primaire au serveur esclave

drbdsetup /dev/drbd0 primary

On peut ensuite monter le disque dur :

mount -t ext3 /dev/drbd0 /mnt/test

Le serveur tonton repart et le serveur tonton_fils resynchronise les données. Une fois finie, sur le serveur 2 :

umount /mnt/test
drbdsetup /dev/drbd0 secondary

Et sur le serveur tonton qui reprend le droit de maître :

drbdsetup /dev/drbd0 primary
mount -t ext3 /dev/drbd0 /mnt/test

Test d’une duplication automatique

/etc/init.d/heartbeat stop
/etc/init.d/drbd stop

mkdir /mnt/partage // ce dossier sera dupliqué entre les 2 serveurs

Il faut modifier le fichier de ressourecs de heartbeat pour configurer le basculement automatique.

nano /etc/ha.d/haresources

tonton IPaddr::192.168.0.10 drbddisk::r0 Filesystem::/dev/drbd0::/mnt/partage::ext3 MailTo::email_administrateur@domaine.com::cluster_linux postfix

// La première ip est l'ip virtuelle
// Le premier nom est le nom du noeud préféré : dans notre cas il s’agit du nom du serveur maitre
// IPaddr:: est un script pour ajouter les adresses ip virtuelles supplémentaires
// Filesystem:: est un script qui monte les partitions
// MailTo : envoit un mail lors du basculement

D'abord Serveur1 puis serveur2 :

/etc/init.d/drbd start
/etc/init.d/heartbeat start

Pour que le serveur tonton redevienne maître, tapez sur l'esclave tonton_fils exécutez :

/etc/init.d/heartbeat restart

Passons maintenant au test :

##### Sur le maître tonton :

mount /dev/drbd0 /mnt/partage
cp -r /usr/src/linux-headers-2.6.18-4 /mnt/partage
umount /mnt/partage
drbdsetup /dev/drbd0 secondary

##### Sur l'esclave tonton_fils :

drbdsetup /dev/drbd0 primary
mount /dev/drbd0 /mnt/partage
ls /mnt/partage/

On vérifie que le fichier "linux-headers-2.6.18-4" apparait bien sur le serveur esclave puis on refait la procédure inverse pour vérifier la réplication entre l’esclave et le maître :

##### Sur l'esclave tonton_fils :

cp -r /usr/src/linux-headers-2.6.18-4-686/ /mnt/partage
umount /mnt/partage
drbdsetup /dev/drbd0 secondary

##### Sur le maître tonton :

drbdsetup /dev/drbd0 primary
mount /dev/drbd0 /mnt/partage

On vérifie que le fichier "linux-headers-2.6.18-4-686" apparait bien sur le serveur maître.

Heartbeat doit gérer le service lors des bacules, donc on supprime la gestion de l’état du système :

update-rc.d -f postfix remove

Coupure réseau

Les 2 machines deviennent primaires et obtiennent la même adresse ip de la machine virtuelle !
Lorsque la connection est rétablie cela entraine un "split-brain" que l'on ne peut résoudre que manuellement.

Sur primaire :

0: cs:StandAlone st:Primary/Unknown ld:Consistent
ns:8 nr:0 dw:380 dr:50 al:1 bm:49 lo:0 pe:0 ua:0 ap:0

Sur secondaire :

0: cs:StandAlone st:Secondary/Unknown ld:Inconsistent
ns:0 nr:8 dw:16 dr:17 al:1 bm:293 lo:0 pe:0 ua:0 ap:0

L'état des noeuds est passé en "Unknown".
"drbdadm connect r0" sur les 2 machines démarre la synchro du primaire vers le secondaire
"drbdadm invalidate r2" sur une machine secondaire : invalide les données et force une resynchronisation.

Configuration de Postfix

apt-get install postfix
Site internet

apt-get install mailx // si mail n'est pas installé : mail: command not found

mkdir /mnt/partage/mail

nano /etc/postfix/main.cf
queue_directory = /mnt/partage/mail

Déchrooté Postfix :

nano /etc/postfix/master.cf
smtp inet n - n - - smtpd
reboot

Création des aliases :

nano /etc/aliases
root : no-reply
no-reply : poubelle
poubelle : /dev/null
postalias /etc/aliases

nano /etc/postfix/canonical
root no-reply
postmap /etc/postfix/canonical

nano /etc/postfix/main.cf
sender_canonical_maps = hash:/etc/postfix/canonical

Puisque "myorigin = /etc/mailname" alors :

nano /etc/mailname
domaine.com

nano /etc/passwd
root:x:0:0:no-reply:/root:/bin/bash

Envoi de mail lors d’un basculement

MailTo::mail_administrateur@domaine.com::cluster_linux

Statistiques Postfix

apt-get install pflogsumm

pflogsumm --iso_date_time /var/log/mail.log

Rapport par mail

Création d'un script qui va s'exécuter tout les soirs à 1h30 du matin avec les statistiques :

nano /root/rapport_mail.sh

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

pflogsumm --iso_date_time /var/log/mail.log.0 --smtpd_stats --verbose_msg_detail | mail -s "Rapport Cluster LINUX" moi@domaine.com

exit 0

chmod +x /root/rapport_mail.sh

Envoi fichier mail.log par FTP

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# date - 1 jour car il s'agit du log de la veille
DATE=$(date +%Y%m%d --date '1 day ago')
DUMP_FILENAME="mail_log-$DATE.log"
DUMP_FILENAME_LONG="mail_log_all-$DATE.log"

pflogsumm --iso_date_time /var/log/mail.log.0 --smtpd_stats --verbose_msg_detail > $DUMP_FILENAME
cp /var/log/mail.log.0 $DUMP_FILENAME_LONG

###### envoi par FTP ######
HOST='192.168.0.150'
USER='toto'
PASS='mot_de_passe_toto'
PORT='21'

ftp -n $HOST $PORT <<EOF
user $USER $PASS
put $DUMP_FILENAME
put $DUMP_FILENAME_LONG
quit
bye
EOF

exit 0

Placer une tâche CRON pour l'exécution :

0 1 * * * /root/mail/envoi_ftp_mail.sh >> /dev/null
30 1 * * * /root/rapport_mail.sh >> /dev/null

Modifier l'horaire de la rotation des logs

Par défaut, le logrotate agit à 6h25. Pour le modifier :

nano /etc/crontab

Puis remplacer :

0 0 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
5 0 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
10 0 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Conclusion

L'utilisation du Cluster Linux est utilisé pour envoyer des mails à partir d'une liste et cela fonctionne très bien.

Nous avons effectué pas mal de tests en envoyant des milliers de mails puis en coupant volontairement le serveur Maître ce qui n'a posé aucun soucis car le serveur Esclave a parfaitement repris le travail.

Sur un lien Gigabits entre les 2 machines, les duplications sont réalisées avec un débit de 40 à 60 Mo/sec (cela dépend de la vitesse des disques durs).

Il ne faut pas non plus négliger le système de disques durs sur les serveurs et un RAID 1 sur chacune des machines est primortdiale (même s'il n'a pas été fait dans mon cas) ainsi que des onduleurs (dans mon cas, les machines se trouvent dans un datacenter) pour une bonne redondance.

J'espère que cet article saura vous aider :)

TOP 5