SCS OSISM Deployment Networking: VIPs, Netzwerkseparation und Multi-Node-Architektur

Sovereign Cloud Stack (SCS): Cloud in a Box Installation and Deployment Guide

A practical guide to deploying SCS Cloud in a Box (CIAB) — a single-node OpenStack+Kubernetes cloud infrastructure built on European open-source standards for digital sovereignty.

Der Sovereign Cloud Stack (SCS) stellt das Open-Source-Cloud-Infrastruktur-Framework für Europa bereit. Seine Deployment-Engine, OSISM, verwaltet alles vom Bare-Metal-Provisioning bis hin zur Orchestrierung von OpenStack, Ceph und Kubernetes. Während der Cloud in a Box Guide Single-Node-Deployments abdeckt, erfordern produktive SCS-Umgebungen mehrere Nodes mit einer ordnungsgemäßen Netzwerksegmentierung, hochverfügbaren Virtual IPs (VIPs) und Software-Defined Networking.

Dieser Leitfaden konzentriert sich speziell auf die Netzwerkebene eines OSISM-verwalteten SCS-Deployments – die Netzwerkzonen, die VIP-Architektur, die Interface-Rollen und die Konfigurationsmuster, die eine Multi-Node-Cloud betriebsbereit machen.

Überblick über die OSISM-Netzwerkarchitektur

Ein OSISM-Cloud-Pod besteht aus mehreren Node-Rollen, von denen jede mit spezifischen Netzwerkzonen verbunden ist:

Die sechs Netzwerkzonen

OSISM definiert bis zu sechs logische Netzwerkzonen. In einem Produktions-Deployment wird jede Zone einem eigenen VLAN und einem physischen Interface oder LAG zugeordnet:

In kleineren Deployments können einige Zonen zusammengefasst werden – API und Management können beispielsweise ein 10-Gbit-Interface teilen, oder Tunnel und Storage können einen High-Speed-Link mit QoS-Tagging gemeinsam nutzen. Die Empfehlung der OSISM Bill of Materials für die Produktion lautet:

• Management: 2 × 1 Gbit (bonded), separater Switch-Stack
• Data plane (API + Tunnel + Storage): 2 × 25 Gbit oder 2 × 100 Gbit pro Host
• External: 2 × 10 Gbit oder 2 × 25 Gbit auf dedizierten Netzwerk-Nodes

Netzwerk-Interface-Rollen

OSISM ordnet Traffic-Typen benannten Interface-Rollen in environments/kolla/configuration.yml zu. Jede Rolle löst sich entweder in ein physisches Interface, ein VLAN-Sub-Interface oder einen Bond auf.

Parameter der Interface-Rollen

Beispiel: Host-Konfiguration mit 3 NICs

Ein Control Node in der Produktion mit drei physischen NICs könnte Folgendes verwenden:

network_interface: "bond0"
api_interface: "bond0"
tunnel_interface: "bond1"
migration_interface: "bond0"
neutron_external_interface: "bond2"
kolla_external_vip_interface: "bond0"

Mit Netplan unter Ubuntu 24.04:

# /etc/netplan/01-osism.yaml
network:
  version: 2
  renderer: networkd
  bonds:
    bond0:
      interfaces: [enp1s0f0, enp1s0f1]
      parameters:
        mode: 802.3ad
        mtu: 1500
    bond1:
      interfaces: [enp2s0f0, enp2s0f1]
      parameters:
        mode: 802.3ad

mtu: 9000 vlans: vlan10: id: 10 link: bond0 mtu: 1500 addresses: ["10.1.10.10/24"] vlan20: id: 20 link: bond0 mtu: 1500 addresses: ["10.1.20.10/24"] vlan30: id: 30 link: bond0 mtu: 1500 addresses: ["10.1.30.10/24"] ethernets: bond2: mtu: 1500 addresses: [] # Keine IP — gebridged zu OVS br-ex

This gives you 3 bonds on 6 physical ports: a management bond for MGMT/API/migration VLANs, a high-speed bond for tunnel/storage with jumbo frames, and a dedicated bond for external provider network bridging.

---

## Virtual IPs (VIPs) — The Core of HA

The single most important networking concept in a multi-node OSISM deployment is the **Virtual IP (VIP)**. Without it, every OpenStack API call would need to know which control node is currently alive. The VIP provides a single, floating endpoint that follows the active controller.

### The Primary VIP: `kolla_external_vip_address`

All OpenStack API services (Keystone, Nova API, Neutron API, Glance, Cinder, Heat, Designate, etc.) are fronted by a single VIP defined as:

```yaml
# environments/kolla/configuration.yml
kolla_external_vip_address: "203.0.113.100"
kolla_external_fqdn: "cloud.example.com"

This IP address is not assigned to any single host permanently. It floats between the three control nodes via Keepalived running inside Docker containers managed by Kolla-Ansible.

How the VIP Works

The flow is:

1. Keepalived runs on all three control nodes, communicating via VRRP
2. One node is elected master — it owns the VIP (203.0.113.100) on the kolla_external_vip_interface
3. HAProxy on the master node listens on the VIP and load-balances API requests across all healthy control nodes on their real IPs
4. If the master fails, a backup node takes over the VIP within seconds (typically 2–3 VRRP advertisement intervals)

Keepalived Configuration (Kolla-managed)

You do not configure Keepalived directly — Kolla-Ansible generates the configuration from variables. The relevant parameters for fine-tuning are:

# environments/kolla/configuration.yml
keepalived_virtual_router_id: 51 # Eindeutig pro VLAN (1-255)
kolla_keepalived_vrrp_priority: 100 # Höher = höhere Wahrscheinlichkeit als Master
kolla_external_vip_interface: "bond0.20" # Interface, auf dem die VIP liegt
kolla_external_vip_address: "203.0.113.100"

The generated Keepalived config on each control node looks like:

vrrp_instance kolla_internal {
  interface bond0.20
  virtual_router_id 51
  priority 100        # (101 auf bevorzugtem Master, 100 auf Backups)
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass kolla
  }
  virtual_ipaddress {
    203.0.113.100/24 dev bond0.20
  }
}

VIP-fähige Dienste

Alle diese OpenStack-Dienste werden über dieselbe VIP erreicht. HAProxy routet diese über den Port:

Anycast VIPs mit dem OVN Network Agent

Zusätzlich zur von Kolla verwalteten VIP können OSISM-Deployments Anycast VIPs für den OVN Network Agent verwenden. Der ovn-network-agent überwacht OVN-Datenbanken und synchronisiert Floating-IP-Routen. Optional kann er diese Routen über Anycast VIPs auf Compute- oder Network-Nodes ankündigen, was Folgendes ermöglicht:

• Active-Active Floating-IP-Forwarding (kein Single Point of Failure)
• Direct Server Return (DSR) für traffic-intensive Workloads
• Gatewaylose Provider-Netzwerke, bei denen Instanzen Provider-IPs direkt zugewiesen bekommen

Dies wird pro Node konfiguriert:

ovn_network_agent:
  anycast_vip: "203.0.113.200/32"
  anycast_interface: "lo"

Netzwerktrennung in der Praxis

Physische Topologie

Ein minimal lebensfähiger Produktions-OSISM-Cluster verwendet:

• 3 Control-Nodes — API-Dienste, Datenbank (Galera), Message Queue (RabbitMQ), Keepalived + HAProxy
• 3 Compute-Nodes — Nova, OVN Controller, Ceph Client
• 3 Storage-Nodes — Ceph MON + OSD (optional: kolloziert auf Compute-Nodes)

Alle Nodes verbinden sich mit:

VLAN-Mapping

Konfiguration der Trennung im Configuration Repository

Das Netzwerk-Layout wird in den Group Variables des Inventars definiert:

# inventory/group_vars/generic/network.yml
network_type: netplan
network_ethernets:
  bond0:
    mtu: 1500
    interfaces: [enp1s0f0, enp1s0f1]
    parameters:
      mode: 802.3ad
      lacp-rate: fast
network_vlans:
  management:
    id: 10
    link: bond0
    addresses:
      - "10.1.10.{{ node_suffix }}/24"
    gateway4: "10.1.10.1"
  api:
    id: 20
    link: bond0
    addresses:
      - "10.1.20.{{ node_suffix }}/24"
  migration:
    id: 30
    link: bond0
    addresses:
      - "10.1.30.{{ node_suffix }}/24"

Das node_suffix wird aus dem letzten Oktett der BMC-IP-Adresse abgeleitet, wodurch jeder Host in jedem VLAN eine vorhersagbare IP erhält, ohne dass eine manuelle Zuweisung erforderlich ist.

Netzwerkfluss beim Multi-Node-Deployment

Das Verständnis des Netzwerkpfads während des initialen Deployments hilft bei der Fehlerbehebung von Konnektivitätsproblemen.

Phase 1: Seed-Node Provisioning

Der Seed-Node betreibt DHCP, TFTP, PXE/iPXE sowie eine lokale APT- und Container-Registry:

Der Zielknoten erhält eine IP im Management-VLAN vom DHCP des Seeds.

Phase 2: Manager Deployment

Sobald der Manager-Knoten online ist, übernimmt er die Orchestrierung. Der Seed wird nach dieser Phase nicht mehr benötigt.

Phase 3: Service Deployment

Nachdem das Networking konfiguriert ist, werden die Services entsprechend ihrer Rolle bereitgestellt:

# On the Manager node:
osism apply openvswitch -l control1,control2,control3
osism apply ovn -l control1,control2,control3
osism apply neutron -l control1,control2,control3
osism apply nova -l compute1,compute2,compute3
osism apply ceph -l storage1,storage2,storage3

Phase 4: VIP Activation

Nachdem alle Services laufen, installiert Kolla-Ansible Keepalived und HAProxy:

osism apply kolla -l control1,control2,control3

Die VIP erscheint auf dem gewählten Master. Überprüfen Sie dies mit:

# On the master controller
ip addr show bond0.20 | grep 203.0.113.100

# From any management host
curl -k https://203.0.113.100:5000/v3

OVN/OVS Software-Defined Networking

OSISM verwendet OVN (Open Virtual Network) als SDN-Controller, mit Open vSwitch auf jedem Hypervisor.

OVN-Komponenten

Bridge-Architektur

Jeder Hypervisor (Compute- oder Network-Knoten) verfügt über:

• br-int: Integration Bridge — hier verbinden sich alle VM-Ports, Router-Ports und Tunnel-Endpunkte
• br-ex: External Bridge — wird für Provider-Netzwerke auf neutron_external_interface gemappt
• br-add: Zusätzliche External Bridge für ein zweites physisches Provider-Netzwerk

Konfiguration von OVN in OSISM

# environments/kolla/configuration.yml
neutron_plugin_type: "ovn"
ovn_ovs_bridge_mappings: "physnet1:br-ex,physnet2:br-add"
neutron_bridge_name: "br-ex,br-add"
network_workload_interface: "vlan101,"

Der Parameter network_workload_interface verbindet OVS-Bridges mit physischen Interfaces. Das kommagetrennte Format mappt die Bridge-Namen positionsabhängig: vlan101 mappt auf br-ex, ein leerer Wert mappt auf br-add.

Externe Netzwerkkonfiguration

Erstellen eines externen (Provider-)Netzwerks, das Mandanten für Floating-IPs nutzen können:

# environments/openstack/configuration.yml
network_external_name: "public"
network_external_provider_network_type: "flat"
network_external_provider_physical_network: "physnet1"
network_external_cidr: "203.0.113.0/24"
network_external_gateway_ip: "203.0.113.1"
network_external_allocation_pool_start: "203.0.113.100"
network_external_allocation_pool_end: "203.0.113.200"
network_external_dns_nameservers:
  - "8.8.8.8"
  - "9.9.9.9"

Anwenden:

osism apply network-external

Dies erstellt ein Neutron-Netzwerk namens public mit einem Flat- (untagged) Provider-Segment auf physnet1, das für alle Projekte verfügbar ist.

Für VLAN-basierte Provider-Netzwerke verwenden Sie provider_network_type: "vlan" und setzen provider_segmentation_id auf die gewünschte VLAN-ID. Für Geneve-Mandantennetzwerke (der Standard in OVN) ist keine explizite Erstellung erforderlich – Neutron erstellt diese bei Bedarf.

Best Practices

Immer 3 Control Nodes verwenden

Keepalived VRRP benötigt mindestens zwei Knoten für das Failover, aber drei Knoten gewährleisten ein echtes Quorum. Bei zwei Knoten kann ein Split-Brain-Szenario (Netzwerkpartitionierung) dazu führen, dass beide Knoten die VIP beanspruchen. Bei drei Knoten erfordert auch der RAFT-Konsens, der von OVN-Datenbanken und Galera verwendet wird, eine Mehrheit (2 von 3).

Speicher-Traffic trennen

Ceph reagiert empfindlich auf Latenz und Paketverlust. Platzieren Sie die Ceph-Replikation immer in einem dedizierten VLAN mit:

• Jumbo Frames (MTU 9000) auf allen Storage-Schnittstellen
• Separaten physischen NICs oder mindestens einem dedizierten VLAN mit QoS-Priorität
• 25 Gbit oder höher für All-Flash-Cluster im Produktivbetrieb

MTU-Konsistenz

Der gesamte Datenpfad muss dieselbe MTU unterstützen. Wenn Sie Jumbo Frames (9000) im Storage-Netzwerk verwenden, stellen Sie sicher, dass alle Switches, Router und NICs in diesem Pfad für MTU 9000 konfiguriert sind. Nicht übereinstimmende MTUs verursachen Paketverluste, die extrem schwierig zu debuggen sind (stille Verluste bei fragmentierten Paketen).

DNS für VIPs

Erstellen Sie vor dem Deployment DNS A/AAAA-Records, die auf jede VIP verweisen:

OSISM und Kolla-Ansible generieren während des Deployments selbstsignierte Zertifikate für diese FQDNs.

Sicherheitszonen

Wenden Sie ACLs an den Leaf-Switches an, um den Inter-VLAN-Traffic einzuschränken:

Überwachung der VIP-Health

Keepalived bietet einen track_script-Mechanismus, mit dem der Zustand von HAProxy überwacht werden kann. Wenn HAProxy auf dem Master ausfällt, sollte Keepalived das Failover auslösen:

vrrp_script chk_haproxy {
  script "/usr/bin/pgrep haproxy"
  interval 2
  fall 2
}

Dies wird automatisch durch Kolla-Ansible konfiguriert. Sie können den HAProxy-Status auf jedem Control Node überprüfen:

docker exec -it haproxy haproxy -f /etc/haproxy/haproxy.cfg -c
docker exec -it keepalived keepalived --dump-conf

Von CIAB zu Production

Der Cloud in a Box-Guide zeigt, wie man eine Single-Node-SCS-Umgebung in etwa zwei Stunden bereitstellt. Dieses Setup verwendet intern VLAN 101 und Masquerading für den externen Zugriff – das Networking ist auf Null-Konfiguration vereinfacht.

Der Übergang zum Produktivbetrieb bedeutet:

1. Trennung der Netzwerkzonen – Management, API, Storage, Tunnel und externer Traffic erhalten jeweils ein eigenes VLAN und (idealerweise) eigene physische Schnittstellen.
2. Einführung von VIPs – Eine einzelne Keepalived-VIP vor HAProxy bietet API-Hochverfügbarkeit über 3 Control Nodes hinweg.
3. Konfiguration von OVN – Die SDN-Schicht verbindet Compute-Nodes über Geneve-Tunnel und bildet Provider-Netzwerke über OVS-Bridges ab.
4. Ceph-Networking – Storage-Nodes benötigen ein dediziertes Hochgeschwindigkeitsnetzwerk mit Jumbo Frames.

Die hier beschriebene Netzwerkarchitektur ist das Fundament, das SCS zu einer produktionsreifen, souveränen Cloud-Plattform macht. Jeder API-Aufruf, jede virtuelle Maschine und jede Storage-Operation fließt durch diese Netzwerkzonen – sie korrekt zu konfigurieren, ist der Unterschied zwischen einer Cloud, die funktioniert, und einer Cloud, die zuverlässig funktioniert.

Links

• OSISM Documentation — Getting Started
• OSISM Concepts — Architecture Overview
• OSISM Bill of Materials — Hardware Recommendations
• OSISM Deploy Guide — Network Configuration
• OSISM Configuration Guide — OpenStack
• OSISM Configuration Guide — Network
• OSISM Cloud in a Box
• OSISM OVN Network Agent
• SCS Project Homepage
• CIAB Guide — Single-Node SCS Deployment Please provide the text you would like me to translate.