Autoscale-Architektur für Google Cloud

NetScaler Console verarbeitet die Verteilung des Client-Datenverkehrs mithilfe von Google Network Load Balancer. Das folgende Diagramm zeigt, wie die Autoskalierung mit dem Google Network Load Balancer als Traffic-Distributor erfolgt:

Google Cloud-Architektur für Autoscaling

Google Network Load Balancer ist die Verteilungsebene zu den Clusterknoten. Network Load Balancer verwaltet den Clientdatenverkehr und verteilt ihn an NetScaler VPX Cluster. Network Load Balancer sendet den Client-Verkehr an NetScaler VPX-Clusterknoten, die in der NetScaler Console-Autoscaling-Gruppe zonenübergreifend verfügbar sind.

NetScaler Console löst die Scale-Out- oder Scale-In-Aktion auf Clusterebene aus. Wenn ein Scale-out ausgelöst wird, werden die registrierten virtuellen Maschinen bereitgestellt und dem Cluster hinzugefügt. Wenn ein Scale-In ausgelöst wird, werden die Knoten entfernt und aus den NetScaler VPX Clustern entfernt.

Die NetScaler Console Autoscale-Gruppe ist eine Gruppe von NetScaler-Instanzen, die den Lastausgleich von Anwendungen als eine Einheit durchführen und Autoscaling basierend auf den konfigurierten Schwellenparameterwerten auslösen.

So funktioniert die automatische Skalierung

Das folgende Flussdiagramm veranschaulicht den automatischen Skalierungsworkflow:

Citrix Autoscale-Flussdiagramm

Die NetScaler Console erfasst die Statistiken (CPU, Arbeitsspeicher und Durchsatz) der von Autoscale bereitgestellten Cluster für jede Minute.

Die Statistiken werden anhand der Konfigurationsschwellenwerte ausgewertet. Abhängig von der Statistik wird Scale-Out oder Scale-In ausgelöst. Scale-out wird ausgelöst, wenn die Statistik den maximalen Schwellenwert überschreitet. Die Skalierung wird ausgelöst, wenn die Statistik unter dem Mindestschwellenwert liegt.

Wenn ein Scale-Out ausgelöst wird:

  1. Ein neuer Knoten wurde bereitgestellt.

  2. Der Knoten ist mit dem Cluster verbunden und die Konfiguration wird vom Cluster mit dem neuen Knoten synchronisiert.

  3. Der Knoten ist bei NetScaler Console registriert.

  4. Die neuen Knoten-IP-Adressen werden im Google Network Load Balancer aktualisiert.

Wenn ein Scale-In ausgelöst wird:

  1. Der zu entfernende Knoten wurde identifiziert.

  2. Stoppen Sie neue Verbindungen zum ausgewählten Knoten.

  3. Der Knoten wird vom Cluster getrennt, von der NetScaler Console abgemeldet und dann aus Google Cloud entfernt.

Hinweis

Wenn die Anwendung bereitgestellt wird, wird ein IP-Satz auf Clustern in jeder Availability Zone erstellt. Dann werden die E-Mail-Adressen der Domäne und der Instanz beim Google Network Load Balancer registriert. Wenn die Anwendung entfernt wird, werden die IP-Adresse der Domäne und der Instanz vom Google Network Load Balancer abgemeldet. Dann wird der IP-Satz gelöscht.

Beispielszenario für Autoscaling

Beachten Sie, dass Sie eine Autoscale-Gruppe mit dem Namen asg_arn in einer einzelnen Availability Zone mit der folgenden Konfiguration erstellt haben.

  • Ausgewählte Schwellenwertparameter — Speicherbelegung.

  • Auf Speicher eingestellter Schwellenwert:

    • Mindestgrenze: 40

    • Höchstgrenze: 85

  • Wiedergabezeit — 2 Minuten.

  • Abklingzeit — 10 Minuten.

  • Wartezeit während der Aufhebung der Bereitstellung — 10 Minuten.

  • DNS-Lebenszeit — 10 Sekunden.

Nachdem die Gruppe “Autoscale” erstellt wurde, werden Statistiken aus der Gruppe “Autoscale” gesammelt. Die Autoscale-Richtlinie bewertet auch, ob ein Autoscale-Ereignis ausgeführt wird. Wenn die automatische Skalierung ausgeführt wird, warten Sie, bis das Ereignis abgeschlossen ist, bevor Sie die Statistiken erfassen.

Liniendiagramm Citrix Autoscale

Die Abfolge der Ereignisse

  1. Die Speicherauslastung überschreitet den Schwellenwert bei T2. Das Scale-Out wird jedoch nicht ausgelöst, da es für die angegebene Wiedergabezeit nicht verletzt wurde.

  2. Scale-out wird bei T5 ausgelöst, nachdem ein maximaler Schwellenwert für 2 Minuten (Wiedergabezeit) kontinuierlich überschritten wurde.

  3. Es wurden keine Maßnahmen für den Verstoß zwischen T5-T10 ergriffen, da die Node-Bereitstellung im Gange ist.

  4. Node wird bei T10 bereitgestellt und dem Cluster hinzugefügt. Die Abklingzeit wurde gestartet.

  5. Aufgrund der Abklingzeit wurden keine Maßnahmen für den Verstoß zwischen T10-T20 ergriffen. Dieser Zeitraum gewährleistet das organische Wachstum von Instanzen einer Autoscale-Gruppe. Bevor die nächste Skalierungsentscheidung ausgelöst wird, wird darauf gewartet, dass sich der aktuelle Datenverkehr stabilisiert und auf den aktuellen Satz von Instanzen durchdurchschnittlich wird.

  6. Die Speicherauslastung sinkt unter den Mindestschwellenwert bei T23. Das Scale-In wird jedoch nicht ausgelöst, da es für die angegebene Wiedergabezeit nicht verletzt wurde.

  7. Die Skalierung wird bei T26 ausgelöst, nachdem der Mindestschwellenwert für 2 Minuten (Wiedergabezeit) kontinuierlich überschritten wurde. Ein Knoten im Cluster wird für die Aufhebung der Bereitstellung identifiziert.

  8. Für den Verstoß zwischen T26-T36 wurden keine Maßnahmen ergriffen, da NetScaler Console darauf wartet, bestehende Verbindungen abzubauen. Bei der DNS-basierten Autoskalierung ist TTL wirksam.

    Hinweis

    Bei DNS-basiertem Autoscaling wartet NetScaler Console auf den angegebenen Time-To-Live-Zeitraum (TTL). Anschließend wartet es, bis vorhandene Verbindungen abgeleitet werden, bevor die Node-Bereitstellung initiiert wird.

  9. Für den Verstoß zwischen T37-T39 wurden keine Maßnahmen ergriffen, da die Node-Bereitstellung im Gange ist.

  10. Knoten wird entfernt und bei T40 aus dem Cluster entfernt.

Alle Verbindungen zum ausgewählten Knoten wurden entleert, bevor die Node-Bereitstellung initiiert wurde. Daher wird die Abklingzeit übersprungen, nachdem das Provisioning des Knotens aufgehoben wurde.

Autoscale-Architektur für Google Cloud