Lastenausgleich für AWS Auto Scaling-Gruppen mit NGINX Plus

Eine der vorteilhaftesten Funktionen der Cloud ist die Möglichkeit, die Anzahl der Computerinstanzen automatisch zu skalieren. Mit AWS Automatische Skalierungkönnen Sie die Anzahl der EC2-Instanzen in einem Auto Scaling-Gruppe, entweder manuell oder automatisch, je nach Zeitplan oder Bedarf. Durch die automatische Skalierung können Sie die Kosten senken, indem Sie die Anzahl der Instanzen entsprechend der aktuellen Arbeitslast anpassen. Darüber hinaus startet Auto Scaling ausgefallene Instanzen neu, was die Ausfallsicherheit Ihrer Anwendungen erhöht.

Bei der Verwendung von Auto Scaling ist der Lastenausgleich von entscheidender Bedeutung. AWS ermöglicht die Lastverteilung von Instanzen von Auto Scaling-Gruppen durch die Integration seiner integrierten Load Balancer – Elastic Load Balancer (ELB), jetzt offiziell Classic Load Balancer genannt, und Application Load Balancer (ALB) – mit Auto Scaling. NGINX Plus bietet erweitertes Cloud-Load-Balancing für jede Cloud-Umgebung, einschließlich AWS, und unterstützt AWS Auto Scaling-Gruppen.

Es gibt drei Hauptgründe, sich für NGINX Plus als Ersatz oder Ergänzung zu den integrierten AWS-Cloud-Load-Balancern zu entscheiden:

1. NGINX Plus bietet mehrere erweiterte Funktionen, die ELB und ALB fehlen.
2. Das Preismodell für die AWS-Load Balancer (insbesondere ALB) ist komplex, was die Kostenvorhersage erschwert. Die Preisgestaltung für NGINX Plus ist unkompliziert, unabhängig davon, ob Sie das NGINX Plus-Abonnement direkt bei uns erwerben oder vorgefertigte NGINX Plus-Instanzen vom AWS Marketplace ausführen, die zu einem festen Stundensatz abgerechnet werden.
3. NGINX Plus bindet Sie nicht an plattformspezifische APIs, sodass Sie die Lastausgleichskonfiguration auf mehreren Cloud-Plattformen wiederverwenden können.

Um zu sehen, wie NGINX Plus im Vergleich zu den integrierten AWS-Lösungen abschneidet (und mit diesen zusammenarbeitet), lesen Sie unsere Blogbeiträge zu ELB und ALB .

In diesem Blogbeitrag zeigen wir zwei Methoden zum Konfigurieren von NGINX Plus zum Lastenausgleich von Auto-Scaling-Gruppen und erklären, wann der Einsatz welcher Methode sinnvoll ist:

1. Verwenden von NGINX Plus vor ELB
2. Verwenden von NGINX Plus mit Integrationssoftware von NGINX, Inc.

Nach dem Lesen dieses Blogbeitrags sind Sie bereit, NGINX Plus auf AWS bereitzustellen, um erweitertes Lastenausgleich für Auto-Scaling-Gruppen zu ermöglichen.

Die Beispielumgebung für AWS Auto Scaling

Wir verwenden eine Beispielanwendungsumgebung, um die beiden Methoden zur Verwendung von NGINX Plus zum Lastenausgleich von Auto-Scaling-Gruppen zu veranschaulichen. Unsere Backend-Webanwendung besteht aus zwei Diensten – Backend One und Backend Two – die jeweils auf Port 80 verfügbar sind. Für jeden Dienst gibt es eine Auto-Scaling-Gruppe mit mehreren Anwendungsinstanzen. Der Load Balancer leitet Clientanforderungen basierend auf der Anforderungs-URI an das entsprechende Backend weiter:

• Anfragen für /backend‑one gehen an Backend One.
• Anfragen für /backend‑two gehen an Backend Two.

Wenn wir die Auto Scaling-Gruppen der Anwendung skalieren (entweder automatisch oder manuell), muss die Load Balancer-Konfiguration aktualisiert werden, um die neue Anzahl der Anwendungsinstanzen widerzuspiegeln. Die integrierten AWS-Load Balancer erledigen dies automatisch. Für NGINX Plus müssen wir Skalierungsereignisse mit einer der oben genannten Methoden (NGINX Plus vor ELB oder NGINX Plus mit der Integrationssoftware) an die Konfiguration weitergeben.

Eine andere Möglichkeit, die NGINX Plus-Konfiguration als Reaktion auf Skalierungsereignisse zu aktualisieren, ist ein externes Dienstregister. NGINX Plus unterstützt die Integration mit Service-Discovery-Systemen, die eine DNS-Schnittstelle bereitstellen, wie beispielsweise Consul . In diesem Blogbeitrag konzentrieren wir uns auf Lösungen, die nicht auf die Verwendung externer Systeme angewiesen sind und einfach einzurichten und zu verwenden sind.

Verwenden von NGINX Plus vor ELB

Wenn Sie bereits Auto-Scaling-Gruppen und ELB verwenden, können Sie einige der erweiterten Funktionen von NGINX Plus am einfachsten in Ihre Anwendung integrieren, indem Sie NGINX Plus vor die ELB-Cloud-Load Balancer platzieren, wie in der Abbildung gezeigt:

In diesem Fall fungiert NGINX Plus als Proxy/Load Balancer für einen oder mehrere ELBs. Mithilfe seiner erweiterten Routing-Funktionen leitet NGINX Plus Anfragen basierend auf der Anfrage-URI an den entsprechenden ELB weiter. Der ELB übergibt die Anfrage dann an eine der Instanzen in der Auto-Scaling-Gruppe. In dieser Konfiguration bietet ELB die Unterstützung für die Skalierung.

Hier ist die NGINX Plus-Konfiguration.

Resolver 169.254.169.253 gültig=10 s; Upstream Backend-Eins { Zone Backend-Eins 64k; Server DNS-Name des ELB für Backend-Eins auflösen; } Upstream Backend-Zwei { Zone Backend-Zwei 64k; Server DNS-Name des ELB für Backend-Zwei auflösen; } Server { abhören 80; Standort /Backend-Eins { Proxy_Set_Header Host $host; Proxy_Passwort http://Backend-Eins; } Standort /Backend-Zwei { Proxy_Set_Header Host $host; Proxy_Passwort http://Backend-Zwei; } }

• Die Resolver- Direktive definiert den DNS-Server, den NGINX Plus zum Auflösen der DNS-Namen der internen ELB-Instanzen verwendet. Hier ist die IP-Adresse des AWS DNS-Servers.

• Wir erstellen zwei Upstream- Blöcke, einen für jede Auto-Scaling-Gruppe, die unseren Diensten entspricht, Backend One und Backend Two. Wir identifizieren die Auto Scaling-Gruppe anhand des DNS-Namens des ELB, der den Datenverkehr dorthin ausgleicht.

  Mit dem Resolve- Parameter weisen wir NGINX Plus an, den Namen regelmäßig neu aufzulösen. Die Häufigkeit wird durch den gültigen Parameter der im vorherigen Punkt beschriebenen Resolver -Direktive festgelegt. Hier haben wir es auf 10 Sekunden eingestellt, da die IP-Adressen von ELB häufigen Änderungen unterliegen.

  Die Zonendirektive reserviert Speicher (hier bis zu 64 KB) für die Speicherung der aufgelösten IP-Adressen.

• Wir definieren einen virtuellen Server , der auf Port 80 lauscht. Die Standortblöcke weisen NGINX Plus an, Anfragen für /backend‑one an den ELB für die Backend One Auto Scaling-Gruppe und Anfragen für /backend‑two an den ELB für die Backend Two Auto Scaling-Gruppe weiterzuleiten.

Wie Sie sehen, ist diese Methode einfach einzurichten und zu verwenden, insbesondere wenn Sie bereits ELB verwenden. Es gibt jedoch mehrere Nachteile:

• Begrenzte Optionen zum Lastenausgleich. Da NGINX Plus Anfragen nicht direkt an die Back-End-Instanzen, sondern an ELB weiterleitet, übernimmt der ELB den Lastenausgleich. Aus diesem Grund können Sie die ausgefeilteren Lastausgleichsalgorithmen und Sitzungspersistenzoptionen von NGINX Plus nicht nutzen.
• Redundanz. NGINX Plus kann Lastenausgleich durchführen, daher ist ELB redundant – wir verwenden es nur, weil es nativ in Auto Scaling integriert ist.
• Eingeschränkte Protokollunterstützung. Im Gegensatz zu NGINX Plus unterstützt ELB kein WebSocket und UDP.

Die nächste Methode basiert nicht auf ELB und hat daher diese Nachteile nicht.

Verwenden von NGINX Plus mit der Integrationssoftware

Bei dieser Methode installieren Sie zusammen mit NGINX Plus zusätzliche Integrationssoftware . Die Software ( nginx-asg-sync ) überwacht ständig Auto-Scaling-Gruppen. Wenn es erkennt, dass ein Skalierungsereignis stattgefunden hat, fügt es der NGINX Plus-Konfiguration Backend-Instanzen hinzu oder entfernt sie. Wie gezeigt, erfährt nginx-asg-sync über Änderungen an Auto Scaling-Gruppen über die AWS Auto Scaling API.

Um die Integrationssoftware zu verwenden, führen Sie die folgenden Schritte aus:

1. Einrichten des Zugriffs auf die AWS-API
2. Installieren der Integrationssoftware
3. NGINX Plus konfigurieren
4. Konfigurieren Sie die Integrationssoftware

Die Anweisungen setzen voraus, dass die Auto Scaling-Gruppen für die Backends bereits vorhanden sind. Sie gehen außerdem davon aus, dass NGINX Plus auf einem Amazon Linux AMI ausgeführt wird.

Schritt 1 – Zugriff auf die AWS-API einrichten

Die Kommunikation mit der Auto Scaling API wird authentifiziert, daher müssen Sie Anmeldeinformationen für nginx-asg-sync angeben. AWS verwendet IAM-Rollen zur Handhabung von Anmeldeinformationen. Daher müssen Sie vor dem Starten der NGINX Plus-Instanz eine Rolle für diese erstellen. Schritt-für-Schritt-Anleitungen finden Sie unter IAM-Rollen für Amazon EC2 in der AWS-Dokumentation.

1. Erstellen Sie eine IAM-Rolle und fügen Sie ihr die vordefinierte AmazonEC2ReadOnlyAccess -Richtlinie hinzu. Diese Richtlinie erlaubt schreibgeschützten Zugriff auf EC2-APIs.
2. Wenn Sie die NGINX Plus-Instanz starten, fügen Sie der Instanz diese IAM-Rolle hinzu.

Schritt 2 – Installieren der Integrationssoftware

Um die Integrationssoftware zu installieren, laden Sie das Paket für Ihr Betriebssystem aus dem GitHub-Repository nginx-asg-sync herunter und installieren Sie es auf der Instanz, auf der NGINX Plus ausgeführt wird.

• Für Amazon Linux, CentOS und RHEL:

  $ sudo rpm -i Paketname .rpm
  

• Für Ubuntu:

  $ sudo dpkg -i Paketname .deb
  

Vollständige Installationsanweisungen finden Sie in der Dokumentation auf GitHub.

Schritt 3: NGINX Plus konfigurieren

Die Integrationssoftware aktualisiert die NGINX Plus-Konfiguration mithilfe der APIs zur dynamischen Neukonfiguration und Live-Aktivitätsüberwachung . Damit die Software ordnungsgemäß funktioniert, müssen Sie diese APIs konfigurieren und die erforderlichen Upstream-Gruppen deklarieren:

• Konfigurieren Sie die API-Endpunkte für eine sofortige Neukonfiguration und Live-Aktivitätsüberwachung. Die Integrationssoftware verwendet diese Endpunkte, um Backend-Instanzen zu Upstream-Gruppen hinzuzufügen und daraus zu entfernen.
• Erstellen Sie für jede Auto Scaling-Gruppe einen Upstream- Block. Definieren Sie keine Server im Block, da nginx-asg-sync diese als Reaktion auf Skalierungsereignisse automatisch hinzufügt und entfernt.

Das folgende Beispiel stellt die Konfiguration für unsere einfache Webanwendung dar:

Upstream Backend-One { Zone Backend-One 64k;
Status /var/lib/nginx/state/backend-One.conf;
}

Upstream Backend-Two {
Zone Backend-Two 64k;
Status /var/lib/nginx/state/backend-Two.conf;
}

Server {
Listen 80;

Statuszone Backend;

Standort /Backend-One {
Proxy_Set_Header Host $host;
Proxy_Pass http://Backend-One;
}

Standort /Backend-Two {
Proxy_Set_Header Host $host;
Proxy_Pass http://Backend-Two;
}
}

Server {
Listen 8080;

Root /usr/share/nginx/html;

Standort = / {
Return 302 /status.html;
}

Standort = /status.html {}

Standort /Status {
Access_Log Off;
Status;
}

Standort /upstream_conf {
upstream_conf;
}
}

• Wie im ELB-Beispiel deklarieren wir zwei Upstream-Gruppen – backend‑one und backend‑two , die unseren Auto Scaling-Gruppen entsprechen. Hier fügen wir jedoch keine Server zu den Upstream-Gruppen hinzu, da die Server von nginx‑aws‑sync hinzugefügt werden. Die State -Direktive benennt die Datei, in der die dynamisch konfigurierbare Serverliste gespeichert wird, sodass sie auch nach Neustarts von NGINX Plus erhalten bleibt.
• Wir definieren einen virtuellen Server , der auf Port 80 lauscht. Im Gegensatz zum ELB-Beispiel leitet NGINX Plus Anfragen für /backend‑one direkt an die Instanzen der Backend One-Gruppe und Anfragen für /backend‑two direkt an die Instanzen der Backend Two-Gruppe weiter.

• Wir definieren einen zweiten virtuellen Server, der auf Port 8080 lauscht, und konfigurieren darauf die NGINX Plus-APIs:

  • Die On‑the‑Fly‑API ist verfügbar unter 127.0.0.1:8080/upstream_conf
  • Die Status-API ist verfügbar unter 127.0.0.1:8080/status

Schritt 4 – Konfigurieren Sie die Integrationssoftware

Die Integrationssoftware wird in der Datei aws.yaml im Ordner /etc/nginx konfiguriert. Für unsere Anwendung definieren wir folgende Konfiguration:

Region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
Upstreams:
- Name: Backend-One
Autoscaling-Gruppe: Backend-One-Gruppe
Port: 80
Art: http
- Name: Backend-Two
Autoscaling_Group: Backend-Two-Group
Port: 80
Art: http

• Der Regionsschlüssel definiert die AWS-Region, in der wir unsere Anwendung bereitstellen.
• Die Schlüssel upstream_conf_endpoint und status_endpoint definieren die NGINX Plus API-Endpunkte, die wir in Schritt 3 konfiguriert haben.
• Der Schlüssel sync_interval_in_seconds definiert das Synchronisierungsintervall: nginx-asg-sync sucht alle 5 Sekunden nach Skalierungsaktualisierungen.

• Der Upstreams -Schlüssel definiert die Liste der Upstream-Gruppen. Für jede Upstream-Gruppe geben wir an:

  • Name – Der Name, den wir in Schritt 3 für den Upstream -Block angegeben haben.
  • autoscaling_group – Der Name der entsprechenden Auto Scaling-Gruppe.
  • Port – Der Port, auf dem unsere Backend-Dienste verfügbar sind.
  • Art – Das Protokoll des Datenverkehrs, mit dem NGINX Plus die Last zur Backend-Anwendung ausgleicht, hier http . Wenn die Anwendung TCP/UDP verwendet, geben Sie stattdessen Stream an.

Nachdem Sie die Datei aws.yaml bearbeitet haben, starten Sie die Software neu:

$ sudo Neustart nginx-asg-sync

Testen des Lastenausgleichs und der Skalierung

In den obigen Schritten haben wir NGINX Plus so konfiguriert, dass die Last der Auto Scaling-Gruppen für unsere Anwendung ausgeglichen wird. Jetzt können wir es testen. NGINX Plus verteilt Anfragen mit der URI /backend‑one an die Instanzen der Gruppe „Backend One“ und Anfragen mit der URI /backend‑two an die Instanzen der Gruppe „Backend Two“.

Wir können sehen, wie NGINX Plus neue Instanzen aufnimmt, wenn wir unsere Auto Scaling-Gruppen skalieren. Zuerst greifen wir auf das Dashboard zur Live-Aktivitätsüberwachung zu, das unter /status.html auf Port 8080 der NGINX Plus-Instanz zugänglich ist. Auf der Registerkarte „Upstream“ sehen wir die Instanzen in unseren Auto Scaling-Gruppen:

Jetzt skalieren wir die Backend One-Gruppe von drei auf fünf Instanzen, indem wir die Kapazität der Auto Scaling-Gruppe ändern. Nachdem die neuen Instanzen gestartet wurden, fügt nginx-asg-sync sie der NGINX Plus-Konfiguration hinzu. Schon bald werden die neuen Instanzen auf dem Dashboard angezeigt:

NGINX Plus hochverfügbar machen

Bisher haben wir nur eine Instanz von NGINX Plus gestartet. Für eine hohe Verfügbarkeit empfehlen wir jedoch, eine Auto-Scaling-Gruppe für NGINX Plus selbst zu erstellen und ELB vor den NGINX Plus-Instanzen zu verwenden. Alternativ zu ELB können Sie Route 53 verwenden, um den Datenverkehr an NGINX Plus-Instanzen weiterzuleiten. Das Diagramm unserer Bereitstellung mit ELB sieht folgendermaßen aus:

Die richtige Methode wählen

Welche Methode zum Konfigurieren von NGINX Plus zum Lastenausgleich von Auto-Scaling-Gruppen ist für Sie also besser? Die Tabelle vergleicht die beiden kurz:

Zusammenfassung

AWS Auto Scaling bietet den Vorteil, dass die Anzahl der Anwendungsinstanzen an die Nachfrage angepasst werden kann. NGINX Plus bietet erweiterte Lastausgleichsfunktionen, die in Verbindung mit AWS Auto Scaling-Gruppen verwendet werden können.

Testen Sie NGINX Plus mit Ihren AWS Auto Scaling-Gruppen – starten Sie Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .