Ein einzelner Webserver ist ein Single Point of Failure. Octavia, der Load-Balancing-Dienst von OpenStack, löst das, indem es Verkehr auf einen Pool aus Backend-Instanzen verteilt und ihn von solchen wegleitet, die einen Health-Check nicht bestehen. Es ist der Cloud-skalierte Nachfolger des Single-Host-Nginx-Reverse-Proxys – dieselbe Idee, aber elastisch, API-gesteuert und hochverfügbar.

Dieses Tutorial baut einen funktionierenden HTTP-Load-Balancer Ende zu Ende: einen Load Balancer auf einem Subnetz, einen Listener auf Port 80, einen Member-Pool aus zwei Instanzen und einen Health-Monitor, der ungesunde Member automatisch entfernt. Es setzt vorhandenes Mandanten-Networking und mindestens zwei laufende Instanzen voraus, die eine Web-App ausliefern.

Voraussetzungen

• Eine laufende OpenStack-2025.2-Cloud mit aktiviertem Octavia-(Load-Balancer-)Dienst.
• Der openstack-Client mit installiertem Plugin python-octaviaclient.
• Zwei Instanzen in acme-subnet, die einen Webserver auf Port 80 betreiben, samt ihrer privaten IPs.

source ~/acme-openrc
openstack loadbalancer provider list
openstack server list -c Name -c Networks

Das Octavia-Objektmodell

Vier Objekte bauen aufeinander auf. Ein Load Balancer besitzt eine VIP auf einem Subnetz. Ein Listener bindet ein Protokoll und einen Port (z. B. HTTP:80) auf dieser VIP. Ein Pool definiert, wie Verkehr verteilt wird, und gruppiert die Backends. Member sind die Backend-Instanzen im Pool, und ein Health-Monitor prüft sie, sodass nur gesunde Member Verkehr erhalten.

Schritt 1: Den Load Balancer erstellen

Erstellen Sie den Load Balancer auf Ihrem Mandanten-Subnetz. Octavia stellt eine Amphora-VM (oder eine treiberspezifische Ressource) bereit, um die VIP zu hosten – dieser Schritt dauert also ein bis zwei Minuten:

openstack loadbalancer create --name acme-lb --vip-subnet-id acme-subnet
openstack loadbalancer show acme-lb -c provisioning_status -c vip_address

Warten Sie, bis provisioning_status auf ACTIVE steht, bevor Sie fortfahren. Sie können pollen oder den Operating-Status beobachten:

openstack loadbalancer list -c name -c provisioning_status -c operating_status

Schritt 2: Einen Listener hinzufügen

Der Listener nimmt Client-Verbindungen an. Erstellen Sie einen HTTP-Listener auf Port 80, angehängt an den Load Balancer:

openstack loadbalancer listener create --name acme-listener \
  --protocol HTTP --protocol-port 80 acme-lb

Schritt 3: Einen Pool erstellen

Der Pool legt den Balancing-Algorithmus fest und hält die Member. ROUND_ROBIN ist eine sinnvolle Vorgabe; LEAST_CONNECTIONS passt zu langlebigen Verbindungen:

openstack loadbalancer pool create --name acme-pool \
  --lb-algorithm ROUND_ROBIN --listener acme-listener --protocol HTTP

Schritt 4: Member hinzufügen

Fügen Sie jede Backend-Instanz über ihre private IP und das Subnetz, in dem sie liegt, dem Pool hinzu. Wiederholen Sie das für jedes Backend:

openstack loadbalancer member create --name web-01 \
  --address 10.0.0.42 --protocol-port 80 --subnet-id acme-subnet acme-pool
openstack loadbalancer member create --name web-02 \
  --address 10.0.0.43 --protocol-port 80 --subnet-id acme-subnet acme-pool

Schritt 5: Einen Health-Monitor anhängen

Der Health-Monitor prüft jeden Member regelmäßig und nimmt fehlschlagende aus der Rotation. Ein HTTP-Monitor, der auf / ein 200 erwartet, ist ein guter Anfang:

openstack loadbalancer healthmonitor create --name acme-hm \
  --delay 5 --timeout 3 --max-retries 3 --type HTTP --url-path / acme-pool

Schritt 6: Die VIP veröffentlichen und testen

Die VIP liegt im privaten Subnetz. Hängen Sie eine Floating IP an, damit Clients von außen den Load Balancer erreichen, und testen Sie, dass Anfragen verteilt werden:

openstack floating ip create ext-net
openstack loadbalancer show acme-lb -c vip_port_id
openstack floating ip set --port <vip_port_id> 203.0.113.80
von außen Anfragen wiederholen – die Antworten sollten zwischen Backends wechseln
for i in $(seq 1 6); do curl -s http://203.0.113.80/ | grep -o 'web-0[12]'; done

Verifizierung

Bestätigen Sie, dass alles gesund ist. Sowohl der Load Balancer als auch die Pool-Member sollten einen gesunden Operating-Status melden:

openstack loadbalancer status show acme-lb
openstack loadbalancer member list acme-pool -c name -c operating_status

operating_status sollte für gesunde Member ONLINE sein

Um Failover zu beweisen, stoppen Sie den Webserver auf einem Backend und beobachten Sie, wie dessen Member auf ERROR wechselt, während der Verkehr ununterbrochen zum anderen fließt.

Häufige Fehler und Fehlersuche

Load Balancer hängt in PENDING_CREATE

Octavia baut noch die Amphora oder kann keine planen. Geben Sie ihm einige Minuten; wird er nie ACTIVE, sollte ein Admin die Octavia-Worker-Logs prüfen sowie dass Management-Netz und Amphora-Image existieren.

Member erscheinen als ERROR / offline

Der Health-Monitor erreicht das Backend nicht. Prüfen Sie, dass der Webserver tatsächlich auf Port 80 lauscht und eine Security Group auf den Membern Verkehr aus dem Load-Balancer-Subnetz auf diesem Port erlaubt.

Curl läuft auf der VIP in einen Timeout

Meist ist die Floating IP nicht mit dem VIP-Port verknüpft oder keine Security Group erlaubt Port 80 eingehend. Prüfen Sie die Floating-IP-Verknüpfung sowie Protokoll/Port des Listeners erneut.

Aller Verkehr trifft ein Backend

Persistente Verbindungen oder Session-Stickiness können Round-Robin verschleiern. Nutzen Sie separate Anfragen (wie in der Schleife oben) und bestätigen Sie, dass der Pool-Algorithmus ROUND_ROBIN ist.

Aufräumen

openstack loadbalancer delete acme-lb --cascade
openstack floating ip delete 203.0.113.80

Fazit

Sie haben einen hochverfügbaren HTTP-Dienst gebaut: einen Load Balancer mit Listener, einen balancierten Pool, gesundheitsgeprüfte Member und eine öffentliche VIP – alles über die API bereitgestellt und ausfallsicher gegenüber einem Backend-Ausfall. Das ist die Cloud-skalierte Version, eine App hinter einen Reverse Proxy zu stellen, und so bleiben produktive Workloads während Deployments und Störungen online. Kombinieren Sie es mit persistenten Volumes und mehreren Instanzen für einen vollständigen, ausfallsicheren Stack.

Octavia produktiv zu betreiben – mit redundanten Amphorae, TLS-Terminierung und Reserve-Kapazität – ist Teil der gemanagten Plattform, die clouditiv auf einer souveränen On-Premise-Cloud betreibt, damit Ihre Anwendungen Cloud-Hochverfügbarkeit erhalten, ohne dass Sie die Load-Balancing-Flotte pflegen.