Lors de vos gros projets, il se peut que vous ayez à garantir la sécurité de votre site et donc avoir une copie exacte de tous vos fichiers et de vos données en permanence. Dans ce cas là, deux possibilités s’offrent à vous :

  • Le plan d’activité de reprise (PRA) : Vous utilisez un serveur maître qui gère le traffic des visiteurs et qui copie toutes ses données et tous ses fichiers sur un serveur esclave qui sera alors prêt à prendre la relève en cas de panne du serveur maître.
  • Le cluster : Vous utilisez deux ou plusieurs serveurs qui vont se répartir le traffic des visiteurs et s’assurer que toutes les données soient les mêmes partout.

Comment choisir votre architecture ? C’est plutôt simple. le PRA a l’avantage d’être peu coûteux par rapport au cluster qui nécessite un matériel spécifique (Load-Balancer, 70€/mois chez OVH contre 1€/mois pour l’IP Fail-over nécessaire au PRA) mais qui, lui, se révèle indispensable pour un projet à fort traffic (puisque les charges des serveurs sont répartis, vos visiteurs auront alors accès à un site plus fluide).

Pour ma part, pour le moment, je n’ai eu à m’occuper que de PRA, alors je voulais vous partager mon expérience. Nous avons déjà vu plusieurs étapes dans des tutoriaux précédents, je ne ferais donc que les citer.

Sommaires :

  • Etape 1 – Installation des serveurs web
  • Etape 2 – Configuration de l’IP Fail-Over
  • Etape 3 – Configuration du nom de domaine
  • Etape 4 – Réplication de la base de données
  • Etape 5 – Réplication des fichiers
Pour effectuer un PRA de base, nous aurons besoins :
  • Un nom de domaine avec ses accès DNS
  • Un IP Fail-Over (disponible chez OVH pour sa gamme de serveurs dédiés professionnels pour 1€HT/mois)
  • Deux serveurs web (pas forcément de la même capacité, il faut simplement qu’ils soient tous les deux accessibles par l’IP Fail-Over)
Pour l’installation d’un PRA, outre la propagation des DNS, comptez environs une heure de travail.

Etape 1 – Installation des serveurs web

Nous allons donc installer nos deux serveurs web, que nous appellerons S1 (pour le serveur maître) et S2 (pour le serveur esclave). Pour cela, pour vos deux serveurs, suivez ce tutoriel : [Tuto] Installer un serveur web sous Debian. Nous reviendrons sur les configurations d’apache plus tard. Pour ceux qui sont chez OVH, celui-ci vous permet de choisir un datacenter en particulier. Je vous conseille grandement de prendre vos deux serveurs dans des DC différents, histoire d’éviter que votre PRA soit mit à mal lors d’un incident physique sur le site.

Etape 2 – Configuration de l’IP Fail-Over

L’IP Fail-Over est un outil très pratique dans l’administration réseau. Celle-ci n’est en fait qu’une IP publique que vous pouvez faire rediriger votre l’IP privée de votre serveur (qui doit se trouver sur le même réseau). L’avantage, c’est qu’en un clic, et de manière presque instantanée, vous pouvez changer son IP de redirection. Fini donc les attentes longues des propagations DNS. Vous configurez votre nom de domaine pour que celui-ci pointe vers votre IP publique (ce qui peut prendre entre 30 minutes et 72 heures) une seule fois. A chaque changement de serveur, vous pourrez faire la modification d’IP rapidement, ce qui évite d’avoir des sites hors ligne de manière hasardeuse pendant quelques temps.

Commandez-donc votre IP fail-over que vous allez faire rediriger vers l’IP de votre serveur S1. Malheureusement, pour le moment, si vous tentez de vous connecter à cette IP, le serveur ne répondra pas. En effet, il va nous falloir configurer S1 et S2 pour accepter le traffic provenant de cette IP qui n’est pas la leur.

Pour cela, faites la manipulation suivante sur vos deux serveurs. Allez modifier le fichier « /etc/network/interfaces » et rajoutez les lignes suivantes à la fin du fichier :

post-up /sbin/ifconfig eth0:X 1.2.3.4 netmask 255.255.255.255 broadcast 1.2.3.4
post-down /sbin/ifconfig eth0:X down

Pensez à bien changer l’IP « 1.2.3.4 » (2 fois) par votre IP Fail-Over (IP publique). Puis lancez la commande :

/etc/init.d/network restart

Une fois que vous avez fait cette manipulation sur le S1, celui-ci devrait être accessible depuis son IP Publique. Mais n’oubliez pas de faire la même chose sur votre S2, sinon vous risquez d’avoir quelques soucis lors de votre premier basculement (et hop, un site hors ligne …).

Etape 3 – Configuration du nom de domaine

Cette étape là est relativement simple et à vrai dire, vous n’êtes pas forcément obligé de faire comme moi. Je vous conseille juste de prendre quelques précautions afin de pouvoir développer au mieux votre projet et de pouvoir cibler rapidement le moindre bug.

Nous allons donc configurer notre nom de domaine pour que celui-ci redirige vers l’IP publique de notre projet mais également des accès directs aux S1 et S2.

@ A [IP Publique]
www A [IP Publique]
s1 A [IP Privée S1]
s2 A [IP Privée S2]

Ainsi, quand vous venez de créer les redirections suivantes :

www.votredomaine.com ==> IP Publique
votredomaine.com ==> IP Publique
s1.votredomaine.com ==> IP privée S1
s2.votredomaine.com ==> IP privée S2

Ce qui vous permettra de configurer votre IP publique mais aussi d’avoir un accès direct au serveur de votre choix (pour la gestion de la BDD par exemple).

Mais il faut maintenant configurer correctement apache de vos deux serveurs. Ainsi sur S1, modifier votre fichier vhost :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s1.votredomaine.com

Et sur votre s2 :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s2.votredomaine.com

Votre nom de domaine, une fois la propagation DNS effectuée, sera convenablement configuré pour votre PRA.

Etape 4 : Réplication de la base de données

Là, je vous invite simplement à relire l’article suivant : [Tuto] Réplication base de données avec PHPMyAdmin.

Etape 5 : Réplication des fichiers

« Et maintenant, le coeur de la maison, la cuisine » Ou du moins la plus importante, la réplication des fichiers de s1 vers s2. Pour cela, nous allons utiliser Unison, qui va assurer la synchronisation de deux répertoires toutes les X minutes à l’aide d’un cron.

La première des choses à faire est de créer un tunnel SSH entre S1 et S2 et encore une fois, je vous renvoi vers ce tutoriel : [Tuto] Créer un tunnel SSH entre deux serveurs Debian.

Nous allons ensuite installer unison sur les deux machines :

apt-get install unison

Unison s’occupe donc de synchroniser les deux répertoires. Il va aller vérifier que tous les fichiers sont présents et sont les mêmes. S’ils ont été modifiés, vous pouvez configurer Unison de deux manières différentes:

  • Newer : C’est le dernier fichier qui a été créé qui est considéré comme le bon fichier.
  • Force : Vous déterminez quel serveur est considéré comme référent.
Dans notre cas, nous allons toujours utiliser la méthode « Force » pour deux raisons :
  1. Nous ne ferons nos développements que sur S1 et nous laisserons le soins à Unison de mettre à jour S2. Ca évite toute erreur.
  2. Unison ne sait pas supprimer les fichiers en mode Newer. En effet, si vous supprimez le fichier sur s1, il va le remplacer par celui présent sur s2 en le considérant comme plus récent (ce qui est logique) ce qui va donc vous causer des soucis.
Le but est donc de forcer la mise à jour du répertoire /var/www de S1 sur S2 toutes les X minutes. Pour cela, nous allons créer le fichier de configuration sur S1 pour Unison : Créez le répertoire /root/.unison/ et le fichier /root/.unison/default.prf :

# On force les modifications en cas de conflit
auto=true
batch=true

# Si tout le répertoire sur s1 est vide, on empêche la mise à jour de s2 (question de sécurité)
confirmbigdeletes=true

# On accepte de se contenter de la vérification du nom du fichier et de sa taille pour la comparaison des fichiers au lieu d’aller vérifier tout son contenu (c’est nettement plus rapide).
fastcheck=true

# On garde le même propriétaire des fichiers
group=true
owner=true

# On force la mise à jour de S2 depuis S1 en cas de conflit entre deux fichiers
prefer = /var/www

# On demande à Unison de ne rien ressortir de ses actions (puisqu’on va l’effectuer avec un cron, c’est inutile)
silent=true

# On demande à ce que l’heure de modification des fichiers soit aussi synchronisée (pour avoir réellement les mêmes données sur les deux serveurs
times=true

Nous allons pouvoir tester notre configuration et voir si tout marche bien manuellement. Pour cela, créez un fichier vide sur S1 mais pas sur S2 dans votre répertoire /var/www/ puis testez la commande suivante

 root@s1:~# unison /var/www ssh://[IP Privée S2]//var/www

C’est la première fois que vous lancez unison donc il se peut qu’il soit un peu bavard mais cela n’a pas d’importance. Si vous allez sur S2, vous devriez voir apparaître votre fichier. Pour aller un peu plus loin dans les vérifications, modifier le contenu de votre fichier sur S1 et relancez la commande. Normalement, Unison ne dit plus rien et le contenu du fichier a bien été modifié sur S2. Refaite le test en modifiant le fichier sur S2, relancez la commande et vérifiez que le fichier sur S1 n’a pas été modifié et que celui sur S2 a bien été écrasé par celui du S1. Et enfin supprimez le fichier sur S1 puis relancez la commande pour vérifier qu’il disparaît bien sur S2.

Nous pouvons maintenant automatiser cette commande à l’aide d’un cron. Pour cela, toujours sur S1, tapez la commande suivante pour ouvrir la console de gestion de vos tâches cron :

root@s1:~# crontab -e

Et ajoutez la ligne suivante :

*/1 * * * * unison /var/www ssh://[IP Privée S2]//var/www &> /dev/null

ici, la synchronisation s’exécute toutes les minutes (la ligne commence par */1). Une mise à jour aussi fréquente n’est pas nécessaire. Cela dépend totalement de votre type de projet. Si votre projet modifie des fichiers (en y stockant des données par exemple) alors oui, une synchronisation régulière est primordiale. Mais celle-ci étant lourde, si vos fichiers ne sont pas modifiés, n’hésitez pas à choisir des intervalle de synchronisation plus longs pour éviter de fatiguer votre serveur pour rien. Testez votre cron en modifiant un de vos fichiers sur S1 dans /var/www/ et vérifiez que celui-ci est répercuté sur S2 après l’intervalle de temps de votre cron.

Maintenant, si les tests sont concluants, alors bravo, vous venez de monter votre propre PRA.

Conclusion

Développez votre projet sur S1, toujours, ne touchez jamais à S2 sauf pour vérifier de temps en temps que tout fonctionne parfaitement (notamment du côté de la base de donnée). Dès que votre S1 a un problème et que vous êtes obligé de le mettre hors ligne, basculez votre IP Publique vers l’IP privée de votre S2 pour que celui-ci prenne la relève. Vous venez d’assurer à votre projet la sauvegarde intégrale de ses données en temps réelle et ça, ce n’est pas négligeable pour des sites importants.