La haute disponibilité vise à prévenir les défaillances d'un point unique. Si la fiabilité matérielle est assurée, un trafic excessif peut nécessiter une répartition de la charge entre plusieurs serveurs. Les solutions comme Nginx, LVS et HAProxy sont couramment utilisées pour cet objectif. Nginx et HAProxy peuvent agir en tant que proxy inverse pour implémenter un équilibrage de charge au niveau applicatif (couche 7), tandis que LVS est une solution de couche 4 limitée à environ 100 nœuds.

Nginx pour l'équilibrage de charge

Nginx utilise sa fonctionnalité de proxy pour distribuer le trafic.

1. Proxies : Forward vs. Reverse

• Proxy Direct (Forward Proxy) : Il agit au nom du client. Le client communique avec le proxy, qui à son tour contacte le serveur de destination. Le serveur ne connaît pas l'identité réelle du client. Un exemple courant est l'utilisation d'un VPN pour accéder à des ressources externes tout en masquant son adresse IP. La sécurité est primordiale pour s'assurer que seuls les clients autorisés utilisent ce type de proxy.
• Proxy Inverse (Reverse Proxy) : Il agit au nom du serveur. Le client communique avec le proxy inverse, qui sélectionne ensuite un serveur backend pour traiter la requête. Le client ignore l'identité du serveur backend réel. Cette configuraton est idéale pour l'équilibrage de charge et rend la structure du backend transparente pour les utilisateurs.

2. Mise en œuvre pratique avec Nginx

Pour une démonstration, nous utiliserons quatre machines virtuelles : trois serveurs web (192.168.200.61, .62, .63) et un serveur Nginx agissant comme proxy inverse (192.168.200.11 avec une adresse externe 192.168.100.90).

2.1 Configuration des serveurs web

Installez le logiciel httpd sur les trois serveurs web et créez une page d'accueil simple sur chacun.

2.2 Configuration du serveur Nginx

Installez Nginx. Modifiez le fichier de configuration principal (nginx.conf). La partie essentielle pour le proxy inverce se trouve dans la configuration http.

Voici un extrait pertinent du fichier nginx.conf après modification :

# ... autres configurations Nginx ...

http {
    # ... configurations http ...

    server {
        listen       80;
        server_name  _;
        root         /usr/share/nginx/html;
        index        index.html index.htm;

        location / {
            proxy_pass http://webgroup; # Redirige les requêtes vers le groupe de serveurs 'webgroup'
        }

        # ... gestion des erreurs ...
    }

    upstream webgroup {  # Définit le groupe de serveurs backend
        server 192.168.200.61:80;
        server 192.168.200.62:80;
        server 192.168.200.63:80;
    }
}

Vérifiez la syntaxe de la configuration Nginx avec nginx -t et redémarrez le service.

2.3 Test client

En accédant à l'adresse IP externe du serveur Nginx (192.168.100.90), les requêtes seront distribuées aux serveurs backend. Le résultat affichera séquentiellement le contenu des pages d'accueil des serveurs (61, 62, 63).

Il est également possible de configurer Nginx pour agir comme proxy vers des sites externes, par exemple : proxy_pass https://www.baidu.com;.

3. Algorithmes de répartition de Nginx

Nginx propose plusieurs algorithmes de répartition :

• Round Robin (Rotation) : Algorithme par défaut, distribue les requêtes séquentiellement.
• Least Connections (Moins de connexions) : Dirige les requêtes vers le serveur ayant le moins de connexions actives.
• IP Hash : Utilise une fonction de hachage basée sur l'adresse IP du client pour déterminer le serveur backend. Cela garantit que toutes les requêtes d'un même client sont dirigées vers le même serveur, maintenant ainsi la persistance de session. Ceci est particulièrement utile pour les applications de commerce électronique où un utilisateur peut avoir plusieurs connexions (panier, historique, etc.) et doit rester sur le même serveur pour une session cohérente.

Exemple de configuration avec ip_hash :

upstream webgroup {
    ip_hash;
    server 192.168.200.61:80;
    server 192.168.200.62:80;
    server 192.168.200.63:80;
}

4. Gestion de l'état des serveurs dans Nginx

Des paramètres permettent de gérer la disponibilité et la charge des serveurs backend :

• down : Marque un serveur comme inactif, Nginx ne lui enverra plus de trafic. Utile pendant la maintenance.

upstream webgroup {
    server 192.168.200.61:80;
    server 192.168.200.62:80 down; # Ce serveur ne recevra pas de trafic
    server 192.168.200.63:80;
}

• backup : Les serveurs marqués comme backup ne sont utilisés que si tous les serveurs principaux sont indisponibles.

upstream webgroup {
    server 192.168.200.61:80;
    server 192.168.200.62:80 backup;
    server 192.168.200.63:80 backup;
}

• max_fails et fail_timeout : Pour la surveillance de l'état de santé. max_fails définit le nombre d'échecs de connexion autorisés avant qu'un serveur ne soit temporairement considéré comme indisponible. fail_timeout spécifie la durée pendant laquelle le serveur restera marqué comme indisponible. Après cette période, Nginx tentera de lui renvoyer du trafic.

upstream webgroup {
    server 192.168.200.61:80;
    server 192.168.200.62:80 max_conns=100; # Limite le nombre de connexions simultanées
    server 192.168.200.63:80 max_fails=1 fail_timeout=300; # Considéré en échec après 1 requête, indisponible pendant 300s
}

• slow_start : Utilisé après un échec, ce paramètre permet de réduire progressivement la quantité de trafic envoyée à un serveur qui sort d'une période d'indisponibilité, évitant ainsi de le surcharger immédiatement. Note : ce paramètre peut être spécifique aux versions commerciales de Nginx.
• weight : Permet d'attribuer un poids différent aux serveurs. Un poids plus élevé signifie que le serveur recevra proportionnellement plus de requêtes.

upstream webgroup {
    server 192.168.200.61:80 weight=3; # Reçoit 3 fois plus de trafic que les autres si les poids sont égaux
    server 192.168.200.62:80 max_conns=100;
    server 192.168.200.63:80 max_fails=1 fail_timeout=300;
}

HAProxy pour l'équilibrage de charge

HAProxy est une autre solusion populaire offrant des capacités d'équilibrage de charge pour les couches 4 et 7. Il supporte les listes de contrôle d'accès (ACL), la surveillance graphique et divers algorithmes de répartition.

1. Configuration de base avec HAProxy

Pour un exemple, nous utiliserons quatre serveurs web (192.168.200.61 à .64) et un serveur HAProxy (192.168.200.80).

Installez HAProxy : yum -y install haproxy.

Voici un exemple de fichier de configuration haproxy.cfg :

global
    log         127.0.0.1 local2
    pidfile     /var/run/haproxy.pid
    user        haproxy
    group       haproxy
    daemon
    maxconn     4000

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    retries                 3
    timeout http-request    5s
    timeout connect         5s
    timeout client          1m
    timeout server          1m
    timeout check           5s
    maxconn                 3000

frontend main
    bind *:80
    default_backend         http_back

backend http_back
    balance     roundrobin
    server  node1 192.168.200.61:80 check
    server  node2 192.168.200.62:80 check
    server  node3 192.168.200.63:80 check
    server  node4 192.168.200.64:80 check

Démarrez le service HAProxy : systemctl restart haproxy.service.

Test client En accédant à l'adresse IP du serveur HAProxy (192.168.200.80), les requêtes seront distribuées aux serveurs backend (61, 62, 63, 64) selon l'algorithme roundrobin.

2. Séparation du trafic avec ACLs HAProxy

HAProxy permet de diriger le trafic vers différents groupes de serveurs backend en fonction de règles définies (ACLs). Par exemple, nous pouvons envoyer les requêtes pour les fichiers statiques (HTML) vers un groupe de serveurs (61, 62) et les requêtes pour les scripts dynamiques (PHP) vers un autre groupe (63, 64).

2.1 Configuration Nginx pour PHP

Sur les serveurs 63 et 64, installez et configurez Nginx pour interpréter les scripts PHP via PHP-FPM. Modifiez la configuration Nginx pour inclure le traitement des fichiers .php. Assurez-vous que PHP-FPM écoute sur un port spécifique (par exemple, 9000).

2.2 Création de contenu différencié

Sur les serveurs 61 et 62, créez des fichiers HTML comme a.html. Sur les serveurs 63 et 64, créez des fichiers PHP comme a.php.

2.3 Configuration HAProxy avec ACLs

Modifiez la configuration de HAProxy pour utiliser des ACLs basées sur la fin du chemin de la requête :

frontend main
    bind *:80
    default_backend         http_back

    acl html_files path_end .html   # ACL pour les fichiers .html
    acl php_files path_end .php     # ACL pour les fichiers .php

    use_backend html_servers if html_files  # Si la requête correspond à html_files, utiliser html_servers
    use_backend php_servers if php_files      # Si la requête correspond à php_files, utiliser php_servers

backend http_back # Ce backend par défaut pourrait être pour les requêtes sans extension spécifique
    balance     roundrobin
    server  node1 192.168.200.61:80 check
    server  node2 192.168.200.62:80 check

backend html_servers
    balance     roundrobin
    server  node1 192.168.200.61:80 check
    server  node2 192.168.200.62:80 check

backend php_servers
    balance     roundrobin
    server  node3 192.168.200.63:80 check
    server  node4 192.168.200.64:80 check

2.4 Test client

• curl localhost dirigera vers http_back.
• curl localhost/a.html dirigera vers html_servers.
• curl localhost/a.php dirigera vers php_servers.

HAProxy offre une flexibilité étendue pour définir des ACLs basées sur divers critères tels que l'adresse IP, le chemin URL, le port, les en-têtes de requête, etc.