Ausführen von nginx 1.0.15 unter CentOS 6.5 . Ich habe drei Upstream-Server und alles funktioniert einwandfrei. Wenn ich jedoch einen Ausfall simuliere und einen der Upstream-Server herunterfahre, stelle ich eine erhebliche Verzögerung der Antwortzeiten fest (zusätzliche 5-7 Sekunden). Sobald ich den ausgefallenen Server wieder online schalte, verschwindet die Verzögerung. Außerdem ist mir aufgefallen, dass die Antwortzeiten normal sind, wenn ich den httpd-Dienst auf dem simulierten Ausfallserver einfach stoppe. Die Verzögerung tritt nur auf, wenn der Server vollständig ausgefallen ist.
Hier ist mein conf:
upstream prod_example_com {
server app-a-1:51000;
server app-a-2:51000;
server app-a-3:51000;
}
server {
# link: http://wiki.nginx.org/MailCoreModule#server_name
server_name example.com www.example.com *.example.com;
#-----
# Upstream logic
#-----
set $upstream_type prod_example_com;
#-----
include include.d/common.conf;
# Configure logging
access_log /var/log/nginx/example/access/access.log access;
error_log /var/log/nginx/example/error.log error;
location / {
# link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
proxy_pass http://$upstream_type$request_uri;
# link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
# link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
proxy_pass http://$upstream_type$request_uri;
# link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
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_hide_header expires;
proxy_hide_header Cache-Control
# Even tho this reads like the older syntax, it is handled internally by nginx to set max age to now + 1 year
expires max;
# Allow intermediary caches the ability to cache the asset
add_header Cache-Control "public";
}
}
Ich habe die Vorschläge für ähnliche Beiträge wie diesen ausprobiert . Und anscheinend ist meine Version von Nginx zu alt, um health_checks zu unterstützen, wie in den Nginx- Dokumenten beschrieben . Ich habe auch versucht, die max_fails=2und fail_timeout=120für die app-a-3Upstream-Definition explizit festzulegen, aber keine davon scheint die zusätzliche Verzögerung von 5 bis 7 Sekunden für jede Anforderung zu vermeiden, wenn sie app-a-3offline ist.
- Update -
Pro Anfrage ist hier die Ausgabe für eine einzelne Anfrage, wenn diese app-a-3vollständig ausgefallen ist. Das einzige, was ich ungewöhnlich sehen konnte, ist die Verzögerung von 3 Sekunden zwischen dem ersten Ereignis und dem nachfolgenden Ereignis.
- Update Nr. 2 -
Es sieht so aus, als hätte Nginx vor einigen Jahren beschlossen, Nginx Plus zu entwickeln, das aktive Gesundheitschecks hinzufügt, jedoch für einen jährlichen Supportvertrag. Aufgrund einiger Artikel, die ich gelesen habe, hatte Nginx es satt, Unternehmen Millionen zu machen und nichts dafür zu bekommen.
Wie in den Kommentaren erwähnt, booten wir und haben nicht das Geld, um einen Vertrag über 1.350 Dollar abzuschließen. Ich habe dieses Repo gefunden , das die Funktionalität bietet. Sie fragen sich, ob jemand Erfahrung damit hat? Stabil? Performant?
Im schlimmsten Fall muss ich nur die Kugel beißen und die zusätzlichen 20 US-Dollar pro Monat für einen Linode "Node Balancer" bezahlen, von dem ich mir ziemlich sicher bin, dass er auf Nginx Plus basiert. Das einzige Problem besteht darin, dass außer einigen generischen Optionen keine Kontrolle über die Konfiguration besteht. Daher können mehrere vhost-Dateien nicht über einen Balancer unterstützt werden, und alle Knoten müssen sich im selben Datencenter befinden.
- Update Nr. 3 -
Hier sind einige Belagerungsergebnisse . Es scheint, dass der zweite Knoten falsch konfiguriert ist, da er nur etwa 75% der Anforderungen verarbeiten kann, die der erste und der dritte Knoten bearbeiten. Außerdem fand ich es seltsam, dass die Leistung beim Abschalten des zweiten Knotens so schlecht war, als ob ich den dritten Knoten (mit besserer Leistung) offline geschaltet hätte. Die Logik würde vorschreiben, dass ich beim Entfernen des schwachen Glieds (zweiter Knoten) eine bessere Leistung erzielen würde, da die verbleibenden zwei Knoten einzeln eine bessere Leistung als das schwache Glied erzielen.
Zusamenfassend:
node 1, 2, 3 + my nginx = 2037 requests
node 1, 2 + my nginx = 733 requests
node 1, 3 + my nginx = 639 requests (huh? these two perform better individually so together should be somewhere around ~1500 requests, based on 2000 requests when all nodes are up)
node 1, 3 + Linode Load Balancer = 790 requests
node 1, 2, 3 + Linode Load Balancer = 1,988 requests