Répartition de charge avec Nginx sur plusieurs serveurs

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.

Comment fonctionne la répartition de charge ?#

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).

Mettre en place un load balancer#

1. Créez un serveur du type Load balancer. Il ne reçoit que Nginx ; consultez types de serveurs.
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.
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.

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.

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é 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.

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 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 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 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é 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 :

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.

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 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. Chaque modification est enregistrée dans le journal d'audit.

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.