Viele identische VMs benötigt? Erstelle eine VM-Skalierungsgruppe

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

CloudTrips benötigt mehrere identische Webserver. Eine Azure-VM-Skalierungsgruppe verwaltet VM-Instanzen anhand einer gemeinsamen Konfiguration und kann bei veränderter Nachfrage Instanzen hinzufügen oder entfernen.

Dieser Trip erstellt zwei Ubuntu-VMs hinter einem Standard Load Balancer. Cloud-init installiert NGINX auf jeder Instanz, und der Load Balancer stellt eine öffentliche HTTP-Adresse für die gesamte Gruppe bereit.

Wähle einen Orchestrierungsmodus

Flexible Uniform
Für neue Bereitstellungen empfohlen Traditionelles Modell für strikt identische Flotten
Instanzen sind normale Azure-VMs Instanzen sind VMSS-spezifische untergeordnete Ressourcen
Mehr Kontrolle über einzelne VMs, NICs und Datenträger Instanzen werden hauptsächlich als Gruppe verwaltet
Unterstützt gemischte VM-Größen und bis zu 1.000 VMs mit Verfügbarkeitsgarantien Unterstützt bis zu 3.000 identische Instanzen

Beide Modi unterstützen Lastenausgleich und Autoskalierung. Dieser Trip verwendet Flexible. Der Orchestrierungsmodus kann später nicht geändert werden.

Erstelle die Ressourcengruppe

Öffne Resource groups > Create und gib ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-vmss-test-weu
Region: West Europe

Wähle Review + create > Create.

Erstelle das virtuelle Netzwerk

Öffne Virtual networks > Create.

Konfiguriere unter Basics:

Resource group: rg-cloudtrips-vmss-test-weu
Name: vnet-cloudtrips-vmss-test-weu
Region: West Europe

Konfiguriere unter IP addresses:

IPv4 address space: 10.82.0.0/16
Subnet name: snet-web
Subnet range: 10.82.1.0/24

Wähle Review + create > Create.

Erstelle die Netzwerksicherheitsgruppe

Öffne Network security groups > Create:

Resource group: rg-cloudtrips-vmss-test-weu
Name: nsg-cloudtrips-vmss-test-weu
Region: West Europe

Öffne nach der Bereitstellung die NSG und wähle Inbound security rules > Add:

Source: Any
Source port ranges: *
Destination: Any
Service: HTTP
Destination port: 80
Protocol: TCP
Action: Allow
Priority: 1010
Name: Allow-HTTP

Öffne vnet-cloudtrips-vmss-test-weu > Subnets > snet-web. Ordne nsg-cloudtrips-vmss-test-weu zu und speichere.

Füge keine öffentliche SSH-Regel hinzu. Verwende Run Command, Bastion, VPN oder einen anderen genehmigten privaten Verwaltungszugang.

Erstelle die öffentliche IP-Adresse

Öffne Public IP addresses > Create:

Resource group: rg-cloudtrips-vmss-test-weu
Name: lb-cloudtrips-vmss-test-weu-publicip
Region: West Europe
IP version: IPv4
SKU: Standard
Availability zone: Zone-redundant, when available
Tier: Regional
IP address assignment: Static
Routing preference: Microsoft network

Wähle Review + create > Create.

Erstelle den Load Balancer

Öffne Load balancers > Create. Konfiguriere unter Basics:

Resource group: rg-cloudtrips-vmss-test-weu
Name: lb-cloudtrips-vmss-test-weu
Region: West Europe
SKU: Standard
Type: Public
Tier: Regional

Wähle unter Frontend IP configuration die Option Add a frontend IP configuration:

Name: fe-web
IP version: IPv4
IP type: IP address
Public IP address: lb-cloudtrips-vmss-test-weu-publicip

Füge unter Backend pools hinzu:

Name: bepool-web
Virtual network: vnet-cloudtrips-vmss-test-weu
Backend pool configuration: NIC

Lasse den Back-End-Pool leer. Die Skalierungsgruppeninstanzen werden später hinzugefügt.

Füge unter Inbound rules einen Integritätstest hinzu:

Name: hp-http
Protocol: TCP
Port: 80
Interval: 5 seconds
Unhealthy threshold: 2

Füge eine Lastenausgleichsregel hinzu:

Name: lbrule-http
IP version: IPv4
Frontend IP address: fe-web
Backend pool: bepool-web
Protocol: TCP
Port: 80
Backend port: 80
Health probe: hp-http
Session persistence: None
Floating IP: Disabled
TCP reset: Enabled

Die Regel verteilt Verbindungen auf dem öffentlichen Port 80 auf fehlerfreie Instanzen.

Standard Load Balancer mit Front-End, Back-End-Pool, Integritätstest und HTTP-Regel

Füge expliziten Ausgangszugriff hinzu

Instanzen flexibler Skalierungsgruppen erhalten keine standardmäßige Ausgangskonnektivität. Ohne expliziten Ausgangspfad kann Cloud-init NGINX nicht aus den Ubuntu-Repositorys herunterladen.

Öffne im Load Balancer Outbound rules > Add:

Name: outrule-internet
IP version: IPv4
Frontend IP address: fe-web
Protocol: All
Backend pool: bepool-web
Port allocation: Manually choose number of outbound ports
Outbound ports: 1024
Idle timeout: 4 minutes
TCP reset: Enabled

Diese Regel verwendet Source NAT oder SNAT für Verbindungen, die von den VMs gestartet werden. Sie erlaubt keine neuen eingehenden Internetverbindungen.

Die zugehörigen Regeltypen erfüllen unterschiedliche Aufgaben:

Regel Zweck
Lastenausgleichsregel Sendet einen öffentlichen Anwendungsport an alle fehlerfreien Back-End-Instanzen
Eingehende NAT-Regel Ordnet einen eindeutigen öffentlichen Port einer bestimmten Instanz und einem Port zu
Ausgangsregel Gibt Back-End-Instanzen SNAT-basierte Ausgangskonnektivität
NSG-Regel Erlaubt oder verweigert Datenverkehr an der Subnetz- oder NIC-Grenze

Dieses Lab benötigt keine eingehende NAT-Regel. Die standardmäßige NSG-Regel AllowAzureLoadBalancerInBound erlaubt Azure-Integritätstests, während Allow-HTTP Clientdatenverkehr auf TCP 80 erlaubt.

Load-Balancer-Ausgangsregel mit SNAT-Konnektivität für den Back-End-Pool

Erstelle die VM-Skalierungsgruppe

Öffne Virtual machine scale sets > Create.

Konfiguriere unter Basics:

Resource group: rg-cloudtrips-vmss-test-weu
Scale set name: vmss-cloudtrips-web-test-weu
Region: West Europe
Availability zone: None
Orchestration mode: Flexible
Security type: Trusted launch virtual machines
Image: Ubuntu Server 24.04 LTS - x64 Gen2
Size: Standard_D2als_v7
Authentication type: SSH public key
Username: azureuser
SSH public key source: Generate new key pair
Key pair name: sshkey-cloudtrips-vmss-test-weu
Scaling mode: Manual
Instance count: 2

Prüfe den angezeigten Preis. Lasse Spot-Instanzen deaktiviert und wähle Standard SSD LRS für den Betriebssystemdatenträger.

Registerkarte „Basics“ für zwei flexible Ubuntu-Instanzen

Verbinde die Skalierungsgruppe mit dem Netzwerk

Wähle unter Networking:

Virtual network: vnet-cloudtrips-vmss-test-weu
Subnet: snet-web
Network security group: None at NIC level
Public IP address per VM instance: Disabled
Load balancing: Azure load balancer
Load balancer: lb-cloudtrips-vmss-test-weu
Backend pool: bepool-web

Das Subnetz besitzt bereits die NSG. Erstelle daher keine zweite NSG auf NIC-Ebene. Erstelle keine weitere öffentliche IP und keinen weiteren Load Balancer. Die Instanzen dürfen keine eigenen öffentlichen IP-Adressen besitzen: Azure erlaubt keine VMSS-NICs mit öffentlichen IPs pro Instanz in einem Back-End-Pool mit Load-Balancer-Ausgangsregel. Der gesamte ein- und ausgehende Internetdatenverkehr verwendet in diesem Design lb-cloudtrips-vmss-test-weu-publicip.

Installiere NGINX mit Cloud-init

NGINX ist ein quelloffener Webserver. Er wartet auf HTTP-Anfragen an TCP-Port 80 und liefert Webinhalte an den Client zurück. Eine VM-Skalierungsgruppe benötigt NGINX nicht zwingend. Dieser Trip verwendet ihn als kleine, realistische Anwendung, die auf jeder Instanz identisch ausgeführt werden kann.

Cloud-init installiert und startet NGINX während der ersten Bereitstellung. Anschließend ersetzt es die Standardseite durch eine Textantwort mit dem VM-Hostnamen. Dadurch entstehen drei nützliche Prüfungen:

  • Der TCP-Integritätstest bestätigt, dass NGINX lauscht, bevor der Load Balancer Datenverkehr an die Instanz sendet.
  • Eine Anfrage an den Load Balancer beweist, dass die Anwendung erreichbar ist.
  • Der Hostname in der Antwort zeigt, welche Instanz die Anfrage verarbeitet hat und ob neu skalierte VMs dieselbe Konfiguration erhalten haben.

Der Anfragepfad lautet:

Client > Öffentliche Load-Balancer-IP:80 > Fehlerfreie VMSS-Instanz:80 > NGINX-Seite

Füge unter Advanced > Custom data and cloud init ein:

#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /usr/local/bin/cloudtrips-index.sh
    permissions: '0755'
    content: |
      #!/bin/sh
      printf 'CloudTrips VM Scale Set\nInstance: %s\n' "$(hostname)" > /var/www/html/index.html
runcmd:
  - /usr/local/bin/cloudtrips-index.sh
  - systemctl enable --now nginx

Speichere keine Geheimnisse in benutzerdefinierten Daten. Füge die üblichen CloudTrips-TEST-Tags hinzu, wähle Review + create und dann Create. Lade den privaten Schlüssel herunter und schütze ihn.

Überprüfe beide Instanzen

Öffne die Skalierungsgruppe > Instances. Warte, bis beide VMs ausgeführt werden.

Instanzseite der VM-Skalierungsgruppe mit zwei ausgeführten VMs

Öffne jede Instanz > Run command > RunShellScript und führe aus:

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

Die erwartete Ausgabe enthält status: done, active und den Instanzhostnamen. Falls NGINX nicht installiert wurde, prüfe /var/log/cloud-init-output.log und bestätige, dass outrule-internet mit bepool-web verbunden ist. Repariere die Instanz nach der Korrektur des Ausgangszugriffs mit Run Command:

sudo apt-get update
sudo apt-get install -y nginx
printf 'CloudTrips VM Scale Set\nInstance: %s\n' "$(hostname)" |
  sudo tee /var/www/html/index.html
sudo systemctl enable --now nginx

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

Das Ergebnis active und die CloudTrips-Seite bestätigen, dass NGINX funktioniert. debconf-Warnungen über ein fehlendes interaktives Terminal sind bei Run Command normal und bedeuten keinen Installationsfehler. Eine manuelle Reparatur überprüft Cloud-init nicht. Erstelle oder skaliere mit den korrigierten benutzerdefinierten Daten eine neue Instanz, um die automatische Bereitstellung zu bestätigen.

Teste den öffentlichen Endpunkt

Kopiere die Adresse von lb-cloudtrips-vmss-test-weu-publicip und führe aus:

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

Die Antworten sollten beide Instanzhostnamen zeigen. Die Load-Balancer-Verteilung basiert auf Flows, daher wechselt ein kurzer Test möglicherweise nicht perfekt.

Terminal mit HTTP-Antworten beider VM-Skalierungsgruppeninstanzen

Skaliere von zwei auf drei Instanzen

Öffne die Skalierungsgruppe > Scaling. Ändere die manuelle Kapazität von 2 auf 3 und wähle Save. Kehre zu Instances zurück und warte, bis die dritte VM ausgeführt wird.

Führe die lokale Überprüfung auf der neuen Instanz aus und wiederhole anschließend den öffentlichen HTTP-Test. Ihr Hostname sollte in den Antworten erscheinen.

Instanzseite mit drei ausgeführten VMs nach der Skalierung

Jede Instanz und jeder Betriebssystemdatenträger wird separat abgerechnet. Auch Load Balancer, öffentliche IP und Datenübertragung können Kosten verursachen.

Behalte die Skalierungsgruppe für Autoskalierung

Setze die manuelle Kapazität von 3 auf 2 zurück, aber lösche weder die Ressourcengruppe noch ihre Ressourcen. Der nächste Trip VMs müssen automatisch skalieren? Konfiguriere VM-Autoskalierung verwendet diese Skalierungsgruppe, den Load Balancer, das Netzwerk und zwei fehlerfreie NGINX-Instanzen. Die Bereinigung erfolgt nach diesem Trip.