Comment configurer l’équilibrage de charge nginx ? méthode de configuration de l'équilibrage de charge nginx

Il existe de nombreuses façons de configurer l'équilibrage de charge Nginx. Ici, je vais vous présenter deux façons de configurer l'équilibrage de charge Nginx. Examinons ensuite en détail les méthodes de configuration courantes de l'équilibrage de charge Nginx.

nginx agit comme un proxy inverse pour les serveurs Web back-end (Apache, nginx, tomcat, weblogic), etc.

Plusieurs serveurs Web back-end doivent prendre en compte le partage de fichiers, le partage de bases de données , et les problèmes de partage de session peuvent utiliser nfs, le stockage partagé (fc, le stockage ip est acceptable) + le système de fichiers du cluster redhat GFS, rsync + la synchronisation de fichiers inotify, etc. Les clusters à petite échelle utilisent plus de nfs pour les systèmes de gestion de contenu. une seule unité est utilisée Pour publier des informations, rsync+inotify est un bon choix pour synchroniser plusieurs machines

Cluster à petite échelle, base de données unique hautes performances (telle que Zhiqiang dual quad-core, 32/64/. 128 Go de mémoire) est suffisant. Pour les clusters à grande échelle, vous pouvez envisager un cluster de base de données. Vous pouvez utiliser le logiciel de cluster officiel fourni par mysql, ou vous pouvez utiliser keepalived+lvs pour séparer la lecture et l'écriture afin de créer un cluster Mysql.

Le problème du partage de session est un gros problème. Si nginx utilise ip_hash Avec la méthode d'interrogation, chaque IP sera attribuée à un serveur back-end fixe dans un certain laps de temps, afin que nous n'ayons pas besoin de le faire. résoudre le problème de partage de session. Au contraire,
les demandes d'adresse IP sont interrogées et distribuées à plusieurs serveurs, ce qui doit être résolu. Pour les problèmes de partage de session, vous pouvez utiliser nfs pour partager la session, écrire la session sur mysql ou memcache. , etc. Lorsque l'échelle de la machine est relativement grande
, utilisez généralement la méthode d'écriture de la session dans Memcache.

Serveur Web back-end Nous ne discuterons pas ici de la façon de le configurer. le serveur peut être Apache, nginx, tomcat, lighthttp, etc. Le front-end ne se soucie pas de ce qu'est le back-end
Créez d'abord un fichier proxy.conf pour faciliter notre appel plus tard (configuration S'il y a plusieurs clusters, c'est une bonne méthode pour écrire les paramètres publics dans un fichier puis continuer à inclure)
vi /usr/local/nginx/conf/proxy.conf
proxy_redirect off;
proxy_set_header Host $host ;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64

Nous discutons de deux méthodes d'équilibrage de charge de nginx ici : pondération du sondage (elle peut également être non pondérée, ce qui correspond à une charge de 1 : 1) et ip_hash (la même IP sera attribuée à un serveur back-end fixe pour résoudre le problème de session)
Nous pouvons écrire ce fichier de configuration dans nginx.conf (s'il n'y a qu'un seul cluster Web). S'il y a plusieurs clusters Web, il est préférable d'écrire Go to vhosts en tant qu'hôte virtuel. Ici, je l'écris dans nginx.conf
La première configuration : interrogation pondérée. , donnant un poids en fonction des performances du serveur. Dans ce cas, il s'agit d'une allocation 1:2

La deuxième configuration : méthode de sondage ip_hash, le serveur ne peut pas être pondéré

 upstream lb {                server 192.168.196.130 weight=1 fail_timeout=20s;
                server 192.168.196.132 weight=2 fail_timeout=20s;
 }
 server {
                listen 80;
                server_name safexjt.com www.safexjt.com;
  index index.html index.htm index.php;
  location / {
                        proxy_pass http://lb;
   proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;
   include proxy.conf;
                }
 }

La méthode 2 d'équilibrage de charge nginx implémente le collage de session basé sur ip_hash

1 Polling (par défaut)

Chaque requête est attribuée à un serveur backend différent une par une dans l'ordre chronologique. Si le serveur backend tombe en panne, il peut. être automatiquement éliminé.

upstream lb {                server 192.168.196.130 fail_timeout=20s;
                server 192.168.196.132 fail_timeout=20s;
  ip_hash;
 }
 server {
                listen 80;
                server_name safexjt.com www.safexjt.com;
  index index.html index.htm index.php;
  location / {
                        proxy_pass http://lb;
   proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;
   include proxy.conf;
                }
 }

2. Spécifiez le poids
Spécifiez la probabilité d'interrogation. Le poids est proportionnel au taux d'accès et est utilisé lorsque les performances du serveur back-end sont inégales.

upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}

3. Liaison IP ip_hash
Chaque requête est allouée en fonction du résultat de hachage de l'IP d'accès, afin que chaque visiteur ait un accès fixe à un serveur back-end, qui peut résoudre le problème de la session.

upstream backserver {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}

4. équitable (tiers)
Attribuez les demandes en fonction du temps de réponse du serveur backend, et celles avec des temps de réponse courts seront attribuées en premier.

upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

5. url_hash (tiers)
Distribuez les requêtes en fonction du résultat de hachage de l'URL consultée, afin que chaque URL soit dirigée vers le même serveur back-end. le serveur back-end est mis en cache Plus efficace.

upstream backserver {
server server1;
server server2;
fair;
}

Dans le serveur qui doit utiliser l'équilibrage de charge, ajoutez

upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

max_fails : le nombre d'échecs de requêtes autorisés est par défaut de 1. Lorsque le maximum nombre est dépassé, renvoie l'erreur définie par le module proxy_next_upstream
fail_timeout : le temps de pause après les échecs max_fails

proxy_pass http://backserver/;
upstream backserver{
ip_hash;
server 127.0.0.1:9090 down; (down 表示单前的server暂时不参与负载)
server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大)
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器)
}

Recommandations associées :

Plusieurs façons pour Nginx d'atteindre l'équilibrage de charge

Question d'entretien PHP 7 : Comment configurer l'équilibrage de charge nginx

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!