Ne jamais
tomber

Acte 7 : balancer la charge entre deux caches, doubler la passerelle, et donner au site une adresse qui survit à tout.

Chaque étage ajouté est un nouveau point de faille

La cache a tout accéléré... et tout concentré : chaque visiteur passe désormais par varnish30. Si cette machine tombe, le site tombe avec elle, même si Apache et MySQL se portent à merveille. L'entreprise fait le grand geste de la haute disponibilité : traquer chaque point de faille unique, et le doubler.

• Objectif du jour : le balancement de charge avec HAproxy, et la relève automatique avec Heartbeat.

Le balancement de charge

HAproxy est une passerelle qui reçoit tous les visiteurs et les répartit entre plusieurs serveurs identiques. Deux caches Varnish au lieu d'une : deux fois la capacité, et la panne de l'une n'arrête plus rien.

• roundrobin : chacun son tour, la répartition la plus simple.
• check inter 10s : HAproxy sonde ses serveurs; un serveur mort est retiré de la rotation tout seul, et revient tout seul quand il guérit.

Anatomie de haproxy.cfg

L'ordre est la grammaire : les options globales, puis les frontend (les portes), puis les backend (les groupes de serveurs). Et avant chaque redémarrage : haproxy -f ... -c vérifie le fichier.

Le cas WordPress : l'admin à part

Le blog public se balance à volonté. Le panneau d'administration, lui, préfère un seul serveur stable : sessions, téléversements, cohérence.

Les acl sont les aiguillages de la passerelle : certains chemins méritent un traitement particulier. C'est la leçon des applications web modernes.

Le point de faille est remonté d'un étage

• Deux Varnish, un HAproxy : la passerelle est maintenant LE point par où tout passe. Si elle tombe... tout tombe.
• La parade : un deuxième HAproxy, identique, en attente. Un serveur actif (maître), un serveur passif (esclave) : le failover.
• Mais les visiteurs ne connaissent qu'une adresse... il faut donc une adresse qui puisse changer de machine.

Heartbeat et l'adresse IP virtuelle

Heartbeat met les deux HAproxy en grappe. La grappe détient une IP virtuelle (référence : 192.168.56.49) : c'est elle que les visiteurs utilisent, et c'est le serveur vivant qui la porte.

• Les deux serveurs s'écoutent battre le coeur (keepalive 1 s); au bout de 10 secondes de silence, l'esclave déclare le maître mort et prend l'IP virtuelle.
• Trois fichiers, identiques sur les deux machines : ha.cf (les noeuds et les délais), authkeys (le secret partagé, chmod 600), haresources (qui est maître, et quelle IP porter).
• auto_failback yes : le maître guéri reprend sa place tout seul.

L'épreuve de vérité

Vendredi soir, heure de pointe. Le HAproxy maître meurt. Dix secondes plus tard, l'esclave porte l'IP virtuelle, et pas un visiteur ne s'est aperçu de quoi que ce soit. Voilà la haute disponibilité : non pas empêcher les pannes, mais les rendre invisibles.

• C'est exactement le test de l'énoncé : test de charge BRUTAL, on éteint le maître, WordPress doit continuer de répondre.
• Et il sera rejoué en classe, devant tout le monde, à la démonstration.

Avant de passer au laboratoire

• HAproxy répartit (roundrobin), surveille (check) et aiguille (acl) : l'admin WordPress a son chemin réservé.
• Doubler la passerelle exige une adresse qui bascule : l'IP virtuelle portée par la grappe Heartbeat.
• La haute disponibilité ne supprime pas les pannes : elle les rend invisibles.

Au laboratoire : le plus gros montage de la session à ce jour. Six instances, deux étages doublés, et l'épreuve du maître éteint sous charge. Le grand frisson.