Analyse der Nginx-Lastausgleichsinstanz

Nginx-Lastausgleich

Beachten Sie: Da sich unsere Website noch in einem frühen Entwicklungsstadium befindet, fungiert Nginx nur als Agent für einen Back-End-Server. Mit zunehmendem Ruf unserer Website wird dies jedoch immer mehr Die Leute kommen damit nicht zurecht, also haben wir mehrere Server hinzugefügt. Wie konfigurieren wir Proxys für so viele Server? Hier dienen zwei Server als Beispiel.

1.Beschreibung des Upstream-Lastausgleichsmoduls

Fall:

Im Folgenden wird die Liste der Lastausgleichsserver festgelegt.

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 ist das http-Upstream-Modul von Nginx. Dieses Modul verwendet einen einfachen Planungsalgorithmus, um einen Lastausgleich von der Client-IP zum Back-End-Server zu erreichen. In den obigen Einstellungen wird über die Upstream-Direktive ein Load Balancer-Name test.net angegeben. Dieser Name kann beliebig angegeben werden und kann direkt dort aufgerufen werden, wo er später benötigt wird.

2. Vom Upstream unterstützte Lastausgleichsalgorithmen

Das Lastausgleichsmodul von nginx unterstützt derzeit 4 Planungsalgorithmen, die im Folgenden separat vorgestellt werden.

• Abfrage (Standard). Jede Anfrage wird nacheinander in chronologischer Reihenfolge verschiedenen Back-End-Servern zugewiesen. Fällt ein Back-End-Server aus, wird das fehlerhafte System automatisch eliminiert, sodass der Benutzerzugriff nicht beeinträchtigt wird. Die Gewichtung gibt die Abfragegewichtung an. Je größer die Gewichtung, desto höher die zugewiesene Zugriffswahrscheinlichkeit. Sie wird hauptsächlich verwendet, wenn die Leistung der einzelnen Back-End-Server ungleichmäßig ist.

• ip_hash. Jede Anfrage wird entsprechend dem Hash-Ergebnis der aufgerufenen IP zugewiesen, sodass Besucher von derselben IP festen Zugriff auf einen Back-End-Server haben, wodurch das Problem der Sitzungsfreigabe dynamischer Webseiten effektiv gelöst wird.

• fair. Dies ist ein intelligenterer Lastausgleichsalgorithmus als die beiden oben genannten. Dieser Algorithmus kann einen intelligenten Lastausgleich basierend auf Seitengröße und Ladezeit durchführen, d. h. Anforderungen basierend auf der Antwortzeit des Back-End-Servers zuweisen und diejenigen mit kurzen Antwortzeiten priorisieren. Nginx selbst unterstützt Fair nicht. Wenn Sie diesen Planungsalgorithmus verwenden müssen, müssen Sie das Modul upstream_fair von Nginx herunterladen.

• url_hash. Diese Methode weist Anforderungen entsprechend dem Hash-Ergebnis der Zugriffs-URL zu, sodass jede URL an denselben Back-End-Server weitergeleitet wird, was die Effizienz des Back-End-Cache-Servers weiter verbessern kann. Nginx selbst unterstützt url_hash nicht. Wenn Sie diesen Planungsalgorithmus verwenden müssen, müssen Sie das Nginx-Hash-Softwarepaket installieren.
  

3. Upstream-unterstützte Statusparameter

Im http-Upstream-Modul können Sie die IP-Adresse und den Port des Back-End-Servers über den Serverbefehl angeben und auch jeden Back-End-Server festlegen den Lastausgleichsplan. Häufig verwendete Zustände sind:

• down, was bedeutet, dass der aktuelle Server vorübergehend nicht am Lastausgleich teilnimmt.

• Backup, reservierte Backup-Maschine. Anforderungen werden nur dann an den Standby-Computer gesendet, wenn alle anderen Nicht-Standby-Computer ausgefallen oder beschäftigt sind, sodass der Standby-Computer am wenigsten belastet ist.

• max_fails, die Anzahl der zulässigen Anforderungsfehler, der Standardwert ist 1. Wenn die Anzahl die maximale Anzahl überschreitet, wird ein vom Modul „proxy_next_upstream“ definierter Fehler zurückgegeben.

• Nach mehreren Fehlern (max_fails-Zeiten werden erreicht) wird der Dienst für einen bestimmten Zeitraum angehalten und ein fail_timeout ausgelöst. max_fails kann zusammen mit fail_timeout verwendet werden.
  

Hinweis: Wenn der Lastplanungsalgorithmus ip_hash ist, kann der Status des Backend-Servers in der Lastausgleichsplanung nicht Gewichtung und Backup sein.

4. Experimentelle Topologie

5. Konfigurieren Sie den Nginx-Lastausgleich

[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;
   }
}

Hinweis: Upstream ist außerhalb des Servers definiert und kann nicht innerhalb des Servers definiert werden Nachdem Sie den Upstream definiert haben, verwenden Sie einfach „proxy_pass“, um darauf zu verweisen. 6. Laden Sie die Konfigurationsdatei neu .

8. Überprüfen Sie das Webzugriffsserverprotokoll

web1:

[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：                      [确定]

web2:

Ändern Sie zunächst das Format des Webserver-Datensatzprotokolls.

[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)"

Dann besuchen Sie uns mehrmals und überprüfen Sie weiterhin das Protokoll.

[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：                      [确定]

Beachten Sie, wie Sie sehen können, zeichnen die Protokolle beider Server Zugriffsprotokolle von 192.168.18.138 auf, was auch zeigt, dass die Lastausgleichskonfiguration erfolgreich ist.

9. Konfigurieren Sie Nginx für die Integritätsstatusprüfung

max_fails, die Anzahl der zulässigen Anforderungsfehler, der Standardwert ist 1. Wenn die Anzahl die maximale Anzahl überschreitet, wird ein vom Modul „proxy_next_upstream“ definierter Fehler zurückgegeben.

Nachdem die maximal zulässige Anzahl von Fehlern (max_fails) erreicht wurde, wird der Dienst für einen bestimmten Zeitraum (fail_timeout) ausgesetzt. Integritätsstatusprüfungen können mit max_fails und fail_timeout durchgeführt werden.

[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：                        [确定]

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

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

注，大家可以看到，现在又可以重新访问，说明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：                        [确定]

注，大家可以看到，当所有服务器都不能工作时，就会启动备份服务器。好了，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.测试一下

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

18.统计web2的访问连接数

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

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

Das obige ist der detaillierte Inhalt vonAnalyse der Nginx-Lastausgleichsinstanz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!