Utilitaires
Scripts
Divers
Jeux
Rechercher
Quillevere.net
Réflexions informatiques

Créer un reverse proxy pour vos web services (avec load balancing)

14/11/2022

Lors de la mise en place d'un web service, il est important de s'assurer que celui-ci pourra absorber la charge et anticiper les défaillances du système. Aussi, redonder ce web-sevice apporte une sécurité supplémentaire mais il faut alors créer un endpoint de façade, qui effectue la redirection vers l'un ou l'autre des services.

Voici une solution rapide pour mettre en place de la répartition de charge (load-balancing) entre plusieurs web services présents sur un ou plusieurs serveurs. Ce système vous assure, en cas d'indisponibilité d'un serveur, qu'au moins un autre peut absorber la charge. Le reverse proxy utilisé ici est Apache mod_proxy.

Le port utilisé pour la façade sera le 8443, un port utilisé par Apache pour https. Vous pouvez évidemment en utiliser un autre.

La machine d'installation est un Red HatLinux, il faut donc adapter certaines commandes (comme yum) à votre distribution.

Il faut au préalable que vous déployez vos web services, sur une même machine (avec des ports différents) ou sur des machines différentes.

Installation du reverse proxy

  • Vérifier que rien ne s'exécute sur le port 8443, afin d'éviter tout conflit :
    netstat -an | grep ":8443"
  • Installer Apache et l'activer :
    sudo yum install httpd
  • Il faut vérifier si le module mod_proxy est bien actif sur la configuration (et l'activer dans le cas contraire) :
    grep "mod_proxy" /etc/httpd/conf.modules.d/00-proxy.conf

Paramétrage du reverse proxy

  • Modifier les paramètres du pare-feu pour ouvrir le port 8443 :
    sudo firewall-cmd --add-port=8443/tcp --permanent
  • Modifier la configuration d'Apache pour ajouter les paramètres du reverse proxy : éditer le fichier de config :
    sudo nano /etc/httpd/conf/httpd.conf
  • Ajouter les lignes suivantes, en fin de fichier :
    Listen 8443

    <VirtualHost *:8443>
    ServerName localhost
    ProxyRequests off
    ProxyPreserveHost on

    <Proxy *>
    Order Deny,Allow
    Allow from all
    </Proxy>

    ProxyPass /balancer-manager !
    ProxyPass / balancer://mycluster/ stickysession=JSESSIONID nofailover=On

    ProxyPassReverse / balancer://mycluster/ stickysession=JSESSIONID
    Header add Set-Cookie "ROUTEID=%{BALANCER_WORKER_ROUTE}e; path=/"

    <Proxy balancer://mycluster>
    Header set Cache-Control no-cache
    Header set Pragma no-cache

    # Serveur 1
    BalancerMember http://127.0.0.1:8040 route=node1

    # Serveur 2
    BalancerMember http://127.0.0.1:8041 route=node2

    ProxySet lbmethod=byrequests
    ProxySet stickysession=ROUTEID
    </Proxy>

    <Location /balancer-manager>
    SetHandler balancer-manager
    Order deny,allow
    Allow from all
    </Location>

    </VirtualHost>
    • Le paramètre lbemethod indique la méthode de répartition de charge :
      • byrequests : pour un décompte de requêtes pondérées (par défaut)
      • bytraffic : pour une répartition en fonction du décompte des octets transmis
      • bybusyness : pour une répartition en fonction des requêtes en attente
    • Adaptez les lignes avec BalanceMember à vos paramètres : ici, il s'agit de deux web services présents en local sur les ports 8040 et 8041
    • L'appel est prévu pour renvoyer dans les en-têtes une information permettant de savoir si on est passé par le 1er ou le second serveur, grâce à Header set-Cookie.
  • Vérifier la configuration des fichiers puis redémarrez le service Apache :
    apachectl configtest
    sudo service httpd.service restart

Tester l'appel et la redirection

Appelez votre web service de façade avec l'URL http://mon_serveur_facade:8443

  • Vérifier que les en-têtes affichent tantôt node1, tantôt node2 pour la valeur du cookie ROUTEID
  • Vérifier qu'Apache reçoit bien les demandes, depuis le fichier de log :
    tail -f /var/log/httpd/access_log

Tester l'indisponibilité et le retour du web service

Lors de mes tests, dès que l'un des web services n'était plus disponible (serveur arrêté), l'appel au web service de secours était immédiat (aucune perte).

En cas de retour à la disponibilité, mod_proxy assure bien les réenvois vers le serveur qui a eu une défaillance.

Dernière modification le 14/11/2022 - Quillevere.net

Rechercher sur le site

fr en rss RSS info Informations