Einheit 4.3: Elastizität und VM Auto Scaling

Einführung

Die Elastizität auf IONOS CLOUD umfasst zwei unterschiedliche Achsen, die zu verschiedenen Zeitpunkten festgelegt werden. Das vertikale Skalieren vergrößert eine einzelne laufende VM und ist weitgehend ein Live-Vorgang; das horizontale Skalieren fügt ganze Replikate hinzu und entfernt sie unter einer Metrikrichtlinie und ist der verwaltene Elastizitätsmechanismus der Plattform. Die Entscheidung, die beide Achsen miteinander verbindet, wird vor dem Start beider getroffen: VM Auto Scaling erzeugt neue Replikate aus einer Replikatvorlage, deren Berechnungskonfiguration (CPU-Architektur, Kerne, RAM) und Speicher vorab festgelegt werden. Die Wahl des verwalteten horizontalen Pfads verpflichtet daher zur Replikatgestaltung der Ebene, die in Einheit 4.1 festgelegt wurde. Diese Einheit behandelt beide Achsen, die Anti-Flapping-Steuerungen, die eine Skalierungsgruppe stabil halten, sowie die zustandslose Voraussetzung, die das horizontale Skalieren sicher macht. Anschließend wird eine Auto-Scaling-Gruppe erstellt und ein Live-Resize auf der FinCorp-Ebene durchgeführt.

1. Vertikale Elastizität: Live-Vertical Scaling und seine Grenzen

Live Vertical Scaling (LVS) ändert die Ressourcen einer VM nach der Bereitstellung. Auf Dedicated Core- und vCPU-Servern ist ein Live-Hotplug nach oben möglich (Hinzufügen von CPU, RAM, NICs und Speicherdatenträgern), während der Server läuft. So können Sie schnell auf Spitzen reagieren, ohne ein Wartungsfenster einzuplanen. Die Grenzen sind spezifisch und für das Design relevant:

Upscale ist live, Downscale ist asymmetrisch. Sie können CPU, RAM, NICs und Speicherdatenträger live hochskalieren. Ein Live-Downscale ist nur für NICs und Speicherdatenträger möglich. Das Verkleinern von CPU oder RAM erfordert einen Neustart. Ein Downscale der Rechenleistung ist daher eine geplante Operation, keine transparente.
Die Obergrenze für RAM-Hotplug beträgt 240 GB. RAM-Hotplug wird automatisch deaktiviert, wenn die RAM-Größe 240 GB überschreitet. Über dieser Grenze führt jede RAM-Erhöhung zu einem Neustart der VM. In dieser Dimension gilt LVS dann nicht mehr.
Windows ist stärker eingeschränkt. Windows erlaubt das Live-Skalieren von CPU-Kernen, aber nicht von RAM. Das Skalieren über acht CPU-Kerne hinaus erfordert einen Neustart. Planen Sie Windows-Tiers entsprechend.

Vertikales Skalieren ist der richtige Hebel, wenn eine einzelne Workload einfach nur größer sein muss und nicht aufgeteilt werden kann. Es hat jedoch eine harte Obergrenze (eine VM kann den Host nicht überschreiten), und der asymmetrische Downscale macht es für schwankenden Traffic ungeeignet. Dafür skalieren Sie horizontal.

2. Horizontale Elastizität: VM Auto Scaling

VM Auto Scaling ist der verwaltete Dienst, der komplette VM-Replikate startet und beendet, um der Auslastung zu entsprechen. Derzeit wird nur horizontales Skalieren unterstützt: Es werden weitere VMs basierend auf der Replikatkonfiguration einer Gruppe erstellt, anstatt bestehende VMs neu zu dimensionieren. Zwei grundlegende Fakten prägen jedes Design, das diesen Dienst verwendet.

Die Replikatkonfiguration wird im Voraus festgelegt. Eine VM Auto Scaling Gruppe erzeugt neue VM-Replikate aus einer Replikatvorlage. Daher sind die Berechnungsform des Replikats (CPU-Architektur, Kerne, RAM) und der Speicher Entscheidungen, die bereits in Einheit 4.1 zum Designzeitpunkt getroffen werden. Die unterstützten Replikat-Speichertypen sind HDD, SSD Premium und SSD Standard. VM Auto Scaling ist eine Early Access Funktion, und Flow Logs werden für Auto-Scaling-Replikate noch nicht unterstützt. Dies ist eine kleine, aber reale Lücke in der Observability, die beachtet werden sollte.

Die Replikatkonfiguration gilt nur für neue Replikate. Die Gruppe verfügt über eine Replikatvorlage (die VM-Definition, aus der neue Replikate erzeugt werden). Änderungen an der Vorlage oder manuelle Änderungen an den Ressourcen eines Replikats betreffen nur Replikate, die nach der Änderung erstellt werden; die bestehende Flotte wird nicht neu dimensioniert. In diesem präzisen Sinne führt der Dienst kein vertikales Skalieren durch: Er fügt laufenden VMs keine Kerne, keinen Arbeitsspeicher und keinen Speicher hinzu. Automatisch generierte Replikatnamen sind Namen, keine Server-IDs, und können nicht verwendet werden, um Informationen über die API abzurufen. Erstellen Sie daher Ihr operatives Tooling um die Gruppe herum, nicht um die Identitäten einzelner Replikate.

2.1 Eine Metrikrichtlinie und die Anti-Flapping-Steuerungen

Eine Gruppe hat genau eine Metrikrichtlinie: Sie definieren eine einzelne Metrik, deren Auslastung das Skalieren auslöst. Die unterstützten Metriken sind der Durchschnitt der CPU-Auslastung der Instanz (Prozent) sowie eingehende und ausgehende Netzwerk-Bytes und -Pakete. Innerhalb dieser einen Richtlinie definieren Sie eine Scale-out-Aktion und eine Scale-in-Aktion, jeweils mit einem Mengentyp (Absolut oder Prozent) und einem Wert.

Die Steuerungen, die verhindern, dass die Gruppe oszilliert (zwischen Scale-out und Scale-in hin und her springt), sind keine optionalen Komfortfunktionen; sie sind das Design einer stabilen Gruppe:

Der obligatorische Schwellenwertabstand. Die Schwellenwerte für Scale-in und Scale-out müssen sich um mindestens 40 Prozentpunkte unterscheiden. Diese tote Zone verhindert, dass eine einzelne verrauschte Metrikmessung ein Scale-out und unmittelbar darauf ein Scale-in auslöst.
Die Abklingzeit. Nach einer Skalierungsaktion wartet die Gruppe eine Abklingzeit, bevor sie erneut handelt. Der Standardwert beträgt 5 Minuten; das Minimum sind 120 Sekunden (2 Minuten) und das Maximum 24 Stunden. Eine Abklingzeit, die kürzer ist als die Zeit, die ein neues Replikat zum Hochfahren und zur Aufnahme der Auslastung benötigt, ist die klassische Ursache für Überdimensionierung.
Die Stapelgröße pro Aktion. Skalieren Sie in Stapeln: Die empfohlene maximale Größe beträgt 5 VMs pro Skalierungsaktion, mit einer empfohlenen Obergrenze der Gruppe von etwa 100 Replikaten und einer Untergrenze von einem Replikat. Die Untergrenze von einem Replikat bedeutet, dass kein Scale-to-zero möglich ist; die Gruppe behält immer mindestens ein warmes Replikat bei.

Die Konfiguration einer Gruppe erstellt automatisch zwei Überwachungsalarme (einen für Scale-in, einen für Scale-out) gemäß der Richtlinie. Optional kann die Replikatkonfiguration auf eine Backup Unit verweisen, damit Replikat-VM-Sicherungen regelmäßig gespeichert werden, und sie kann eine Managed Application Load Balancer Zielgruppe (Zielgewichtsbereich 1 bis 256) zuordnen, sodass neue Replikate automatisch hinter dem Load Balancer hinzugefügt werden, sobald sie erscheinen. Diese ALB-Zuordnung ist es, die eine Skalierungsebene nutzbar macht: Ohne sie würden neue Replikate keinen Traffic erhalten.

2.2 Die stateless-Voraussetzung

Horizontales Skalieren ist nur sicher, wenn ein Replikat erstellt oder zerstört werden kann, ohne den Benutzerzustand zu verlieren, da die Gruppe ganze VMs nach eigenem Zeitplan hinzufügt und löscht. Dadurch wird der stateless-Betrieb zu einer Voraussetzung und nicht zu einer wünschenswerten Option. Jeder Sitzungs- oder Prozesszustand muss aus dem Replikat herausgelöst werden, was genau die Aufgabe der In-Memory DB Cache-Ebene (Modul 5) ist: Sitzungs- und geteilter Zustand befinden sich im Cache, die Replikate bleiben stateless, und die Auto-Scaling-Gruppe kann sie frei durchwechseln. Dies ist dieselbe In-Memory-Ebene, die in Einheit 1.3 als Substitution für das Read-Scaling benannt wurde und nun doppelte Dienste als Schicht zur Externalisierung des Zustands leistet, die das Auto-Scaling sauber macht. Eine stateful-Ebene (zum Beispiel eine Datenbank) ist niemals die Auto-Scaling-Ebene; sie wird über einen privaten Layer 4 Load Balancer erreicht und gemäß den Datenstufen-Mustern in Modul 5 skaliert.

Designüberlegungen

Skalierbarkeit. Bestimmen Sie die Skalierungsachse pro Ebene: vertikal für eine Arbeitslast, die größer sein muss und nicht aufgeteilt werden kann (innerhalb der 240-GB-Hotplug-Grenze und der CPU/RAM-Downscale mit Neustart), horizontal für Verkehr, der schwankt. Nur der horizontale Pfad wird verwaltet, und er erzeugt neue Replikate aus einer Replikatvorlage zur Designzeit.
Zuverlässigkeit. Die Schwellenwertlücke, die Abklingzeit und die Batch-Größe sind die Stabilitätssteuerungen. Eine zu kurze Abklingzeit im Verhältnis zur Aufwärmzeit der Replikate ist der häufigste Produktionsausfall und führt zu einem unkontrollierten Scale-out.
Betrieb. Änderungen an der Replikatkonfiguration werden nur auf neue Replikate angewendet, und Replikatnamen sind keine Server-IDs, daher arbeiten Sie mit der Gruppenabstraktion. Die Mindestgrenze von eins bedeutet, dass für jede Skalierungsebene mindestens ein dauerhaft aktives Replikat eingeplant werden muss.

Implementierungsanleitung für DCD

In dieser Anleitung wird eine VM Auto Scaling-Gruppe für die kundenseitige Anwendungsebene von FinCorp (die Dedicated Core-Ebene aus Einheit 4.1) erstellt und anschließend eine vertikale Live-Größenanpassung durchgeführt, um die beiden Achsen der Elastizität nebeneinander zu zeigen. Die Voraussetzungen sind die Dedicated Core-Replikatvorlage (eine Serverdefinition, von der die Gruppe Replikate erstellt) und, für die Lastverteilung, der öffentliche Layer 7 Application Load Balancer aus Einheit 3.3.

Ziel der Erstellung: Konfigurieren einer Auto-Scaling-Gruppe mit einer Metrikrichtlinie und einer Live-Größenanpassung.

Schritte (im Data Center Designer):

Starten Sie im FinCorp-VDC Create VM Auto Scaling Group. Das Erstellungsfenster zeigt einen Tab „Autoscaling Setup“ und einen Tab „Replica Configuration“. Stellen Sie sicher, dass das Rechenzentrum, in dem die Gruppe gehostet wird, die erforderlichen Ressourcen verfügbar hat.
Setzen Sie in Autoscaling Setup die Mindest- und Höchstanzahl der Replikate der Gruppe (Untergrenze von 1; empfohlene Obergrenze von etwa 100).
Definieren Sie die einzelne Metrikrichtlinie. Wählen Sie die Metrik (für die FinCorp-App: Durchschnittsnutzung der CPU). Setzen Sie den Scale Out Threshold und den Scale In Threshold und halten Sie einen Abstand von mindestens 40 Prozentpunkten ein.
Definieren Sie die Scale Out-Aktion: Mengentyp (Absolut oder Prozentual) und Menge (die Anzahl der Replikate, die hinzugefügt werden sollen), wobei das Batch bei oder unter den empfohlenen 5 pro Aktion bleiben sollte.
Definieren Sie die Scale In-Aktion auf dieselbe Weise (minimale Menge von 1).
Setzen Sie die Abklingzeit (Standard 5 Minuten; Minimum 2 Minuten, Maximum 24 Stunden) auf mindestens die Warm-up-Zeit der Replikate, damit neue Replikate Last aufnehmen können, bevor die nächste Aktion ausgeführt wird.
Definieren Sie in Replica Configuration die Dedicated Core-Replikatvorlage (Kerne, RAM, Speicher aus den unterstützten Typen und das Boot-Image). Verknüpfen Sie die ALB-Zielgruppe aus Einheit 3.3, damit neue Replikate Verkehr erhalten (Zielgewicht 1 bis 256; der ALB leitet an einen konfigurierbaren Zielport im gesamten TCP-Bereich 1 bis 65535 weiter, nicht an einen festen Port 80). Verweisen Sie optional auf eine Backup Unit. Klicken Sie auf Create.
Um vertikale Elastizität zu zeigen, wählen Sie den zugrunde liegenden Dedicated Core-Server (oder eine manuell verwaltete VM) im Workspace aus und erhöhen Sie im Inspector die CPU und den RAM. Stellen Sie die Änderung bereit: Die Erhöhung von CPU und RAM erfolgt live (unterhalb der 240-GB-RAM-Hotplug-Obergrenze), während eine spätere Reduzierung von CPU/RAM einen Neustart erfordern würde.

Häufige Fehler:

Das Setzen der Scale-in- und Scale-out-Schwellenwerte auf einen Abstand von weniger als 40 Prozentpunkten. Der vorgeschriebene Abstand wird bei Verstoß abgelehnt und dient genau dazu, Flapping zu verhindern.
Eine Abklingzeit, die kürzer ist als die Warm-up-Zeit der Replikate, wodurch die Gruppe weiterhin skaliert, bevor die vorherigen Replikate Last aufnehmen.
Das Vergessen, die ALB-Zielgruppe zu verknüpfen, sodass neue Replikate erscheinen, aber keinen Verkehr erhalten.
Die Erwartung, dass eine Änderung der Replikatvorlage die laufende Flotte neu dimensioniert. Sie wird nur auf neue Replikate angewendet; die bestehende Flotte bleibt unverändert.
Das Skalieren einer zustandsbehafteten Ebene. Externisieren Sie zuerst Sitzung/Zustand in den In-Memory-Cache; nur zustandslose Ebenen skalieren sicher automatisch.

Architekturpattern

Die standardmäßige elastische Web-Ebene vereint drei Themenstränge dieses Kurses. Der öffentliche Layer-7-Load Balancer (Einheit 3.3) steht vor einer Dedicated Core-Autoskalierungsgruppe, deren Replikaten zustandslos sind. Sitzungs- und geteilter Zustand werden in einem In-Memory DB-Cache im privaten Netzwerk gehalten (Modul 5). Unter Last überschreitet die CPU-Auslastung die Skalierungsschwelle nach oben, die Gruppe fügt Replikate in Chargen von bis zu fünf hinzu, die ALB-Zielgruppe nimmt sie automatisch auf, und die Abklingzeit verhindert eine Überkorrektur. Sinkt die Last und unterschreitet die Skalierungsschwelle nach unten (mindestens 40 Punkte niedriger), werden Replikate entfernt, bis der Mindestbestand von einem Replikat erreicht ist. Für die kundenseitige Anwendung von FinCorp ist dies die Ebene, die die täglichen Lastschwankungen auffängt: Die Grundauslegung ist auf Dedicated Core (Einheit 4.1) klein dimensioniert, Spitzenlasten werden durch das Hinzufügen von Replikaten abgefangen, nicht durch eine dauerhaft große VM, und da die Replikate keinen Zustand halten, kann die Gruppe sie austauschen, ohne angemeldete Benutzer zu beeinträchtigen.

Zusammenfassung

Die Elastizität von IONOS CLOUD hat zwei Achsen, die zu unterschiedlichen Zeitpunkten festgelegt werden. Vertikales Skalieren vergrößert eine einzelne laufende VM, wobei CPU/Arbeitsspeicher/Netzwerkschnittstelle/Storage live hochskaliert und Netzwerkschnittstelle/Storage live herabgestuft werden können. Für das Herabstufen von CPU/Arbeitsspeicher ist ein Neustart erforderlich, und das RAM-Hotplug ist ab 240 GB deaktiviert. Horizontales Skalieren über VM Auto Scaling ist der verwaltete Weg, eine Early-Access-Funktion, die neue Replikate aus einer Replikatvorlage zur Entwurfszeit stempelt. Dabei gilt eine Metrikrichtlinie pro Gruppe, ein obligatorischer Schwellenwertabstand von 40 Punkten, eine Abklingzeit von zwei Minuten bis 24 Stunden, eine Batch-Empfehlung von etwa fünf VMs pro Aktion und ein Mindestwert von einem Replikat (kein Scale-to-zero). Die Replikatkonfiguration gilt nur für neue Replikate, und die skalierte Ebene muss zustandslos sein, wobei der Zustand in den In-Memory-Cache ausgelagert wird. Der Build verdrahtet eine metrikgesteuerte Gruppe hinter dem ALB und zeigt daneben eine Live-Größenanpassung.

Wichtige Punkte:

Vertikal: CPU/Arbeitsspeicher/Netzwerkschnittstelle/Storage live hochskalieren; nur Netzwerkschnittstelle/Storage live herabstufen; CPU/Arbeitsspeicher herabstufen erfordert einen Neustart; RAM-Hotplug ist ab 240 GB deaktiviert.
Horizontales Auto Scaling stempelt neue Replikate aus einer Replikatvorlage zur Entwurfszeit (Compute-Form und Storage), die in Einheit 4.1 festgelegt wird.
Eine Metrikrichtlinie pro Gruppe; die Schwellenwerte für Scale-in und Scale-out müssen sich um mindestens 40 Prozentpunkte unterscheiden; Standard-Abklingzeit 5 Minuten (2 Minuten bis 24 Stunden); empfohlene Batch-Größe bis zu 5 VMs; Mindestwert von einem Replikat, kein Scale-to-zero.
Die Replikatkonfiguration gilt nur für neue Replikate; der Dienst passt die laufende Flotte nicht in der Größe an, und Replikatnamen sind keine Server-IDs.
Die Auto-Scaling-Ebene muss zustandslos sein, wobei Sitzung/Zustand in den In-Memory-Cache ausgelagert wird; eine ALB-Zielgruppe zuordnen, damit neue Replikate Traffic erhalten.

Wichtige Begriffe:

Live Vertical Scaling (LVS): Ändern der Ressourcen einer laufenden VM, live für Hochskalierung und für das Herabstufen von Netzwerkschnittstelle/Storage; CPU/Arbeitsspeicher herabstufen und RAM über 240 GB erfordern einen Neustart.
Metrikrichtlinie: Die einzige Regel pro Auto-Scaling-Gruppe (eine Metrik, eine Scale-out- und eine Scale-in-Aktion), die das Skalieren auslöst.
Abklingzeit: Die Wartezeit nach einer Skalierungsaktion vor der nächsten, die primäre Steuerung gegen übermäßiges Skalieren.
Schwellenwertabstand: Der obligatorische Mindestabstand von 40 Prozentpunkten zwischen den Schwellenwerten für Scale-in und Scale-out, der Flapping verhindert.

Weitere Lektüre

Einheit 4.1: Auswahl der Compute-Klasse (warum die Stufe Dedicated Core ist).
Einheit 3.3: Lastverteilung - Ebene 7 (der ALB, an dem die Gruppe angehängt wird).
Einheit 5.5: In-Memory-Datenbank (die Stufe zur Externalisierung des Zustands, die das automatische Skalieren sicher macht).

Lernziele