Maison  >  Article  >  Opération et maintenance  >  analyse de l'instance d'équilibrage de charge nginx

analyse de l'instance d'équilibrage de charge nginx

WBOY
WBOYavant
2023-05-21 08:01:321052parcourir

nginx Load Balancing

Remarque, comme vous pouvez le constater, étant donné que notre site Web en est aux premiers stades de développement, nginx n'agit que comme agent pour un serveur principal, mais à mesure que la réputation de notre site Web grandit, de plus en plus les gens le visitent. Le serveur ne pouvait vraiment pas le gérer, nous avons donc ajouté plusieurs serveurs. Comment pouvons-nous configurer des proxys pour autant de serveurs ? Ici, nous prenons deux serveurs comme exemple pour le démontrer à tout le monde.

1.description du module d'équilibrage de charge en amont

Cas :

Ce qui suit définit la liste des serveurs d'équilibrage de charge.

upstream test.net{
ip_hash;
server 192.168.10.13:80;
server 192.168.10.14:80 down;
server 192.168.10.15:8009 max_fails=3 fail_timeout=20s;
server 192.168.10.16:8080;
}
server {
 location / {
  proxy_pass http://test.net;
 }
}

upstream est le module http en amont de nginx. Ce module utilise un algorithme de planification simple pour réaliser l'équilibrage de charge de l'IP du client vers le serveur back-end. Dans les paramètres ci-dessus, un nom d'équilibreur de charge test.net est spécifié via la directive en amont. Ce nom peut être spécifié arbitrairement et peut être appelé directement là où il est nécessaire ultérieurement.

2. Algorithmes d'équilibrage de charge pris en charge par le module d'équilibrage de charge en amont

nginx prend actuellement en charge 4 algorithmes de planification, qui sont présentés séparément ci-dessous.

  • Sondage (par défaut). Chaque requête est attribuée à différents serveurs back-end un par un dans l'ordre chronologique. Si un serveur back-end tombe en panne, le système défectueux est automatiquement éliminé afin que l'accès des utilisateurs ne soit pas affecté. Weight spécifie le poids d'interrogation. Plus la valeur de pondération est élevée, plus la probabilité d'accès attribuée est élevée. Elle est principalement utilisée lorsque les performances de chaque serveur back-end sont inégales.

  • ip_hash. Chaque requête est allouée en fonction du résultat de hachage de l'adresse IP accédée, de sorte que les visiteurs de la même adresse IP aient un accès fixe à un serveur principal, ce qui résout efficacement le problème de partage de session des pages Web dynamiques.

  • juste. Il s'agit d'un algorithme d'équilibrage de charge plus intelligent que les deux ci-dessus. Cet algorithme peut effectuer intelligemment un équilibrage de charge en fonction de la taille de la page et du temps de chargement, c'est-à-dire allouer les requêtes en fonction du temps de réponse du serveur back-end et donner la priorité à celles ayant des temps de réponse courts. nginx lui-même ne prend pas en charge fair. Si vous devez utiliser cet algorithme de planification, vous devez télécharger le module amont_fair de nginx.

  • url_hash. Cette méthode attribue les requêtes en fonction du résultat de hachage de l'URL d'accès, de sorte que chaque URL soit dirigée vers le même serveur principal, ce qui peut encore améliorer l'efficacité du serveur de cache principal. nginx lui-même ne prend pas en charge url_hash. Si vous devez utiliser cet algorithme de planification, vous devez installer le package logiciel de hachage nginx.

3. Paramètres d'état pris en charge en amont

Dans le module http en amont, vous pouvez spécifier l'adresse IP et le port du serveur back-end via la commande server, et vous pouvez également définir chaque serveur back-end dans l'état du planning d'équilibrage de charge. Les états couramment utilisés sont :

  • down, ce qui signifie que le serveur actuel ne participe pas à l'équilibrage de charge pour le moment.

  • sauvegarde, machine de sauvegarde réservée. Les requêtes sont envoyées à la machine de secours uniquement lorsque toutes les autres machines non en veille sont en panne ou occupées, de sorte que la machine de secours a la charge la plus légère.

  • max_fails, le nombre d'échecs de requêtes autorisés, la valeur par défaut est 1. Si le nombre dépasse le nombre maximum, une erreur définie par le module proxy_next_upstream sera renvoyée.

  • Après plusieurs échecs (atteignant les temps max_fails), le service sera suspendu pendant un certain temps et fail_timeout sera déclenché. max_fails peut être utilisé avec fail_timeout.

Remarque : Lorsque l'algorithme de planification de charge est ip_hash, l'état du serveur backend dans la planification de l'équilibrage de charge ne peut pas être le poids et la sauvegarde.

4. Topologie expérimentale

analyse de linstance déquilibrage de charge nginx

5. Configurez l'équilibrage de charge nginx

[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
   server 192.168.18.201 weight=1;
   server 192.168.18.202 weight=1;
 }
 server {
   listen    80;
   server_name localhost;
   #charset koi8-r;
   #access_log logs/host.access.log main;
   location / {
       proxy_pass   http://webservers;
       proxy_set_header x-real-ip $remote_addr;
   }
}

Remarque, l'amont est défini en dehors du serveur{ } et ne peut pas être défini à l'intérieur du serveur{ }. Après avoir défini en amont, utilisez simplement proxy_pass pour le référencer.

6. Rechargez le fichier de configuration

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx:                      [确定]

7. Testez-le

analyse de linstance déquilibrage de charge nginx

analyse de linstance déquilibrage de charge nginx

Remarque, vous pouvez constamment actualiser le contenu de navigation, vous pouvez constater que web1 et web2 apparaissent alternativement, atteignant l'effet de charge équilibrée. .

8. Vérifiez le journal du serveur d'accès Web

web1:

[root@web1 ~]# tail /var/log/httpd/access_log
192.168.18.138 - - [04/sep/2013:09:41:58 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:58 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:59 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:59 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:21 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:22 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:22 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"

web2:

Modifiez d'abord le format du journal d'enregistrement du serveur Web.

[root@web2 ~]# vim /etc/httpd/conf/httpd.conf
logformat "%{x-real-ip}i %l %u %t \"%r\" %>s %b \"%{referer}i\" \"%{user-agent}i\"" combined
[root@web2 ~]# service httpd restart
停止 httpd:                        [确定]
正在启动 httpd:                      [确定]

Ensuite, visitez plusieurs fois et continuez à vérifier le journal.

[root@web2 ~]# tail /var/log/httpd/access_log
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:29 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:29 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"

Notez, comme vous pouvez le voir, que les journaux des deux serveurs enregistrent les journaux d'accès de 192.168.18.138, ce qui montre également que la configuration de l'équilibrage de charge est réussie.

9. Configurez nginx pour la vérification de l'état de santé

  • max_fails, le nombre d'échecs de requête autorisés, la valeur par défaut est 1. Si le nombre dépasse le nombre maximum, une erreur définie par le module proxy_next_upstream sera renvoyée.

  • Après avoir connu le nombre maximum d'échecs autorisé (max_fails), le service sera suspendu pendant un certain temps (fail_timeout). Les vérifications de l'état de santé peuvent être effectuées à l'aide de max_fails et fail_timeout.

[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
  }

10.重新加载一下配置文件

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx:                      [确定]

11.停止服务器并测试

先停止web1,进行测试。
[root@web1 ~]# service httpd stop
停止 httpd:                        [确定]

analyse de linstance déquilibrage de charge nginx

注,大家可以看到,现在只能访问web2,再重新启动web1,再次访问一下。

[root@web1 ~]# service httpd start
正在启动 httpd:                      [确定]

analyse de linstance déquilibrage de charge nginx

analyse de linstance déquilibrage de charge nginx

注,大家可以看到,现在又可以重新访问,说明nginx的健康状态查检配置成功。但大家想一下,如果不幸的是所有服务器都不能提供服务了怎么办,用户打开页面就会出现出错页面,那么会带来用户体验的降低,所以我们能不能像配置lvs是配置sorry_server呢,答案是可以的,但这里不是配置sorry_server而是配置backup。

12.配置backup服务器

[root@nginx ~]# vim /etc/nginx/nginx.conf
server {
        listen 8080;
        server_name localhost;
        root /data/www/errorpage;
        index index.html;
    }
upstream webservers {
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
    server 127.0.0.1:8080 backup;
  }
[root@nginx ~]# mkdir -pv /data/www/errorpage
[root@nginx errorpage]# cat index.html
<h1>sorry......</h1>

13.重新加载配置文件

[root@nginx errorpage]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx:                      [确定]

14.关闭web服务器并进行测试

[root@web1 ~]# service httpd stop
停止 httpd:                        [确定]
[root@web2 ~]# service httpd stop
停止 httpd:                        [确定]

analyse de linstance déquilibrage de charge nginx

注,大家可以看到,当所有服务器都不能工作时,就会启动备份服务器。好了,backup服务器就配置到这里,下面我们来配置ip_hash负载均衡。

15.配置ip_hash负载均衡

ip_hash,每个请求按访问ip的hash结果分配,这样来自同一个ip的访客固定访问一个后端服务器,有效解决了动态网页存在的session共享问题。(一般电子商务网站用的比较多)

[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
    ip_hash;
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
    #server 127.0.0.1:8080 backup;
  }

注,当负载调度算法为ip_hash时,后端服务器在负载均衡调度中的状态不能有backup。(有人可能会问,为什么呢?大家想啊,如果负载均衡把你分配到backup服务器上,你能访问到页面吗?不能,所以了不能配置backup服务器)

16.重新加载一下服务器

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx:                      [确定]

17.测试一下

analyse de linstance déquilibrage de charge nginx

注,大家可以看到,你不断的刷新页面一直会显示的民web2,说明ip_hash负载均衡配置成功。下面我们来统计一下web2的访问连接数。

18.统计web2的访问连接数

[root@web2 ~]# netstat -an | grep :80 | wc -l
304

注,你不断的刷新,连接数会越来越多。

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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer