OSISM: Der Open-Source-Infrastructure-Manager für souveräne Clouds

CephFS: From Zero to Hero — Das verteilte Dateisystem, End-to-End

CephFS im Produktiveinsatz: MDS-Architektur, Pool-Design, Quotas, Snapshots, Subvolume-Gruppen, Multi-MDS-Skalierung, Kubernetes CSI und Betrieb.

OSISM (Open Source Infrastructure as a Service Manager) ist die Deployment- und Operations-Plattform hinter dem Sovereign Cloud Stack (SCS) — Europas Antwort auf den Lock-in-Effekt von Hyperscalern. Es orchestriert den vollständigen Lebenszyklus einer Private Cloud, die auf OpenStack, Ceph und Kubernetes basiert, und wird über eine einzige, Ansible-gesteuerte Control Plane verwaltet. OSISM 10, veröffentlicht im März 2026, bietet Multi-Version-Support für sowohl OpenStack (2025.1 und 2025.2) als auch Ceph, wodurch der Release-Zyklus von OSISM zum ersten Mal von den Versionen der einzelnen Komponenten entkoppelt wird.

Dieser Artikel beschreibt, was OSISM ist, wie seine Komponenten zusammenpassen und die schrittweise Installationsroutine vom Bare-Metal-Server bis zum laufenden Cloud Pod.

Das Cloud Pod Modell

Jedes OSISM-Deployment wird als Cloud Pod bezeichnet — eine eigenständige Private-Cloud-Umgebung mit eigenen Compute-, Storage-, Networking- und Management-Ebenen. Die Architektur ist geschichtet aufgebaut:

Der Cloud Pod ist kein Hypervisor-Produkt. Er ist ein Integrations-Framework, das bewährte Open-Source-Projekte nimmt und sie zu einer kohärenten, prüfbaren und upgradefähigen Plattform verknüpft. Jede Konfigurationsänderung erfolgt über ein einziges Git-Repository — es gibt keine "Click-Ops"-Konsole für den Operator.

Kernkomponenten

OSISM Manager

Der Manager ist der zentrale Control Node und der einzige Einstiegspunkt für den Operator. Jede Aufgabe — das Deployment von OpenStack-Services, das Upgrade von Ceph, das Bootstrapping von Nodes, das Ausführen von Health-Checks — wird über ihn via osism CLI gesteuert.

Intern läuft der Manager als Set von Containern, die auf dem Manager-Node durch Docker Compose orchestriert werden. Die Architektur besteht aus:

osismclient / python-osism — Der Container, der die osism CLI bereitstellt. Alle Interaktionen des Operators erfolgen über diesen Befehl. Die zugrunde liegende Python-Bibliothek ist python-osism, welche zudem eine programmatische API exponiert.

Celery + Redis Job-Queues — Der Manager nutzt Celery, unterstützt durch eine Redis-Instanz (manager-redis), um Ansible-Tasks asynchron zu verteilen. Dieselbe Redis-Instanz dient gleichzeitig als Ansible-Facts-Cache, sodass alle Ansible-Container die gesammelten Host-Facts teilen. Fünf dedizierte Queues laufen parallel:

Parallele Queues bedeuten, dass ein OpenStack-Deployment und ein Ceph-Rolling-Upgrade gleichzeitig laufen können, ohne sich gegenseitig zu blockieren.

Ansible-Container — Jeder Workload-Typ hat sein eigenes Container-Image, das den relevanten Ansible-Code und die Abhängigkeiten enthält:

• kolla-ansible — OpenStack Service Lifecycle (container-image-kolla-ansible)
• ceph-ansible — Ceph Deployment und Day-2-Management (container-image-ceph-ansible)
• osism-ansible — Node-Bootstrapping, Netzwerkkonfiguration, unterstützende Services (container-image-osism-ansible)
• osism-kubernetes — Kubernetes Cluster Provisioning und Lifecycle (osism-kubernetes)

inventory-reconciler — Der einzige Container, der in das gemeinsame /ansible/inventory Volume schreibt. Er führt das Konfigurations-Repository mit NetBox-Daten (falls verwendet) zu einem einzigen, konsolidierten Inventory zusammen. Alle Ansible-Container mounten dieses Volume schreibgeschützt, wodurch garantiert wird, dass jeder Workload dieselbe konsistente Sicht auf Hosts und Variablen hat.

Konfigurations-Volume (/opt/configuration) — Wird schreibgeschützt in jeden Ansible-Container gemountet. Dies ist das Git-Konfigurations-Repository — die "Single Source of Truth" für Inventory, Gruppenvariablen, Host-Variablen und Secrets.

OSISM MetalBox

Die MetalBox ist ein Hardware-Provisioning-Toolkit, das auf OpenStack Ironic basiert. Sie provisioniert Bare-Metal-Server und Switches und bündelt alle Komponenten, die für das Offline-Bootstrapping eines Cloud Pods benötigt werden:

Die MetalBox übernimmt zudem das SONiC ZTP (Zero Touch Provisioning) für Netzwerk-Switches. Switches mit ONIE booten in den Installationsmodus, finden die MetalBox via DHCP, laden ihr spezifisches SONiC-Image und die Konfiguration, installieren beides und booten in ein vollständig konfiguriertes Netzwerk-Betriebssystem neu — ohne dass eine Interaktion über die Konsole erforderlich ist.

Konfigurations-Repository

Das Git-Konfigurations-Repository ist die Single Source of Truth für die gesamte Umgebung. Es enthält:

• Inventory-Definitionen (Hosts, Gruppen, Host-Variablen)
• Kolla/OpenStack Konfigurations-Overrides
• Ceph Konfigurationsparameter
• Netzwerktopologie (für die NetBox-Integration)
• Secrets (verschlüsselt mit Ansible Vault)
• TLS-Zertifikate und NTP/DNS-Serverlisten

Das Repository wird aus einem Cookiecutter-Template auf einer lokalen Workstation oder einer dedizierten VM (dem sogenannten Seed Node) erstellt und anschließend auf den Manager übertragen. Nach dem initialen Deployment erfolgen Updates über osism apply configuration.

NetBox

NetBox stellt die DCIM-Schicht (Data Centre Infrastructure Management) bereit — Hardware-Inventory, IP-Adressmanagement (IPAM), Verkabelung, Rack-Positionen, VLANs und benutzerdefinierte Felder. Die lokale NetBox-Instanz wird aus dem Konfigurations-Repository befüllt und dient als autoritative Datenquelle sowohl für den Manager als auch für die MetalBox.

Storage: Ceph

Ceph stellt das vereinheitlichte Storage-Backend bereit — Block Storage (RBD) für Cinder, Object Storage (RGW) mit S3-kompatiblen APIs und File Storage (CephFS). In OSISM 10 ist ceph-ansible zugunsten von cephadm für neue Deployments veraltet; bestehende Cluster können via cephadm adopt in-place migriert werden.

Networking: SONiC + OVN

Die Netzwerkebene nutzt SONiC (Software for Open Networking in the Cloud) auf Leaf-Spine-Switches mit BGP-unnumbered host-based Routing. Traditionelle Konzepte wie MLAG, Spanning Tree und Bonding werden durch BFD, BGP und ECMP ersetzt. Das virtuelle Networking innerhalb des Pods wird durch OVN (Open Virtual Network) gehandhabt, welches Overlay-Netzwerke zur Mandantentrennung bereitstellt.

Die sechs Schritte der Installationsroutine

OSISM folgt einem strikten sequenziellen Deployment-Prozess. Jeder Schritt baut auf dem vorherigen auf, und der Seed Node wird verworfen, sobald der Manager betriebsbereit ist.

Schritt 1: Erstellen des Konfigurations-Repositorys

Der Ausgangspunkt ist kein Server — es ist ein Git-Repository. Erstellen Sie auf einer lokalen Workstation (dem Seed Node) das Konfigurations-Repository aus dem Cookiecutter-Template:

pip install cookiecutter
cookiecutter https://github.com/osism/cookiecutter-configuration.git
cd output/configuration
git init && git add -A && git commit -m "init: configuration repository"

Bevor das Repository verwendbar ist, müssen sechs Dinge angepasst werden:

1. TLS-Zertifikate — Platzieren Sie Ihre CA- und Server-Zertifikate in environments/manager/files/certificates/
2. NTP-Server — bearbeiten environments/manager/configuration.yml
3. DNS-Server — bearbeiten environments/manager/configuration.yml
4. Globales Inventory — ersetzen Sie das Beispiel node01 durch Ihre tatsächlichen Hostnamen in environments/manager/hosts
5. Manager-Inventory — fügen Sie den Manager-Knoten der Gruppe manager in environments/manager/hosts hinzu
6. Secrets — das Verzeichnis secrets/ enthält den SSH-Deploy-Key für das Repository

Pushen Sie das Repository zu GitHub, GitLab oder Ihrem internen Git-Server.

Schritt 2: Vorbereitung des Seed-Knotens

Der Seed-Knoten ist eine temporäre VM (oder Ihre Workstation), die das initiale Bootstrap des Managers durchführt. Er benötigt Docker oder Podman, SSH-Zugriff auf den zukünftigen Manager-Knoten und einen Klon des Konfigurations-Repositorys.

cd environments/manager

Alle nachfolgenden Befehle werden aus diesem Verzeichnis ausgeführt. Das Skript run.sh erkennt die Container-Engine automatisch und pullt den registry.osism.tech/osism/seed:latest Container, sofern verfügbar.

Schritt 3: Deployment des Manager-Knotens

Dies ist der aufwendigste Schritt, der in fünf Teilschritte unterteilt ist:

3a — Operator-Benutzer erstellen

Der Operator-Benutzer dragon wird auf jedem Knoten erstellt. Alle OSISM-Container laufen unter diesem Benutzer, und Ansible nutzt ihn für den SSH-Zugriff.

ANSIBLE_BECOME_ASK_PASS=True \
ANSIBLE_ASK_VAULT_PASS=True \
ANSIBLE_ASK_PASS=True \
ANSIBLE_USER=osism \
./run.sh operator

ANSIBLE_USER ist der initiale Provisioning-Benutzer (z. B. osism im Knoten-Image oder ubuntu bei manuellen Installationen). Nach diesem Schritt werden für alle weiteren Befehle dragon verwendet.

3b — Netzwerkkonfiguration anwenden

./run.sh network

Sichern Sie bestehende Netzwerkkonfigurationen, bevor Sie dies ausführen. Die Netzwerk-Role wendet die Konfiguration aus environments/manager/configuration.yml an. Danach ist ein Neustart erforderlich, um sicherzustellen, dass die Konfiguration nach einem Reboot erhalten bleibt.

3c — Bootstrap des Manager-Knotens

./run.sh bootstrap
./run.sh reboot

Dies installiert Docker, die OSISM-Container-Images und bereitet den Knoten für den Manager-Dienst vor.

3d — Deployment des Manager-Dienstes

./run.sh configuration   # Transfer the config repo
./run.sh traefik         # Optional: reverse proxy
./run.sh netbox          # Optional: DCIM inventory
./run.sh manager         # Deploy the Manager containers

3e — Vault-Passwort setzen

ssh -i id_rsa.operator dragon@YOUR_MANAGER_NODE
osism set vault password

Nach diesem Schritt wird der Seed-Knoten nicht mehr benötigt.

Schritt 4: Provisionierung von Bare-Metal-Knoten

Bei Verwendung der MetalBox werden Bare-Metal-Server über Ironic mittels virtueller Medien und Redfish provisioniert. Der Provisionierungs-Flow:

1. Hardware-Inventory und Verkabelungsdaten werden über das netbox-configuration Repository in NetBox eingetragen
2. Der Manager liest aus NetBox und erstellt Ironic-Knoten
3. Ironic mountet das IPA-Boot-Image über das Out-of-Band-Management-Netzwerk
4. Der ironic-python-agent schreibt das Deploy-Image über das Datennetzwerk auf die Festplatte
5. PXE wird nicht verwendet — es gibt keine DHCP/TFTP-Anforderungen im Datennetzwerk

In Umgebungen ohne MetalBox werden Knoten manuell provisioniert (Ubuntu 24.04 LTS Installation) und dem Inventory des Konfigurations-Repositorys hinzugefügt.

Schritt 5: Bootstrap der Bare-Metal-Knoten

Sobald die Knoten über ein Betriebssystem und Netzwerkzugriff verfügen, bootstrappen Sie diese vom Manager aus:

ssh dragon@YOUR_MANAGER_NODE
osism apply bootstrap
osism apply network
osism reboot

Schritt 6: Deployment der Dienste

Dienste werden in einer strikten Reihenfolge bereitgestellt. Jeder Befehl kann optional zuerst die Container-Images vorab pullen:

osism pull <service-list>
osism apply <service-list>

Die empfohlene Deployment-Reihenfolge:

1. Clustered Infrastructure — HAProxy, MariaDB, RabbitMQ, Redis, Elasticsearch
2. Infrastructure — OpenvSwitch, Memcached, etcd, Kibana
3. Ceph — Monitors, Managers, OSDs, Crash, Client
4. Basic OpenStack — Keystone, Horizon, Placement, Glance, Cinder, Neutron, Nova
5. Extended Services — Heat, Gnocchi, Ceilometer, Barbican, Designate (nach Bedarf)
6. Kubernetes — K3s, Gardener oder Cluster API (nach Bedarf)

Validieren Sie vor dem Deployment die Netzwerkverbindung:

osism validate kolla-connectivity
osism validate ceph-connectivity   # if using Ceph

Cloud in a Box: Der schnelle Weg

Für Evaluation, Entwicklung und Training bietet OSISM Cloud in a Box (CIAB) an – ein Single-Node-Deployment, das eine vollständige Kubernetes-Cloud (oder einen kompletten OpenStack + Ceph + K8s Stack) von einem bootfähigen USB-Image aus installiert.

Mindestanforderungen an die Hardware: 4 Kerne, 32 GB RAM, 1 TB Festplatte (bei /dev/sda oder /dev/nvme0n1), eine Netzwerkkarte (NIC) mit DHCP-Internetzugang.

Automatisierte Installation:

1. Download von ubuntu-autoinstall-cloud-in-a-box-1.iso (oder -2.iso für NVMe)
2. Auf USB flashen mit balenaEtcher oder dd
3. Von USB booten – Ubuntu 24.04 wird installiert, danach fährt das System herunter
4. USB entfernen, Netzwerk verbinden, von Festplatte booten
5. Das Deployment läuft automatisch (~1 Stunde), danach fährt das System erneut herunter
6. Ein letztes Mal booten – Login via SSH als dragon / password

Die CIAB stellt eine WireGuard-VPN-Konfiguration unter /home/dragon/wireguard-client.conf bereit, um einen sicheren Zugriff auf alle Web-Interfaces (Horizon, Grafana, NetBox, Netdata, ARA, Ceph Dashboard) zu ermöglichen.

Zentrale Design-Entscheidungen

GitOps standardmäßig. Jede Konfigurationsänderung ist ein Git-Commit. Der Manager liest aus dem gemounteten Repository, nicht aus Ad-hoc-Konsolenbefehlen. Dies macht Audits, Rollbacks und Disaster Recovery unkompliziert – Repository klonen, den Manager darauf ausrichten und erneut anwenden.

Containerisiertes Ansible. Anstatt Ansible direkt auf dem Manager-Node auszuführen, läuft jeder Workload-Typ in seinem eigenen Container mit fixierten Versionen. Der Befehl osism apply steuert über Celery den korrekten Container an. Diese Isolation ermöglicht es, dass kolla-ansible und ceph-ansible gleichzeitig unterschiedliche Ansible-Versionen nutzen können.

Multi-Versions-Support (OSISM 10+). Ein OSISM 10 Deployment kann OpenStack 2025.1 oder 2025.2 sowie Ceph Quincy, Reef oder Squid betreiben. Die Version wird im Konfigurations-Repository ausgewählt und ist nicht an das OSISM-Release gebunden. Dies ist eine signifikante Änderung gegenüber früheren Versionen, bei denen der gesamte Stack an einen einzigen OpenStack-Release-Train gebunden war.

Operator-Benutzermodell. Der Benutzer dragon ist sowohl der SSH-Benutzer für Ansible als auch der Runtime-Benutzer für alle Container. Dies vereinfacht die Berechtigungen – es gibt keine Vermischung von Root- und Non-Root-Kontexten, und das SSH-Schlüsselpaar (id_rsa.operator) bietet konsistenten Zugriff über alle Nodes hinweg.

Weitere Ressourcen

• OSISM Dokumentation
• GitHub Organisation
• Sovereign Cloud Stack (SCS)
• OSISM Release Notes (10.0.0)
• Cloud in a Box Repository