Einheit 4.3: Elastizität und VM Auto Scaling

Einführung

Die Elastizität bei IONOS hat zwei verschiedene Achsen, die zu unterschiedlichen Zeiten entschieden werden. Die vertikale Skalierung vergrößert eine einzelne laufende VM und ist größtenteils ein Live-Vorgang. Die horizontale Skalierung hingegen fügt und entfernt ganze Replikate unter einer metrischen Richtlinie und ist das managede Elastizitätsmechanismus der Plattform. Die Entscheidung, die die beiden zusammenbindet, wird vor dem Ausführen beider getroffen: VM Auto Scaling erstellt neue Replikate aus einer Replikat-Vorlage, deren Compute-Konfiguration (CPU-Architektur, Kerne, RAM) und Speicher im Voraus eingerichtet werden, sodass die Auswahl des manageden horizontalen Pfads die Replikat-Design der Ebene in Einheit 4.1 festlegt. Diese Einheit behandelt beide Achsen, die Anti-Flapping-Steuerungen, die eine Skalierungsgruppe stabil halten, und die zustandslose Voraussetzung, die die horizontale Skalierung sicher macht, und baut dann eine Auto-Skalierungsgruppe auf und führt eine Live-Größenänderung auf der FinCorp-Ebene durch.

1. Vertikale Elastizität: Live-Vertikale Skalierung und ihre Grenzen

Live-Vertikale Skalierung (LVS) ändert die Ressourcen eines VM nach der Bereitstellung. Sowohl auf Dedicated-Core- als auch auf vCPU-Servern können Sie nach oben hotpluggen (CPU, RAM, NICs und Speicher-Volumes hinzufügen), während der Server läuft, was die schnelle Reaktion auf einen Spitzenwert ohne Wartungsfenster ermöglicht. Die Grenzen sind spezifisch und wichtig für das Design:

• Upscale ist live, Downscale ist asymmetrisch. Sie können CPU, RAM, NICs und Speicher-Volumes live-upsizen. Sie können nur NICs und Speicher-Volumes live-downsizen. Die Reduzierung von CPU oder RAM erfordert einen Neustart, sodass eine Downscale von Rechenressourcen ein geplanter Vorgang und kein transparenter ist.
• Die RAM-Hotplug-Grenze beträgt 240 GB. Die RAM-Hotplugging wird automatisch deaktiviert, wenn die RAM-Größe 240 GB überschreitet. Über dieser Grenze erzwingt die Erhöhung von RAM einen Neustart des VM, was bedeutet, dass LVS nicht mehr auf diese Dimension angewendet wird.
• Windows ist eingeschränkter. Windows ermöglicht die Live-Skalierung von CPU-Kernen, aber nicht von RAM, und die Skalierung über acht CPU-Kerne hinaus erfordert einen Neustart. Planen Sie die Windows-Stufen entsprechend.

Vertikale Skalierung ist der richtige Hebel, wenn eine einzelne Workload einfach größer sein muss und nicht aufgeteilt werden kann, aber sie hat eine harte Grenze (ein VM kann den Host nicht überschreiten) und die asymmetrische Downscale macht sie zu einer schlechten Wahl für Datenverkehr, der schwankt. Für diesen Fall skalieren Sie horizontal.

2. Horizontale Elastizität: VM Auto Scaling

VM Auto Scaling ist der gemanagte Dienst, der ganze VM-Repliken startet und beendet, um der Last anzupassen. Er unterstützt derzeit nur horizontale Skalierung: Er erstellt mehr virtuelle Maschinen (VMs) auf der Grundlage einer Gruppenreplik-Konfiguration, anstatt bestehende zu ändern. Zwei wichtige Fakten prägen jedes Design, das ihn verwendet.

Die Replik-Konfiguration wird im Voraus entschieden. Eine VM Auto Scaling-Gruppe erstellt neue VM-Repliken aus einer Replik-Vorlage, sodass die Replik-Computeshape (CPU-Architektur, Kerne, RAM) und der Speicher Designzeit-Entscheidungen sind, die bereits in Einheit 4.1 getroffen wurden. Die unterstützten Replik-Speichertypen sind HDD, SSD Premium und SSD Standard. VM Auto Scaling ist ein Early-Access-Feature, und Flow Logs werden noch nicht auf Auto-Scaling-Repliken unterstützt, was eine kleine, aber reale Observabilitätslücke ist, die beachtet werden muss.

Die Replik-Konfiguration gilt nur für neue Repliken. Die Gruppe hat eine Replik-Vorlage (die VM-Definition, von der aus neue Repliken erstellt werden). Eine Änderung der Vorlage oder eine manuelle Änderung der Ressourcen einer Replik betrifft nur Repliken, die nach der Änderung erstellt wurden; sie ändert nicht die bestehende Flotte. Dies ist der genaue Sinn, in dem der Dienst keine vertikale Skalierung durchführt: Er fügt keine Kerne, RAM oder Speicher zu laufenden VMs hinzu. Auto-generierte Replik-Namen sind Namen, keine Server-IDs, und können nicht verwendet werden, um Informationen über den API abzurufen, sodass Sie Ihre operativen Tools um die Gruppe und nicht um einzelne Replik-Identitäten herum aufbauen sollten.

2.1 Ein Metrik-Policy und die Anti-Flapping-Steuerungen

Eine Gruppe hat genau eine Metrik-Policy: Sie definieren eine einzelne Metrik, deren Auslastung das Skalieren auslöst. Die unterstützten Metriken sind die durchschnittliche Auslastung von Instanz-CPU (Prozent), sowie die ein- und ausgehenden Netzwerk-Bytes und -Pakete. Innerhalb dieser Policy definieren Sie eine Skalierungs-Aktion und eine Reduzierungs-Aktion, jede mit einem Menge-Typ (Absolut oder Prozentsatz) und einer Menge.

Die Steuerungen, die die Gruppe daran hindern, zu oszillieren (zwischen Skalieren und Reduzieren zu fluktuieren), sind keine optionalen Annehmlichkeiten; sie sind das Design einer stabilen Gruppe:

• Die obligatorische Schwellenlücke. Die Reduzierungs- und Skalierungs-Schwellen müssen mindestens 40 Prozentpunkte voneinander getrennt sein. Diese tote Zone verhindert, dass eine einzelne verrauschte Metrik-Leseaktion ein Skalieren und ein sofortiges Reduzieren auslöst.
• Die Abkühlzeit. Nach einer Skalierungs-Aktion wartet die Gruppe eine Abkühlzeit, bevor sie erneut reagiert. Die Standard-Abkühlzeit beträgt 5 Minuten; die Mindest-Abkühlzeit beträgt 120 Sekunden (2 Minuten) und die Maximal-Abkühlzeit 24 Stunden. Eine Abkühlzeit, die kürzer ist als die Zeit, die eine neue Replik benötigt, um sich aufzuwärmen und die Last aufzunehmen, ist die klassische Ursache für Über-Skalieren.
• Die pro-Aktion-Batch-Größe. Skalieren Sie in Batches: Die empfohlene Maximalgröße beträgt 5 VMs pro Skalierungs-Aktion, mit einer empfohlenen Gruppen-Obergrenze von etwa 100 Repliken und einer Untergrenze von einer Replik. Die Mindest-Untergrenze von einer Replik bedeutet, dass es kein Skalieren auf Null gibt; die Gruppe behält immer mindestens eine warme Replik bei.

Das Konfigurieren einer Gruppe erstellt zwei Überwachungs-Warnungen automatisch (eine für Reduzieren, eine für Skalieren) gemäß der Policy. Optional kann die Replik-Konfiguration auf eine Sicherungseinheit verweisen, sodass Replik-VM-Sicherungen regelmäßig gespeichert werden, und sie kann eine Managed Application Load Balancer-Zielgruppe (Ziel-Gewichtsbereich 1 bis 256) zuweisen, sodass neue Repliken automatisch hinter dem Lastenausgleich hinzugefügt werden, wenn sie erscheinen. Diese ALB-Zuweisung ist es, die eine Skalierungs-Stufe nutzbar macht: Ohne sie würden neue Repliken keinen Datenverkehr erhalten.

2.2 Die Zustandslose Vorbedingung

Horizontale Skalierung ist nur sicher, wenn eine Replik erstellt oder zerstört werden kann, ohne dass Benutzerzustände verloren gehen, da die Gruppe ganze VMs nach ihrem eigenen Zeitplan hinzufügt und entfernt. Das macht Zustandslosigkeit zu einer Vorbedingung, nicht zu einem Nice-to-Have. Jeder Sitzungs- oder Prozess-Zustand muss von der Replik externalisiert werden, was genau die Aufgabe der In-Memory DB-Cache-Schicht (Modul 5) ist: Sitzungs- und gemeinsame Zustände leben im Cache, die Repliken bleiben zustandslos, und die Auto-Skalierungs-Gruppe kann sie frei umschichten. Dies ist die gleiche In-Memory-Schicht, die in Einheit 1.3 als Lese-Skalierungs-Ersatz benannt wurde, die jetzt doppelte Aufgaben als Zustands-Externalisierungsschicht übernimmt, die das Auto-Skalieren sauber macht. Eine zustandsbehaftete Schicht (eine Datenbank, zum Beispiel) ist niemals die Auto-Skalierungs-Schicht; sie wird über einen privaten Layer-4-Lastenausgleich erreicht und nach den Daten-Schicht-Mustern in Modul 5 skaliert.

Entwurfsüberlegungen

• Skalierbarkeit. Entscheiden Sie die Skalierungsachse pro Tier: vertikal für ein Workload, das größer sein muss und nicht aufgeteilt werden kann (innerhalb der 240 GB Hotplug-Obergrenze und der neu startenden CPU/RAM-Downscale), horizontal für Datenverkehr, der schwankt. Nur der horizontale Pfad wird gemanagt, und er erstellt neue Repliken aus einer Replik-Vorlage zur Entwurfszeit.
• Zuverlässigkeit. Die Schwellenlücke, die Abkühlzeit und die Batch-Größe sind die Stabilitätskontrollen. Eine zu kurze Abkühlzeit im Verhältnis zur Replik-Warmzeit ist der häufigste Produktionsfehler, der zu einem unkontrollierten Skalieren führt.
• Betrieb. Änderungen an der Replik-Konfiguration gelten nur für neue Repliken, und Replik-Namen sind keine Server-IDs, daher sollten Sie auf der Gruppenabstraktion operieren. Die Mindestanzahl von einem bedeutet, dass Sie für mindestens eine immer eingeschaltete Replik pro Skalierungstier budgetieren müssen.

DCD Implementierung Schritt-für-Schritt

Diese Implementierung erstellt eine VM Auto Scaling-Gruppe für die Kundenfacing-Anwendungsebene von FinCorp (die Dedicated Core-Ebene aus Einheit 4.1) und führt dann eine Live-Vertikal-Größenanpassung durch, um die beiden Elastizitätsachsen nebeneinander zu zeigen. Die Voraussetzungen sind die Dedicated Core-Replikate-Vorlage (eine Serverdefinition, von der die Gruppe Replikate erstellt) und, für die Verkehrsverteilung, der öffentliche Layer 7-Anwendungs-Load Balancer aus Einheit 3.3.

Ziel: Konfigurieren Sie eine Auto-Scaling-Gruppe mit einer Metrik-Richtlinie und einer Live-Größenanpassung.

Schritte (im Data Center Designer):

1. Im FinCorp-VDC starten Sie Erstellen VM Auto Scaling-Gruppe. Das Erstellungsfenster zeigt eine Autoscaling-Setup-Registerkarte und eine Replikate-Konfigurations-Registerkarte an. Stellen Sie sicher, dass das Rechenzentrum, das die Gruppe hostet, die erforderlichen Ressourcen verfügbar hat.
2. Im Autoscaling-Setup legen Sie die Mindest- und Höchstanzahl der Replikate der Gruppe fest (Mindestanzahl 1; empfohlene Höchstanzahl um 100).
3. Definieren Sie die einzelne Metrik-Richtlinie. Wählen Sie die Metrik (für die FinCorp-App, CPU-Auslastungsdurchschnitt). Legen Sie die Skalierungs-Schwellenwerte und EinSkalierungs-Schwellenwerte fest, wobei diese mindestens 40 Prozentpunkte voneinander entfernt sein sollten.
4. Definieren Sie die Skalierungs-Aktion: Mengestyp (Absolut oder Prozentsatz) und Menge (Anzahl der Replikate, die hinzugefügt werden), wobei die Charge bei oder unter der empfohlenen 5 pro Aktion liegen sollte.
5. Definieren Sie die EinSkalierungs-Aktion auf die gleiche Weise (Mindestmenge 1).
6. Legen Sie die Abkühlzeit (Standard 5 Minuten; Mindestens 2 Minuten, Höchstens 24 Stunden) auf mindestens die Replikate-Aufwärmezeit fest, damit neue Replikate die Last aufnehmen können, bevor die nächste Aktion durchgeführt wird.
7. Im Replikate-Konfiguration definieren Sie die Dedicated Core-Replikate-Vorlage (Kerne, RAM, Speicher aus den unterstützten Typen und das Boot-Bild). Verknüpfen Sie die Einheit 3.3 ALB-Zielgruppe, damit neue Replikate Verkehr erhalten (Zielgewicht 1 bis 256; die ALB leitet an einen konfigurierbaren Zielport im gesamten TCP-Bereich 1 bis 65535 weiter, nicht an einen festen Port 80). Optional können Sie eine Backup-Einheit referenzieren. Klicken Sie auf Erstellen.
8. Um die vertikale Elastizität zu zeigen, wählen Sie die zugrunde liegende Dedicated Core Server (oder ein manuell gemanagtes VM) im Workspace und erhöhen Sie im Inspector CPU und RAM. Bewilligen Sie die Änderung: Die Aufrüstung von CPU und RAM ist live (unter der 240 GB RAM-Hotplug-Obergrenze), während eine spätere CPU/RAM-Abstufung einen Neustart erfordern würde.

Häufige Fehler:

• Festlegen der Ein- und AusSkalierungs-Schwellenwerte näher als 40 Prozentpunkte. Die obligatorische Lücke wird abgelehnt, wenn sie verletzt wird und genau dazu dient, um ein Auf und Ab zu verhindern.
• Eine Abkühlzeit, die kürzer ist als die Replikate-Aufwärmezeit, was dazu führt, dass die Gruppe weiterhin ausSkaliert, bevor die vorherigen Replikate die Last übernehmen.
• Vergessen, die ALB-Zielgruppe zu verknüpfen, so dass neue Replikate erscheinen, aber keinen Verkehr erhalten.
• Erwarten, dass eine Änderung der Replikate-Vorlage die laufende Flotte vergrößert. Sie gilt nur für neue Replikate; die bestehende Flotte bleibt unverändert.
• Skalieren einer Zustandsbehafteten Ebene. Externalisieren Sie die Sitzung/Zustand in den In-Memory-Cache; nur Zustandslose Ebenen Skalieren sicher.

Architekturmuster

Das Standard-Elastizitäts-Muster für das Web besteht aus drei Fäden dieses Kurses. Der öffentliche Layer-7-Lastverteiler (Einheit 3.3) fronts eine Dedicated-Core-Auto-Scaling-Gruppe, deren Replikate zustandslos sind, wobei Sitzung und gemeinsamer Zustand in einem In-Memory DB-Cache im privaten Netzwerk (Modul 5) gespeichert werden. Unter Last übersteigt die CPU-Auslastung die Skalierungs-Schwellenwert, die Gruppe fügt Replikate in Chargen von bis zu fünf hinzu, die ALB-Zielgruppe nimmt sie automatisch auf, und die Abkühlzeit verhindert eine Überkorrektur; wenn die Last sinkt und die Skalierungs-Schwellenwert (mindestens 40 Punkte niedriger) unterschreitet, werden Replikate entfernt, bis zum Boden von einer Replikate. Für die kundenorientierte Anwendung von FinCorp ist dies die Ebene, die die täglichen Verkehrsschwankungen aufnimmt: Die Grundausstattung ist auf Dedicated Core (Einheit 4.1) klein dimensioniert, Spitzen werden durch Hinzufügen von Replikaten und nicht durch ein permanent großes VM gehandhabt, und da die Replikate keinen Zustand speichern, kann die Gruppe sie ohne Auswirkungen auf angemeldete Benutzer ersetzen.

Zusammenfassung

Die Elastizität von IONOS hat zwei Achsen, die zu verschiedenen Zeiten entschieden werden. Die vertikale Skalierung vergrößert eine einzelne laufende VM, live für CPU/RAM/NIC/Speicher Aufrüstung und NIC/Speicher Abstufung, wobei die Abstufung von CPU/RAM einen Neustart erfordert und die Hotplug-Funktion von RAM über 240 GB deaktiviert ist. Die horizontale Skalierung über VM Auto Scaling ist der gemanagte Pfad, eine Funktion im Frühzugriff, die neue Replikate aus einer Replikate-Vorlage zur Entwurfszeit erstellt, mit einer Metrik-Richtlinie pro Gruppe, einem obligatorischen Schwellenwert-Abstand von 40 Prozentpunkten, einer Abkühlzeit von zwei Minuten bis 24 Stunden, einer Batch-Empfehlung von etwa fünf virtuellen Maschinen pro Aktion und einem Replikat-Boden (keine Skalierung auf Null). Die Replikat-Konfiguration gilt nur für neue Replikate, und die skalierte Ebene muss zustandslos sein, wobei der Zustand extern im In-Memory-Cache gespeichert wird. Der Build verbindet eine metrik-getriebene Gruppe hinter dem ALB und zeigt eine Live-Größe neben ihr.

Wichtige Punkte:

• Vertikal: Aufrüstung von CPU/RAM/NIC/Speicher live; Abstufung nur von NIC/Speicher live; Abstufung von CPU/RAM erfordert einen Neustart; Hotplug-Funktion von RAM über 240 GB deaktiviert.
• Horizontale Auto-Skalierung erstellt neue Replikate aus einer Replikate-Vorlage zur Entwurfszeit (Rechenform und Speicher), wie in Einheit 4.1 festgelegt.
• Eine Metrik-Richtlinie pro Gruppe; Skalierungs-Schwellenwerte müssen sich um mindestens 40 Prozentpunkte unterscheiden; Abkühlzeit-Standard 5 Minuten (2 Minuten bis 24 Stunden); empfohlene Batch-Größe bis zu 5 virtuellen Maschinen; Boden von einem Replikat, keine Skalierung auf Null.
• Replikat-Konfiguration gilt nur für neue Replikate; der Dienst ändert nicht die Größe der laufenden Flotte, und Replikat-Namen sind keine Server-IDs.
• Die Auto-Skalierungsebene muss zustandslos sein, wobei die Sitzung/Zustand extern im In-Memory-Cache gespeichert wird; verknüpfen Sie eine ALB-Zielgruppe, damit neue Replikate Datenverkehr erhalten.

Wichtige Begriffe:

• Live-Vertikale Skalierung (LVS): Änderung der Ressourcen einer laufenden VM, live für Aufrüstung und für NIC/Speicher-Abstufung; Abstufung von CPU/RAM und RAM über 240 GB erfordern einen Neustart.
• Metrik-Richtlinie: die einzelne Regel pro Auto-Skalierungsgruppe (eine Metrik, eine Aufrüstungs- und eine Abstufungsaktion), die die Skalierung auslöst.
• Abkühlzeit: die Wartezeit nach einer Skalierungsaktion, bevor die nächste erfolgt, die primäre Anti-Überskalierungs-Kontrolle.
• Schwellenwert-Abstand: der obligatorische Mindestabstand von 40 Prozentpunkten zwischen Skalierungs-Schwellenwerten, der verhindert, dass die Skalierung zu oft umgeschaltet wird.

Weiterführende Literatur

• Einheit 4.1: Auswahl der Compute-Klasse (warum die Stufe Dedicated Core ist).
• Einheit 3.3: Lastverteilung - Layer 7 (der Application Load Balancer, an den die Gruppe angehängt wird).
• Einheit 5.5: In-Memory-Datenbank (die state-externalisation-Stufe, die das Auto-Scaling sicher macht).