Lastverteilung für AWS Auto Scaling Groups mit NGINX Plus

Michael Pleshakov

Eine der nützlichsten Funktionen der Cloud ist die Möglichkeit, die Anzahl der Computing-Instanzen automatisch zu skalieren. Mit AWS Auto Scaling können Sie die Anzahl der EC2-Instanzen in einer Auto-Scaling-Gruppe entweder manuell oder automatisch nach Zeitplan oder Bedarf ändern. Auto Scaling trägt zur Kostensenkung bei, indem die Anzahl der Instanzen an die aktuelle Arbeitslast angepasst wird. Darüber hinaus startet Auto Scaling ausgefallene Instanzen neu und erhöht so die Ausfallsicherheit Ihrer Anwendungen.

Beim Einsatz von Auto Scaling ist der Lastenausgleich von entscheidender Bedeutung. AWS ermöglicht den Lastenausgleich für Instanzen in Auto-Scaling-Gruppen durch die Integration seiner integrierten Load Balancer – Elastic Load Balancer (ELB), inzwischen offiziell als Classic Load Balancer bezeichnet, und Application Load Balancer (ALB) – in Auto Scaling. NGINX Plus bietet erweiterten Cloud-Lastenausgleich für jede Cloud-Umgebung, einschließlich AWS, und unterstützt AWS-Auto-Scaling-Gruppen.

Es gibt drei Hauptgründe, NGINX Plus als Ersatz oder Ergänzung für die integrierten AWS-Cloud-Load-Balancer zu wählen:

1. NGINX Plus bietet zahlreiche erweiterte Funktionen, die ELB und ALB nicht bieten.
2. Das Preismodell für die AWS-Load-Balancer (insbesondere ALB) ist komplex, sodass sich die Kosten nur schwer vorhersagen lassen. Die Preisgestaltung von NGINX Plus ist transparent – unabhängig davon, ob Sie das NGINX Plus-Abonnement direkt bei uns erwerben oder vorkonfigurierte NGINX Plus-Instanzen über den AWS Marketplace ausführen, die zu einem festen Stundensatz abgerechnet werden.
3. NGINX Plus bindet Sie nicht an plattformspezifische APIs, sodass Sie die Load-Balancing-Konfiguration auf mehreren Cloud-Plattformen wiederverwenden können.

Wenn Sie erfahren möchten, wie NGINX Plus im Vergleich zu den integrierten AWS-Lösungen abschneidet (und mit ihnen zusammenarbeitet), lesen Sie unsere Blogbeiträge zu ELB und ALB.

In diesem Blogbeitrag stellen wir zwei Methoden zur Konfiguration von NGINX Plus für den Lastenausgleich von Auto-Scaling-Gruppen vor und erläutern, wann welche Methode sinnvoll ist:

1. NGINX Plus vor ELB verwenden
2. NGINX Plus mit der von NGINX, Inc. bereitgestellten Integrationssoftware verwenden

Nach der Lektüre dieses Blogbeitrags sind Sie bereit, NGINX Plus auf AWS bereitzustellen, um erweiterten Lastenausgleich für Auto-Scaling-Gruppen zu ermöglichen.

Die AWS-Auto-Scaling-Beispielumgebung

Wir verwenden eine Beispielanwendungsumgebung, um die beiden Methoden zu veranschaulichen, mit denen NGINX Plus die Lastverteilung für Auto-Scaling-Gruppen übernimmt. Unsere Backend-Webanwendung besteht aus zwei Diensten – Backend One und Backend Two –, die jeweils über Port 80 erreichbar sind. Für jeden Dienst gibt es eine Auto-Scaling-Gruppe mit mehreren Anwendungsinstanzen. Der Load Balancer leitet Clientanfragen anhand des Anfrage-URI an das entsprechende Backend weiter:

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

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

Eine weitere Möglichkeit, die NGINX Plus-Konfiguration als Reaktion auf Skalierungsereignisse zu aktualisieren, ist die Verwendung einer externen Service-Registry. NGINX Plus unterstützt die Integration mit Service-Discovery-Systemen, die eine DNS-Schnittstelle bereitstellen, wie etwa Consul. In diesem Blogbeitrag konzentrieren wir uns auf Lösungen, die ohne externe Systeme auskommen und einfach einzurichten und zu verwenden sind.

NGINX Plus vor ELB verwenden

Wenn Sie bereits Auto-Scaling-Gruppen und ELB verwenden, können Sie einige der erweiterten Funktionen von NGINX Plus am einfachsten für Ihre Anwendung nutzen, indem Sie NGINX Plus vor den ELB-Cloud-Load-Balancern platzieren, wie in der Abbildung dargestellt:

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 dem Anfrage-URI an den entsprechenden ELB weiter. Der ELB übergibt die Anfrage anschließend an eine der Instanzen in der Auto-Scaling-Gruppe. In dieser Konfiguration übernimmt ELB die Unterstützung der Skalierung.

Hier ist die NGINX Plus-Konfiguration.

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

• Die resolver-Direktive definiert den DNS-Server, den NGINX Plus zur Auflösung der DNS-Namen der internen ELB-Instanzen verwendet. Hierbei handelt es sich um die IP-Adresse des AWS-DNS-Servers.
• Wir erstellen zwei upstream-Blöcke, jeweils einen für jede Auto-Scaling-Gruppe, die unseren Diensten Backend One und Backend Two entspricht. Wir identifizieren die Auto-Scaling-Gruppe anhand des DNS-Namens des ELB, der den Datenverkehr auf sie verteilt. Mit dem Parameter resolve weisen wir NGINX Plus an, den Namen regelmäßig erneut aufzulösen. Die Häufigkeit wird durch den Parameter valid der im vorherigen Aufzählungspunkt erläuterten Direktive resolver festgelegt. Hier legen wir sie auf 10 Sekunden fest, da sich die IP-Adressen des ELB häufig ändern können. Die Direktive zone weist Speicher (hier bis zu 64 KB) zum Speichern der aufgelösten IP-Adressen zu.
• Wir definieren einen virtuellen server, der Port 80 überwacht. Die location-Blöcke weisen NGINX Plus an, Anfragen für /backend‑one an den ELB der Auto-Scaling-Gruppe „Backend One“ und Anfragen für /backend‑two an den ELB der Auto-Scaling-Gruppe „Backend Two“ weiterzuleiten.

Wie Sie sehen, lässt sich diese Methode einfach einrichten und verwenden, insbesondere wenn Sie ELB bereits nutzen. Allerdings gibt es einige Nachteile:

• Eingeschränkte Optionen für den Lastenausgleich. Da NGINX Plus Anfragen an ELB und nicht direkt an die Backend-Instanzen weiterleitet, übernimmt ELB den Lastenausgleich. Daher können Sie die ausgefeilteren Lastenausgleichsalgorithmen und Optionen für Sitzungspersistenz von NGINX Plus nicht nutzen.
• Redundanz. NGINX Plus kann den Lastenausgleich übernehmen, sodass ELB überflüssig ist – wir verwenden es nur, weil es nativ in Auto Scaling integriert ist.
• Eingeschränkte Protokollunterstützung. Im Gegensatz zu NGINX Plus unterstützt ELB weder WebSocket noch UDP.

Die nächste Methode ist nicht von ELB abhängig und weist daher diese Nachteile nicht auf.

NGINX Plus mit der Integrationssoftware verwenden

Bei dieser Methode installieren Sie zusätzlich zu NGINX Plus eine weitere Integrationssoftware. Die Software (nginx-asg-sync) überwacht kontinuierlich Auto-Scaling-Gruppen. Sobald sie ein Skalierungsereignis erkennt, fügt sie der NGINX Plus-Konfiguration Backend-Instanzen hinzu oder entfernt sie daraus. Wie dargestellt, erfährt nginx-asg-sync über die AWS Auto Scaling API von Änderungen an Auto-Scaling-Gruppen.

Führen Sie die folgenden Schritte aus, um die Integrationssoftware zu verwenden:

1. Zugriff auf die AWS-API einrichten
2. Installieren Sie die Integrationssoftware
3. NGINX Plus konfigurieren
4. Konfigurieren Sie die Integrationssoftware

Die Anleitung setzt voraus, dass die Auto-Scaling-Gruppen für die Backends bereits vorhanden sind. Außerdem wird davon ausgegangen, 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 Anmeldedaten für nginx-asg-sync bereitstellen. AWS verwendet IAM-Rollen zur Verwaltung von Anmeldedaten. Daher müssen Sie vor dem Start der NGINX-Plus-Instanz eine Rolle für diese erstellen. Eine schrittweise Anleitung finden Sie unter „IAM-Rollen für Amazon EC2“ in der AWS-Dokumentation.

1. Erstellen Sie eine IAM-Rolle und weisen Sie ihr die vordefinierte Richtlinie AmazonEC2ReadOnlyAccess zu. Diese Richtlinie gewährt schreibgeschützten Zugriff auf EC2-APIs.
2. Fügen Sie beim Starten der NGINX Plus-Instanz diese IAM-Rolle zur Instanz hinzu.

Schritt 2 – Installieren der Integrationssoftware

Um die Integrationssoftware zu installieren, laden Sie das Paket für Ihr Betriebssystem aus dem nginx-asg-sync-Repository auf GitHub 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 package-name.rpm

• Für Ubuntu:

$ sudo dpkg -i package-name.deb

Eine vollständige Installationsanleitung finden Sie in der Dokumentation auf GitHub.

Schritt 3 – NGINX Plus konfigurieren

Die Integrationssoftware aktualisiert die NGINX Plus-Konfiguration mithilfe der APIs für die dynamische Neukonfiguration und die 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 die dynamische Neukonfiguration und die Live-Aktivitätsüberwachung. Die Integrationssoftware verwendet diese Endpunkte, um Backend-Instanzen zu Upstream-Gruppen hinzuzufügen oder daraus zu entfernen.
• Erstellen Sie für jede Auto-Scaling-Gruppe einen upstream-Block. Definieren Sie in diesem Block keine Server, da nginx-asg-sync diese bei Skalierungsereignissen automatisch hinzufügt und entfernt.

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

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /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 den Upstream-Gruppen jedoch keine Server hinzu, da die Server von nginx‑aws‑sync hinzugefügt werden. Die Direktive state gibt die Datei an, in der die dynamisch konfigurierbare Serverliste gespeichert wird, sodass sie auch nach Neustarts von NGINX Plus erhalten bleibt.
• Wir definieren einen virtuellen Server, der Port 80 überwacht. Im Gegensatz zum ELB-Beispiel leitet NGINX Plus Anfragen für /backend‑one direkt an die Instanzen der Gruppe Backend One und Anfragen für /backend‑two direkt an die Instanzen der Gruppe Backend Two weiter.
• Wir definieren einen zweiten virtuellen Server, der Port 8080 überwacht, 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 – Integrationssoftware konfigurieren

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

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_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

• Der Schlüssel „region“ legt die AWS-Region fest, 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 legt das Synchronisierungsintervall fest: nginx-asg-sync prüft alle 5 Sekunden auf Skalierungsaktualisierungen.
• Der Schlüssel „upstreams“ definiert die Liste der Upstream-Gruppen. Für jede Upstream-Gruppe geben wir Folgendes an:
  • name – Der Name, den wir für den upstream-Block in Schritt 3 angegeben haben.
  • autoscaling_group – Der Name der entsprechenden Auto-Scaling-Gruppe.
  • port – Der Port, über den unsere Backend-Dienste erreichbar sind.
  • kind – Das Protokoll des Datenverkehrs, den NGINX Plus per Lastenausgleich an die Backend-Anwendung verteilt, 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 restart nginx-asg-sync

Lastverteilung und Skalierung testen

In den obigen Schritten haben wir NGINX Plus so konfiguriert, dass es die Last auf die Auto-Scaling-Gruppen unserer Anwendung verteilt. Nun können wir die Konfiguration testen. NGINX Plus verteilt Anfragen mit dem URI /backend‑one auf die Instanzen der Gruppe „Backend One“ und Anfragen mit dem URI /backend‑two auf die Instanzen der Gruppe „Backend Two“.

Wir können sehen, wie NGINX Plus neue Instanzen erkennt, wenn wir unsere Auto-Scaling-Gruppen skalieren. Zunächst rufen wir das Dashboard zur Überwachung der Live-Aktivitäten auf, das unter /status.html auf Port 8080 der NGINX Plus-Instanz erreichbar ist. Auf der Registerkarte Upstream sehen wir die Instanzen in unseren Auto-Scaling-Gruppen:

Nun skalieren wir die Gruppe „Backend One“ von drei auf fünf Instanzen, indem wir die Kapazität der Auto-Scaling-Gruppe ändern. Nachdem die neuen Instanzen gestartet wurden, nginx-asg-sync fügt sie der NGINX Plus-Konfiguration hinzu. Kurz darauf werden die neuen Instanzen im 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 den NGINX-Plus-Instanzen einen ELB vorzuschalten. Alternativ zu ELB können Sie Route 53 verwenden, um den Datenverkehr an die NGINX-Plus-Instanzen weiterzuleiten. Das Diagramm unserer Bereitstellung mit ELB sieht folgendermaßen aus:

Die richtige Methode auswählen

Welche Methode zur Konfiguration von NGINX Plus für den Lastenausgleich von Auto-Scaling-Gruppen eignet sich also besser für Sie? Die Tabelle bietet einen kurzen Vergleich der beiden Methoden:

NGINX Plus vor ELB NGINX Plus mit IntegrationssoftwareVorteile Einfache Konfiguration und keine Installation zusätzlicher Software. Sämtliche Vorteile aller Funktionen von NGINX Plus ohne die durch die ELB-Methode bedingten Einschränkungen.Nachteile Schränkt die Anzahl der nutzbaren Funktionen von NGINX Plus ein, einschließlich der unterstützten Protokolle. Erhöht sowohl die Bereitstellungskosten als auch die Latenz. Erfordert die Installation und Konfiguration der Integrationssoftware.Zusammenfassung Verwenden Sie diese Methode, wenn deren Nachteile für Sie akzeptabel sind. Verwenden Sie diese Methode, um die Möglichkeiten von NGINX Plus voll auszuschöpfen.

Zusammenfassung

AWS Auto Scaling bietet den Vorteil, die Anzahl der Anwendungsinstanzen an den jeweiligen Bedarf anzupassen. NGINX Plus bietet erweiterte Funktionen für den Lastenausgleich, 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.

Über den Autor

Michael Pleshakov

Weitere Blogbeiträge von Michael Pleshakov