Cas Pratique Haute Disponibilité Lamp

Une zone pour les utilisateurs enregistrés qui désirent contribuer au site et faire profiter la communauté de leur expérience d'Apache.

Modérateur : Gandalf

Avatar de l’utilisateur
karrakis
Membre ancien
Membre ancien
Messages : 444
Inscription : lun. 26 avr. 2004, 12:29
Localisation : Paris
Contact :

Messagepar karrakis » mer. 23 juin 2004, 15:46

Mise en place d'une configuration 'cheap' LAMP en haute disponibilité sous 2 serveurs.

Cet article a pour but de vous éclairer dans la réalisation d'une installation en haute disponibilité d'un service Web, il vous présentera l'application à un cas pratique plutôt qu'une explication des concepts de la haute disponibilité. Je vous rappelle également qu'il ne s'agit que d'une solution et que tous les choix fait sont bien évidemment discutable.

Pré-requis :

Il vous faut avoir installé et configuré au préalable Apache+PHP et mysql sur vos deux serveurs.
Guide d'installation apache <a href='http://www.apachefrance.com/Articles/1/' target='_blank'>http://www.apachefrance.com/Articles/1/</a>

Il vous faudra réaliser deux installation équivalente sur chaque serveur.

Qu'allons nous faire :

Nous allons faire en sorte que nos deux serveurs se relaie dans le traitement des requêtes si l'un d'entre eux tombe. Afin de fournir ce service nous devrons nous assurer que :

1.Les sites sur les 2 serveurs sont les mêmes à tous moments.
2.Les données de mysql sont les même à tous moments.
3.Apache et MySQL soient accessibles. (*)

Apache et MySQL auront chacun un serveur préféré et nous basculerons si nécessaire les services de l'un sur l'autre. Nous aurions pu aussi faire du load balancing entre les deux serveurs (mais attention pour gérer les insertions sur deux serveurs distinct) ou encore tout faire tourner sur un serveur, l'autre servant de serveur de secours (C'est dommage de n'utiliser qu'un seul serveur quand on en a deux).

I.Synchronisation des données pour Apache.

Dans un premier temps, nous devons nous assurer que les deux serveurs délivreront les mêmes pages. Nous allons utiliser unison pour synchroniser nos données.

3. unison kesako.

Pour plus d'information : <a href='http://www.cis.upenn.edu/~bcpierce/unison/' target='_blank'>http://www.cis.upenn.edu/~bcpierce/unison/</a>

Unison est outil de synchronisation de fichier sous Unix et Windows. Il permets à 2 arborescences situé sur deux hôtes différents ou sur deux disques sur chez un même hôte d'être modifiés séparément puis mises à jour en propageant les changements de chaque arborescence vers l'autre.

C'est bien ce que l'on souhaite.

Note : Dans le cas un même fichier est modifié sur les deux arborescences, unison demandera l'avis d'un humain pour savoir quelle fichier il doit garder.

2. Pour commencer.

Afin de pouvoir synchroniser nos données avec unison, il va nous falloir, dans un premier temps, installer et configurer SSH et SSHD sur chaque serveurs. Il existe sous forme de package pour la plupart des distributions. choisissez votre méthode d'installation préféré.

Une fois ssh installé, on va le configurer pour qu'un utilisateur toto puisse se connecter sur son compte sur l'autre serveur sans avoir à rentrer de mot de passe.

Sur le serveur 1 :

[toto@pctoto consult]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/toto/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/toto/.ssh/id_dsa.
Your public key has been saved in /home/toto/.ssh/id_dsa.pub.
The key fingerprint is:
27:9d:78:d3:7a:1d:2c:54:bf:a0:29:aa:6b:91:16:ea toto@pctoto

On demande la création d'une paire de clé dsa (ssh-keygen -t dsa). Le programme nous demande d'entrer le nom du fichier où sera écrite la clé (par défaut id_dsa). Pour plus de sécurité, vous pouvez entrer une passphrase mais elle vous sera demandé à chaque connexion ce qui pourrais nous gêner lors de la synchronisation. Nous avons donc maintenant un paire de clé id_dsa pour la clé privé et id_dsa.pub pour la clé publique. Ensuite, il faut copier id_dsa.pub dans le fichier /home/toto/.ssh/authorized_keys du serveur 2 afin de permettre la connexion. Faites la même chose sur le serveur 2.

Si tout se passe bien vous devriez obtenir un shell la machine distante.
[toto@serveur1]$ ssh serveur2
Last Login ...
[toto@serveur2]$

3. Synchronisons.

Unison s'invoque le plus simplement du monde :
$ unison local distant

Bien sûr, unison doit être invoquer avec l'uid du propriétaire de l'arborescence à synchroniser.
Dans le cadre de notre article deux options d'unison nous intéresse -auto pour accepter automatiquement les conseils d'unison, et -silent pour un mode non-interactif. Donc, unison /var/www ssh://seurveur2//var/www -auto -silent synchronisera automatiquement les deux arborescence. Les conflits possibles (le fichier a été modifié sur les 2 hôtes) seront archiver (mais non résolu) dans le fichier /home/toto/unison.log.

Afin de pouvoir lancer unison sans intervention humaine, il ne vous reste plus qu'à éditer votre crontab.

Je vous conseille vivement de consulter la man page de unison, et celle de cron au besoin.

II Réplication MySQL.

La réplication sous MySQL est en fait unidirectionnel/asynchrone d'un noeud maître vers un noeud esclave. S'il existe des solutions pour une réplication synchrone de MySQL, n'hésitez pas à m'en parler.

Comme vous l'avez compris, il nous faut tout d'abord deux serveurs (ou noeuds) avec MySQL d'installer sur chacun. Le noeud maître s'appellera serveur1, le noeud esclave serveur2.
1.Le noeud Maître.
Nous allons créer un utilisateur avec le droits nécessaire (et seulement ceux ci) pour la réplication. Connectez vous sur la base mysql
$mysql -u root -p
master> GRANT FILE, REPLICATION SLAVE ON *.* TO replicant@'%' IDENTIFIED BY 'replicant';
Query OK, 1 row affected (0.00 sec)
master>

Nous pouvons nous déconnecter de mysql et arrêter le serveur. Vous pouvez créer une archive tar.gz de votre base de données. Nous allons maintenant éditer le fichier de configuration de MySQL (my.cnf)
# locate my.cnf
/etc/my.cnf
Afin d'activer la réplication, nous avons deux chose à faire sur la master, dans la section [mysqld]
indiquer l'identifiant unique de votre serveurs dans les replicas, entrée 'server-id'. Activer le log binaire qui va stocker les modifications apportés à la base, entrée log-bin.
[attention] : L'utilisateur mysql doit pouvoir lire/écrire dans le répertoire contenant le journal binaire.

#/etc/my.cnf
(...)
[mysqld]
(...)
server-id = 1 #un chiffre entre 1 2^32
log-bin=/var/lib/mysql/mysql-bin.log

Le noeud maître est maintenant configuré.

2.Le Noeud Esclave

La base de données doit être arrêter. Nous devons la encore spécifier quelques valeur dans le fichier my.cnf. Un identifiant de serveur, l'adresse du maître, le port du maître, l'utilisateur et le mot de passe, le délai et ainsi que le journal binaire.

#/etc/my.cnf
[mysqld]
server-id = 2
log-bin = /var/lib/mysql/mysql-bin.log
master-host = serveur1
master-port = 3306 #3306 est le port par défaut de mysql
master-user = replicant
master-password = replicant
master-connect-retry = 10 #nombre de seconde entre 2 tentative de connexion au maître.

Vous pouvez donc extraire l'archive de la base maître dans le datadir du noeud esclave.

Un petit mot sur le journal binaire activé sur l'esclave, dans le cadre d'un système avec tolérance de panne, l'activation du journal binaire nous permets d'inverser le maître et l'esclave en cas de chute du serveur maître, ce qui est ce que nous souhaitons.

III Heartbeat

Maintenant que nous avons garantis le redondance et la synchronisation des données sur les deux serveurs, on va pouvoir attaquer la haute disponibilité des services. Heartbeat est un démon fait pour nous (et ce quelque soit votre culture musicale).

1.Heartbeat Kesako

Heartbeat est un logiciel open-source qui implémente un protocole de ligne de vie (hearbeat). Il va nous permettre d'assurer qu'un service tourne en permanence sur une adresse IP mouvante. Prenons un exemple, imaginons deux serveurs 198.157.1.112 et 198.157.1.113 qui doivent assurer un service web sur l'adresse 198.157.1.114. Hearbeat va pouvoir nous assurer qu'à un instant t un des deux serveurs écouteras à l'adresse 198.157.1.114.

2.Installation et Configuration

a. Installation

L'installation d'heartbeat est simple à réaliser soit en compilant les sources, soit en téléchargeant les RPMs. <a href='http://Http://www.ultramonkey.org' target='_blank'>Http://www.ultramonkey.org</a> fournie des paquetages pour debian et pour RedHat. Pour la Mandrake, vous devrez au préalable définir la source plf (easy-Urpmi) : <a href='http://urpmi.org/easyurpmi/index.php' target='_blank'>http://urpmi.org/easyurpmi/index.php</a>

Une fois l'installation effectué, on attaque la configuration. Vous pouvez un câble null-modem pour relier les deux machines entre elles pour plus de sécurité.

b. configuration

Hearbeat nécessite 2 fichier de configuration ;
ha.cf qui contient la configuration de heartbeat (ce qui existe)
haresources qui définit les ressources disponible sur notre cluster. (ce qui semble exister)

Il existe un troisième fichier authkeys qui permettra l'identification des 2 noeuds.

ha.cf:
bcast eth0
baud 19200
serial /dev/ttyS0

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

keepalive 2
deadtime 10
warntime 6
initdead 60

udpport 1001
node serveur1
node serveur2
auto_failback Off

Les trois premières entrée correspondes a la surveillance des noeuds, nous prenons le pouls en udp avec l'interface eth0 et par le câble null-modem (/dev/ttyS0). Ensuite, vienne les informations de journaux. La troisième série concerne la gestion des délais et du temps par hearbeat.

Keepalive : délai entre deux pouls.
Deadtime : temps avant de déclarer la mort d'un noeud
warntime : délai avant l'avertissement pouls en retard.
Initdead : ne sert que lors du démarrage d'un noeuds.

Enfin le quatrième paragraphe, où l'on spécifie le port udp à utiliser pour la prise de pouls (udpport), les différents noeud (node) et la directive auto_failback pour le comportement lors du redémarrage d'un noeud.
Les noms de noeuds doivent être les noms retourner par la commande uname -n.
la directive auto_failback prend plusieurs valeurs :
On : Le noeud maître reprend la main lors de son retour dans le cluster
Off : Le noeud maître ne reprends pas la main lors de son retour dans le cluster.

Le contenu de ha.cf peut être copier sur le serveur2 mais veuillez à vérifier les points de configuration spécifique à chaque noeud (interface réseau etc...)

haresources :

Ce fichier contient les informations sur ce qu'il semble exister, ce qui sous-entends entre autres qu'il doit être identique sur les deux noeuds.

Lors de la chute du noeud maître pour un service, heartbeat sur le noeud esclave verra la disparition de celui-ci et provoquera un flood ARP (Adress Resolution Protocol) pour indiquer au réseau que c'est lui désormais qui dessert l'adresse du service (198.157.1.114 dans l'exemple).
Le fichier haresource est écrit sous la forme :
<noeud maître> <service> <service>
par exemple :
serveur1 198.157.1.114
nous indique que le noeud serveur1 est le noeud maître pour écouter à l'adresse 198.157.1.114
198.157.1.114 est en fait équivalent à Ipaddr::198.157.1.114
pour assurer un service web on peut écrire :
serveur1 198.157.1.114 apache
heartbeat s'assurera de l'existence d'un service apache, le lancera et le stoppera si nécessaire.

Hearbeat recherche les scripts dans les répertoire dans cet ordre :

/etc/ha.d/resource.d/ installé par défaut.
/etc/init.d/ ou /etc/rc.d/init.d
Les scripts doivent répondre aux arguments start, stop, status comme les script d'init du système. Vous pouvez bien évidemment fournir vos propres scripts maison, c'est assez souvent nécessaire d'ailleurs.

Authkeys :

Le fichier authkeys permets au deux noeuds de s'identifier il doit impérativement être en mode 600.
Heartbeat propose 3 identification :
crc
md5
sha

auth 1
1 crc

Précise que l'identification ce fait selon la méthode crc. Le mot clé auth suivie d'un index précise l'identification à utiliser, valeur qui doit être présente dans les ligne suivante qui on la forme index méthode. Suivant la sécurité requise on peut utiliser md5 et sha pour garantir plus de sûreté. Enfin, plusieurs méthodes peuvent être liste afin de permettre un changement rapide selon les besoin.

Auth 2
1 crc
2 md5 « bonjour cluster »
3 sha « Je suis un node »

VI.Finalisation

Maintenant que nous avons installer heartbeat et que nos données sont synchroniser, nous allons pouvoir commencer à mettre en place la haute-disponibilité sur nos deux serveurs.

1.Apache

Afin de rendre apache disponible sur nos deux serveurs il va falloir donc le préciser à heartbeat, un ligne a ajouter dans haresources. Soit apache le script d'init d'apache.
Bien sûr, haresources est le même sur les deux serveurs.
serveur1 198.157.1.114 apache

voilà c'est fini, il ne reste plus qu'à lancer heartbeat sur les deux serveurs et faire quelque test pour faire comment ça fonctionne.

2.Mysql

Pour rendre mysql disponible sur les deux serveurs avec la réplication, il va falloir ruser, en effet, heartbeat arrête le service si le noeud n'est pas maître, mais dans notre cas on souhaite que mysql tourne. Il va donc falloir récrire le script mysql d'init. Dans ce même temps on pourras changer les valeur dans my.cnf pour pouvoir activer le mode esclave ou pas (si c nécessaire). Ce n'est pas très compliqué.
Pour commencer en root :
# cp /etc/init.d/mysql /etc/ha.d/resource.d
Profitez en si nécessaire par créer 2 fichier my.cnf-slave et my.cnf-master

Puis éditer votre script
rechercher la ligne : #start daemon
ajouter en dessous :
cp /root/my.cnf-master /etc/my.cnf

rechercher la ligne : #stop daemon
ajouter :
cp /root/my.cnf-slave /etc/my.cnf
à la fin de la section avant « 
;;

'status') »
ajouter $0 start
qui permets de relancer le démon automatiquement. Attention ne modifier que le script dans ressource.d, le script d'init de mysql ne doit pas être modifier sous peine de ne plus pouvoir arrêter proprement mysql.

Et enfin dans haresources ajouter la ligne :
serveur2 198.157.1.115 mysql
qui demanderas au serveur2 d'écouter à l'adresse 198.157.1.115.

Relancez heartbeat normalement vous devriez avoir un mysql en haute disponibilité.

Pour plus de sûreté, il serais bien sur plus intéressant d'ajouter une interface eth1 dédié pour la prise de pouls ainsi qu'une liaison série.

V Sources

Linux Magazine Hors série N° 18 Haute Disponibilité
http://www.ultramonkey.org
http://www.cis.upenn.edu/~bpierce/unison


--

Voici un premier jet, merci de préciser les corrections nécessaires. :)

Avatar de l’utilisateur
Gandalf
Sorcier des forums
Sorcier des forums
Messages : 2528
Inscription : jeu. 04 déc. 2003, 22:58

Messagepar Gandalf » ven. 25 juin 2004, 14:10

à priori tu peux éditer ton article sans passer par la modération par la suite, si ça ne marche pas, PM moi.

ps: si tu fais des mises à jour, n'oublie pas de faire un CHANGELOG pour qu'on puisse savoir ce qui a changé/été corrigé.
Celui qui détruit quelque chose pour savoir ce que c'est, a quitté le chemin de la sagesse.


Revenir vers « Articles »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 2 invités