Utilisation de Nginx pour la Répartition de Charge

  1. Présentation Générale

1.1. Qu'est-ce que Nginx ?

Nginx est un serveur web et un serveur proxy inverse haute performance. Il est également reconnu pour ses capacités en tant que proxy IMAP/POP3/SMTP. Sa popularité provient de ses performances élevées, de sa stabilité, de la richesse de ses fonctionnalités, de la simplicité de sa configuration et de sa faible consommation de ressources système.

1.2. Concept de Répartition de Charge

La répartition de charge (ou équilibrage de charge) consiste à distribuer équitablement les requêtes entrantes vers un ensemble de serveurs backend. Cette technique améliore les performances et la fiabilité des applications, sites web ou bases de données. L'équilibreur de charge peut opérer à différents niveaux du modèle OSI, les plus courants étant le niveau 4 (couche transport) et le niveau 7 (couche application).

  1. Répartition de Charge au Niveau 4 (Couche Transport)

2.1. Principe de Fonctionnement

Un équilibreur de charge de couche 4 fonctionne en se basant sur les protocoles de la couche transport (TCP et UDP). Lorsque Nginx agit comme un tel équilibreur, il achemine les paquets vers les serveurs backend en fonction des adresses IP et des ports de destination, sans inspecter le contenu de la couche application.

2.2. Caractéristiques Clés

  • Transparence : L'équilibreur ne traite que les en-têtes des couches réseau et transport, ignorant le contenu applicatif.
  • Efficacité : L'absence d'analyse des données applicatives garantit une vitesse de traitement et des performances élevées.
  • Simplicité : La configuration est généralement plus simple, adaptée aux scénarios ne nécessitant pas de décisions complexes basées sur l'application.

2.3. Avantages et Inconvénients

  • Répartition TCP : Distribuer le trafic TCP, par exemple pour des connexions à des bases de données ou des services de chat.
  • Répartition UDP : Distribuer le trafic UDP, par exemple pour des requêtes DNS ou des serveurs de jeux.
  1. Répartition de Charge au Niveau 7 (Couche Aplication)

3.1. Principe de Fonctionnement

La répartition de charge de couche 7 opère au niveau des protocoles applicatifs (comme HTTP et HTTPS). Nginx, agissant à ce niveau, peut analyser les requêtes HTTP entrantes et prendre des décisions de routage complexes basées sur des éléments comme l'URL, les en-têtes, les cookies, etc.

3.2. Caractéristiques Clés

  • Flexibilité : Possibilité d'effectuer une répartition de charge en fonction de tout élément de la couche application.
  • Visibilité : Capacité à analyser et journaliser des informations détaillées sur les requêtes, facilitant la surveillance et le débogage.
  • Sécurité : Possibilité d'implémenter des filtres de sécurité et des contrôles d'accès basés sur le contenu de la requête.

3.3. Avantages et Inconvénients

4.1. Round Robin (Robin-Round)

Il s'agit de l'algorithme par défaut de Nginx. Les requêtes sont distribuées de manière cyclique à chaque serveur backend. C'est une approche simple et équitable si tous les serveurs ont des capacités similaires.

  • Cas d'usage : Idéal pour des environnements homogènes où la charge de travail est équilibrée.

4.2. Least Connections (Moins de Connexions)

Les nouvelles requêtes sont envoyées au serveur qui a actuellement le moins de connexions actives. Cela permet de mieux répartir la charge lorsque les serveurs traitent les requêtes à des vitesses différentes.

  • Cas d'usage : Adapté aux applications où le temps de traitement des requêtes varie considérablement.

4.3. Weighted Round Robin (Robin-Round Pondéré)

Cet algorithme est une variante du Round Robin, où chaque serveur se voit attribuer un poids. Les serveurs avec un poids plus élevé reçoivent une plus grande proportion des requêtes. Ceci est utile pour exploiter des serveurs de capacités différentes.

  • Cas d'usage : Parfait pour des parcs de serveurs hétérogènes (différences de CPU, RAM, etc.).

4.4. IP Hash (Hachage IP)

L'algorithme calcule une valeur de hachage à partir de l'adresse IP du client. Ce hachage détermine le serveur backend qui traitera la requête. Ainsi, toutes les requêtes d'un même client sont dirigées vers le même serveur, ce qui permet de maintenir la session.

  • Cas d'usage : Essentiel pour les applications qui nécessitent une persistance de session, comme les paniers d'achat ou les connexions utilisateur.
  1. Exemple Pratique : Répartition au Niveau 4

Objectif : Utiliser Nginx pour exposer un point d'accès MySQL sur le port 7777, lequel répartit les connexions entre deux serveurs MySQL backend (un maître et un esclave).

Topologie :

  • Serveur Nginx : 192.168.50.101, port 7777
  • Serveur MySQL 1 : 192.168.50.21, port 3306
  • Serveur MySQL 2 : 192.168.50.22, port 3306

5.1. Installation et Configuration des Bases de Données

Installez MariaDB sur les deux serveurs backend et initialisez la base de données.

yum -y install mariadb-server
systemctl enable mariadb --now
# Exécutez le script de sécurisation pour configurer le mot de passe root
mysql_secure_installation

5.2. Autoriser les Connexions à Distance

Pour que Nginx puisse se connecter aux serveurs MySQL, il est nécessaire d'autoriser les connexions à distance pour l'utilisateur root.

# Connectez-vous à la base de données locale
mysql -uroot -p123
# Accordez tous les privilèges à root depuis n'importe quel hôte
MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;
# Vérifiez les hôtes autorisés
MariaDB [(none)]> SELECT user, host FROM mysql.user;

5.3. Configuration de Nginx

La configuration de la répartition de charge de couche 4 se fait en dehors du bloc http. Ajoutez un bloc stream au niveau supérieur du fichier nginx.conf.

vim /etc/nginx/nginx.conf
# Ajoutez à la fin du fichier
stream {
    upstream mysql_backend {
        server 192.168.50.21:3306;
        server 192.168.50.22:3306;
    }
    server {
        listen 7777;
        proxy_pass mysql_backend;
    }
}

Important : Le bloc stream doit être un enfant direct du bloc principal, au même niveau que le bloc http. Ne l'ajoutez pas dans un fichier inclus par le bloc http.

5.4. Test de la Configuration

Redémarrez Nginx et testez la connexion à MySQL via le proxy.

systemctl restart nginx
# Depuis un client, connectez-vous à MySQL via Nginx
mysql -uroot -p123 -h 192.168.50.101 -P 7777
# Vous devriez voir une invite MariaDB. La connexion a été redirigée vers l'un des serveurs backend.

5.5. Exemple de Répartition SSH

Le même principe peut être appliqué pour d'autres services TCP, comme SSH.

stream {
    upstream ssh_backend {
        server 192.168.50.21:22;
    }
    server {
        listen 2222;
        proxy_pass ssh_backend;
    }
}

Vous pourrez ensuite vous connecter en SSH via ssh root@192.168.50.101 -p 2222.

  1. Exemple Pratique : Répartition au Niveau 7

Objectif : Distribuer les requêtes HTTP entre deux serveurs web backend.

Topologie :

  • Serveur Nginx (répartiteur) : 192.168.50.101
  • Serveur Web A : 192.168.50.21
  • Serveur Web B : 192.168.50.22

6.1. Configuration des Serveurs Web

Sur chaque serveur backend, créez un fichier index.html avec un contenu distinct pour identifier le serveur.

# Serveur A
echo "serveur-web-a" > /usr/share/nginx/html/index.html
systemctl restart nginx

# Serveur B
echo "serveur-web-b" > /usr/share/nginx/html/index.html
systemctl restart nginx

6.2. Configuration du Proxy Inverse

Contrairement à la couche 4, la configuration pour la couche 7 se fait dans le bloc http. Vous pouvez placer cette configuration dans un fichier dédié dans le dossier conf.d.

# /etc/nginx/conf.d/web_proxy.conf
upstream web_backend {
    server 192.168.50.21:80;
    server 192.168.50.22:80;
}

server {
    listen 80;
    location / {
        proxy_pass http://web_backend/;
        # Les en-têtes proxy_set_header peuvent être ajoutés ici si nécessaire
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

6.3. Test de la Répartition

Redémarrez Nginx et effectuez plusieurs requêtes pour observer la distribution.

systemctl restart nginx
# Effectuez deux requêtes. Le serveur de réponse devrait alterner.
curl 192.168.50.101 -s
# Affiche : serveur-web-a
curl 192.168.50.101 -s
# Affiche : serveur-web-b
  1. Gestion de l'État des Serveurs Backend

Nginx permet de contrôler précisément le comportement des serveurs dans un groupe en utilisant des directives.

  • down : Marque le serveur comme étant définitivement indisponible. Utile pour la maintenance programmée.
  • backup : Marque le serveur comme étant un serveur de secours. Il ne reçoit de trafic que lorsque tous les serveurs principaux (non marqués backup) sont indisponibles.
  • max_fails et fail_timeout : Ces paramètres définissent une fenêtre de détection d'échec. Si un serveur échoue max_fails fois dans un intervalle de temps de fail_timeout secondes, il est considéré comme indisponible pendant la durée du fail_timeout.
  1. Synthèse
  • Répartition de charge : Nginx offre une solution robuste pour distribuer le trafic.
  • Couche 4 (Transport) : Idéal pour une répartition rapide et simple basée sur les adresses IP et les ports, sans inspecter le contenu applicatif.
  • Couche 7 (Application) : Offre une grande flexibilité pour router les requêtes en fonction de leur contenu (URL, en-têtes, etc.), au prix d'une légère surcharge de performance.

Étiquettes: nginx Reverse Proxy Load Balancing Layer 4 Layer 7

Publié le 17 juillet à 18h25

Étiquettes Populaires

©2026 L'Atelier Monstre