Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Was digitale Souveränität bedeutet und wie Unternehmen und Entwickler ihre Infrastruktur, Daten und AI-Systeme unabhängig gestalten können
Der Sovereign Cloud Stack (SCS) ist Europas Open-Source-Framework für Cloud-Infrastrukturen – eine standardskonforme Plattform, die digitale Souveränität in die Praxis umsetzt. Dieser Leitfaden erklärt, was SCS ist und wie Sie Ihre eigene Cloud in a Box (CIAB) bereitstellen können – eine Single-Node-OpenStack+Kubernetes-Umgebung, die in etwa zwei Stunden mit nahezu vollständiger Automatisierung installiert wird.
SCS ist ein Projekt der Open Source Business Alliance (OSB Alliance), gefördert durch das Bundesministerium für Wirtschaft und Klimaschutz (BMWK). Es besitzt den Status eines Gaia-X Leuchtturmprojekts – eine Anerkennung dafür, dass SCS die Gaia-X-Vision einer föderierten, souveränen Dateninfrastruktur vorantreibt – und ist als Kandidat für ein European Digital Infrastructure Consortium (EDIC) anerkannt.
Das Projekt adressiert ein Kernproblem moderner Cloud-Infrastrukturen: die Dominanz nicht-europäischer Cloud-Anbieter und die Lock-in-Risiken, die mit proprietären APIs verbunden sind. SCS löst dies durch die Definition von drei Säulen:
Jeder Anbieter, der eine standardskonforme SCS-Umgebung betreibt, kann interoperable Cloud-Services anbieten. Dies ist das Infrastruktur-Äquivalent zu Container-Images, die auf OCI-Standards basieren – Sie können Workloads zwischen SCS-konformen Anbietern verschieben, ohne plattformspezifische Anpassungen am Code vornehmen zu müssen.
Der SCS-Software-Stack folgt einer Schichtenarchitektur, die von der Bare-Metal-Hardware bis zur benutzerorientierten Zugriffsschicht reicht:
| Schicht | Komponenten | Verantwortung |
|---|---|---|
| Hardware & OS | x86_64 Server, Ubuntu 24.04 LTS | Physische Basis, Networking (DHCP), Storage (SATA/NVMe) |
| OSISM | Ansible Playbooks, containerisierte Control Plane | Deployment, Lifecycle-Management, Rolling Upgrades, Backup/Restore |
| OpenStack | Nova, Neutron, Cinder, Glance, Keystone, Designate | Virtuelle Compute-Ressourcen, Networking, Block Storage, Image Registry, Identity, DNS |
| Ceph | RADOS, RBD (Block), RGW (S3 Object), CephFS | Distribuierter Speicher – vereinheitlichter Block-, Object- und File-Storage |
| Kubernetes | Gardener, Cluster API, Calico/OVN | Container-Orchestrierung und Cluster-Lifecycle |
| SCS Standards | SCS-OpenStack, SCS-K8s, IAM (Keycloak) | Compliance-Verifizierung, Identity Federation, Audit |
| Access | Horizon Dashboard, OpenStack CLI, REST API, Terraform | Benutzeroberflächen für das Cloud-Management |
OSISM ist das Deployment- und Operations-Framework, das den gesamten Lebenszyklus des SCS-Stacks verwaltet:
Das R9-Release (September 2025) führte OpenStack Epoxy (2025.1) und Kubernetes 1.33 ein.
Cloud in a Box ist ein Single-Node-OSISM-Deployment, das für Teams entwickelt wurde, die eine vollständige SCS-Umgebung benötigen, ohne die Komplexität eines Multi-Node-Clusters bewältigen zu müssen.
| Typ | Komponenten | Ideal für |
|---|---|---|
| sandbox | Vollständiges OpenStack + Ceph + K8s | Komplette Cloud-Evaluierung auf einem einzelnen Node |
| edge | OpenStack (reduziertes Ceph), zentrales Logging | Remote-Standorte mit geringem Speicherbedarf |
| kubernetes | Nur K8s, kein OpenStack | Teams, die sich ausschließlich auf Container-Orchestrierung konzentrieren |
Die Sandbox-Variante ist der häufigste Startpunkt und steht im Mittelpunkt dieses Leitfadens.
| Komponente | Minimum | Empfohlen |
|---|---|---|
| CPU | 8 Kerne (x86_64) | 16+ Kerne für parallele Workloads |
| RAM | 64 GB | 128 GB (Ceph benötigt signifikant viel Speicher) |
| Boot-Storage | 500 GB SATA SSD | 2+ TB NVMe für VM- und Ceph-OSD-Kapazität |
| Netzwerk | 1 Gbit | 10 Gbit für die Performance der Storage-Replikation |
Ein Supermicro-Server mit 128 GB RAM, einer 2 TB NVMe-Festplatte und dualen 1 Gbit NICs ist ein typisches Community-Lab-Setup. Das CIAB-ISO bietet separate Builds für SATA- und NVMe-Boot-Laufwerke – die Auswahl der falschen Variante verhindert, dass der automatisierte Installer Ihre Festplatte erkennt.
Die CIAB-Installation erfolgt in fünf Schritten. Die gesamte Zeit beträgt etwa zwei Stunden, wobei nur etwa fünf Minuten aktive Arbeit erforderlich sind.
Laden Sie das entsprechende ISO aus der OSISM CIAB-Dokumentation herunter:
| ISO-Datei | Boot-Storage | Anwendungsfall |
|---|---|---|
ubuntu-autoinstall-cloud-in-a-box-1.iso | SATA/SAS (erstes Block-Device /dev/sda) | Traditionelle Server mit SATA- verbundenen Laufwerken |
ubuntu-autoinstall-cloud-in-a-box-2.iso | NVMe (erstes Block-Device /dev/nvme0n1) | Moderne Server mit NVMe M.2 oder U.2 Laufwerken |
Jedes ISO (ca. 8–10 GB) enthält ein Ubuntu 24.04 Basissystem, das OSISM-Deployment-Framework und alle erforderlichen Container-Images. Die CIAB-Installationsskripte sind ebenfalls im OSISM CIAB-Repository zur Einsicht oder für benutzerdefinierte Deployments verfügbar.
Sie benötigen einen USB-Stick mit mindestens 16 GB Kapazität. Schreiben Sie das ISO unter Linux mit dd oder nutzen Sie balenaEtcher/Rufus unter Windows:
lsblk
# ⚠️ This erases ALL data on /dev/sdX
sudo dd if=ciab-sandbox-nvme.iso of=/dev/sdX bs=4M status=progress conv=fsync
Das Flag conv=fsync stellt sicher, dass der Schreibpuffer geleert wird, bevor der Befehl beendet wird, um unvollständige Schreibvorgänge zu vermeiden.
Nach dem ersten Neustart beginnt das System mit dem automatisierten OSISM-Deployment. Dies ist die einzige längere Wartezeit – etwa 90–120 Minuten, abhängig von der Hardware und der Netzwerkgeschwindigkeit.
Voraussetzungen vor Beginn des Deployments:
Der Deployment-Prozess:
/home/dragon/ geschriebenSie können den Fortschritt über die lokale Konsole oder per SSH überwachen:
# Watch real-time deployment logs
journalctl -fu osism-deployment -n 100
# Check OSISM container status
osism container status
# View Ansible playbook output
tail -f /opt/osism/ansible.log
Sobald das Deployment abgeschlossen ist, haben Sie zwei Zugriffsmöglichkeiten:
Horizon-Dashboard (Web-UI):
http://ciab.fritz.box:8080
Oder verwenden Sie die IP-Adresse des Servers auf Port 8080. Der Standard-SSH-Benutzer ist dragon mit dem Passwort password – ändern Sie diese sofort bei jedem Deployment, das mit dem Internet verbunden ist.
OpenStack-CLI (via WireGuard-VPN): Das CIAB richtet einen WireGuard-VPN-Endpunkt für den sicheren API-Zugriff ein:
# Install WireGuard on your client
sudo apt install wireguard
# Import the CIAB client configuration
sudo wg-quick up /path/to/ciab-client.conf
# Authenticate (uses CIAB's built-in clouds.yaml)
export OS_CLOUD=test
# Verify the cloud is operational
openstack compute service list
openstack network agent list
openstack image list
Die Umgebungsvariable OS_CLOUD=test wählt den vorkonfigurierten clouds.yaml-Abschnitt des CIAB aus, der auf den lokalen Keystone-Endpunkt mit Administrator-Credentials verweist.
Wenn die Cloud läuft, deployen Sie Ihre erste virtuelle Maschine:
# Create a network and subnet
openstack network create demo-net
openstack subnet create --network demo-net \
--subnet-range 10.1.0.0/24 \
--dns-nameserver 8.8.8.8 demo-subnet
# Create a router and connect to the external network
openstack router create demo-router
openstack router add subnet demo-router demo-subnet
openstack router set --external-gateway public demo-router
# Create a security group allowing SSH
openstack security group create demo-ssh
openstack security group rule create --proto tcp --dst-port 22 demo-ssh
# Boot a test VM
openstack server create \
--image ubuntu-24.04 \
--flavor m1.small \
--network demo-net \
--security-group demo-ssh \
--key-name my-key \
demo-vm
# Assign a floating IP
openstack floating ip create public
openstack server add floating ip demo-vm <IP>
# SSH into the instance
ssh ubuntu@<FLOATING_IP>
Binden Sie persistenten Block-Storage an:
openstack volume create --size 20 demo-volume
openstack server add volume demo-vm demo-volume
# Inside the VM:
# sudo mkfs.ext4 /dev/vdb
# sudo mount /dev/vdb /mnt/data
SCS folgt einem vorhersagbaren halbjährlichen Release-Zyklus:
| Release | Datum | OSISM | OpenStack | Kubernetes | Highlights |
|---|---|---|---|---|---|
| R8 | März 2025 | 9.x | Zed | 1.30 | Initiale CIAB-Stabilisierung |
| R9 | September 2025 | 10.x | Epoxy | 1.33 | K8s 1.33, verbessertes CIAB |
| R10 | März 2026 | 11.x | Next | 1.35+ | TBD |
Dieser Zyklus orientiert sich an den OpenStack-Upstream-Releases (Frühjahr/Herbst), sodass Betreiber Upgrades nach einem festen Zeitplan planen können, ähnlich wie bei Ubuntu LTS.
| Szenario | CIAB | Full Cluster |
|---|---|---|
| Dev/Test-Umgebung | ✅ Ideal | ❌ Overkill |
| Edge/Pop-up Cloud | ✅ Perfekt | ❌ Zu komplex |
| Trainings/Workshops | ✅ Großartig | ⚠️ Möglich |
| Produktions-Workloads | ❌ Kein HA | ✅ Erforderlich |
| Multi-tenant SaaS | ❌ Keine Isolation | ✅ Vollständiges Multi-Node |
| Hochverfügbarkeit | ❌ Single Point of Failure | ✅ HA mit Ceph-Replikation |
CIAB ist ein Single-Node-Setup ohne integrierte Redundanz. Für die Produktion sollte das vollständige OSISM-Cluster-Deployment mit mindestens drei Control-Nodes und drei Ceph-Nodes verwendet werden.
SCS verfügt über eine aktive Community, in der Sie Hilfe erhalten können:
#scs:matrix.org — Community-Diskussionen und Echtzeit-SupportEin CIAB-fähiger Server kostet je nach Konfiguration etwa 2.000–5.000 €:
| Komponente | Budget | Empfohlen |
|---|---|---|
| Server | Supermicro SYS-510 (800 €) | Supermicro SYS-110 (1.500 €) |
| RAM | 64 GB (400 €) | 128 GB (800 €) |
| Storage | 1 TB NVMe (150 €) | 2 TB NVMe (300 €) |
| Gesamt | ~2.000 € | ~3.500–5.000 € |
Dies sind einmalige Hardwarekosten. Es fallen keine Lizenzgebühren an – der gesamte SCS-Stack ist Open Source.
SCS folgt einem halbjährlichen Release-Zyklus. CIAB-Upgrades folgen dem Standard-Upgrade-Pfad von OSISM:
# Update OSISM to the latest release
osism update --release R10
# Run upgrade playbooks
osism apply upgrade
# Verify all services
site-services status
Das Cloud in a Box des Sovereign Cloud Stack bietet eine produktionsreife OpenStack- und Kubernetes-Umgebung auf einem einzigen Server, die in weniger als zwei Stunden mit minimalem Aufwand durch den Betreiber bereitgestellt werden kann. Es dient als Einstiegspunkt in die europäische souveräne Cloud-Infrastruktur und als praktisches Werkzeug zur Evaluierung von SCS als Plattform.
Workloads, die auf einem CIAB entwickelt und getestet wurden, laufen ohne Modifikationen bei jedem SCS-konformen Provider – und machen so die souveräne Cloud-Infrastruktur von einem Konzept zu einer einsatzbereiten Realität.
Links: