Dieser Artikel erscheint auch im Blog von NGINX. Lesen Sie unter NGINX>
Traditionell wurden Webentwicklung und -hosting hauptsächlich mit dem LAMP-Stack durchgeführt – LAMP ist die Abkürzung für L inux (Betriebssystem), A Pache (Webserver), M ySQL (Datenbank) und P HP (Programmiersprache), die Kernkomponenten, die dann zum Ausführen von Unternehmenswebsites verwendet wurden.
Da Webstacks und Load Balancer agiler werden und geschäftliche Anforderungen eine bessere Leistung und Stabilität erfordern, wird es immer üblicher, Apache HTTP Server durch eine leichtgewichtige und hochskalierbare Alternative, NGINX, zu ersetzen. Mit NGINX wird der Stack als LEMP bekannt – L inux, (e )NGINX, M ySQL, P HP.
Atlantic.Net bietet eine Reihe von Lösungen, darunter Speicher, Hosting und verwaltete Dienste. Unsere VPS-Hosting-Plattform verfügt über eine LEMP-Option mit einem Klick, mit der Ihr Stack in weniger als 30 Sekunden einsatzbereit ist. Für diejenigen, die es vorziehen, NGINX von Docker aus auszuführen, haben wir sowohl Linux- als auch Windows-Cloud-Server mit Docker. Wir bieten auch verwaltete Dienste für diejenigen an, die Unterstützung bei der Einrichtung von NGINX wünschen oder benötigen.
Wir nutzen NGINX häufig und zuverlässig nicht nur als Webserver, sondern auch als Reverse-Proxy und Load-Balancer. Wir haben uns für NGINX entschieden, nachdem wir nach Lastausgleichslösungen für unseren zentralisierten Protokollierungscluster gesucht hatten. Durch die Verwendung von NGINX in verschiedenen Kapazitäten erreichen wir eine hohe Verfügbarkeit sowohl für unsere Front-End- als auch für unsere Back-End-Server bei gleichzeitig extrem geringem Platzbedarf – alles dank der Effizienz von NGINX bei der RAM- und CPU-Auslastung.
Im Hinblick darauf, welche spezifischen Funktionen von NGINX am nützlichsten sind, finden wir einige besonders leistungsfähig, darunter TCP/UDP-Proxy und Lastausgleich, Zugriffskontrolle und Drei-Wege-SSL-Handshakes. In diesem Blogbeitrag beschreibe ich, wie wir jede dieser Funktionen nutzen.
Load-Balancing unserer zentralisierten Protokollierung mit NGINX-Streams
Da die Notwendigkeit, Protokollierung für Auditing und Sicherheit bereitzustellen, immer mehr in den Fokus gerückt ist, suchten wir bei Atlantic.Net nach der richtigen Proxy- und Lastenausgleichslösung – nicht nur für HTTP-Datenverkehr, sondern auch für Syslog. Syslog wird üblicherweise im UDP-Format (User Datagram Protocol) gesendet, also brauchten wir etwas, das sowohl UDP als auch HTTP verarbeiten kann.
Hier wird der NGINX stream Module ins Spiel, da sie den Lastausgleich des UDP-Verkehrs ermöglichen. Load Balancing verwendet eine Reihe von Back-End-Servern zur effizienten Verteilung des Netzwerkverkehrs. Wie der Begriff schon sagt, besteht der Zweck darin, die Arbeitsbelastung gleichmäßig zu verteilen.
Im folgenden Snippet senden wir Syslog-Nachrichten von unserer Netzwerkinfrastruktur an unser Protokollierungs-Backend:
...
stream {
upstream networking_udp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass networking_udp;
}
}
... Streams funktionieren auch gut für SSL über TCP, wie im folgenden Beispiel gezeigt, das Filebeat-Protokolle sicher sendet:
...
upstream filebeat_tcp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 ssl;
ssl_certificate /etc/nginx/ssl/certs/cert.pem;
ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
proxy_pass filebeat_tcp;
proxy_ssl on;
proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
proxy_ssl_protocols TLSv1.2;
proxy_ssl_session_reuse on;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
... Wie Sie sehen können, ist NGINX in der Lage, UDP- und TCP-Verkehr (Transmission Control Protocol) zu proxieren und auszugleichen.
Die Verwendung von Reverse-Proxys und Load-Balancing ist hilfreich, wenn Sie einen Dienst, eine Datenbank oder ein Programm haben, das über UDP oder TCP kommuniziert. Grundsätzlich sind diese Methoden relevant, wenn Sie denselben Dienst, dieselbe Datenbank oder dieselbe Programminstanz auf mehreren Upstream-Servern ausführen, die von NGINX verwaltet werden. Bei Atlantic.Net nutzen wir auch den Reverse-Proxy von NGINX, da er unseren kritischen Back-End-Diensten eine zusätzliche Verschleierungsebene mit sehr geringem Overhead bietet.
Zugriffskontrolle
Ein weiterer wichtiger Schritt zur Sicherung unserer zentralisierten Protokollierung bestand darin, das Löschen von Daten zu verhindern. Darüber hinaus sind Zugriffskontrolllisten (ACLs) sehr nützlich, um den Datenverkehr basierend auf der IP-Adresse zu begrenzen. Für unsere Zwecke wollten wir den Zugriff auf Protokolldaten nur von unserem internen Verwaltungsnetzwerk zulassen.
NGINX gibt uns eine Möglichkeit, sehr genau zu beschreiben, welche Arten von HTTP-Aktionen durchgeführt werden können und von wo aus, wie hier zu sehen ist:
...
server {
listen 9200;
client_max_body_size 20M;
location / {
limit_except GET POST PUT OPTIONS {
deny all;
}
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
location ~* ^(/_cluster|/_nodes|/_shutdown) {
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
}
... NGINX unterstützt auch eine transparente IP-Funktion, die es uns ermöglicht, die ursprüngliche IP-Adresse zu sehen, nachdem die Anfrage den Proxy passiert hat. Diese Funktion hilft beim Nachverfolgen, woher Protokolle stammen. NGINX macht diese Aufgabe sehr einfach:
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Drei-Wege-SSL-Handshakes
NGINX handhabt beide Seiten der SSL-Übergabe für unsere zentralisierte Protokollierung sauber. Diese Implementierung ist sehr wichtig, da sie bedeutet, dass sowohl interne als auch Kundenserver sicher mit NGINX kommunizieren können. Jeder protokollierte Server verfügt über ein eigenes Zertifikat für die bidirektionale SSL-Kommunikation, wodurch Schwachstellen weiter reduziert werden. NGINX überträgt die Daten dann sicher über unser internes Netzwerk per SSL an die Logging-Server. Insgesamt sind für jede End-to-End-Kommunikation, die eine sichere Übertragung unterstützt, drei SSL-Zertifikate beteiligt. (Siehe das zweite Konfigurations-Snippet in Load-Balancing unserer zentralisierten Protokollierung mit NGINX-Streams für unser bevorzugtes Drei-Wege-SSL-Setup).
Perspektiven und Tests von NGINX
Verschiedene Einzelpersonen und Organisationen haben NGINX im Laufe der Jahre gelobt, und wir haben die gleichen zusätzlichen Vorteile von NGINX erlebt, die sie erwähnt haben.
Der Softwareentwickler Chris Lea von NodeSource vergleicht Apache mit Microsoft Word und stellt fest, dass beide Anwendungen eine absurd große Anzahl von Funktionen haben, aber normalerweise nur wenige notwendig sind. Lea bevorzugt NGINX, weil es die Funktionen hat, die Sie benötigen, ohne die Masse und eine weitaus bessere Leistung.
Laut Thomas Gieselman von der Risikokapitalgesellschaft BV Capital haben einige der von ihnen finanzierten Organisationen Probleme im Zusammenhang mit der Skalierung behoben, indem sie ihren Server auf NGINX umstellten. Gieselman ist der Ansicht, dass NGINX schnelles Wachstum einfacher und für mehr Unternehmen zugänglich macht.
Das Linux Journal führte einen einfachen Test mit der Apache-Benchmark-Software ab durch , um Apache mit NGINX (Version 2.2.8 bzw. 0.5.22) zu vergleichen. Die Programme top und vmstat wurden verwendet, um die Leistung des Systems zu überprüfen, während die beiden Server gleichzeitig liefen.
Der Test zeigte, dass NGINX als statischer Inhaltsserver schneller war als Apache. Die beiden Server liefen jeweils optimal, wobei die Parallelität auf 100 eingestellt war. Um 6500 Anfragen pro Sekunde zu verarbeiten, verwendete Apache 17 MB Arbeitsspeicher, 30 % CPU und 4 Worker-Prozesse (im Thread-Modus). Um mit einem viel schnelleren Clip von 11.500 Anfragen pro Sekunde zu liefern, benötigte NGINX nur 1 MB Arbeitsspeicher, 15 % CPU und 1 Worker.
Bob Ippolito gründete die Gaming-Plattform Mochi Media, die zu Spitzenzeiten 140 Millionen einzelne Nutzer pro Monat hatte – daher versteht er die Nachfrage nach hoher Leistung gut. Ippolito sagte 2006, dass er einen Test durchgeführt hat, bei dem er NGINX als Reverse-Proxy für zig Millionen HTTP-Anfragen pro Tag (d. h. einige hundert pro Sekunde) auf einem Server verwendet hat.
Als der NGINX-Server seine maximale Kapazität erreicht hatte, verbrauchte er ungefähr 10 % CPU und 15 MB Arbeitsspeicher in seinem Setup, das FreeBSD (ein auf UNIX basierendes Open-Source-Betriebssystem) war. Mit den gleichen Parametern generierte Apache 1000 Prozesse und verschlang eine riesige Menge an RAM. Pound hat übermäßig viele Threads erstellt und mehr als 400 MB für die verschiedenen Thread-Stapel verwendet. Benötigte leicht mehr CPU und leckte stündlich über 20 MB.
Atlantic.Net mit NGINX ausprobieren
Bei Atlantic.Net haben wir mit NGINX ähnliche Leistungssteigerungen festgestellt, wie sie von diesen verschiedenen Parteien beschrieben wurden. Auch wir haben von den oben beschriebenen Besonderheiten profitiert. Wenn Sie derzeit Apache oder einen anderen Webserver verwenden, sollten Sie NGINX ausprobieren, um zu sehen, ob Sie ähnliche Verbesserungen erhalten, die Ihnen helfen können, die Skalierbarkeit und den ständig wachsenden Bedarf an Geschwindigkeit besser zu bewältigen. Testen Sie NGINX noch heute mit einem Cloud-Server.