Dans la première partie de ce blog, nous avons configuré HAProxy sur un nœud Virtual Load Balancer sur E2E Cloud. Nous avons également configuré HAProxy pour acheminer les requêtes vers des serveurs Web principaux à l'aide d'une politique de tourniquet.
Dans cette deuxième et dernière partie de ce blog, nous passerons en revue quelques paramètres de configuration avancés dont la plupart des sites Web ont besoin :la permanence de la session et l'accès sécurisé au site Web à l'aide de SSL. Mais avant cela, nous allons montrer comment notre instance HAProxy unique peut répondre à un grand site Web avec de nombreuses applications Web, grâce aux ACL. Pendant ce temps, nous aborderons quelques options de configuration supplémentaires, telles que la politique de répétition alternée pondérée, et conclurons avec des pointeurs vers d'autres considérations importantes pour un déploiement en production.
Configuration de l'équilibreur de charge pour plusieurs applications Web
De nombreux grands sites Web se composent de plusieurs clusters de serveurs Web, chaque cluster hébergeant une application Web différente. Par exemple, il peut y avoir un site Web avec un contenu principal ainsi qu'un site Web pour le plaisir et le divertissement. HAProxy est capable d'acheminer les requêtes vers le bon cluster en fonction des modèles d'URL et des listes de contrôle d'accès (ACL).
Pour illustrer cette capacité, nous créons d'abord deux nouveaux nœuds de serveur Web sur le cloud E2E, nommés "webserver3" et "webserver4". Comme d'habitude, nous installons le serveur Web Apache et les packages PHP sur les deux nouveaux nœuds. Ensuite, nous déployons une deuxième application PHP à l'URL '/fun/films.php' sur ces deux nœuds nouvellement ajoutés uniquement . (La deuxième application utilise la persistance de session et sa fonctionnalité sera expliquée dans la section suivante.)
Nous avons donc les nœuds suivants (4 serveurs Web et un équilibreur de charge) visibles sur notre tableau de bord :
Figure 1 :Serveurs Web pour plusieurs applications Web
Ainsi, HAProxy doit acheminer les demandes des clients pour l'URL '/fun/films.php' vers l'un des nœuds 'webserver3' et 'webserver4' uniquement, sinon la demande ne peut pas être traitée du tout. Pour répondre à cette exigence, nous modifions la configuration de HAProxy (/etc/haproxy/haproxy.cfg) et créons un backend supplémentaire (appelé "films") composé uniquement des deux nouveaux nœuds de serveur Web. Ceci s'ajoute au backend existant nommé 'site'.
Figure 2 :Configuration du backend pour une nouvelle application
Ensuite, dans la configuration frontale existante, nous introduisons une ACL comme indiqué ci-dessous. Cela signifie que tout chemin d'URL commençant par '/fun' sera acheminé vers le backend nommé 'films', alors que par défaut toutes les autres requêtes atterriront sur le backend (préexistant) nommé 'site' (constitué de nœuds 'websrv1' et 'websrv2' uniquement).
Figure 3 :Configuration frontale avec ACL
Figure 4 :Équilibrage de charge HAProxy avec ACL
Paramètres de configuration avancés
Politique de tournoi à la ronde pondérée :Lors des modifications apportées aux ACL, nous avons introduit une pondération à chaque serveur. En production, différents serveurs peuvent avoir une puissance de calcul différente, donc l'utilisation de pondérations permet à HAProxy d'acheminer plus de requêtes vers des serveurs plus puissants. (Dans notre cas, tous les nœuds de serveur Web sont similaires et tous les poids sont égaux, mais nous pouvons l'utiliser comme modèle et le modifier dans un scénario différent.)
Nombre maximal de connexions par serveur :Deuxièmement, nous avons également utilisé le paramètre 'maxconn' au niveau du serveur backend , afin que chaque serveur puisse limiter le nombre de connexions à ce qui est raisonnable pour sa puissance de traitement. Le « maxconn » global doit être supérieur à la somme totale des valeurs au niveau du serveur de ce paramètre (ce qui laisse de la place pour que d'autres nœuds de serveur Web soient ajoutés à des fins d'évolutivité).
Résistance à la session
La nouvelle application PHP utilise des sessions PHP. Chaque fois qu'un client accède à cette application, il fournit le nom d'un film préféré (via un paramètre HTTP GET nommé "fav"), qui est ajouté à la session PHP. Le serveur répond avec la liste des films préférés (unique à chaque client) recueillis jusqu'à présent.
- session_start();
- $fav =$_GET[‘fav’] ;
- si ( isset( $_SESSION[‘favoris’] ) ) {/li>
- $_SESSION[‘favoris’] .=‘ , ‘;
- $_SESSION[‘favoris’] .=$fav ;
- } autre {
- $_SESSION[‘favoris’] =$fav ;
- }
- $msg =‘Mes films préférés :‘. $_SESSION[‘favoris’] ;
- ?>
-
Mes films préférés - echo $msg ;
- ?>
Les sessions PHP peuvent être locales à une instance de serveur Web (sauf si la persistance ou la réplication de session sont activées). Ainsi, si le même client est acheminé de manière aléatoire vers différentes instances de serveur Web principal à des moments différents, lorsqu'il effectue une série de demandes, ses données de session peuvent devenir imprévisibles. Mais un client peut être contraint de "s'en tenir ' à une seule instance de serveur Web pendant la durée d'une session.
Une façon de configurer cela dans HAProxy est d'introduire le paramètre 'appsession' dans la configuration du backend concerné ('films' , dans notre cas). Différents types d'applications utilisent différents cookies HTTP pour la gestion des sessions. Dans le cas d'applications PHP, ce cookie est nommé « PHPSESSID ». En définissant 'appsession', HAProxy associe un seul serveur Web à chacun « PHPSESSID » (celui où cette session a été créée) et achemine les demandes répétées des clients contenant le même identifiant de session vers ce même serveur Web, tant qu'il est opérationnel ou que la session a expiré .
- appsession PHPSESSID len 32 timeout 1h
Bien sûr, si ce serveur Web devient indisponible pour une raison quelconque, HAProxy devrait être libre d'acheminer les requêtes avec le même identifiant de session vers une autre instance de serveur actif. Cela peut être assuré en ajoutant l'option 'redispatch' dans la section 'defaults' du fichier de configuration HAProxy.
- option réexpédition
Test
Nous pouvons désormais tester à la fois les ACL et la permanence de la session. Nous pouvons suivre les journaux HAProxy sur le nœud de l'équilibreur de charge :
- tail -f /var/log/haproxy.log
Nous suivons également les journaux d'accès au serveur Web sur chacun des nœuds "webserver3" et "webserver4".
1. tail -f /var/log/apache2/access.log
Depuis deux machines clientes différentes, nous envoyons des requêtes à l'URL suivante à partir d'un navigateur :http://
Dans chaque requête, nous pouvons définir une valeur différente pour le paramètre de requête nommé "fav".
Dès le premier client, nous envoyons les requêtes successives suivantes :
- http://
/fun/films.php?fav=avengers - http://
/fun/films.php?fav=jurassicworld
La fenêtre du navigateur du premier client affichera :
Figure 5 :une session client
Depuis le deuxième client, nous envoyons les requêtes successives suivantes :
- http://
/fun/films.php?fav=race3 - http://
/fun/films.php?fav=gold
La fenêtre du navigateur du deuxième client affichera :
Figure 6 :Une autre session client
D'après la réponse affichée dans chaque navigateur client, il est clair que les sessions sont maintenues correctement dans chaque cas. Dans Firefox, depuis la console Web, nous pouvons également inspecter les valeurs PHPSESSID.
Nous pouvons faire les deux observations suivantes à partir des journaux HAProxy et du serveur Web :
- Ces requêtes avec le modèle d'URL "/fun" sont acheminées vers le backend nommé "films" uniquement (règles ACL)
- Une requête provenant de la même adresse IP client arrive sur le même nœud de serveur Web (permanence de la session)
Figure 7 :Journaux HAProxy avec sessions persistantes
Figure 8 :Accéder aux journaux sur le nœud webserver3 avec des sessions permanentes
Figure 9 :Accéder aux journaux sur le nœud webserver4 avec des sessions permanentes
Sécurité :Terminaison SSL
Une dernière mais cruciale configuration que nous aimons aborder est liée à la sécurité. Les serveurs Web Apache peuvent être configurés pour prendre en charge HTTPS, mais lorsque HAProxy est installé sur le frontend, les demandes des clients atterriront d'abord sur l'équilibreur de charge.
Il est donc recommandé de configurer HAProxy pour prendre en charge HTTPS. Il s'agit d'un processus en quatre étapes :
- Obtenez un certificat SSL pour notre site Web. À des fins expérimentales, nous avons créé un certificat auto-signé nommé haproxy.pem en utilisant openssl
- Liez le frontend à un port HTTPS (par défaut 443) et attribuez le certificat SSL à ce frontend
- Activer HAProxy pour rediriger les requêtes client envoyées via HTTP vers le port HTTPS
- Ajouter ou définir les en-têtes requis à la requête HTTP à chaque des backends configurés
Les trois premières étapes ci-dessus sont implémentées au niveau du frontend. (Nous avons renommé notre interface en "alltraffic" au lieu de "httptraffic".)
Figure 10 :Configuration frontale pour SSL
La quatrième étape ci-dessus est mise en œuvre à chaque back-end :
Figure 11 :Configuration du backend pour SSL
Généralement, les en-têtes X-Forward-Port et X-Forward-Proto aident l'application à créer correctement l'URL lorsque les requêtes HTTP et HTTPS sont possibles.
L'arrêt de SSL au niveau du nœud d'équilibrage de charge crée une surcharge de traitement au niveau de ce nœud (par rapport au relais de la demande chiffrée vers les backends). Il existe un paramètre lié à l'algorithme de chiffrement sous-jacent utilisé. Une valeur plus élevée augmente la surcharge de traitement sur le nœud HAProxy. Il peut être défini dans la section "global" de la configuration HAProxy :
- tune.ssl.default-dh-param 2048
Ainsi, les requêtes chiffrées SSL se terminent au niveau de l'équilibreur de charge, qui achemine les requêtes HTTP non chiffrées vers les serveurs Web principaux.
Figure 12 :Terminaison SSL
Paramètres du pare-feu
Nous devons ouvrir le port 443 sur le nœud de l'équilibreur de charge virtuel (fonctionnant sur CentOS), en exécutant la commande :
- iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state NEW,ETABLISHED -j ACCEPT
- systemctl redémarre iptables
Test
Nous essayons maintenant d'accéder à notre application PHP Greeter via un navigateur (Firefox), en pointant sur le HTTP non sécurisé URL :
http://
Même alors, Firefox nous demandera d'ajouter une exception de sécurité, indiquant que le client est transféré vers l'URL HTTPS sécurisée . Ceci est également indiqué dans la barre d'adresse du navigateur lui-même.
Figure 13 :Accéder à l'application Web via SSL
Création d'images de machine et surveillance
Astuce :Beaucoup d'efforts ont été consacrés à la configuration de l'instance d'équilibreur de charge virtuel. Une image machine de ce nœud peut être enregistrée afin que des instances d'équilibreur de charge similaires puissent être créées à l'avenir en l'utilisant comme modèle. Sur E2E Cloud, cela peut être réalisé en fermant d'abord le nœud HAProxy, puis en enregistrant une image de ce nœud à partir du tableau de bord.
Figure 14 :Enregistrement de l'image machine HAProxy
Figure 15 :Création d'une image machine à partir du nœud HAProxy
En option, une image machine des instances de serveur Web peut également être enregistrée.
Surveillance à l'aide de Zabbix :Le nœud HAProxy, comme tout autre nœud virtuel sur le Cloud E2E, peut être surveillé à l'aide de Zabbix. Nous devrions tirer parti de cette capacité.
Figure 16 :Surveillance de l'intégrité de l'équilibreur de charge
Conclusion et prochaines étapes
E2E Cloud propose des nœuds Virtual Load Balancer pour configurer l'équilibrage de charge à l'aide de HAProxy. Dans ces deux blogs, nous avons examiné comment une installation HAProxy sur E2E Cloud peut être configurée pour prendre en charge l'équilibrage de charge circulaire pour les sites Web multi-applications simples et volumineux avec permanence de session et accès sécurisé via HTTPS.
Nous terminerons ce blog en prenant note de quelques autres considérations pour un déploiement en production :
- Tout d'abord, le nœud Virtual Load Balancer (et éventuellement les nœuds du serveur Web) doit être lié à un domaine à l'aide des paramètres DNS appropriés
- En conséquence, le certificat SSL pour un accès sécurisé à l'instance HAProxy doit être lié au même domaine
- Enfin, l'équilibreur de charge ne doit pas devenir un point de défaillance unique. Ainsi, un déploiement actif-passif de HAProxy peut être recommandé.