Vous pouvez utiliser Nginx comme équilibreur de charge devant votre application Web.
Par exemple, si votre application d'entreprise s'exécute sur Apache (ou Tomcat), vous pouvez configurer une 2ème instance de votre application d'entreprise sur Apache (ou Tomcat) sur un serveur différent.
Et puis, vous pouvez mettre Nginx en front-end, ce qui équilibrera la charge entre les deux serveurs Apache (ou Tomcat, ou JBoss).
Si vous débutez avec Nginx, il est important de comprendre la différence entre Nginx vs Apache et l'architecture Nginx.
Nginx prend en charge les trois types d'équilibrage de charge suivants :
- round-robin - Il s'agit du type par défaut pour Nginx, qui utilise l'algorithme typique de round-robin pour décider où envoyer la demande entrante
- least-connected – Comme son nom l'indique, la demande entrante sera envoyée au serveur qui a le moins de connexions.
- ip-hash - Ceci est utile lorsque vous souhaitez avoir une persistance ou une connexion permanente de la demande entrante. Dans ce type, l'adresse IP du client est utilisée pour décider à quel serveur la requête doit être envoyée.
1. Définissez en amont et proxy_pass dans le fichier de configuration Nginx
Pour l'équilibrage de charge, vous devez ajouter deux choses au fichier de configuration nginx :1) en amont 2) proxy_pass
Tout d'abord, en amont : Spécifiez un nom unique (peut être le nom de votre application) et répertoriez tous les serveurs qui seront équilibrés par ce Nginx.
Dans l'exemple suivant, "crmdev" est le nom de l'amont, qui est le nom de l'application qui s'exécute sur le serveur Web Apache individuel (101.1 et 102.2, comme indiqué ci-dessous). Au lieu de "crmdev", vous pouvez spécifier ici tout ce que vous voulez.
Remarque :L'amont doit être défini dans votre contexte "http" de Nginx.
upstream crmdev {
server 192.168.101.1;
server 192.168.101.2;
}
Remarque :Si les serveurs individuels s'exécutent sur un port différent (autre que le port 80), spécifiez le numéro de port comme indiqué ci-dessous dans le processus en amont
upstream crmdev {
server 192.168.101.1:8080;
server 192.168.101.2:8080;
}
Deuxièmement, proxy_pass : Spécifiez le nom unique en amont qui a été défini à l'étape précédente comme proxy_pass dans votre section "emplacement", qui sera sous la section "serveur", comme indiqué ci-dessous.
server {
listen 80;
location / {
proxy_pass http://crmdev;
}
}
Remarque :Dans cet exemple, nginx lui-même écoute sur le port 80, comme indiqué ci-dessus par le paramètre listen.
Veuillez noter que vous pouvez également utiliser proxy_pass pour configurer Nginx en tant que proxy inverse pour Apache/PHP.
2. Définissez en amont et proxy_pass dans le fichier de configuration par défaut de Nginx
Remarque :En règle générale, ce qui précède doit être sous http ou https, comme indiqué ci-dessous.
http {
upstream crmdev {
server 192.168.101.1:8080;
server 192.168.101.2:8080;
}
server {
listen 80;
location / {
proxy_pass http://crmdev;
}
}
}
Mais, si vous utilisez le fichier default.conf fourni avec le fichier nginx.conf par défaut, vous n'avez pas besoin de donner le "http", car il est déjà défini dans le contexte http.
Remarque :Pour HTTPS, remplacez le contexte "http" (dans la 1ère ligne ci-dessus) par https. De plus, dans la ligne proxy_pass, utilisez https://{your-upstream-name}
Dans ce cas, si vous utilisez le "http" comme indiqué ci-dessus, vous pourriez obtenir le message d'erreur suivant :la directive http n'est pas autorisée :
Starting nginx: nginx: [emerg] "http" directive is not allowed here in /etc/nginx/conf.d/default.conf:1
Ceci est la copie de mon fichier default.conf, où j'ai ajouté l'amont en haut (sans le http), puis commenté l'emplacement par défaut et ajouté le nouvel emplacement à l'aide du proxy_pass.
# vi /etc/nginx/conf.d/default.conf
upstream crmdev {
server 127.0.0.1:4080;
server 127.0.0.1:7080;
}
server {
listen 3080;
server_name localhost;
#location / {
# root /usr/share/nginx/html;
# index index.html index.htm;
#}
location / {
proxy_pass http://crmdev;
}
..
..
}
3. Configurer l'algorithme le moins connecté pour l'équilibreur de charge Nginx
Dans cet algorithme, la demande entrante est envoyée au serveur qui a le moins de connexions actives existantes.
Pour cela, ajoutez le mot-clé "least_conn" en haut de l'amont comme indiqué ci-dessous.
upstream crmdev {
least_conn;
server 192.168.101.1:8080;
server 192.168.101.2:8080;
}
Si vous avez plusieurs serveurs répertoriés dans le least_conn, et si plusieurs serveurs ont le même nombre faible de connexions actives existantes, alors parmi ces serveurs, un sera choisi en fonction du round robin pondéré.
4. Configurer la persistance ou l'algorithme collant pour l'équilibreur de charge Nginx
L'inconvénient de la méthode round-robin et la moins connectée est que la connexion suivante du client n'ira pas au même serveur dans le pool. Cela peut être correct pour une application non dépendante de la session.
Mais si votre application dépend de la session, une fois qu'une connexion initiale est établie avec un serveur particulier, vous souhaitez que toutes les connexions futures de ce client particulier aillent vers le même serveur. Pour cela, utilisez l'algorithme ip_hash comme indiqué ci-dessous.
upstream crmdev {
ip_hash;
server 192.168.101.1:8080;
server 192.168.101.2:8080;
}
Pour le hachage, pour l'adresse IPv4, les trois premiers octets sont utilisés. S'il s'agit d'une adresse IPv6, l'intégralité de l'adresse est utilisée.
5. Options de pondération pour les serveurs individuels
Vous pouvez également spécifier une pondération pour un serveur particulier dans votre pool. Par défaut, tous les serveurs ont la même priorité (poids). c'est-à-dire que la valeur par défaut du poids est 1.
Mais vous pouvez modifier ce comportement en attribuant un poids à un serveur comme indiqué ci-dessous.
upstream crmdev {
server 192.168.101.1:8080;
server 192.168.101.2:8080;
server 192.168.101.3:8080 weight 2;
server 192.168.101.4:8080;
server 192.168.101.5:8080;
}
Dans cet exemple, nous avons un total de 5 serveurs. Mais le poids sur le 3ème serveur est de 2. Cela signifie que pour chaque 6 nouvelles requêtes, 2 requêtes iront au 3ème serveur, et le reste du serveur recevra 1 requête.
C'est donc utile pour répartir plus de charge sur un serveur spécifique qui a plus de puissance.
Même si dans l'exemple ci-dessus, le poids est utilisé avec l'algorithme round-robin par défaut, vous pouvez également utiliser le poids pour last_conn et ip_hash.
6. Options de délai d'expiration pour les serveurs individuels - max_fails et fail_timeout
Vous pouvez également spécifier max_fails et fail_timeout à un serveur particulier, comme indiqué ci-dessous.
upstream crmdev {
server 192.168.101.1:8080 max_fails=3 fail_timeout=30s;
server 192.168.101.2:8080;
server 192.168.101.3:8080 weight 2;
server 192.168.101.4:8080;
server 192.168.101.5:8080;
}
Dans ce qui précède :
- Le fail_timeout par défaut est de 10 secondes. Dans cet exemple ci-dessus, il est réglé sur 30 secondes. Cela signifie que dans les 30 secondes s'il y a eu un nombre x de tentatives infructueuses (comme défini par max_fails), le serveur sera indisponible. De plus, le serveur restera indisponible pendant 30 secondes.
- Le max_fails par défaut est de 1 tentative. Dans l'exemple ci-dessus, il est défini sur 3 tentatives. Cela signifie qu'après 3 tentatives infructueuses de connexion à ce serveur particulier, Nginx considérera ce serveur comme indisponible pendant la durée de fail_timeout qui est de 30 secondes.
7. Attribuer un serveur de sauvegarde dans le pool Nginx LoadBalancer
Dans l'exemple suivant, le 5e serveur est marqué comme serveur de secours à l'aide du mot-clé "sauvegarde" à la fin du paramètre du serveur.
upstream crmdev {
server 192.168.101.1:8080 max_fails=3 fail_timeout=30s;
server 192.168.101.2:8080;
server 192.168.101.3:8080 weight 2;
server 192.168.101.4:8080;
server 192.168.101.5:8080 backup;
}
Ce qui précède fera du 5ème serveur (192.168.101.5) un serveur de secours. La demande entrante ne sera pas transmise à ce serveur à moins que les 4 autres serveurs ne soient en panne.