Aufbau eines Nginx-Reverse-Proxy-Cache-Servers

Verwandte Tags：1. Nginx Ingress Controller
2. Nginx-Logs analysieren

Zusammenfassung: Dient dazu, Verbindungsanfragen (wie VPN/NAT) aus dem internen Netzwerk ins Internet weiterzuleiten.

Proxy-Dienste lassen sich grundsätzlich in Forward-Proxy und Reverse-Proxy unterteilen:

Forward-Proxy: Der Client gibt den Proxy-Server an und sendet die HTTP-Anfrage, die ursprünglich direkt an den Ziel-Webserver gerichtet war, an den Proxy-Server. Der Proxy-Server greift dann auf den Webserver zu und leitet dessen Antwort an den Client zurück:

Reverse-Proxy: Im Gegensatz zum Forward-Proxy kann ein Proxy-Server eingerichtet werden, wenn das lokale Netzwerk Ressourcen für das Internet bereitstellt und anderen Benutzern im Internet den Zugriff auf Ressourcen im lokalen Netzwerk ermöglicht. Der bereitgestellte Dienst ist ein Reverse-Proxy. Der Reverse-Proxy-Server nimmt Verbindungen aus dem Internet entgegen, leitet die Anfrage an den Server im internen Netzwerk weiter und sendet die Antwort zurück an

Clients im Internet, die eine Verbindung anfordern:

1. Nginx Reverse-Proxy: Der Scheduler des Webservers

1. Reverse-Proxy bedeutet, dass der Proxy-Server die Verbindungsanfrage des Clients entgegennimmt und die Anfrage an den Webserver (z. B. Apache, Nginx, Tomcat, IIS usw.) im Netzwerk weiterleitet. Das vom Webserver erhaltene Ergebnis wird an den anfragenden Client zurückgesendet, wobei der Proxy-Server nach außen als Server fungiert.

Wie in der obigen Abbildung zu sehen ist: Der Reverse-Proxy-Server empfängt die HTTP-Anfrage und leitet sie weiter. Als Reverse-Proxy-Server kann Nginx Anfragen je nach Inhalt der Benutzeranfrage an verschiedene Backend-Webserver weiterleiten, z. B. zur Trennung von statischen und dynamischen Inhalten. Zudem können mehrere virtuelle Hosts auf Nginx erstellt werden, sodass beim Aufrufen verschiedener Domainnamen (URLs) im Browser unterschiedliche Webserver oder Web-Cluster im Backend erreicht werden.

2. Welche Rolle spielt ein Reverse-Proxy?

① Schutz der Websitesicherheit: Jede Anfrage aus dem Internet muss zunächst einen Proxy-Server durchlaufen;

wKioL1jsz9yAHyulAABvTU4R-Ew435.png-wh_50

② Beschleunigung von Webanfragen durch Konfiguration der Cache-Funktion: Statische Ressourcen auf dem eigentlichen Webserver können zwischengespeichert werden, um die Last des echten Webservers zu verringern;

wKiom1jsz-nwYDqSAABjrKK3l5E661.png-wh_50

③ Lastverteilung ermöglichen: Als Load-Balancing-Server fungieren, der Anfragen gleichmäßig verteilt und die Last jedes Servers im Cluster ausgleicht;

wKiom1jsz__Q7RpoAAJQnYSWdA8640.png-wh_50

2. Was ist Nginx

1. Einführung in Nginx

Nginx ist ein leichtgewichtiger Webserver, Reverse-Proxy- und E-Mail-Proxy-Server. Bekannt für seine Stabilität, seinen umfangreichen Funktionsumfang, einfache Konfigurationsdateien und geringen Systemressourcenverbrauch. Nginx (ausgesprochen „Engine X“) wurde vom russischen Programmierer Igor Sysoev entwickelt. Ursprünglich kam es beim großen russischen Portal und der Suchmaschine Rambler (russisch: Рамблер) zum Einsatz. Diese Software wird unter einer BSD-ähnlichen Lizenz veröffentlicht und läuft auf UNIX, GNU/Linux, BSD, Mac OS X, Solaris und Microsoft Windows.

Einsatzstatus von Nginx

Nginx läuft bereits auf Rambler Media (www.rambler.ru), der größten Portalseite Russlands, und mehr als 20 % der virtuellen Hosting-Plattformen in Russland verwenden Nginx als Reverse-Proxy-Server.

In China nutzen viele Websites wie Taobao, Sina Blog, Sina Podcast, Netease News, Liujianfang, 56.com, Discuz!, Shuimu Community, Douban, YUPOO, Domestic, Xunlei Online usw. bereits Nginx als Webserver oder Reverse-Proxy-Server.

2. Die Kernfunktionen von Nginx

(1) Plattformübergreifend: Nginx kann auf den meisten Betriebssystemen kompiliert und ausgeführt werden; es gibt auch eine Windows-Version;

(2) Sehr einfache Konfiguration: Der Einstieg ist unkompliziert.

(3) Nicht-blockierend, hohe parallele Verbindungen: Offizielle Tests unterstützen bis zu 50.000 parallele Verbindungen; in der tatsächlichen Produktionsumgebung sind 20.000 bis 30.000 parallele Verbindungen möglich. (Dies verdankt Nginx dem modernen epoll-Modell);

Hinweis:

Bei einem Webserver betrachtet man zunächst den grundlegenden Ablauf einer Anfrage: Verbindungsaufbau – Datenempfang – Datentransmission. Auf Systemebene handelt es sich bei diesem Prozess (Verbindungsaufbau – Datenempfang – Datenübertragung) um Lese- und Schreibereignisse.

Wird die blockierende Aufrufmethode verwendet und die Lese-/Schreibereignisse sind noch nicht bereit, bleibt nur das Warten: Der aktuelle Thread wird angehalten, und Lese-/Schreibvorgänge können erst ausgeführt werden, wenn die Ereignisse bereit sind.

Bei der nicht-blockierenden Aufrufmethode kehrt das Ereignis sofort zurück und signalisiert, dass es noch nicht bereit ist. Nach kurzer Zeit wird das Ereignis erneut geprüft, bis es bereit ist. In der Zwischenzeit können andere Aufgaben erledigt werden. Obwohl der Thread nicht blockiert wird, muss der Ereignisstatus regelmäßig überprüft werden – dies ermöglicht zwar mehr Parallelität, verursacht jedoch spürbaren Overhead. Ein nicht-blockierender Aufruf bedeutet, dass der aktuelle Thread nicht blockiert wird, auch wenn das Ergebnis nicht sofort verfügbar ist.

(4) Ereignisgesteuert: Der Kommunikationsmechanismus nutzt das epoll-Modell, um größere parallele Verbindungen zu unterstützen.

Das nicht-blockierende Modell prüft kontinuierlich den Ereignisstatus, was erheblichen Overhead verursacht. Daher gibt es einen asynchronen, nicht-blockierenden Ereignisverarbeitungsmechanismus. Dieser ermöglicht die gleichzeitige Überwachung mehrerer Ereignisse. Die Aufrufe sind nicht-blockierend, aber es kann ein Timeout festgelegt werden. Wenn innerhalb des Timeouts ein Ereignis bereit ist, wird es zurückgegeben. Dieser Mechanismus löst die oben genannten Probleme sowohl blockierender als auch nicht-blockierender Aufrufe.

Am Beispiel des epoll-Modells: Ist ein Ereignis nicht bereit, wird es in die epoll-Warteschlange gestellt. Ist es bereit, wird es verarbeitet; andernfalls wartet es in epoll. So können zahlreiche parallele Anfragen gleichzeitig bearbeitet werden. Die parallelen Anfragen beziehen sich hier auf noch nicht verarbeitete Anfragen. Es gibt nur einen Thread, daher kann jeweils nur eine Anfrage gleichzeitig verarbeitet werden – es findet ein ständiger Wechsel zwischen den Anfragen statt. Dieser Wechsel erfolgt auch aktiv, weil das asynchrone Ereignis noch nicht bereit ist. Der Wechsel selbst verursacht keine Kosten; man kann es sich als Durchlaufen mehrerer vorbereiteter Ereignisse vorstellen.

Im Vergleich zum Multithreading-Ansatz bietet diese Ereignisverarbeitung große Vorteile: Es müssen keine Threads erstellt werden, und jede Anfrage beansprucht nur wenig Speicher. Es findet kein Kontextwechsel statt. Die Ereignisverarbeitung ist sehr leichtgewichtig, und auch bei hoher Parallelität entsteht keine unnötige Ressourcenverschwendung durch Kontextwechsel. Beim Apache-Server erhält jede Anfrage einen eigenen Worker-Thread. Erreicht die Parallelität mehrere Tausend, verarbeiten gleichzeitig Tausende Threads Anfragen. Dies stellt eine große Herausforderung für das Betriebssystem dar: Der Speicherverbrauch durch die Threads ist enorm, der CPU-Overhead durch Kontextwechsel ist sehr hoch, und die Leistung lässt sich nicht steigern – was bei hoher Parallelität zu einem deutlichen Leistungsabfall führt.

Zusammenfassung: Durch den asynchronen, nicht-blockierenden Ereignisverarbeitungsmechanismus verarbeitet Nginx mehrere vorbereitete Ereignisse zyklisch im Prozess und erreicht so hohe Parallelität bei geringem Ressourceneinsatz.

(5) Master/Worker-Struktur: Ein Master-Prozess erzeugt einen oder mehrere Worker-Prozesse.

Hinweis: Das Master-Worker-Designmuster besteht hauptsächlich aus zwei Komponenten: Master und Worker. Der Master verwaltet die Worker-Warteschlange und verteilt Anfragen an mehrere Worker zur parallelen Ausführung. Der Worker führt die eigentlichen Logikberechnungen durch und gibt die Ergebnisse an den Master zurück.

Welche Vorteile bietet dieses Prozessmodell bei Nginx? Die Verwendung unabhängiger Prozesse verhindert gegenseitige Beeinflussung. Beendet sich ein Prozess, arbeiten die anderen weiter – der Dienst wird nicht unterbrochen. Der Master-Prozess startet schnell einen neuen Worker-Prozess. Ein abnormaler Worker-Austritt ist zwar auf einen Programmfehler zurückzuführen und führt zum Ausfall aller Anfragen auf diesem Worker, betrifft jedoch nicht alle Anfragen insgesamt, wodurch das Risiko begrenzt bleibt.

(6) Geringer Speicherverbrauch: Der Speicherbedarf für die Verarbeitung zahlreicher paralleler Anfragen ist sehr niedrig. Bei 30.000 parallelen Verbindungen verbrauchen 10 Nginx-Prozesse nur 150 MB Speicher (15 MB × 10 = 150 MB).

(7) Integrierte Health-Check-Funktion: Fällt ein Webserver hinter dem Nginx-Proxy aus, beeinträchtigt dies den Frontend-Zugriff nicht.

(8) Bandbreite sparen: GZIP-Komprimierung wird unterstützt, und lokal vom Browser zwischengespeicherte Header können hinzugefügt werden.

(9) Hohe Stabilität: Als Reverse-Proxy eingesetzt, ist die Ausfallwahrscheinlichkeit minimal.

3. Nginx + Apache: Load Balancing für Webserver-Cluster

Nginx als Reverse-Proxy konfigurieren

Konfigurieren Sie Nginx als Reverse-Proxy und Load-Balancer. Nutzen Sie die Cache-Funktion, um statische Seiten in Nginx zwischenzuspeichern, die Anzahl der Backend-Server-Verbindungen zu reduzieren und die Gesundheit der Backend-Webserver zu überprüfen.



wKiom1js0B-iFnITAACVfFt6894317.png-wh_50

1. Nginx installieren

Umgebung:

BS: CentOS 7.2

Nginx: 192.168.31.83

Apache1: 192.168.31.141

Apache2: 192.168.31.250

Abhängigkeiten wie zlib-devel und pcre-devel installieren

[root@www ~]# yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel openssl openssl-devel

Hinweis:

Kombination von Proxy- und Upstream-Modulen für Backend-Web-Load-Balancing

Statische Datei-Caching über das Proxy-Modul

Kombiniert mit den Standardmodulen ngx_http_proxy_module und ngx_http_upstream_module von Nginx

Für die Gesundheitsprüfung des Backend-Servers kann auch das Drittanbietermodul nginx_upstream_check_module verwendet werden

Das Erweiterungsmodul nginx-sticky-module ermöglicht Cookie-Session-Sticking (Sitzungserhalt)

Mit ngx_cache_purge wird eine leistungsstärkere Cache-Bereinigungsfunktion erreicht

Die beiden oben genannten Module sind Drittanbieter-Erweiterungsmodule. Laden Sie den Quellcode vorab herunter und installieren Sie sie beim Kompilieren mit --add-module=src_path.



Nginx installieren

[root@www ~]# groupadd www #Gruppe www hinzufügen

[root@www ~]# useradd -g www www -s /sbin/nologin #Nginx-Benutzerkonto www erstellen, zur Gruppe www hinzufügen und direkte Anmeldung verbieten

#tar zxf nginx-1.10.2.tar.gz

#tar zxf ngx_cache_purge-2.3.tar.gz

#tar zxf master.tar.gz

# cd nginx-1.10.2/

[root@www nginx-1.10.2]# ./configure --prefix=/usr/local/nginx1.10 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with- http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi- temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky -module-ng-08a395c66e42

[root@www nginx-1.10.2]# make && make install

Hinweis: Alle Nginx-Module müssen beim Kompilieren hinzugefügt werden und können zur Laufzeit nicht dynamisch geladen werden.

4. Weitere Scheduling-Verfahren für Load Balancing:

Hier eine Übersicht weiterer Scheduling-Algorithmen, die vom Nginx-Load-Balancing-Modul unterstützt werden:

Polling (Standard): Jede Anfrage wird nacheinander in chronologischer Reihenfolge an verschiedene Backend-Server zugewiesen. Fällt ein Backend-Server aus, wird das fehlerhafte System automatisch ausgeschlossen, sodass der Benutzerzugriff nicht beeinträchtigt wird. Weight legt die Polling-Gewichtung fest. Je höher der Weight-Wert, desto höher die Zugriffswahrscheinlichkeit. Wird hauptsächlich verwendet, wenn die Leistung der Backend-Server ungleichmäßig ist.

ip_hash: Jede Anfrage wird basierend auf dem Hash-Ergebnis der Zugriffs-IP zugewiesen, sodass Besucher derselben IP denselben Backend-Server erreichen. Dies löst effektiv das Problem der Session-Sharing bei dynamischen Webseiten. Ist dieser Knoten nicht verfügbar, wird die Anfrage an den nächsten Knoten gesendet. Ohne Session-Synchronisierung erfolgt dabei eine Abmeldung.

least_conn: Die Anfrage wird an den Realserver mit den wenigsten aktuellen aktiven Verbindungen gesendet. Der Weight-Wert wird berücksichtigt.

url_hash: Dieses Verfahren weist Anfragen basierend auf dem Hash-Ergebnis der URL zu, sodass jede URL stets auf denselben Backend-Server geleitet wird. Dies verbessert die Effizienz des Backend-Cache-Servers weiter. Nginx unterstützt url_hash nicht nativ. Für diesen Algorithmus muss das Nginx-Hash-Paket nginx_upstream_hash installiert werden.

fair: Dies ist ein intelligenterer Load-Balancing-Algorithmus als die vorgenannten. Er führt Load Balancing intelligent nach Seitengröße und Ladezeit durch, d. h., Anfragen werden nach der Antwortzeit des Backend-Servers zugewiesen, wobei Server mit kurzer Antwortzeit priorisiert werden. Nginx unterstützt fair nicht nativ. Für diesen Algorithmus muss das upstream_fair-Modul von Nginx heruntergeladen werden.

5. Load Balancing und Health Check:

Streng genommen verfügt Nginx nicht über eine integrierte Gesundheitsprüfung für Backend-Knoten im Load Balancing. Dies kann jedoch über die entsprechenden Anweisungen im Standardmodul ngx_http_proxy_module und ngx_http_upstream_module umgesetzt werden. Fällt ein Backend-Knoten aus, wird automatisch auf den nächsten Knoten umgeschaltet.

weight: Die Polling-Gewichtung, auch in ip_hash verwendbar, Standardwert ist 1

max_fails: Maximale Anzahl fehlgeschlagener Anfragen, Standardwert ist 1. Wird dieser Wert überschritten, wird ein vom Modul proxy_next_upstream definierter Fehler zurückgegeben.

fail_timeout: Hat zwei Bedeutungen: Zum einen sind bis zu 2 Fehlversuche innerhalb von 10 s zulässig; zum anderen werden diesem Server nach 2 Fehlversuchen für 10 s keine weiteren Anfragen zugewiesen.

6. Nginx-Proxy-Cache-Nutzung:

Beim Caching werden JS-, CSS-, Bild- und andere statische Dateien vom Backend-Server in das von Nginx angegebene Cache-Verzeichnis zwischengespeichert. Dies entlastet nicht nur den Backend-Server, sondern beschleunigt auch den Zugriff. Da jedoch die rechtzeitige Cache-Bereinigung problematisch sein kann, wird das Modul ngx_cache_purge benötigt, um den Cache vor Ablauf manuell zu bereinigen.

Die häufig verwendeten Direktiven im Proxy-Modul sind proxy_pass und proxy_cache.

Die Web-Caching-Funktion von Nginx wird hauptsächlich durch die Befehlssätze proxy_cache, fastcgi_cache und zugehörige Direktiven umgesetzt. Die proxy_cache-Direktive ist für das Caching statischer Inhalte des Backend-Servers über den Reverse-Proxy zuständig, während fastcgi_cache hauptsächlich für das Caching dynamischer FastCGI-Prozesse verwendet wird.