Doubler
tous les étages
Deux Varnish, deux HAproxy, une IP virtuelle, et un maître qu'on éteint sous charge : le laboratoire 3 de l'Application distribuée.
420-5A4-MT · Acte 7 · Ne jamais tomberCornucopia · Expansion Régionale & Délais Critiques
Garantir un accès ininterrompu aux maraîchers, aux livreurs et aux abonnés : le système doit survivre à la défaillance physique soudaine d'un serveur web ou d'une passerelle.
- Objectif de disponibilité : 99,9 % du temps en ligne.
- Élimination de chaque point de faille unique (SPOF).
Panne du reverse proxy : Keepalived et l'IP flottante !
Sur le terrain
99,9 % de temps en ligne
Si l'unique passerelle Varnish/HAProxy plante ou subit une coupure de courant, tous les serveurs web derrière deviennent inaccessibles !
Rapport du terrain
Point de faille unique sur le point d'entrée réseau du domaine de la ferme.
Monter deux passerelles HAProxy redondantes orchestrées par Keepalived. L'IP virtuelle bascule automatiquement en moins de 1 seconde sans déconnexion !
La mission du jour
À la fin de la séance, vous aurez :
- Un deuxième Varnish (varnish31) et un balanceur HAproxy (haproxy40) qui répartit entre les deux.
- L'admin WordPress aiguillé vers un chemin réservé (acl).
- Un deuxième HAproxy (haproxy41) et la grappe Heartbeat qui porte l'IP virtuelle (référence : 192.168.56.49).
- Réussi l'épreuve : maître éteint sous charge, WordPress répond encore.
- Le tout mesuré (parties 4 et 5) et dans Git : /votre-depot/balancement/
C'est le laboratoire le plus payant du module (10 points) et le plus dense : deux semaines de techniques en une. Minimum 2 commits pertinents en classe cette semaine.
HAproxy et Heartbeat : balancer, puis ne jamais tomber
Partie HAproxy. Ajoutez à votre ensemble existant :
- Une seconde instance de cache Varnish en avant de votre serveur HTTP.
- Une instance qui offre le balancement de la charge HAproxy en avant de vos serveurs Varnish.
- Modifiez l'URL d'accès de WordPress pour utiliser l'adresse HAproxy.
Partie Heartbeat. Puis :
- Une seconde instance HAproxy en avant de vos serveurs Varnish.
- Un Heartbeat sur vos instances HAproxy qui assure la haute disponibilité et procure une IP virtuelle à la grappe de serveurs.
- Modifiez l'URL d'accès de WordPress pour utiliser l'IP virtuelle de la grappe.
- L'épreuve de vérité : lancez un test de charge BRUTAL et éteignez le HAproxy maître. WordPress doit continuer de répondre. (Ce test sera reproduit en classe pour l'évaluation.)
Mesures : pour chaque partie, test de charge BRUTAL, captures top à 10 et 60 secondes (parties 4 et 5), tableau rempli.
Barème : guide d'installation (4), fichiers de configuration (2), tableau rempli (2), captures d'écran (2).
Minimum 2 commits pertinents en classe durant la semaine 8; le reste avant le cours de la semaine 9. Ce laboratoire doit être entièrement terminé pour le début de la semaine 9. Note selon l'infra : l'IP virtuelle se configure différemment en VirtualBox (réseau hôte), en DinD (réseau Docker) et en VPS (IP partagée du fournisseur); le coup de main par infra est donné en classe.
HAproxy
HAproxy
La mise en place
- Ajouter les services suivants à votre ensemble de serveurs existants avec les mêmes caractéristiques précédentes :
- Un second serveur qui offre le service de cache Varnish en avant de votre serveur HTTP (apache).
- Un serveur qui offre le service de balancement de la charge HAproxy en avant de vos serveurs varnish.
- Modifier l'URL d'accès de WordPress pour utiliser l'IP du serveur haproxy.
Le test de charge BRUTAL
- Faire un test de charge BRUTAL avec JMeter pour documenter les performances de votre ensemble de serveurs actuel.
- Faire une seule capture d'écran statique de la commande top exécutée en ssh de tous les serveurs actifs après environ 10 secondes de test (performances_partie_4_10secondes.png).
- La même chose après environ 60 secondes de test (performances_partie_4_60secondes.png).
- Noter dans un tableau la valeur idle du processeur (id) pour chaque serveur.
- Noter dans un tableau la valeur moyenne (temps moyen de réponse) indiquée par JMeter.
Heartbeat
Heartbeat
La mise en place
- Ajouter les services suivants à votre ensemble de serveurs existants avec les mêmes caractéristiques précédentes :
- Un second serveur qui offre le service de balancement de la charge HAproxy en avant de vos serveurs varnish.
- Un Heartbeat sur vos serveurs HAproxy qui assure la haute disponibilité et procure une IP virtuelle à la grappe de serveurs.
- Modifier l'URL d'accès de WordPress pour utiliser l'IP virtuelle de la grappe haproxy.
Le test de charge BRUTAL
- Faire un test de charge BRUTAL avec JMeter pour documenter les performances de votre ensemble de serveurs actuel.
- Faire une seule capture d'écran statique de la commande top exécutée en ssh de tous les serveurs actifs après environ 10 secondes de test (performances_partie_5_10secondes.png).
- La même chose après environ 60 secondes de test (performances_partie_5_60secondes.png).
- Noter dans un tableau la valeur idle du processeur (id) pour chaque serveur.
- Noter dans un tableau la valeur moyenne (temps moyen de réponse) indiquée par JMeter.
Faire un test de charge BRUTAL et éteindre le serveur haproxy maître : WordPress doit continuer de répondre. (Ce test sera reproduit en classe pour l'évaluation.)
Le deuxième Varnish
- Créer varnish31 (référence : 192.168.56.31), idéalement en clonant varnish30 : même configuration, nouvelle identité.
- Rappel clonage : adresse MAC, nom d'hôte, adresse IP, et l'adresse d'écoute dans varnish.service.
- Vérifier : les deux caches servent le site chacune par leur adresse.
HAproxy balance entre les deux caches
WordPress derrière la passerelle, l'admin à part
- Modifier l'URL d'accès de WordPress : c'est maintenant l'adresse de HAproxy que le monde connaît.
- Ajouter au frontend les acl wp-admin et wp-login, et le backend admin_servers (balance source, vers http20).
- Mesurer : test BRUTAL, captures performances_partie_4_*.png, ligne 4 du tableau.
| secondes / serveur | HTTP | MYSQL | VARNISH-1 | VARNISH-2 | HAPROXY | temps moyen de réponse (seconde) |
|---|---|---|---|---|---|---|
| 10 secondes | ||||||
| 60 secondes |
Amusez-vous à éteindre varnish31 pendant que vous rafraîchissez le site : check inter fait son travail, le site ne bronche pas. Premier avant-goût de la suite.
La grappe Heartbeat
Pièges connus : les noms des noeuds doivent correspondre à uname -n (fichier hosts à l'appui); et sur Ubuntu récent, l'interface par défaut du script IPaddr doit devenir enp0s8. Le coup de main est donné en classe.
HAproxy adopte l'IP virtuelle
- Si le ping répond, la grappe vit. (Ça prend quelques secondes au démarrage.)
- Dernier déménagement de WordPress : son URL devient l'IP virtuelle. C'est la dernière fois, promis : cette adresse-là ne meurt jamais.
Éteindre le maître sous charge
- Lancer le test de charge BRUTAL contre l'IP virtuelle.
- Éteindre brutalement haproxy40, le maître.
- Observer : quelques secondes de flottement... et le site répond encore, porté par haproxy41.
- Mesures de la partie 5 : captures performances_partie_5_*.png, dernière ligne du tableau.
- Rallumez le maître : auto_failback le remet en selle tout seul.
| secondes / serveur | HTTP | MYSQL | VARNISH-1 | VARNISH-2 | HAPROXY-1 | HAPROXY-2 | temps moyen de réponse (seconde) |
|---|---|---|---|---|---|---|---|
| 10 secondes | |||||||
| 60 secondes |
Ce test sera reproduit en classe pour l'évaluation. Répétez-le jusqu'à ce qu'il soit ennuyeux : c'est à ce moment-là qu'il est prêt.
HAproxy · Heartbeat
- (4 points) sa version de son guide d'installation
- (2 points) les fichiers de configurations utilisés
- (2 points) le tableau rempli
- (2 points) les captures d'écran
Un minimum de 2 commits pertinents doit être effectué en classe durant la semaine 3, les autres devant être complétés avant le cours de la semaine 4. Ce laboratoire doit être entièrement terminé pour le début de la semaine 4.
Livrables et devoir
- Dans Git : guide, configurations (haproxy.cfg, ha.cf, authkeys expurgé, haresources), tableau, captures. Pour chaque étudiant.
- Six instances vivantes : mysql10, http20, varnish30, varnish31, haproxy40, haproxy41. Votre première vraie grappe.
- Devoir : terminer avant la semaine 9, où cette architecture déménagera sur de vraies machines qu'on peut toucher.
La semaine prochaine, l'acte 8 : le monde réel. En équipe, un cluster de Raspberry Pi, et la panne qu'on provoque en débranchant un fil, pour de vrai.