VMs müssen automatisch skalieren? Konfiguriere VM-Autoskalierung

Veröffentlicht am:
#virtual-machine-scale-set

Die CloudTrips-Webebene soll bei anhaltend höherer Nachfrage Kapazität hinzufügen und ungenutzte Kapazität anschließend entfernen. Azure Monitor Autoskalierung ändert die Instanzanzahl einer VM-Skalierungsgruppe anhand von definierten Metriken und Grenzen.

Dieser Trip ergänzt die vorhandene Skalierungsgruppe um CPU-basierte Regeln für Skalierung und Rückskalierung, erzeugt vorübergehende CPU-Last, überprüft die neue Instanz und beobachtet die Rückkehr zur Mindestkapazität.

Bestätige die Skalierungsgruppe

Dieser Trip benötigt die Ressourcen aus Viele identische VMs benötigt? Erstelle eine VM-Skalierungsgruppe:

Resource group: rg-cloudtrips-vmss-test-weu
Scale set: vmss-cloudtrips-web-test-weu
Orchestration mode: Flexible
Healthy instance count: 2
Load balancer: lb-cloudtrips-vmss-test-weu

Öffne die Skalierungsgruppe > Instances. Bestätige, dass beide Instanzen ausgeführt werden und NGINX über Run command active zurückgibt:

systemctl is-active nginx
curl --fail http://localhost/

Konfiguriere Autoskalierung erst, wenn beide Instanzen fehlerfrei sind. Eine fehlerhafte Anwendung wird nicht repariert, indem weitere fehlerhafte Instanzen erstellt werden.

Erstelle eine Autoskalierungseinstellung

Öffne die Skalierungsgruppe > Scaling und wähle je nach Portalansicht Custom autoscale oder Configure. Erstelle eine Einstellung:

Autoscale setting name: autoscale-cloudtrips-web-test-weu
Resource group: rg-cloudtrips-vmss-test-weu
Scale mode: Scale based on a metric
Minimum instances: 2
Maximum instances: 4
Default instances: 2

Das Minimum erhält zwei Webserver. Das Maximum verhindert, dass dieser Test mehr als vier kostenpflichtige Instanzen erstellt. Der Standardwert wird verwendet, wenn Azure die Metrik nicht lesen kann. Er ist kein normales Ziel, das die Regeln außer Kraft setzt.

Autoskalierungseinstellung mit mindestens zwei, höchstens vier und standardmäßig zwei Instanzen

Füge die Regel zur Skalierung hinzu

Wähle Add a rule und konfiguriere:

Metric source: Current resource
Metric namespace: Virtual Machine Host
Metric name: Percentage CPU
Dimension values: All values
Time aggregation: Average
Operator: Greater than
Metric threshold: 70
Duration: 5 minutes
Time grain statistic: Average
Operation: Increase count by
Instance count: 1
Cooldown: 5 minutes

All values verhindert eine Filterung der Metrik auf eine bestimmte Instanz. Azure bewertet die durchschnittliche CPU-Auslastung der Skalierungsgruppe. Bleibt sie während des Auswertungsfensters über 70 %, fordert Autoskalierung eine zusätzliche Instanz an. Die Abkühlzeit gibt der neuen VM Zeit zum Starten, bevor eine weitere Skalierungsaktion möglich wird.

CPU-Regel, die nach anhaltender Auslastung über 70 Prozent eine Instanz hinzufügt

Füge die Regel zur Rückskalierung hinzu

Füge eine zweite Regel hinzu:

Metric source: Current resource
Metric namespace: Virtual Machine Host
Metric name: Percentage CPU
Dimension values: All values
Time aggregation: Average
Operator: Less than
Metric threshold: 30
Duration: 10 minutes
Time grain statistic: Average
Operation: Decrease count by
Instance count: 1
Cooldown: 5 minutes

Das längere Fenster mit niedriger CPU-Auslastung reduziert ein ständiges Wechseln zwischen Skalierung und Rückskalierung. Azure reduziert die Kapazität nicht unter das Minimum von zwei.

CPU-Regel, die nach anhaltender Auslastung unter 30 Prozent eine Instanz entfernt

Speichere die Autoskalierungseinstellung. Bestätige, dass sie aktiviert ist und beide Regeln im Standardprofil erscheinen.

Erzeuge vorübergehende CPU-Last

Die durchschnittliche CPU-Auslastung muss in der gesamten Skalierungsgruppe steigen. Führe deshalb über Run command > RunShellScript auf beiden aktuellen Instanzen aus:

sudo apt-get update
sudo apt-get install -y stress-ng
nohup stress-ng \
  --cpu 0 \
  --cpu-load 90 \
  --timeout 10m \
  > /tmp/stress-ng.log 2>&1 &

pgrep -a stress-ng

stress-ng beansprucht absichtlich zehn Minuten lang CPU und stoppt anschließend. Verwende es nur in dieser entbehrlichen TEST-Umgebung. Der Befehl läuft im Hintergrund, sodass Azure Run Command beendet werden kann, während die Last weiterläuft.

Beobachte die automatische Skalierung

Öffne die Skalierungsgruppe > Metrics und zeige Percentage CPU mit Durchschnittsaggregation an. Öffne anschließend Scaling > Run history oder den Ausführungsverlauf der Autoskalierungseinstellung.

Autoskalierung erfolgt nicht sofort: Die Metrik muss fünf Minuten über dem Schwellenwert bleiben, Azure muss die Regel auswerten und die VM bereitstellen. Warte auf ein erfolgreiches Skalierungsereignis und eine dritte Instanz.

Autoskalierungsverlauf mit erfolgreicher Skalierung von zwei auf drei Instanzen

Führe auf der neuen Instanz aus:

cloud-init status --long
systemctl is-active nginx
curl --fail http://localhost/

Die Instanz muss active melden und ihren Hostnamen zurückgeben. Dadurch wird bewiesen, dass das VMSS-Modell automatisch erstellte Kapazität konfigurieren kann.

Überprüfe die neue Instanz hinter dem Load Balancer

Sende mehrere Verbindungen an die öffentliche IP:

for request in 1 2 3 4 5 6; do
  curl --silent --header 'Connection: close' http://<PUBLIC-IP>/
done

Die Ergebnisse sollten schließlich alle drei fehlerfreien Hostnamen enthalten. Azure Load Balancer verteilt Flows und nicht Anfragen in strikt zyklischer Reihenfolge. Wiederhole deshalb die Schleife, falls ein Hostname nicht in den ersten sechs Antworten erscheint.

Terminalzusammenfassung mit Antworten von drei fehlerfreien VMSS-Instanzen

Beobachte die automatische Rückskalierung

Nach zehn Minuten stoppt stress-ng. Die CPU-Auslastung sollte unter 30 % fallen. Warte auf das zehnminütige Fenster mit niedriger CPU-Auslastung, die Regelauswertung und die Abkühlzeit. Bestätige im Autoskalierungsverlauf, dass die Kapazität sinkt und die Instanzanzahl zu zwei zurückkehrt.

Autoskalierungsverlauf mit Rückskalierung nach sinkender CPU-Auslastung

Autoskalierung entfernt eine Instanz und bewahrt keine Daten auf, die nur auf deren Betriebssystemdatenträger gespeichert sind. Workloads in Skalierungsgruppen müssen dauerhafte Daten in externen Diensten speichern.

Bereinige

Deaktiviere die Autoskalierungseinstellung, falls du das Lab ohne weitere Kapazitätsänderungen untersuchen möchtest. Lösche anschließend die eigene Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-vmss-test-weu \
  --yes

Dadurch werden Autoskalierungseinstellung, Skalierungsgruppe, Instanzen, Datenträger, Load Balancer, öffentliche IP, NSG, VNet und Subnetz entfernt. Überprüfe die Löschung:

az group exists --name rg-cloudtrips-vmss-test-weu

Das erwartete Ergebnis ist false.