Eine Webanwendung benötigt Traffic-Verteilung? Erstelle einen Load Balancer

Veröffentlicht am: 8. August 2026

Ein einzelner Webserver wird zum Engpass und Single Point of Failure. Wenn er ausgelastet oder nicht verfügbar ist, kann die CloudTrips-Website keine neuen Anfragen bedienen.

Erstelle einen öffentlichen Azure Load Balancer mit zwei privaten Backend-VMs. Benutzer senden Datenverkehr an eine gemeinsame öffentliche Frontend-IP. Der Load Balancer wählt für jeden neuen Netzwerkfluss ein Backend aus.

Internet
   |
Öffentliche Frontend-IP
   |
Azure Load Balancer
   |-------------------|
Privates WEB01      Privates WEB02

Azure Load Balancer arbeitet auf Layer 4, dem Transport Layer des OSI-Netzwerkmodells. Auf dieser Ebene verteilt er Verbindungen anhand von Quell- und Ziel-IP-Adressen, dem TCP- oder UDP-Protokoll und den Portnummern. Er liest keine Anwendungsinhalte wie HTTP-Pfade oder Header. Ein späterer Application-Gateway-Trip führt dieses Layer-7-Verhalten ein.

Dieser Trip verwendet das Netzwerkfundament aus Eine App benötigt ein privates Netzwerk? Erstelle ein VNet. Behalte vnet-cloudtrips-test-weu, snet-app und nsg-cloudtrips-app-test-weu. Das Azure-Firewall-Lab wird nicht benötigt und sollte bereits entfernt sein.

Load Balancer, öffentliche IP, VMs, Datenträger und ausgehende Daten können Kosten verursachen. Schließe diesen und den folgenden Health-Probe-Trip zusammen ab und gib die VMs danach frei oder lösche sie.

HTTP zum Backend-Subnetz erlauben

Die vorhandene Subnetz-NSG erlaubt HTTPS nur für Mitglieder der CloudTrips-Application-Security-Group. Dieses Lab stellt eine einfache HTTP-Seite auf TCP-Port 80 bereit. Füge deshalb eine eigene Regel hinzu.

Öffne nsg-cloudtrips-app-test-weu, wähle Settings > Inbound security rules und danach Add. Konfiguriere:

Source: Service Tag
Source service tag: Internet
Source port ranges: *
Destination: IP Addresses
Destination IP addresses/CIDR ranges: 10.20.1.0/24
Service: HTTP
Action: Allow
Priority: 110
Name: Allow-HTTP-LoadBalancer
Description: Allow public HTTP traffic distributed by the test load balancer

Wähle Add.

Behalte die vorhandene Regel Allow-HTTPS-Internet. Die beiden benutzerdefinierten Regeln bedienen unterschiedliche Ports:

Allow-HTTPS-Internet:      Internet -> Application ASG -> TCP 443
Allow-HTTP-LoadBalancer:   Internet -> snet-app        -> TCP 80

Bei einer HTTP-Anfrage auf Port 80 passt die HTTPS-Regel mit Priorität 100 nicht, weil ihr Port 443 ist. Die Auswertung läuft mit der HTTP-Regel mit Priorität 110 weiter, die die Anfrage erlaubt. Der aktuelle Load Balancer verwendet Port 80 und nutzt deshalb die HTTPS-Regel nicht.

Die beiden VMs erhalten keine öffentlichen IP-Adressen. Das Load-Balancer- Frontend ist deshalb ihr öffentlicher Einstiegspunkt. Azure Load Balancer behält bei eingehendem Datenverkehr die Quell-IP des Clients bei. Die NSG muss deshalb die Internet-Quelle erlauben.

Azure Load Balancer sendet außerdem kleine Testverbindungen an jedes Backend, um zu prüfen, ob dessen Service-Port erreichbar ist. Diese Health Probes kommen vom Azure-verwalteten Service Tag AzureLoadBalancer und nicht vom öffentlichen Benutzer. Jede NSG enthält die standardmäßige Inbound-Regel AllowAzureLoadBalancerInBound, die diesen Plattformdatenverkehr erlaubt. Die benutzerdefinierte HTTP-Regel erlaubt deshalb echte Clientanfragen, während die Standardregel separat die Health Checks von Azure erlaubt. Eine eigene Deny-Regel mit einer kleineren Prioritätszahl könnte die Standardregel dennoch übersteuern und gesunde Backends als nicht verfügbar erscheinen lassen.

Den öffentlichen Load Balancer erstellen

Suche im Azure-Portal nach Load balancers. Wähle Create > Standard Load Balancer.

Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: lb-cloudtrips-web-test-weu
Region: West Europe
SKU: Standard
Type: Public
Tier: Regional

Basic Load Balancer wurde eingestellt. Standard ist die unterstützte SKU und unterstützt außerdem spätere zonenredundante und regionsübergreifende Designs.

Füge unter Frontend IP configuration hinzu:

Name: fe-cloudtrips-web-test-weu
IP version: IPv4
IP type: IP address
Public IP address: Create new
Public IP name: pip-cloudtrips-lb-test-weu
SKU: Standard
Availability zone: Zone-redundant
Routing preference: Microsoft network

Wenn die Region kein Availability-Zone-Feld anzeigt, fahre ohne dieses Feld fort.

Füge unter Backend pools hinzu:

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

Der Pool ist zunächst leer. Die Netzwerkschnittstellen der beiden VMs treten ihm bei, nachdem der Load Balancer existiert.

Die erste Load-Balancing-Regel erstellen

Eine Load-Balancing-Regel verbindet den öffentlichen Frontend-Port mit dem Backend-Port. Sie benötigt außerdem einen Health Probe, damit der Load Balancer keine neuen Flows an ein Backend mit geschlossenem Port sendet.

Wähle unter Inbound rules die Option Add a load balancing rule und konfiguriere:

Name: rule-http-80
IP version: IPv4
Frontend IP address: fe-cloudtrips-web-test-weu
Backend pool: be-cloudtrips-web-test-weu
Protocol: TCP
Port: 80
Backend port: 80
Health probe: Create new
Health probe name: probe-tcp-80
Health probe protocol: TCP
Health probe port: 80
Session persistence: None
Idle timeout: 15 minutes
TCP reset: Enabled
Floating IP: Disabled
Outbound SNAT: Use outbound rules to provide backend pool members internet access

Erstelle für dieses Lab keine Outbound Rule. Die Webserver verwenden bereits in Ubuntu enthaltene Software und müssen keine Pakete herunterladen. Wenn ein späterer Workload ausgehenden Internetzugriff benötigt, konfiguriere ein explizites NAT Gateway oder eine Load-Balancer-Outbound-Rule, anstatt dich auf Default Outbound Access zu verlassen.

Dieser Trip verwendet den kleinsten sinnvollen TCP-Probe, weil eine Load-Balancing-Regel Informationen zum Backendzustand benötigt. Der nächste Trip ersetzt ihn durch einen anwendungsbezogenen HTTP-Health-Check und beweist das Failover-Verhalten.

Füge unter Tags hinzu:

Application: CloudTrips
Environment: TEST
Purpose: WebTrafficDistribution

Wähle Review + create und danach Create. Öffne den bereitgestellten Load Balancer und notiere seine öffentliche Frontend-IP-Adresse.

Azure-Load-Balancer-Übersicht mit dem regionalen CloudTrips Standard Load Balancer und seiner öffentlichen Frontend-IP

Die öffentliche IP identifiziert den Dienst. Sie gehört keiner der beiden Backend-VMs. Der Load Balancer kann deshalb dasselbe Frontend behalten, während Backendinstanzen hinzugefügt, entfernt oder ersetzt werden.

Zwei private Web-VMs erstellen

Erstelle die erste VM im Azure-Portal:

Resource group: rg-cloudtrips-network-test-weu
Name: vm-cloudtrips-web01-test-weu
Region: West Europe
Availability options: No infrastructure redundancy required
Security type: Standard
Image: Ubuntu Server 24.04 LTS - x64 Gen2
Size: Standard_D2s_v3
Authentication type: Password or SSH public key
Username: azureuser
Public inbound ports: None

Verwende einen Standard-SSD-Betriebssystemdatenträger und aktiviere dessen Löschung mit der VM. Konfiguriere unter Networking:

Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-app
Public IP: None
NIC network security group: None
Delete NIC when VM is deleted: Enabled
Load balancing options: Azure load balancer
Load balancer: lb-cloudtrips-web-test-weu
Backend pool: be-cloudtrips-web-test-weu

None für die NIC-NSG ist beabsichtigt, weil snet-app bereits nsg-cloudtrips-app-test-weu besitzt. Füge die Tags Application: CloudTrips, Environment: TEST und Purpose: LoadBalancerBackend hinzu und erstelle die VM.

Wiederhole dieselbe Konfiguration für:

Name: vm-cloudtrips-web02-test-weu

Dieses Lab verwendet zwei gewöhnliche VMs, damit die Verteilung sichtbar wird. Ein Produktionsdesign würde Instanzen normalerweise auf Availability Zones verteilen oder ein Virtual Machine Scale Set verwenden.

Azure-Virtual-Machines-Seite mit den beiden laufenden privaten CloudTrips-Web-Backend-VMs

Auf jeder VM eine andere Testseite starten

Öffne vm-cloudtrips-web01-test-weu, wähle Operations > Run command > RunShellScript und führe aus:

sudo mkdir -p /opt/cloudtrips-web
printf '%s\n' 'CloudTrips response from WEB01' | sudo tee /opt/cloudtrips-web/index.html >/dev/null
printf '%s\n' \
  '[Unit]' \
  'Description=CloudTrips test web server' \
  'After=network.target' \
  '' \
  '[Service]' \
  'ExecStart=/usr/bin/python3 -m http.server 80 --bind 0.0.0.0 --directory /opt/cloudtrips-web' \
  'Restart=always' \
  '' \
  '[Install]' \
  'WantedBy=multi-user.target' \
  | sudo tee /etc/systemd/system/cloudtrips-web.service >/dev/null
sudo systemctl daemon-reload
sudo systemctl enable --now cloudtrips-web
curl --silent http://127.0.0.1

Die letzte Zeile sollte zurückgeben:

CloudTrips response from WEB01

Führe dasselbe Skript auf vm-cloudtrips-web02-test-weu aus, ersetze aber beide Vorkommen von WEB01 durch WEB02. Der lokale Test sollte zurückgeben:

CloudTrips response from WEB02

Der permanente systemd-Dienst startet den kleinen Python-Webserver nach einem VM-Neustart erneut. Er eignet sich für dieses Lab und nicht als Produktions-Webserver.

Backend Pool und Regel überprüfen

Öffne lb-cloudtrips-web-test-weu. Öffne unter Settings > Backend pools den Pool be-cloudtrips-web-test-weu und bestätige, dass die beiden VM-NIC-IP-Konfigurationen vorhanden sind.

Öffne danach Load balancing rules und bestätige:

rule-http-80: frontend TCP 80 -> backend TCP 80
Backend pool: be-cloudtrips-web-test-weu
Health probe: probe-tcp-80

CloudTrips-Load-Balancer-Backend-Pool mit den Netzwerkschnittstellen beider privater Web-VMs

Der Backend Pool beantwortet: Welche Server können Datenverkehr erhalten? Die Regel beantwortet: Welcher Frontend-Datenverkehr wird an welchen Backend-Port verteilt? Der Probe beantwortet: Welche Poolmitglieder sind aktuell geeignet?

Traffic-Verteilung testen

Ersetze in einem Terminal auf deinem Mac den Platzhalter durch die öffentliche Frontend-IP des Load Balancers und führe aus:

for request in {1..10}; do
  curl --connect-timeout 5 http://<load-balancer-public-ip>
done

Die Ausgabe sollte Antworten von beiden Backends enthalten:

CloudTrips response from WEB01
CloudTrips response from WEB02

Lokales Terminal mit Anfragen an eine Load-Balancer-IP, die beide CloudTrips-Backend-VMs erreichen

Azure Load Balancer berechnet einen Hash für jeden Netzwerkfluss. Er verspricht keine strikte Abfolge WEB01, WEB02, WEB01. Mehrere aufeinanderfolgende Anfragen können dieselbe VM erreichen. Wenn über mehrere neue Verbindungen beide Namen erscheinen, beweist das die Verteilung von einem Frontend an beide privaten Backends.

Fortfahren oder bereinigen

Fahre mit Ein Load Balancer benötigt einen Health Check? Konfiguriere einen Health Probe fort. Behalte Load Balancer, öffentliche IP, TCP Probe, Regel, Backend-VMs, NICs, Datenträger und HTTP-NSG-Regel. Gib die VMs nur frei, wenn du nicht sofort fortfährst.

Wenn du hier aufhörst, lösche die beiden VMs mit ihren NICs und Datenträgern. Lösche danach lb-cloudtrips-web-test-weu, pip-cloudtrips-lb-test-weu und die NSG-Regel Allow-HTTP-LoadBalancer. Behalte VNet, Subnetze, NSG, ASG und Route Table für spätere Networking-Trips.