Stratégie et configuration d'équilibrage de charge nginx

Cet article présente principalement la stratégie et la configuration d'équilibrage de charge nginx, qui a une certaine valeur de référence. Maintenant, je le partage avec tout le monde. Les amis dans le besoin peuvent s'y référer

Avant-propos

Tout d'abord, comprenons brièvement ce qu'est l'équilibrage de charge. Cela peut être expliqué en le comprenant littéralement.NN serveurs partagent la charge de manière égale. certains serveurs ont une charge élevée et tombent en panne alors qu'un certain serveur est inactif. Ensuite, le principe de l'équilibrage de charge est qu'il peut être réalisé par plusieurs serveurs, c'est-à-dire que plus de deux serveurs suffisent. L'équilibrage de charge est une technologie qui doit être mise en œuvre pour les sites Web à forte concurrence et à fort trafic.

Environnement

Utilisation d'un déploiement d'équilibrage de charge sur deux machines

Tester le nom de domaine :a.com

A serveurIP : 10.1.108.31 (Serveur principal)

BServeurIP : 192.168.112.128

Idée de déploiement

Unserveur comme le serveur principal, le nom de domaine est directement résolu sur le serveur A (10.1.108.31 ), par A Le serveur est équilibré en charge sur lui-même (10.1.108.31 ) avec le serveur B (192.168.112.128 ) sur.

Projets nécessitant un équilibrage de charge

nodejs web projet, nom du projet social, port 6602.

Démarrez sur le serveur A et le serveur B serveur respectivement projet >social (comment démarrer le projet nodejs ne sera pas présenté ici), installez-le sur le A serveur nginx (Le mode d'installation n'est pas présenté ici, le serveur B n'a pas besoin d'être installé).

Déploiement

Résolution du nom de domaine

Puisque ce n'est pas le cas un environnement réel, utilisez simplement le nom de domaine a.com pour les tests, donc la résolution de a.com ne peut être effectuée que sur les paramètres du fichier hosts.

Ouvrir : C:WindowsSystem32driversetchosts

Ajouter

à la fin 10.1.108.31 a.com

Enregistrez et quittez, puis démarrez le mode commandeping pour voir s'il a été configuré avec succès

Il On peut voir sur la capture d'écran qu'il a été configuré avec succès. Résolu avec succès a.com vers 10.1.108.31

configuration nginx.conf

est dans le répertoire conf de l'installation répertoire de nginx , ouvrez le fichier nginx.conf

et ajoutez le code suivant dans le

http rubrique

upstream a.com {

            server 127.0.0.1:6602;

            server 192.168.112.128:6602;

        }

server {

        listen       80;

        location / {

            proxy_pass http://a.com;      #设置反向代理的地址

            proxy_connect_timeout 2;      #代理服务器超时时间，秒

        }

Note :

2

nœuds dont un en panne, nginx lui distribuera toujours les requêtes, Jusqu'au délai d'expiration, il n'y a pas de réponse, puis il est envoyé à un autre nœud. Par défaut, plus aucune demande ne sera envoyée dans 1 minutes, et l'action ci-dessus sera répétée après une minute. Le résultat est que le site Web est parfois rapide et parfois lent. Réglez proxy_connect_timeout sur 2 secondes pour raccourcir le délai d'attente afin qu'il le soit. pas trop lent.

Enregistrez la configuration, démarrez

nginx, visitez a.com 1

Figure 2

Comme le montre la figure ci-dessus, j'ai visité deux fois

A.COM , et je suis revenu 🎜>A le serveur et B sont des données. Indique que la configuration de l'équilibrage de charge nginx est réussie.

Explication détaillée de la configuration de nginx

user    www-data;                        #运行用户worker_processes  4;                   #启动进程,通常设置成和cpu的核数相等

worker_cpu_affinity 0001 0010 0100 1000;   #为每个进程绑定cpu内核，参考下面注解1

error_log  /var/log/nginx/error.log;   #全局错误日志pid        /var/run/nginx.pid;          #PID文件

#events模块中包含nginx中所有处理连接的设置

events {                            
   use   epoll;  #连接处理方式，参考注解2

  worker_connections  1024;    #单个后台worker process进程的最大并发链接数，不能超过最大文件打开数，最大文件打开数可以通过worker_rlimit_nofile修改。  multi_accept on;   #on:worker process一次接受所有新连接, off: 一次接受一个新的连接

}

#设定http服务器，利用它的反向代理功能提供负载均衡支持

http {
     
    include       /etc/nginx/mime.types;       #设定mime类型,类型由mime.type文件定义

   include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

    default_type  application/octet-stream;  #默认文件类型

   #charset utf-8; #默认编码

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;       #设定日志格式

    
    sendfile        on;   #开启高效文件传输模式，sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的负载.注意：如果图片显示不正常把这个改成off。

   #防止网络阻塞，两者区别参考注解3    tcp_nopush     on;

   tcp_nodelay        on;

autoindex on; #开启目录列表访问，合适下载服务器，默认关闭。    keepalive_timeout  30;                 #连接超时时间，单位秒

  #gzip模块设置  gzip on; #开启gzip压缩输出  gzip_min_length 1k; #最小压缩文件大小,大于1K才压缩  gzip_buffers 4 16k; #压缩缓冲区  gzip_http_version 1.0; #压缩版本（默认1.1，前端如果是squid2.5请使用1.0）  gzip_comp_level 2; #压缩等级，1-10，数字越大压缩也越大  gzip_types text/plain application/x-javascript text/css application/xml;
  #压缩类型，默认就已经包含text/html，所以上面就不用再写了，写上去也不会有问题，但是会有一个warn。

  gzip_vary on;  # 和http头有关系，加个vary头，给代理服务器用的，有的浏览器支持压缩，有的不支持，所以避免浪费不支持的也压缩，所以根据客户端的HTTP头来判断，是否需要压缩

  gzip_disable "MSIE [1-6]\.";  #禁用IE6的gzip压缩，IE6的某些版本对gzip的压缩支持很不好，会造成页面的假死

    client_header_buffer_size    1k;    #设定请求头缓存大小    large_client_header_buffers  4 10k;  #设置用于读取大客户机请求头文件的最大数量和大小，超过则返回给客户端414或400错误。请求处理结束后缓存释放。

   #使用Nginx最大的好处就是负载均衡

   #upstream用于设置一组可以在proxy_pass指令中使用的代理服务器，默认的代理方式为轮询。    upstream mysvr {

      #设定负载均衡的服务器列表

      #server指令用于指定后端服务器的名称和参数。       server 192.168.8.1x:80  weight=5;
       server 192.168.8.2x:80  weight=1;   
       server 192.168.8.3x:80  weight=6; 
    }

   #在server内可通过proxy_pass指令设置关于反向代理的upstream服务器集群。             
   server {                
        listen       80;  #侦听192.168.8.x的80端口        server_name  192.168.8.x;

      
       location ~ .*\.aspx$ {     #对aspx后缀的进行负载均衡请求

            root   /root;             #定义服务器的默认网站根目录位置             index index.php index.html index.htm;   #定义首页索引文件的名称

             proxy_pass  http://mysvr ;                 #请求转向mysvr 定义的服务器列表

             #以下是一些反向代理的配置可删除.

             proxy_redirect off;

             #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
             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_connect_timeout 90;     #nginx跟后端服务器连接超时时间(代理连接超时)
             proxy_send_timeout 90;        #后端服务器数据回传时间(代理发送超时)
             proxy_read_timeout 90;         #连接成功后，后端服务器响应时间(代理接收超时)
             proxy_buffer_size 4k;          #设置代理服务器（nginx）保存用户头信息的缓冲区大小             proxy_buffers 4 32k;     #proxy_buffers缓冲区，网页平均在32k以下的话，这样设置             proxy_busy_buffers_size 64k;    #高负荷下缓冲大小（proxy_buffers*2）             proxy_temp_file_write_size 64k;  #设定缓存文件夹大小，大于这个值，将从upstream服务器传

         }

   }
}

nginx L'annotation de configuration

1.worker_cpu_affinityNotes

Nginx est non activé par défaut En profitant des processeurs multicœurs, nous pouvons utiliser pleinement les processeurs multicœurs en augmentant le paramètre de configuration worker_cpu_affinity. Le processeur est la ressource la plus critique pour le traitement et le calcul des tâches. Plus il y a de cœurs de processeur, meilleures sont les performances.
Configurez le processeur multicœur Nginx, les méthodes d'utilisation et les exemples de worker_cpu_affinity

2coreCPU, activez 2 processus
worker_processes 2;
worker_cpu_affinity 01 10;

01 signifie activer le premier processeur cœur, 10 signifie activer le deuxième cœur du processeur
worker_cpu_affinity 01 10 signifie démarrer deux processus, le premier processus correspond au premier Cœur de CPU, et le deuxième processus correspond au deuxième cœur de CPU.

2CPU de base, Ouvrir 4 processus
worker_processes 4;
worker_cpu_affinity 01 10 01 10;

ouvre quatre processus, qui correspondent respectivement à l'ouverture de 2cœurs CPU

4CPU de base, compte 4 processus
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

0001 signifie activer le premier cœur du processeur , 0010 signifie activer le deuxième cœur du processeur, et ainsi de suite

4 Core CPU, démarrez 2 processus
worker_processes 2;
worker_cpu_affinity 0101 1010;

0101 signifie allumer le premier et le troisième cœurs, 1010 signifie activer les deuxième et quatrième cœurs
2 processus correspondent à quatre cœurs
la configuration worker_cpu_affinity est écrite dans /etc/nginx/nginx.conf.
2 cœurs valent 01, 4 cœurs valent 0001 et 8 cœurs valent 00000001. Il y a plusieurs chiffres en fonction du nombre de cœurs 1 signifie que le cœur est allumé, 0 signifie que le cœur est éteint.

8CPU de base, compte 8 processus
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 0010000001000000;

0001 signifie activer le premier cœur du processeur, 0010 signifie activer le deuxième cœur du processeur, et ainsi de suite
Un maximum de 8 worker_processes peuvent être ouverts. L'amélioration des performances de plus de 8 ne sera pas améliorée et la stabilité deviendra inférieure, donc 8 processus suffisent.

2.Méthode de traitement des connexions

nginx prend en charge plusieurs méthodes de traitement des connexions , la méthode utilisée dépend du système utilisé. Lorsque le système prend en charge plusieurs méthodes, nginx sélectionnera automatiquement la méthode la plus efficace. Si nécessaire, la méthode à utiliser peut être précisée via la directive use.

sélectionner :

1.PriseLimite de quantité : Le nombre de Socket utilisables dans ce mode est déterminé par FD_SETSIZE, La valeur par défaut du noyau est 32*32=1024.
Restrictions de fonctionnement :En parcourant FD_SETSIZE( 1024)Socket pour terminer la planification, peu importe lequel Socket est actif , sont parcourus partout .

sondage :

1.PriseQuasiment aucune quantité Limitation :Le Socket correspondant dans ce mode est un tableau Pour enregistrer , aucune limite de taille ( par défaut 4k 2.Restrictions de fonctionnement :
Identique àSélectionnez epoll :

Linux 2.6ou supérieur

1.Prise

Quantité illimitée :Idem comme Sondage 2.Opération illimitée :
Basé sur le mode réflexion fourni par le noyau ,Lorsqu'il y a un Socket actif, le noyau accède au Socketrappel de 🎜>, n'a pas besoin de traverser le sondage .kqueue  :

n'est pas très différent de epoll

, le principe est le même, et il est utilisé dans le système d'exploitation :

FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 et MacOS X

sélectionnerLa raison de l'inefficacité du mode
sélectionner La raison de l'inefficacité du mode le mode est Select est déterminé par la définition et n'a rien à voir avec l'implémentation du système d'exploitation. Tout noyau doit effectuer un round robin lors de l'implémentation de select. afin de connaître ces socket, cela consommera du cpu. De plus, lorsque vous disposez d'une grande collection de prises, même si seule une petite partie des prises sont à tout moment une fois "Actif", mais à chaque fois il faut remplir toutes les prise La saisie d'un FD_SET consommera également du cpu, et lorsque sélectionnerAprès le retour , vous devrez peut-être effectuer «Cartographie contextuelle» lors du traitement des affaires, ce qui aura également un certain impact sur les performances. Par conséquent, select est relativement inefficace que epoll. Le scénario applicable pour epoll
est qu'il existe un grand nombre de socket, mais l'activité n'est pas très élevée.

3.tcp_nodelay et tcp_nopushDifférences

tcp_nodelay

Nginx

L'option TCP_NODELAY permet d'ouvrir un nouveau Ajouté Option TCP_NODELAY pour le socket.

Mais cela provoquera une situation :

L'application du terminal enverra un paquet à chaque fois qu'une opération se produit, et dans des circonstances typiques, un paquet aura un octet de données et

40 octets d'en-tête long, ce qui entraînera une surcharge de 4000%, ce qui est très Cela peut facilement provoquer une surcharge du réseau congestion.

Pour éviter cela, la pile

TCP est implémentée pour attendre les données 0.2 horloge en secondes, il n'enverra donc pas de paquet de données après l'opération, mais regroupera les données au cours de cette période dans un seul gros paquet.

Ce mécanisme est garanti par l'algorithme Nagle.

Nagle est devenu plus tard un standard et a été immédiatement implémenté sur Internet. Il s'agit désormais de la configuration par défaut, mais il existe des situations dans lesquelles il est souhaitable de désactiver cette option.

Imaginez maintenant qu'une application fasse une requête et souhaite envoyer de petits morceaux de données. Nous pouvons choisir d'envoyer les données immédiatement ou d'attendre que davantage de données soient générées, puis de les renvoyer.

Les applications interactives et clientes / basées sur serveur bénéficieront grandement si nous envoyons des données immédiatement. Si la demande est faite immédiatement, le temps de réponse sera plus rapide.

L'opération ci-dessus peut être accomplie en définissant l'option TCP_NODELAY = on du socket, désactivant ainsi Nagle algorithme.

Une autre situation nous oblige à attendre que la quantité de données atteigne le maximum avant d'envoyer toutes les données via le réseau en même temps. Cette méthode de transmission de données est bénéfique pour. la communication de grandes quantités de données. Performance, une application typique est un serveur de fichiers.

Nginx utilise TCP_NODELAY dans la connexion de keepalive . keepalive La connexion restera connectée une fois les données envoyées et permettra également d'envoyer davantage de données via elle.

De cette façon, vous pouvez instancier beaucoup moins de connexions sockées et le processus de prise de contact à trois pour chaque connexion.

tcp_nopush

dans nginx , tcp_nopush configuration et tcp_nodelay s'excluent mutuellement. Il peut configurer la taille des paquets de données envoyées en même temps.

En d'autres termes, il n'envoie pas de paquets après avoir accumulé 0,2 secondes en fonction du temps, mais lorsque les paquets s'accumulent jusqu'à une certaine taille .

Dans nginx , tcp_nopush doit être le même que sendfile À utiliser avec .

4.L'équilibrage de charge

nginx prend en charge les éléments suivants Mécanisme d'équilibrage de charge :

1) round-robin : sondage. Distribuez les requêtes à différents serveurs par interrogation. La valeur par défaut est l'interrogation.

2）least-connected：最少连接数。将下一个请求分配到连接数最少的那台服务器上。

3）ip-hash ：基于客户端的IP地址。散列函数被用于确定下一个请求分配到哪台服务器上。

在一些要求需要更长的时间才能完成的应用情况下，最少连接可以更公平地控制应用程序实例的负载。使用最少连接负载均衡，nginx不会向负载繁忙的服务器上分发请求，而是将请求分发到负载低的服务器上。配置如下：

upstream mysvr {

   least-connected
  server 192.168.8.1:3128
  server 192.168.8.2:80
  server 192.168.8.3:80
}

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!