Im August 2016 führte Amazon Web Services (AWS) den Application Load Balancer für das Layer 7-Lastausgleichssystem von HTTP- und HTTPS-Verkehr ein. Das neue Produkt fügte mehrere Funktionen hinzu, die im vorhandenen Layer 4- und Layer 7-Load Balancer von AWS, dem Elastic Load Balancer, fehlten, der offiziell in Classic Load Balancer umbenannt wurde.
Ein Jahr später führte AWS den Network Load Balancer für ein verbessertes Layer-4-Load-Balancing ein. Benutzer, die hochverfügbare, skalierbare Anwendungen auf AWS ausführen, haben nun folgende Auswahlmöglichkeiten:
In diesem Beitrag überprüfen wir die Funktionen von ALB und vergleichen seine Preise und Funktionen mit NGINX Open Source und NGINX Plus.
Hinweise –
ALB ist wie Classic Load Balancer oder NLB eng in AWS integriert. Amazon beschreibt es als Layer-7-Load Balancer – allerdings bietet es nicht die gesamte Bandbreite an Funktionen, Feinabstimmung und direkter Kontrolle, die ein eigenständiger Layer-7-Reverse-Proxy und Load Balancer bieten kann.
ALB bietet die folgenden Funktionen, die in Classic Load Balancer fehlen:
dem Host
-Header und Feldern in der Anforderung, die standardmäßige und benutzerdefinierte HTTP-Header und -Methoden, Abfrageparameter und die Quell-IP-Adresse enthalten. (Siehe „Vorteile der Migration von einem klassischen Load Balancer“ in der ALB-Dokumentation .)(Einen vollständigen Funktionsvergleich von ALB und Classic Load Balancer finden Sie unter „Produktvergleiche“ in der AWS-Dokumentation .)
ALB war ein wichtiges Update für AWS-Benutzer, die mit dem eingeschränkten Funktionsumfang von Classic Load Balancer zu kämpfen hatten, und es ging in gewisser Weise auf die Anforderungen anspruchsvoller Benutzer ein, die den Datenverkehr zu ihren Webanwendungen sichern, optimieren und kontrollieren müssen. Es bietet jedoch immer noch nicht alle Funktionen dedizierter Reverse-Proxys (wie NGINX) und Load Balancer (wie NGINX Plus).
Anstatt Amazon ALB zu verwenden, können Benutzer NGINX Open Source oder NGINX Plus auf AWS bereitstellen, um den Datenverkehr zu steuern und die Last auszugleichen. Sie können auch Classic Load Balancer oder Network Load Balancer als Frontend einsetzen, um eine hohe Verfügbarkeit über mehrere Verfügbarkeitszonen hinweg zu erreichen. Die Tabelle vergleicht die von ALB, NGINX und NGINX Plus unterstützten Funktionen.
Notiz: Die Informationen in der folgenden Tabelle sind Stand Juli 2020, können sich jedoch ändern.
Amazon ALB | NGINX Open Source | NGINX Plus | |
---|---|---|---|
Lastenausgleich Methoden und Funktionen |
Round_Robin- und Least_Outstanding_Requests -Methoden mit Cookie-basierter Sitzungspersistenz, gewichteten Zielgruppen und langsamem Start |
Mehrere Lastausgleichsmethoden (einschließlich Round Robin, Least Connections, Hash, IP Hash und Random) mit gewichteten Upstream-Servern | Wie NGINX Open Source, plus Least-Time-Methode, mehr Methoden zur Sitzungspersistenz und langsamer Start |
Zwischenspeicherung | ❌ Caching im Load Balancer wird nicht unterstützt | ✅ Statisches Datei-Caching und dynamisches (Anwendungs-)Caching | ✅ Statisches und dynamisches Caching sowie erweiterte Funktionen |
Gesundheitschecks | Aktiv (identifiziert ausgefallene Server durch Prüfung des für asynchrone Prüfungen zurückgegebenen Statuscodes) | Passiv (identifiziert ausgefallene Server durch Überprüfung der Antworten auf Client-Anfragen) | Sowohl aktiv als auch passiv – aktive Prüfungen sind umfangreicher und konfigurierbarer als ALBs |
Hohe Verfügbarkeit | Sie können ALB-Instanzen in mehreren Availability Zones für HA bereitstellen, jedoch nicht regionsübergreifend. | Aktiv-Aktiv-HA mit NLB und Aktiv-Passiv-HA mit Elastic IP-Adressen | Dasselbe wie NGINX Open Source, plus integrierte Cluster-Statusfreigabe für nahtlose Hochverfügbarkeit über alle NGINX Plus-Instanzen hinweg |
Unterstützung für alle Protokolle in der IP-Suite | ❌ Nur HTTP und HTTPS | ✅ Auch TCP und UDP, mit passiven Integritätsprüfungen | ✅ Auch TCP und UDP, mit aktiven und passiven Integritätsprüfungen |
Mehrere Anwendungen pro Load Balancer-Instanz | ✅ | ✅ | |
Inhaltsbasiertes Routing | ✅ Basierend auf Anforderungs-URL, Host -Header und Anforderungsfeldern, einschließlich standardmäßiger und benutzerdefinierter HTTP-Header, Methoden, Abfrageparameter und Quell-IP-Adresse |
✅ Basiert auf denselben Faktoren wie ALB, plus Cookies und dynamische Berechnungen unter Verwendung des NGINX JavaScript-Moduls als Inline-JavaScript-Engine | ✅ Basiert auf denselben Faktoren wie NGINX Open Source, plus JWT-Ansprüche und Werte im Schlüssel-Wert-Speicher |
Containerisierte Anwendungen | Kann Lastenausgleich zu Amazon-IDs, ECS-Containerinstanzen, Auto-Scaling-Gruppen und AWS-Lambda-Funktionen durchführen | Erfordert manuelle Konfiguration oder Konfigurationsvorlagen | Automatisierte Konfiguration mittels DNS, inklusive SRV- Records; funktioniert mit führenden Registry-Diensten |
Portabilität | ❌ Alle Umgebungen (Entwicklung, Test und Produktion) müssen auf AWS sein | ✅ Jede Umgebung kann auf jeder Bereitstellungsplattform sein | |
SSL/TLS | ✅ Mehrere SSL/TLS-Zertifikate mit SNI-Unterstützung ❌ Validierung von SSL/TLS-Upstreams wird nicht unterstützt |
✅ Mehrere SSL/TLS-Zertifikate mit SNI-Unterstützung ✅ Vollständige Auswahl an SSL/TLS-Chiffren ✅ Vollständige Validierung von SSL/TLS-Upstreams |
|
HTTP/2 und WebSocket | ✅ | ✅ | |
Authentifizierungsfunktionen | – OIDC-, SAML-, LDAP- und AD IdP-Authentifizierungsoptionen – Integriert mit AWS Cognito und CloudFront |
Mehrere Authentifizierungsoptionen | |
Erweiterte Funktionen | ❌ Barebones-API | ✅ Origin-Serving, Priorisierung, Ratenbegrenzung und mehr | ✅ Gleich wie NGINX Open Source, plus RESTful API, Schlüssel-Wert-Speicher |
Protokollierung und Debuggen | ✅ Binäres Amazon-Protokollformat | ✅ Anpassbare Protokolldateien und mehrere Debug-Schnittstellen | ✅ Vollständig anpassbare Protokolldateien und mehrere Debug-Schnittstellen, vollständig unterstützt von NGINX |
Überwachungstools | ✅ Integriert mit Amazon CloudWatch | ✅ NGINX Controller* und andere Tools von Drittanbietern | ✅ NGINX Controller und andere Tools von Drittanbietern; erweiterter Satz gemeldeter Statistiken |
Offizieller technischer Support | ✅ Gegen Aufpreis | ❌ Nur Community-Support | ✅ Im Preis inbegriffen und direkt von NGINX |
Kostenloses Kontingent | ✅ Erste 750 Stunden | ✅ Immer kostenlos | ✅ 30‑tägiges Probeabonnement |
* NGINX Controller ist jetzt F5 NGINX Management Suite .
Natürlich sollten Sie Ihre Wahl des Lastausgleichs nicht anhand einer Funktionscheckliste bewerten, sondern indem Sie die Fähigkeiten beurteilen, die Sie benötigen, um Ihre Anwendungen fehlerfrei, mit hoher Sicherheit, maximaler Verfügbarkeit und vollständiger Kontrolle bereitzustellen.
Der Classic Load Balancer (ehemals ELB) von Amazon reagierte schlecht auf Verkehrsspitzen. Die Größe der Load Balancer-Instanzen wurde automatisch an das aktuelle Verkehrsaufkommen angepasst. Bei auftretenden Verkehrsspitzen konnte es mehrere Minuten dauern, bis ELB reagierte und zusätzliche Kapazitäten bereitstellte. Benutzer mussten auf einen manuellen, formularbasierten Prozess zurückgreifen, um vor Verkehrsspitzen zusätzliche Ressourcen anzufordern (als „Pre-Warming“ bezeichnet). Da ALB auf NGINX basiert, können ALB-Instanzen wesentlich mehr Datenverkehr verarbeiten, es kann jedoch dennoch zu Skalierungsereignissen als Reaktion auf Datenverkehrsspitzen kommen. Darüber hinaus führt eine Verkehrsspitze automatisch zu einem höheren Verbrauch von Load Balancer Capacity Units (LCUs) und damit zu höheren Kosten.
Sie erhalten die vollständige Kontrolle über Kapazität und Kosten, wenn Sie Ihre Lastausgleichs-Proxys selbst bereitstellen und skalieren. NGINX und NGINX Plus werden in Standardinstanzen von Amazon eingesetzt und unser Größenleitfaden gibt einen Hinweis auf die potenzielle Spitzenleistung von Instanztypen mit unterschiedlichen Kapazitäten. Die Preise für NGINX Plus sind für alle Instanzgrößen gleich. Daher ist es kosteneffizient, überschüssige Kapazitäten einzusetzen, um Spitzen abzufedern. Und wenn mehr Kapazität benötigt wird, können schnell weitere Instanzen eingesetzt werden – ohne dass Formulare ausgefüllt werden müssen.
Unsere Tests von Amazon ALB zeigen, dass keine „passiven“ Integritätsprüfungen durchgeführt werden. Ein Serverfehler wird erst dann erkannt, wenn ein asynchroner Test bestätigt, dass er nicht den erwarteten Statuscode zurückgibt.
Wir haben dies herausgefunden, indem wir eine ALB-Instanz erstellt haben, um den Lastenausgleich eines Clusters von Instanzen durchzuführen. Wir haben eine Integritätsprüfung mit einer Mindestfrequenz von 5 Sekunden und einem Mindestschwellenwert von 2 fehlgeschlagenen Prüfungen konfiguriert und einen stetigen Strom von Anfragen an den ALB gesendet. Als wir eine der Instanzen stoppten, gab ALB für einige Anfragen eine 502
Schlecht
Tor
Fehler für mehrere Sekunden, bis die Integritätsprüfung erkannte, dass die Instanz ausgefallen war. Passive Integritätsprüfungen (unterstützt von NGINX und NGINX Plus) verhindern, dass diese Art von Fehlern von Endbenutzern gesehen wird.
Die Integritätsprüfungen von ALB können die Integrität einer Instanz nur durch Überprüfung des HTTP-Statuscodes ermitteln (z. B. 200
OK
oder 404
Nicht
gefunden
). Solche Integritätsprüfungen sind unzuverlässig. Manche Webanwendungen ersetzen beispielsweise vom Server generierte Fehler durch benutzerfreundliche Seiten, und manche Fehler werden nur im Hauptteil einer Webseite gemeldet.
NGINX Plus unterstützt sowohl passive als auch aktive Integritätsprüfungen . Letztere sind leistungsfähiger als ALBs, da sie sowohl mit dem Hauptteil einer Antwort als auch mit dem Statuscode abgleichen können.
Die größte Frage, die Sie sich bei der Bereitstellung von ALB stellen müssen, sind schließlich die Kosten. Der Lastausgleich kann einen erheblichen Teil Ihrer Amazon-Rechnung ausmachen .
AWS verwendet zur Preisbestimmung einen komplizierten Algorithmus . Sofern Sie nicht genau wissen, wie viele neue Verbindungen, wie viele gleichzeitige Verbindungen und wie viele Daten Sie jeden Monat verwalten werden – was sich nur schwer vorhersagen lässt – und Sie die LCU-Berechnung nicht auf die gleiche Weise wie Amazon durchführen können, werden Sie Ihre Amazon-Rechnung jeden Monat mit Grauen betrachten.
NGINX Plus auf AWS bietet Ihnen vollständige Vorhersehbarkeit. Für einen festen Stundenpreis zuzüglich AWS-Hosting-Gebühren erhalten Sie eine deutlich leistungsfähigere Lastausgleichslösung mit vollem Support.
NGINX Plus ist eine bewährte Lösung für Layer-7-Lastausgleich und verfügt auch über Layer-4-Lastausgleichsfunktionen. Es funktioniert gut im Verbund mit Amazons eigenem Classic Load Balancer oder NLB.
Wir fördern die fortgesetzte und zunehmende Nutzung von NGINX und NGINX Plus in der AWS-Umgebung, da es sich bereits um eine sehr beliebte Lösung handelt. Wenn Sie noch kein NGINX Plus-Benutzer sind, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."