Description

Objectif

 

• Assurer une visibilité maximum sur le Web pour le club :

- site web
- courriel
- liste de diffusion
- service FTP
- autres...

 

Le besoin

 

• Assurer la disponibilité des services du Club en cas de panne du serveur (nonobstant une panne d'électricité de plus de vingt minutes ou un problème avec le fournisseur d'accès Internet!)
• Si les services sont interrompus, que ce soit pour une durée minimale
• Que le transfert des services se fasse sans intervention (automatique)
• Qu'il y ait le moins de perte d'information possible (idéalement aucune perte)

HA clusters, High availability
Services redondants

 

• HA peut vouloir dire différentes choses; ici il s'agit de plusieurs ordinateurs qui offrent les mêmes services
• Les services n'appartiennent pas à une machine, mais au « cluster », à la grappe. Si un service n'est pas fourni par une machine dans la grappe, une autre machine de la grappe s'en occupe.

 

HA peut réduire le transfert de service de façon dramatique

La règle des neuf en ce qui concerne la disponibilité :
90 % => 37 jours de non disponibilité de service par année
99 % => 3,7 jours
99,9 % => 8,8 heures
99,99 % => 53 min.
99,999 % => 5,3 min.
99,9999 % => 32 secondes

Description - Suite

Pour obtenir de hauts pourcentages de disponibilité

 

• Équipements de catégorie Serveurs d'entreprise
• Un noyau Linux stable
• Une maintenance élevée du réseau
• Applications infaillibles (stables)
• Administrateur certifié et structuré

Même sans les éléments ci-dessus, on peut grandement améliorer la disponibilité avec HA.

 

Qui bénéficie de HA

 

• Le Club dans son ensemble
• Réduction du stress de notre admin préféré (il aura plein de temps pour réparer le problème)
• Les usagers sont contents :-)
• Le patron est content :-))

 

Configuration avec DRBD

Dans cette configuration, chaque noeud est connecté sur l'onduleur (UPS) de l'autre. Si l'un des deux noeuds tombe, l'onduleur de l'autre le « tue » (l'éteint) pour prévenir un conflit si jamais il revient à la vie.

Ce dont nous avons besoin

Ce dont nous avons besoin

 

• Deux ordinateurs comparables mais non identiques
• Logiciel HA (Heartbeat)
• Services HA (Adresse IP de service, httpd, smtp,..)
• Réplication de disque ou disque partagé
• Logiciel STONITH (Shoot the other node in the head :-()

 

Logiciel HA Heartbeat

 

• S'exécute sur les deux ordinateurs
• Communique d'une machine à l'autre via un lien sériel croisé et/ou Ethernet croisé
• Détecte la panne de l'autre
• Gère l'arrêt et le démarrage des services HA
• Deux modes possibles :

- Actif-Passif
- Actif-Actif

Réplication des disques (faible performance)

 

• DRBD Raid 1 (miroir) via un lien Ethernet (synchro. bi-directionnel entre les deux disques)
• Scp, ftp, scripts, ...
• Rsync (synchro unidirectionnelle de fichiers altérés)

 

Disques partagés (plus performant)

Disques partagés (plus performant)

 

• Multi-attach SCSI Raid
• Dual controller Raid (IBM ServeRaid)
• Disques reliés par fibre partagée (Shared fiber-channel disks)
• Serveur de stockage d'entreprise

 

Solutions dispendieuses allant de 5 000 $ US à plusieurs millions.

 

Étapes

 

1. Installer deux machines de base (de préférence de même distribution, ça simplifie les choses)
2. Installer les services de façon à ce que les fichiers de configuration, services et données soient sur le disque partagé
3. Cartes Ethernet paramétrées et câble série installé.
4. Logiciels Heartbeat et DRBD installés

 

Point de panne unique (single point of failure, ou SPOF)

Avec la configuration ci-dessus, nous avons :
- Deux blocs d'alimentation redondants
- Deux cartes maîtresses/mémoires/CPU redondants
- Deux disques en miroir et/ou synchronisés qui ne sont pas dans le même boîtier
- Deux onduleurs (UPS)
- Câble Ethernet croisé pour éviter une panne de concentrateur (hub) ou de commutateur, idem pour la connexion série.

Heartbeat

 

• Agit comme init pour lancer et arrêter les services.
• Gère les services en groupe, c.-à.-d. les services dans ce groupe, incluant l'adresse IP de service, sont transférés d'une machine à l'autre.
• A besoin de deux autres adresses IP (une par machine) pour ses propre besoins.

Paul est le maître et est en état de fonctionner

 

 

L'adresse de service de la « grappe » est 10.10.10.20

Paul est en panne. Silas prend la relève

 

 

Logiciels à charger :

 

• Heartbeat-version...
• Heartbeat-pils-version...
• Heartbeat-stonith-version....
• drbd-version...

 

Configuration

 DRBD

 

• Ne sera pas démontré ici :-(.
• Nous parlerons plutôt de rsync, que nous utilisons pour le site du Club

 

Stonith (Shoot The Other Node In The Head)

 

• Mécanisme pour éteindre complètement le serveur qui vient de flancher en éteignant son onduleur
• Surtout utilisé avec des disques partagés; on ne veut vraiment pas que l'ordinateur qui est supposé être hors d'état vienne écrire sur le disque partagé et corrompre/altérer les données.
• Donc on lui donne le coup de grâce en l'éteignant.

 

Fichiers de configuration de heartbeat

 

• 3 fichiers à configurer

- /etc/ha.d/ha.cf (configuration générale)
- /etc/ha.d/haresources (liste des services HA à gérer)
- /etc/ha.d/authkeys (contient la méthode d'encryption utilisée par heartbeat pour communiquer)

ha.cf, un exemple

logfacility local7     # mécanisme de journalisation
keepalive 1      # Intervalle HB en secondes
warntime 2      # Retard de l'autre à se manifester
deadtime 10      # prise de la relève dans 10 secondes
nice_failback on      #
node paul silas
ping 10.10.10.254      # adresse du routeur
respawn /usr/lib/heartbeat/ipfail
bcast eth0 eth1      # HB bcast
serial /dev/ttyS0      # Liaison HB série
stonith_host paul apcsmart silas /dev/ttyS1
stonith_host silas apcsmart paul /dev/ttyS1

Haresources, un exemple

paul 10.10.10.20 datadisk::drbd0 nfslock nfsserver nmb smb dhcpd postfix

Nota : Paul est le serveur primaire actif, le reste sont les services, incluant l'adresse IP de service, qui sont démarrés ou éteints par Heartbeat.
Nota : Tout doit être écrit sur la même ligne

Authkeys, un exemple

auth 1
1 sha1 MotdePassePrisauhasardfc970c94efb

Mesures à prendre

 

1. Empêcher les services HA de démarrer au démarrage du serveur ( c'est heartbeat qui s'en occupe).
2. Empêcher la partition partagée (disque partagé) de démarrer au démarrage du serveur (dans le cas de drbd; dans le cas de rsync, il n'y a pas de disque partagé)
3. Démonter la partition ci-haut mentionnée (dans le cas de drbd)
4. S'assurer que l'on donne l'adresse de service aux clients soit via /etc/hosts et/ou DNS. Nommer Paul et Silas aussi.
5. Transférer les services sur la partition partagée (toujours avec drbd).
6. Vérifier que la méthode de réplication fonctionne (drbd)
7. Démarrer heartbeat sur les deux machines (service heartbeat start ou /etc/init.d/heartbeat start, selon votre distribution)
8. Vérifier que les services HA sont tous démarrés par heartbeat

 

Tests, simulations

 

• Pour migrer de Paul vers Silas, sur la console de Paul on tape:
  /usr/sbin/heartbeat/hb_stanby ou
  /usr/lib/heartbeat/hb_standby, selon les distributions
• Vérifier que les services ont migrés vers Silas et qu'ils sont démarrés et accessibles aux usagers.
• Le transfert ne dure que 15 secondes :-)).
• On peut passer à la console de Silas et lancer la même commande, les services seront transférés à Paul. :-)))
• Débrancher le lien Internet d'une des machines, Heartbeat transfère vers l'autre machine :-)))))

Configuration particulière du serveur du Club

 

• Chose importante à noter, les deux serveurs (clo et clo2) sont derrière un coupe-feu qui redirige les requêtes (http, smtp,ftp, etc.) vers l'adresse de service. Il est donc important que cette adresse soit toujours la même, car le coupe-feu ne sait pas si c'est clo ou clo2 qui est actif. D'où l'importance du transfert d'adresse de service grâce à Heartbeat. De plus, nous ne disposons que d'un seul onduleur (UPS)
• Comme nous l'avons déjà dit, il y a 3 fichiers à configurer
• Voir respectivement :

- http://www.linux-ha.org/ha.cf
- http://www.linux-ha.org/haresources
- http://www.linux-ha.org/authkeys

• Le fichier /etc/ha.d/ha.cf

- logfacility local0    # inscription dans journal local
- logfile /var/log/ha    # nom du fichier journal
- keepalive 1    # intervalle entre les paquets (en sec.)
- deadtime 10    # nb de sec. avant de constater la mort
- Warntime 2    # ¼ à ½ du nb de sec. de deadtime
- baud 19200    # vitesse de comm. entre les ports série
- serial /dev/ttyS0    # le port du lien série
- bcast eth1    # le lien ethernet (câble croisé entre les 2 serveurs)
- auto_failback on    # off=actif/passif on=actif/actif
- node clo clo2    # ordi maître, ordi esclave

• Le fichier haresources :
• Doit absolument être le même sur les deux serveurs, avec le nom du maître pour commencer, l'adresse de service et les services gérés par Heartbeat

- clo 123.456.2.2/24/eth0 named apache2 postfix courier-imapd courier-pop3d mailman vsftpd mysql

• L'adresse 123.456.2.2 est un alias transféré d'un serveur à l'autre lorsque le maître n'est plus actif.
• Le fichier authkeys :

- auth 1
- 1 sha1 MotdePassePrisauhasardfc970c94efb

• On aurait également pu utiliser 1 CRC, mais pour des raisons de sécurité, CRC n'est pas recommandé pour des connexions autres qu'un câble série et un câble ethernet croisé. Autrement dit, pour une connexion d'ordi à ordi, ce qui est notre cas, ce n'aurait pas été un problème.

 

Synchronisation des serveurs

 

• Pour que clo2 soit à jour lorsqu'il doit prendre la relève de clo, il faut faire une synchronisation entre les deux. Il faut donc autoriser clo2 à aller chercher les fichiers nécessaires sur clo. Cela se fait à l'aide du fichier /etc/rsync.conf sur clo :

pid file = /var/run/rsyncd.pid
max connections = 5
use chroot = yes
uid = nobody
gid = nobody

# Optionnel : restriction de l'accès à vos machines
hosts allow = 123.456.2.1 123.456.1.4 123.456.2.4 123.456.1.6   # permettre seulement à certaines machines d'avoir accès
hosts deny = *   # On empêche tous les autres

[web]    # Module des pages Web du site
path = /home/clo
comment = Répertoire clo pour le site
uid = clo   # ce paramètre prend la priorité sur le paramètre global (uid = nobody)

[pool]    # Module d'un autre site
path = /home/pool
comment = Répertoire pool pour le site
uid = pool

[securinux1]    # Module d'un autre site
path = /home/securinux
comment = Répertoire securinux pour le site
uid = securinux
exclude = gallery/    # Ici on exclut un répertoire

[mailman]    # Pour la synchronisation de la liste de diffusion
path = /usr/local/mailman
comment = Archives de Mailman
uid = mailman

 

crontab sur clo2

 

• Sur clo2, la synchronisation se fait à l'aide de crontab, avec la commande crontab -e qui ouvre un fichier. On place une tâche cron par ligne :

30 5 * * * emerge sync
31 2 * * * rsync -avz --delete 123.456.2.3::web /home/clo
32 2 * * * rsync -avz --delete 123.456.2.3::securinux1 /home/securinux
33 2 * * * rsync -avz --delete 123.456.2.3::pool /home/pool
*/5 * * * * rsync -avz --delete 123.456.2.3::mailman /usr/local/mailman

• Les chiffres et les astérisques (*) signifient, de gauche à droite, la minute de l'heure, l'heure de la journée (sur 24 heures), le jour du mois, le mois de l'année et le jour de la semaine. L'astérisque signifie tous (toutes) les (minutes, heures, jours, mois, jours de la semaine).
• Sur la première ligne, nous avons une fonction Gentoo (emerge sync) de synchronisation des métafichiers gérant les sources et les dépendances. Cette synchronisation se fait à la 30e minute de la 5e heure, tous les jours du mois, tous les mois et tous les jours de la semaine.
• Sur la dernière ligne, Mailman se synchronise toutes les cinq minutes (*/5)
• Les options -avz et --delete signifient :

a  archive (récursif et préserve les permissions, le propriétaire, le groupe, les "devices", le temps et les liens symboliques. Équivaut à rpogDtl)
v  verbeux
z  comprimer
delete  supprimer les fichiers qui n'existent plus sur l'envoyeur

• Voir man rsync et man crontab(1) et crontab(5) pour une foule d'autres possibilités.

Guy Lessard
Jean-Marc Vaillancourt
Club Linux Gatineau
28 mars 2006