Lors de mon précédent article, j’ai expliqué comment substituer l’IP d’un serveur avec une IP Fail Over sans interruption de service. Les raisons de l’utilisation de ces IP sont multiples, dans mon cas c’est pour permettre le basculement sur une autre machine en cas de panne ou pour faire des mises à jour sur la machine principale.

Pour permettre cela, je configure bien évidement une nouvelle machine pour qu’elle réponde également sur la même adresse IP. Je refais l’installation de tous les sites, c’est-à-dire la reconfiguration des virtualhosts, accès SSH, base de données, et cetera. C’est ce que j’appelle une installation miroir, en d’autres termes, deux machines peuvent rendre le même site internet via le même domaine.

Je travaille beaucoup avec WordPress où il y a tout le côté synchronisation de base de données. C’est donc, dans la plupart des cas, plus rentable pour moi de configurer les sites pour qu’ils ne rendent simplement qu’une page de maintenance.

La mise en place d’IP Fail Over entraine une problématique qui est l’impossibilité de choisir localement vers quelle machine on pointe en changeant son fichier hosts (ici je parle de l’IP FO d’un site web et pas de l’IP de la machine), puisqu’elles auront toutes les deux la même adresse IP.

Voici une infrastructure simple avec deux serveurs où je m’apprête à mettre Fail Over. J’accède au serveur 1 via la résolution de nom classique (DNS) ou bien je peux décider de pointer sur la machine 2 en changeant mon fichier de hosts.

Si je mets en place IP Fail Over et que je veux tester le site sur la deuxième machine avec son adresse IP finale, c’est-à-dire l’IP FO, je ne peux pas le faire en changeant mon fichier hosts comme précédemment. Je perds cette capacité, car je n’ai aucun pouvoir sur le switcher, à part de dire sur quelle instance je veux que ça pointe, mais ce sera global pour tout le monde.

Mettre en place un serveur miroir avec un site web configuré sur l’IP Fail Over implique donc de le faire de la bonne manière et dans le bon sens pour s’éviter des surprises. C’est-à-dire aller le plus loin possible avant de ne plus pouvoir tester de manière isolée.

Je considère ici que tu as deux machines, qu’une IP FO est en ta possession et que tu as sauvegardé tout ce qu’il fallait.

La première chose à faire est ajouter l’IP sur les interfaces réseaux des deux machines. Et penser aussi à configurer le firewall de l’IP Fail Over comme ça tu démarres bien.

Seconde étape, configurer le site web sur le serveur miroir avec l’IP FO, c’est-à-dire configurer le virtualhost pour que ce site écoute sur l’IP Fail Over. Au niveau du site, soit tu fais une petite page web qui retourne un blabla indiquant que le site est en maintenance, soit tu clones le site, tout dépendra de ce que tu cherches à avoir derrière.

Tu devras peut-être mettre une redirection d’URLs (dans le cas d’un serveur de maintenance) et peut-être bloquer l’indexation des moteurs de recherche.

Ensuite, changer ton fichier de hosts pour pointer sur l’IP Fail Over et tester ta page web.

Si ton application est en HTTPS, tu devras remettre ton certificat SSL. Via Let’s Encrypt, tu pourras normalement avoir un certificat facilement avec une validation par challenge DNS (tu devras ajouter une entrée DNS)

Maintenant que tu sais que ton serveur miroir rend la page web que tu désires et que tout est fonctionnel, tu peux enlever la configuration locale que tu avais mis dans ton fichier hosts. Il va falloir configurer le site sur la machine principale pour qu’il réponde depuis deux adresses IP, du moins si tu ne souhaites pas d’interruption de service, car tu vas devoir changer la zone DNS et il y aura un temps de propagation.

Lorsque la propagation DNS est terminée, change la configuration du site pour qu’il ne réponde que sur l’IP FO. Dorénavant, tu pourras basculer l’IP Fail Over de ton serveur principal vers le serveur miroir et inversement (depuis la console OVH).

Ton serveur miroir fonctionne, tu peux désormais basculer ton IP entre deux instances, félicitations. Au début je pensais mettre uniquement en place Fail Over pour pouvoir gérer les incidents sur data center, mais je me rends compte que je l’utilise pour de plus en plus de choses, telles que la sécurité, la montée en charge verticale, les mises à jour et je trouve que c’est un outil formidable.