Utilisation de HAProxy pour l'équilibrage de charge sur E2E Cloud :configuration de la stratégie Round-Robin

HAProxy est un équilibreur de charge open source aux performances très impressionnantes. Il est utilisé pour les applications Web frontales, même à l'échelle planétaire, comme Twitter. Il peut équilibrer la charge des applications en réseau sur TCP (couche 3) et HTTP (couche 7). Il bascule également les requêtes vers les instances de serveur actives si nécessaire, et offre donc une haute disponibilité (HA).

E2E Networks propose des nœuds désignés avec une puissance de calcul adaptée à l'exécution d'un équilibreur de charge hautes performances comme HAProxy. Ces nœuds sont appelés nœuds Virtual Load Balancer (VLB). Dans ce blog, nous expliquerons comment configurer HAProxy sur un nœud Virtual Load Balancer sur E2E Cloud. Nous utiliserons HAProxy au niveau 7, pour les applications PHP frontales exécutées sur les serveurs Web Apache. Dans la deuxième et dernière partie de ce blog, nous passerons en revue quelques étapes supplémentaires que la plupart des administrateurs de sites Web doivent effectuer, en plus de la configuration de base. Ces étapes supplémentaires sont :la mise en œuvre de la permanence de la session et la sécurisation de l'accès au site Web à l'aide de SSL. Dans une large mesure, ces deux blogs sont autonomes et ensemble, ils devraient aider les administrateurs système à configurer facilement HAProxy en tant qu'équilibreur de charge frontal pour les applications Web déployées sur E2E Cloud.

Installation et configuration de base

Bien que nous nous concentrions sur HAProxy, nous commencerons par l'installation de deux serveurs Web, vers lesquels les requêtes HTTP peuvent être acheminées. Après vous être connecté à notre tableau de bord des réseaux E2E, nous suivons les liens vers "Créer un nœud" et choisissons une distribution Ubuntu 16.04 avec 1 CPU et 2 Go de RAM . Laissez ce nœud de calcul virtuel être nommé 'websrv1 ‘. Ensuite, nous créons un autre nœud identique pour installer une deuxième instance de serveur Web, nommée 'websrv2 ‘. Sur chaque nœud de serveur Web, nous installons Apache 2.4 et PHP, en exécutant les commandes suivantes sur le terminal (de chaque nœud de serveur Web) :

1. apt-obtenir la mise à jour 
2. apt-get install apache2 # installe le serveur Web
3. apt-get install php libapache2-mod-php php-mcrypt # php et les packages associés
4. systemctl enable apache2 # permet au serveur Web de démarrer au redémarrage du système
5. systemctl restart apache2 # redémarrage du serveur Web
6. systemctl status apache2 # vérifier que le serveur Web est opérationnel 

Afin de tester que les instances de serveur Web peuvent serveur PHP, nous allons créer un simple fichier PHP à la racine du document (répertoire/var/www/html) sur chaque serveur Web à l'aide de l'éditeur vi :

 />                ?>
           
       

Maintenant, si nous dirigeons notre navigateur vers http:///greet.php , ce message d'accueil "Hello World" devrait être affiché. Nous pouvons substituer l'adresse IP de chacun des nœuds websrv1 et websrv2 tour à tour.

Nous sommes donc prêts à installer HAProxy pour servir d'interface aux serveurs Web. À partir de notre tableau de bord des réseaux E2E, nous créons à nouveau un nœud, mais cette fois à partir d'une «Appliance». Nous choisissons une appliance de type ‘Load Balancing HAProxy’. Il existe plusieurs configurations disponibles, parmi lesquelles nous choisissons VLB-B-1 (5 VCPU et 4 Go de RAM) pour notre instance HAProxy.

Figure 1 :Création d'un nœud d'équilibreur de charge virtuel

Les nœuds VLB sur E2E Cloud sont de puissants nœuds de calcul fonctionnant sous CentOS 7. Pour installer HAProxy sur chacun de ces nœuds, nous exécutons les commandes suivantes sur le terminal :

1. yum installer haproxy # installer HAProxy
2. systemctl enable haproxy # permet à HAProxy de démarrer au redémarrage du système
3. systemctl redémarrer haproxy # redémarrer HAProxy
4. systemctl status haproxy # vérifier que HAProxy est opérationnel 

Dans notre déploiement, nous aurons besoin de deux packages supplémentaires pour que HAProxy fonctionne :syslog et openssl. Étant donné que les nœuds VLB (s'exécutant sur CentOS) sont préinstallés avec ces deux packages, aucune étape d'installation supplémentaire n'est impliquée. Cependant, nous avons besoin de quelques étapes de configuration pour HAProxy avant même que l'équilibrage de charge ne commence à fonctionner.

Configuration générique HAProxy

Le fichier de configuration HAProxy se trouve dans /etc/haproxy/haproxy.cfg , et est livré avec quelques paramètres prêts à l'emploi, dont certains devront peut-être être modifiés. Ce fichier de configuration devrait avoir au moins un "frontend" et au moins un "backend" définis. Chaque frontend équilibre la charge sur un ou plusieurs backends. Un backend se compose de plusieurs serveurs Web servant la même application Web, pour l'évolutivité et la redondance. Mais il y a aussi une section dans ce fichier intitulée "générique" qui se rapporte à l'installation globale de HAProxy et une section "par défaut" qui spécifie les valeurs de paramètre applicables à tous frontend et backends définis ici.

Connexions max  :Dans la section "global", nous définissons le paramètre "maxconn" (le nombre maximal de connexions client que cet équilibreur de charge peut gérer sur tous backends auxquels il s'adresse). Ce paramètre peut être défini à l'aide des directives de dimensionnement HAProxy , ou inversement, nous pouvons choisir un nœud VLB d'E2E Cloud, en fonction du pic de charge attendu que notre site Web peut rencontrer. Avec notre VLB-B-1 choisi node, 4096 est une valeur raisonnable pour 'maxconn' au niveau global.

Figure 2 :Paramètres de configuration globaux et par défaut pour HAProxy

Protocole : Dans notre déploiement, HAProxy interceptera et équilibrera la charge du trafic HTTP. Ceci est configuré en définissant le mode dans la section par défaut ci-dessus.

1. mode http

Journalisation :Il est recommandé que HAProxy utilise syslog . Sur CentOS, cela signifie définir le paramètre 'log' sur 'local2' comme indiqué dans la capture d'écran ci-dessus. De plus, la configuration syslog sur le nœud HAProxy (/etc/rsyslog.conf) doit également être modifiée pour qu'il écoute sur le port UDP 514.

Figure 3 :Configuration Syslog sur le nœud HAProxy

Pour nous assurer que tous les messages de log sur 'local2' dans un fichier séparé exclusivement pour HAProxy (/var/log/haproxy.log), nous devons créer un fichier haproxy.conf dans le répertoire / etc/rsyslog.d et saisissez la ligne suivante :

2. local2.* /var/log/haproxy.log

Pour une traçabilité des requêtes de bout en bout, nous devons également modifier le format de journal du serveur Web Apache dans le fichier de configuration du serveur Web (/etc/apache2/apache2.conf). Sur chaque nœud de serveur Web, nous modifions LogFormat pour inclure l'adresse réelle du client (X-Forwarded-For) à l'origine de la requête HTTP (au lieu d'afficher l'adresse IP du nœud HAProxy).

Figure 4 :format de journal du serveur Web Apache

Statistiques HAProxy :HAProxy peut être configuré pour afficher des statistiques de requête sur une interface utilisateur Web. Nous pouvons définir une URL pour afficher les statistiques HAProxy (/lb-stats) protégées à l'aide d'une authentification de base.

Autres valeurs par défaut  :La section "par défaut" contient un ensemble de paramètres de délai d'attente que nous avons laissé inchangé. Mais en production, chaque administrateur de site peut souhaiter affiner les délais d'attente en fonction de facteurs tels que la latence du réseau, le temps de traitement côté serveur, etc. Nous avons introduit l'option "httpclose" afin que les connexions client HTTP soient fermées dès que possible. lorsque la réponse est renvoyée, sans consommer de ressources inutilement (sauf s'il existe un paramètre Keep-Alive pour les connexions HTTP). Et nous nous sommes assurés que l'adresse IP réelle du client est transmise jusqu'au serveur Web pour la traçabilité (en utilisant l'option 'option forwardfor' paramètre). Pour des définitions détaillées des paramètres de configuration HAProxy, documentation HAProxy doit être consulté.

Équilibrage de charge simple à tour de rôle

Au départ, nous avons mis en place un seul site Web (constitué de la simple application PHP Greeter mentionnée précédemment), dont la charge est équilibrée par notre installation HAProxy. Nous avons déjà configuré deux serveurs Web et un équilibreur de charge (HAProxy) comme indiqué sur le tableau de bord E2E Cloud.

Figure 5 :nœuds de serveur Web et d'équilibrage de charge

Tout d'abord, nous lions HAProxy à une adresse IP et un port appropriés (généralement le port 80 pour le mode http) sur notre nœud VLB . L'adresse IP doit être orientée vers l'extérieur pour accepter les demandes des clients. Cela nous amène à définir un ‘frontend‘, nommé ‘httptraffic‘, comme le suivant (dans /etc/haproxy/haproxy.cfg). Ici, par défaut, ce frontend équilibre la charge de toute demande client vers le backend nommé 'site'.

Figure 6 :Configuration frontale pour HAProxy

Donc, évidemment, nous devons définir un "backend" nommé "site". Il devrait se composer des adresses IP des serveurs Web vers lesquels acheminer les requêtes (bien que nous devions utiliser des adresses internes/privées dans ce but). Et nous spécifions que la politique d'équilibrage de charge est "round-robin". HAProxy nous permet également d'activer le bilan de santé périodique des nœuds backend, en utilisant le paramètre ‘check‘.

Figure 7 :Configuration du backend pour HAProxy

À ce stade, nous devons redémarrer syslog et HAProxy sur le nœud de l'équilibreur de charge :

1. systemctl redémarre rsyslog
2. systemctl redémarrer haproxy

Paramètres du pare-feu

Avant d'accéder à l'application Web via HAProxy, nous devons ouvrir le port 80 (pour HAProxy configuré pour le mode http) sur le nœud d'équilibreur de charge virtuel, et le port UDP 514 pour syslog. Sur CentOS, cela nécessite la configuration de iptables de manière appropriée :

1. iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
2. iptables -A INPUT -i eth0 -p udp –dport 514 -j ACCEPTER
3. iptables -A INPUT -i eth0 -p tcp –dport 80 -m state –state NEW,ETABLISHED -j ACCEPT
4. systemctl redémarre iptables

Test

À ce stade, nous pouvons réellement tester la fonctionnalité d'équilibrage de charge et certains des paramètres de configuration (y compris la journalisation et la collecte de statistiques) mentionnés dans la section précédente.

Pour détecter les requêtes arrivant sur HAProxy, nous exécutons la commande suivante sur le nœud de l'équilibreur de charge :

5. tail -f /var/log/haproxy.log

Pour HAProxy, ce fichier journal (/var/log/haproxy.log) est mis à jour via syslog.

De même, nous pouvons consulter les journaux d'accès sur chaque nœud de serveur Web pour suivre la demande de bout en bout.

1. tail -f /var/log/apache2/access.log

Maintenant, nous accédons à l'application simple PHP Greeter à partir de deux machines différentes . Sur chaque machine cliente, nous pouvons pointer un navigateur vers l'URL :

http:///greet.php

Nous devrions trouver des mises à jour des journaux HAProxy. (Cela vérifie également que notre configuration syslog fonctionne.)

Figure 8 :Journaux HAProxy (équilibrage de charge à tour de rôle)

L'une des requêtes est servie par le nœud websrv1 tandis que l'autre est servie par le nœud websrv2. Cela est évident à partir des journaux d'accès à chaque serveur Web et en faisant correspondre étroitement les horodatages. Les adresses IP des clients sont également enregistrées dans HAProxy et dans les journaux du serveur Web.

Figure 9 :Journaux d'accès à partir du nœud :websrv1

Figure 10 :Journaux d'accès à partir du nœud :websrv2

Les salutations suivantes seront affichées sur le navigateur sur chaque ordinateur client :

Figure 11 :Affichage du navigateur

Statistiques de l'équilibreur de charge  :Enfin, nous pouvons consulter les statistiques HAProxy en pointant notre navigateur vers l'URL suivante (configurée dans la section 'defaults'):

http:///lb-stats

Figure 12 :Statistiques de l'équilibreur de charge

Conclusion et prochaines étapes

Jusqu'à présent, nous avons réussi à mettre en place l'équilibrage de charge sur le cloud E2E à l'aide de HAProxy. Dans la partie suivante (et finale) de ce blog, nous porterons cette configuration au niveau supérieur en permettant des sessions persistantes et un accès sécurisé au site Web, et nous mettrons également en place un site Web plus grand avec plusieurs applications. Ces étapes nous rapprocheront d'un déploiement en production.

Veuillez suivre le lien ci-dessous pour voir l'étape 2 :

Utilisation de HAProxy pour l'équilibrage de charge sur le cloud E2E :adhérence et sécurité de la session