# Répartition de charge avec Nginx sur plusieurs serveurs

> Répartissez le trafic d'un site sur plusieurs serveurs d'application avec un load balancer Nginx : méthodes, poids, secours, HTTPS et IP du visiteur.

La **répartition de charge** distribue les visiteurs d'un site sur plusieurs serveurs d'application. Un serveur load balancer se place devant : votre domaine pointe vers lui, il répond en HTTP et en HTTPS, et Nginx transmet chaque requête à l'un des serveurs d'application placés derrière. Si un serveur d'application ne répond plus, les autres prennent le relais.

Dans Vimonto Deploy, un load balancer est un serveur à part entière, sur lequel se trouve un site à charge répartie. Sur la page **Répartition de charge** de ce site, vous choisissez les serveurs d'application, la façon dont le trafic est réparti entre eux, et ceux qui n'interviennent que lorsque les autres sont hors service.

![La page Répartition de charge d'un site avec la méthode de répartition, deux serveurs d'application et leurs poids](https://ops.vimonto.com/docs-media/fr/site-load-balancing.webp?v=161e760d "Un site à charge répartie")

## Comment fonctionne la répartition de charge ?

| Élément | Rôle |
|---|---|
| **Serveur load balancer** | Un serveur du type **Load balancer**, avec uniquement Nginx. Le DNS de votre domaine pointe vers lui. |
| **Site à charge répartie** | Le site du load balancer, créé à partir du preset **Load balancer**. Il porte le domaine, le certificat et la liste des serveurs d'application, mais pas de code. |
| **Serveurs d'application** | Des serveurs d'application ou des serveurs web de votre organisation, chacun avec un site pour le même domaine. Ils font tourner votre code et sont déployés comme d'habitude. |

Un visiteur se connecte au load balancer. Nginx y choisit un serveur d'application, lui transmet la requête avec l'en-tête `Host` d'origine et les en-têtes `X-Forwarded-*`, puis renvoie la réponse. Les serveurs d'application voient l'adresse IP du visiteur et savent s'il a utilisé HTTPS, car leurs sites font confiance à ce load balancer (consultez [ce dont les serveurs d'application ont besoin](#de-quoi-les-serveurs-dapplication-ont-ils-besoin-)).

## Mettre en place un load balancer

1. [Créez un serveur](https://ops.vimonto.com/docs/fr/servers/create-a-server) du type **Load balancer**. Il ne reçoit que Nginx ; consultez [types de serveurs](https://ops.vimonto.com/docs/fr/servers/server-types).
2. Vérifiez que chaque serveur d'application a un site pour votre domaine, par exemple `shop.example.com`, et qu'il est déployé. Utilisez le même domaine ou ajoutez-le comme alias dans [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl).
3. Sur la page **Sites** du load balancer, cliquez sur **Nouveau site** et choisissez **Load balancer** sous **Répartition de charge**.
4. Saisissez le même domaine avec **Utiliser un domaine personnalisé** et cliquez sur **Créer le site**. Un site à charge répartie n'a ni dépôt, ni base de données, ni déploiements.

> [!NOTE]
> Le load balancer a besoin d'un domaine à vous avant que vous puissiez ajouter des serveurs d'application : les sites de vos serveurs d'application ne peuvent pas répondre pour un nom `on-deploy.link`. Tant qu'il n'en a pas, la page Répartition de charge affiche **Ajoutez d’abord un domaine**. Une fois qu'il en a un, les requêtes qui arrivent sur son adresse `on-deploy.link` fonctionnent toujours : le load balancer les transmet avec votre propre domaine comme `Host`.
5. Ouvrez la page **Répartition de charge** du nouveau site et ajoutez vos serveurs d'application (voir ci-dessous).
6. Faites pointer le DNS du domaine vers l'adresse IP du load balancer, et activez HTTPS sur le site du load balancer dans [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl).

Tant que vous n'avez pas ajouté de serveur d'application, le load balancer répond à chaque requête par `503 Service Unavailable`, et la vue d'ensemble du site affiche **Pas encore de serveur d’application. Les visiteurs reçoivent une 503 jusqu’à ce que vous en ajoutiez un.**

Un serveur load balancer n'accueille que des sites à charge répartie, et le preset **Load balancer** ne se place que sur un serveur load balancer : le formulaire ne liste que les serveurs adaptés.

## Ajouter un serveur d'application

1. Sur la page **Répartition de charge** du site, cliquez sur **Ajouter un serveur**.
2. Choisissez le **Serveur**. La liste contient les serveurs d'application et les serveurs web actifs de votre organisation auxquels vous avez accès.
3. Définissez le **Port** sur lequel écoute le site du serveur d'application : `80` par défaut.
4. Définissez le **Poids**, de 1 à 100 : un serveur de poids 3 reçoit trois fois plus de requêtes qu'un serveur de poids 1.
5. Activez **Serveur de secours** si ce serveur ne doit recevoir du trafic que lorsque les autres serveurs sont hors service.
6. Cliquez sur **Ajouter un serveur**.

Le load balancer joint le serveur d'application via le [réseau privé](https://ops.vimonto.com/docs/fr/servers/network) lorsque les deux serveurs sont sur le même, et via son adresse IP publique sinon. La liste **Serveurs** affiche chaque serveur d'application avec l'adresse et le port qu'utilise le load balancer, son poids et un badge **Secours**.

Un serveur peut être ajouté plusieurs fois, sur des ports différents.

## Modifier un serveur d'application

Cliquez sur **Modifier** à côté du serveur, changez son **Port**, son **Poids** ou son réglage **Serveur de secours** et cliquez sur **Enregistrer**. Le serveur lui-même reste le même ; pour en utiliser un autre, ajoutez-le et retirez celui-ci. La modification est appliquée immédiatement.

## Choisir la méthode de répartition

Sous **Méthode**, cliquez sur l'une des trois options. La modification est appliquée immédiatement.

| Méthode | Comment Nginx choisit un serveur d'application |
|---|---|
| **Tourniquet** (par défaut) | Chaque serveur à tour de rôle, selon son poids. |
| **Moins de connexions** | Le serveur qui a le moins de connexions ouvertes, pour des requêtes dont la durée varie beaucoup. |
| **Hachage IP** | Chaque visiteur reste sur un même serveur, selon son adresse IP. Ne l'utilisez que si votre application conserve quelque chose sur un seul serveur. |

Nginx n'accepte pas les serveurs de secours avec **Hachage IP** : Vimonto Deploy ne vous laisse donc pas combiner les deux. Avec le hachage IP choisi, **Serveur de secours** ne peut pas être activé et le formulaire indique **Le hachage IP ne fonctionne pas avec des serveurs de secours. Choisissez d’abord une autre méthode.** Si la liste contient un serveur de secours, le choix du hachage IP est refusé avec **Le hachage IP ne fonctionne pas avec des serveurs de secours** : modifiez d'abord vos serveurs de secours pour qu'ils n'en soient plus.

## Que se passe-t-il quand un serveur d'application tombe en panne ?

Le load balancer vérifie les serveurs d'application grâce aux requêtes qu'il leur envoie ; il n'y a pas de contrôles de santé séparés. Quand une requête vers un serveur d'application échoue avec une erreur de connexion, un délai dépassé ou une `502`, `503` ou `504`, Nginx essaie le serveur suivant : le visiteur obtient donc quand même une réponse. Après 3 échecs en 10 secondes, le serveur ne reçoit plus de trafic pendant 10 secondes, puis Nginx l'essaie à nouveau.

Les serveurs de secours ne reçoivent du trafic que lorsque tous les autres serveurs sont indisponibles.

## Retirer un serveur d'application

Cliquez sur **Retirer** à côté du serveur et confirmez. Le load balancer cesse de lui envoyer du trafic, et les sites de ce serveur cessent de faire confiance au load balancer (voir ci-dessous). Rien d'autre ne change sur le serveur, et son site continue de fonctionner sur sa propre adresse.

Le même nettoyage se fait automatiquement quand vous supprimez le site à charge répartie ou le serveur load balancer : les sites des serveurs d'application cessent de lui faire confiance. Quand vous supprimez un serveur d'application, le load balancer cesse de lui envoyer du trafic.

## De quoi les serveurs d'application ont-ils besoin ?

Chaque modification sur la page Répartition de charge réécrit aussi la configuration Nginx des sites des serveurs d'application qui servent le même domaine. Ces sites font alors confiance au load balancer, et à lui seul :

- **L'adresse IP du visiteur.** Nginx prend l'adresse dans `X-Forwarded-For`, mais uniquement quand la requête vient du load balancer (`set_real_ip_from`). Votre application voit l'adresse IP du visiteur comme adresse distante, sans réglage de proxy de sa part.
- **HTTPS.** Quand le load balancer a reçu la requête en HTTPS, PHP reçoit `HTTPS=on` et une application Node.js reçoit `X-Forwarded-Proto: https`. Laravel et les autres frameworks construisent alors des liens `https://` sans configuration de proxys de confiance.

Les requêtes venant d'ailleurs ne peuvent pas falsifier ces en-têtes. Retirer un serveur, ou supprimer le site à charge répartie ou le load balancer, supprime à nouveau cette confiance. Un site avec une [configuration Nginx personnalisée](https://ops.vimonto.com/docs/fr/sites/nginx#quest-ce-qui-change-quand-vous-utilisez-votre-propre-configuration-) n'est pas modifié ; ajoutez ces lignes vous-même.

Votre application doit aussi fonctionner sur plusieurs serveurs à la fois :

- Gardez les **sessions et le cache** dans Redis ou dans la base de données, sur un [serveur de base de données ou de cache](https://ops.vimonto.com/docs/fr/servers/server-types) partagé, et non dans des fichiers sur un seul serveur. Pour Laravel, cela signifie `SESSION_DRIVER` et `CACHE_STORE` définis sur `redis` ou `database` dans le [.env](https://ops.vimonto.com/docs/fr/sites/environment) de chaque serveur d'application, et pointant vers le même Redis ou la même base de données.
- Gardez les **fichiers envoyés** dans un stockage objet comme S3, et non dans le `storage/` d'un seul serveur.
- **Déployez** le site de chaque serveur d'application. Chaque serveur d'application a sa propre release et son propre déploiement : déployez-les tous quand vous publiez une nouvelle version.
- Faites tourner le **planificateur** sur un seul serveur d'application, sauf si vos tâches planifiées peuvent sans risque s'exécuter plusieurs fois.

HTTPS se configure sur le load balancer, qui parle en HTTP simple aux serveurs d'application. Un site sur un serveur d'application peut tout de même avoir son propre certificat, par exemple pour y accéder directement : il redirige le HTTP simple vers HTTPS pour tout le monde sauf le load balancer, qu'il sert en HTTP simple, si bien qu'il n'y a pas de boucle de redirection.

## HTTPS sur le load balancer

Le site à charge répartie a sa propre page **Domaines et SSL**. Comme votre domaine pointe vers le load balancer, c'est là que vous demandez un certificat Let's Encrypt gratuit, comme pour n'importe quel site, et il se renouvelle automatiquement. Le load balancer répond alors en HTTPS, redirige le HTTP vers HTTPS et transmet les requêtes aux serveurs d'application en HTTP, avec `X-Forwarded-Proto: https`.

Le trafic entre le load balancer et les serveurs d'application n'est pas chiffré. Placez-les sur le même [réseau privé](https://ops.vimonto.com/docs/fr/servers/network) pour qu'il reste à l'intérieur du réseau de votre fournisseur.

## À quoi ressemble la configuration Nginx

La configuration du site à charge répartie contient un bloc `upstream` avec les serveurs d'application, et une `location` qui lui transmet les requêtes :

```nginx
upstream site_7_servers {
    least_conn;
    server 10.0.0.3:80 weight=3 max_fails=3 fail_timeout=10s;
    server 10.0.0.4:80 max_fails=3 fail_timeout=10s backup;
    keepalive 32;
}

server {
    # listen, server_name, certificate and logs as for every site

    location / {
        proxy_pass http://site_7_servers;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade_keepalive;
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_read_timeout 120;
    }
}
```

Les connexions aux serveurs d'application restent ouvertes et sont réutilisées, et les connexions WebSocket sont transmises. Chaque modification est écrite sous forme de tâche en arrière-plan, testée avec `nginx -t` et seulement ensuite chargée ; si Nginx la rejette, la configuration précédente reste active. Consultez [Nginx](https://ops.vimonto.com/docs/fr/sites/nginx).

Si vous avez enregistré votre propre configuration sur la page Nginx du site à charge répartie, les modifications faites sur la page Répartition de charge sont enregistrées mais pas appliquées : vous voyez **Enregistré, non appliqué**. Restaurez la configuration par défaut sur la page Nginx pour les utiliser.

## Que comporte d'autre un site à charge répartie ?

La barre latérale d'un site à charge répartie affiche **Vue d'ensemble**, **Répartition de charge**, **Domaines et SSL**, **Logs**, **Nginx** et **Paramètres**. Il n'a pas de page Déploiements ni de page Environnement, car il n'a pas de code. Sa page **Paramètres** ne contient que **Supprimer le site** : il n'y a ni répertoire web, ni réglage de déploiement, ni isolation à choisir. L'en-tête du site indique vers combien de serveurs d'application il envoie le trafic.

- **Logs** affiche les logs d'erreurs et de requêtes Nginx du load balancer lui-même. Les logs de votre application se trouvent sur les sites des serveurs d'application.
- **Protection par mot de passe**, dans le menu du framework de l'en-tête du site, protège d'un coup tous les serveurs d'application placés derrière le load balancer. C'est la seule [fonctionnalité de site](https://ops.vimonto.com/docs/fr/sites/site-features) d'un site à charge répartie.

Chaque membre peut voir la page Répartition de charge. Ajouter, modifier et retirer des serveurs et changer la méthode nécessitent la permission de gérer les sites ; consultez [membres et rôles](https://ops.vimonto.com/docs/fr/organization/members-and-roles). Chaque modification est enregistrée dans le [journal d'audit](https://ops.vimonto.com/docs/fr/organization/audit-log).

## Questions fréquentes

### Combien de serveurs d'application puis-je placer derrière un load balancer ?

Autant que vous le souhaitez. Chacun correspond à une ligne du bloc `upstream`.

### Ai-je besoin de sessions persistantes ?

Pas quand les sessions sont conservées dans Redis ou dans la base de données, que chaque serveur d'application lit. Dans ce cas, **Tourniquet** ou **Moins de connexions** fonctionnent le mieux. N'utilisez **Hachage IP** que lorsque quelque chose se trouve réellement sur un seul serveur.

### Puis-je utiliser un seul load balancer pour plusieurs domaines ?

Oui. Créez un site à charge répartie par domaine sur le load balancer, chacun avec ses propres serveurs d'application.

### Pourquoi mon domaine apparaît-il comme pointant ailleurs sur les serveurs d'application ?

Parce qu'il pointe vers le load balancer, comme il se doit. Seul le site du load balancer a besoin de l'enregistrement DNS et du certificat.