Funktionsweise von Cloud Computing: Hypervisor, SDN und Orchestrierung im Detail

Für Endanwender und viele kaufmännische Entscheider erscheint Cloud Computing oft wie ein abstraktes Versprechen der Digitalwirtschaft. Rechenkapazitäten stehen scheinbar grenzenlos auf Abruf bereit, neue Serverinstanzen starten per API-Aufruf innerhalb weniger Sekunden und Speicherpools dehnen sich elastisch im laufenden Betrieb aus.

Hinter dieser komfortablen Self-Service-Fassade verbirgt sich jedoch kein immaterieller Zauber, sondern ein streng deterministisches Zusammenspiel moderner Systemarchitektur. Hardwaregestützte Prozessor-Virtualisierung, programmierbare Kernel-Netzwerkpfade, mathematische Speicherverteilung und deklarative Steuerungs-Engines greifen auf Bare-Metal-Servern präzise ineinander.

Wer Cloud-Infrastrukturen als CIO oder Chefarchitekt strategisch bewerten, gegen Ausfälle härten und wirtschaftlich betreiben will, darf sich nicht mit Marketing-Metaphern begnügen. Eine fundierte Architektur-Governance erfordert das genaue Verständnis der technischen Wirkungsmechanismen vom physischen Silizium über den Betriebssystem-Kernel bis zur orchestrierten Programmierschnittstelle.

Vom statischen Blech-Silo zur programmierbaren Ressourcen-Fabric

Vor der Etablierung softwaredefinierter Cloud-Architekturen operierten Unternehmensrechenzentren nach dem Prinzip des dedizierten Silo-Hostings. Jede geschäftskritische Applikation, vom ERP-Kern über relationale Datenbanken bis zum Mailserver, erhielt eigene physische Server zugewiesen, die starr mit proprietären Storage-Area-Networks (SAN) und manuell konfigurierten Switches verkabelt waren.

Dieses Betriebsmodell litt unter struktureller Ressourcenverschwendung. Da jedes Blech-System für die theoretische Jahreshöchstlast ausgelegt werden musste, lag die durchschnittliche CPU-Auslastung typischer x86-Server im Jahresmittel bei lediglich fünf bis fünfzehn Prozent, während Strom- und Kühlkapazitäten permanent für ungenutzte Leerlaufzyklen bezahlt wurden.

Gleichzeitig wirkte die physische Bereitstellung als massiver Innovationsbremser. Benötigte eine Fachabteilung neue Test- oder Produktionsumgebungen, erstreckten sich Hardware-Ausschreibung, Lieferung, Rack-Einbau, SAN-Zoning und Firewall-Freischaltung über mehrere Wochen oder Monate, was agile Release-Zyklen technisch unmöglich machte.

Erst die Entkopplung der logischen Ausführungs-, Speicher- und Netzwerkebenen von der darunterliegenden COTS-Hardware (Commercial Off-The-Shelf) löste diese Starre auf. Durch die Bündelung standardisierter Serverknoten in dynamisch teilbare Ressourcenpools steigt die reale Hardwareauslastung auf 70 bis 85 Prozent bei gleichzeitiger Bereitstellung im Sekundentakt.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Dienste im Enterprise-Einsatz sowie zu Cloud-Merkmale im Enterprise-Einsatz.

Schicht 1 (Compute): Typ-1-Hypervisoren, MicroVMs und DPU-Offloading

Das technische Fundament jeder Cloud-Umgebung bildet die Abstraktion von Prozessor, Hauptspeicher und I/O-Bussen durch einen Typ-1-Hypervisor (Bare-Metal-Hypervisor). Im Gegensatz zu Typ-2-Lösungen, die als gewöhnliche Anwendung auf einem Desktop-Wirtssystem laufen, operiert ein Typ-1-Hypervisor wie KVM (Kernel-based Virtual Machine) unmittelbar auf der Hardware-Ebene.

Moderne Serverprozessoren stellen dafür spezielle Befehlssatzerweiterungen bereit, namentlich Intel VT-x und AMD-V. Diese unterteilen die CPU-Privilegien in einen hochprivilegierten VMX-Root-Modus für den Hypervisor und einen Non-Root-Modus für die Gast-Betriebssysteme, sodass unkritische Maschinenbefehle direkt ohne Software-Emulation auf den physischen Rechenkernen ausgeführt werden.

Speichervirtualisierung via EPT/RVI, NUMA-Pinning und KSM

Damit sich mehrere virtuelle Maschinen (VMs) denselben physischen Arbeitsspeicher teilen können, ohne fremde Datenbereiche auszulesen, greift eine zweistufige Adressübersetzung in der Memory Management Unit (MMU). Technologien wie Intel Extended Page Tables (EPT) und AMD Rapid Virtualization Indexing (RVI) übersetzen virtuelle Gast-Adressen direkt in der Hardware in physische Host-Speicheradressen.

Für latenzkritische Datenbanken und Telekommunikations-Workloads kombinieren Cloud-Architekten diese Mechanismen mit striktem NUMA-Pinning (Non-Uniform Memory Access) und HugePages. Dadurch greifen virtuelle Prozessorkerne (vCPUs) ausschließlich auf Speicherriegel zu, die direkt am selben physischen CPU-Sockel angebunden sind, während Kernel Samepage Merging (KSM) identische Speicherseiten zusammenführt.

Von QEMU/KVM zu AWS Nitro, Firecracker und SmartNIC-DPUs

Während klassische KVM-Implementierungen den Prozess QEMU nutzen, um virtuelle Hardware wie Netzwerkkarten, Storage-Controller und serielle Schnittstellen im User-Space des Host-Systems zu emulieren, gehen moderne Hyperscaler und Enterprise-Clouds noch einen Schritt weiter. Bei Architekturen wie dem AWS Nitro System oder dedizierten SmartNICs (Data Processing Units, DPUs) wird die gesamte Geräte-Emulation auf eigene ASIC-Koprozessoren ausgelagert.

Ergänzend ermöglicht Single Root I/O Virtualization (SR-IOV) in Verbindung mit der Input-Output Memory Management Unit (IOMMU / Intel VT-d), dass sich eine physische 100-GbE-Netzwerkkarte oder ein NVMe-Laufwerk gegenüber dem PCIe-Bus als dutzende unabhängige Virtual Functions (VFs) präsentiert. Die Gast-VM kommuniziert per Direct Memory Access (DMA) ohne Hypervisor-Overhead direkt mit der Hardware und erreicht bis zu 99 Prozent der Bare-Metal-Leistung.

Für hochdynamische Serverless-Funktionen und Container-Workloads kommen zudem leichtgewichtige MicroVMs wie Firecracker oder Cloud Hypervisor zum Einsatz. Sie reduzieren den Gerätemodell-Overhead auf ein absolutes Minimum aus VirtIO-Netzwerk und VirtIO-Blockgerät, starten in unter 125 Millisekunden und verbinden die harte kryptografische Kernel-Isolation einer VM mit der Kompaktheit von Linux-Containern (cgroups und Namespaces).

Schicht 2 (Networking): Software-Defined Networking mit EVPN-VXLAN und eBPF

Sobald tausende virtuelle Maschinen und Container innerhalb von Sekunden über wechselnde Serverknoten hinweg starten oder per Live-Migration verschoben werden, stoßen klassische Layer-2-Netzwerke an ihre Grenzen. Das traditionelle IEEE-802.1Q-VLAN-Protokoll unterstützt aufgrund seines 12-Bit-Headers maximal 4.094 Segmente und erzwingt bei Topologieänderungen langsame Spanning-Tree-Neuberechnungen.

Moderne Cloud-Infrastrukturen trennen daher das physische Transportnetz (Underlay) konsequent vom logischen Mandantennetz (Overlay). Im Underlay kommt eine hochverfügbare Spine-Leaf-Architektur zum Einsatz, in der jeder Serverknoten redundant über Punkt-zu-Punkt-Layer-3-Verbindungen und das Border Gateway Protocol (BGP) angebunden ist, sodass sämtliche Leitungen aktiv über Equal-Cost Multi-Path (ECMP) genutzt werden.

Mandanten-Isolation über VXLAN-Tunnel und BGP-EVPN Control Plane

Auf diesem IP-Underlay spannt das Software-Defined Networking (SDN) virtuelle Layer-2- und Layer-3-Segmente über Kapselungsprotokolle wie VXLAN (IETF RFC 7348) oder Geneve auf. Ein VXLAN Tunnel Endpoint (VTEP) direkt im Hypervisor-Kernel verpackt die Ethernet-Frames der Gast-VM in UDP-Pakete und versieht sie mit einem 24-Bit VXLAN Network Identifier (VNI), der über 16 Millionen streng isolierte Mandantennetze erlaubt.

Damit die Serverknoten jederzeit wissen, hinter welchem physischen Host sich eine bestimmte virtuelle MAC- oder IP-Adresse befindet, dient BGP Ethernet VPN (EVPN nach RFC 7432) als verteilte Control Plane. Statt unbekannten Datenverkehr per Broadcast durch das gesamte Rechenzentrum zu fluten, tauschen die Hypervisoren Standortinformationen von Workloads deterministisch als BGP-Routen aus.

„Cloud Computing ist keine schwarze Magie fremder Großkonzerne, sondern angewandte Systeminformatik: Wer KVM-Virtualisierung, BGP-EVPN-Routing, eBPF-Datenpfade und Ceph-Storage architektonisch durchdringt, verwandelt Standard-Server in eine hochverfügbare, souveräne Infrastruktur.“

In modernen Cloud-Native-Umgebungen wird die Paketweiterleitung im Host-Kernel zusätzlich durch eBPF (Extended Berkeley Packet Filter) und Plattformen wie Cilium beschleunigt. Anstatt Netzwerkpakete durch tausende sequenzielle iptables- oder Netfilter-Regeln zu schleusen, klinken sich verifizierte eBPF-Bytecode-Programme direkt am Netzwerktreiber (XDP / Express Data Path) und auf Socket-Ebene ein, was Durchsatz und Mikrosegmentierung massiv beschleunigt.

Schicht 3 (Storage): Verteilte Speicher-Fabrics mit Ceph RADOS und CRUSH

Die dritte Säule der Cloud-Funktionsweise betrifft die persistente Datenhaltung. Würde eine virtuelle Maschine ihre Festplattendaten lediglich auf der lokalen NVMe-SSD ihres aktuellen Host-Servers ablegen, wäre sie bei einem Hardwaredefekt dieses Knotens verloren. Gleichzeitig bilden monolithische Fibre-Channel-SAN-Schränke kostspielige Engpässe und potenzielle Single Points of Failure.

Software-Defined Storage (SDS) auf Basis von Ceph löst diesen Zielkonflikt durch eine vollständig verteilte, objektbasierte Speicherarchitektur namens RADOS (Reliable Autonomic Distributed Object Store). Jeder physische Speicherknoten betreibt für seine lokalen Enterprise-NVMe-Laufwerke eigene Object Storage Daemons (OSDs), die über die BlueStore-Engine direkt ohne zwischengeschaltetes Dateisystem auf die Rohblöcke zugreifen.

Deterministische Platzierung via CRUSH statt zentraler Metadaten-Tabellen

Der entscheidende architektonische Kunstgriff von Ceph liegt im Verzicht auf zentrale Verzeichnis- oder Lookup-Tabellen, die bei großen Datenmengen zwangsläufig zum Flaschenhals würden. Stattdessen verwenden sowohl Clients (etwa der KVM-Hypervisor über das librbd-Protokoll) als auch die Storage-Knoten den mathematischen CRUSH-Algorithmus (Controlled Replication Under Scalable Hashing).

Anhand einer kompakten Cluster-Topologiekarte (CRUSH-Map), welche die physischen Ausfalldomänen wie Server, Racks, Brandabschnitte und Rechenzentren abbildet, berechnet jeder Client pseudozufällig, aber vollkommen deterministisch, welcher primäre OSD für ein Datenobjekt zuständig ist. Auf demselben RADOS-Fundament stellt Ceph parallel Blockspeicher (RBD für VMs), POSIX-Dateisysteme (CephFS) und S3-kompatiblen Objektspeicher (RADOS Gateway) bereit.

3x-Replikation versus Erasure Coding und automatische Selbstheilung

Um den Ausfall einzelner NVMe-Medien oder ganzer Serverracks ohne Datenverlust zu überstehen, unterstützt ein solcher Speicherpool zwei komplementäre Schutzverfahren. Bei der 3x-Replikation wird jeder 4-Megabyte-Datenblock synchron über das dedizierte 25- oder 100-GbE-Storage-Netzwerk auf drei verschiedene Server in getrennten Racks geschrieben, bevor der Schreibvorgang gegenüber der Applikation bestätigt wird (Strong Consistency).

Für große S3-Objektspeicher, Backups und Datenarchive kommt hingegen Erasure Coding (beispielsweise im Schema k=4, m=2) zum Einsatz: Ein Datenblock wird in vier Datenfragmente zerlegt und um zwei mathematisch berechnete Paritätsfragmente nach dem Reed-Solomon-Verfahren ergänzt. Dadurch sinkt der Speicher-Overhead von 200 Prozent auf lediglich 50 Prozent bei unveränderter Ausfalltoleranz von zwei kompletten Knoten.

Fällt im laufenden Betrieb ein Speicherknoten aus, registrieren die im Raft- bzw. Paxos-Quorum arbeitenden Ceph-Monitore die Statusänderung binnen Sekunden. Ohne manuellen Eingriff des Administrators starten die verbleibenden OSD-Knoten im Hintergrund das sogenannte Rebalancing (Recovery und Backfill) und stellen die definierte Redundanzstufe auf den gesunden Laufwerken vollautomatisch wieder her.

Schicht 4 (Control Plane): Deklarative Orchestrierung und Reconciliation Loops

Erst die vierte Architekturschicht verwandelt virtualisierte Server, SDN-Tunnel und verteilten Speicher in eine vollwertige Cloud: die Orchestrierungs- und Control-Plane-Ebene, repräsentiert durch Systeme wie OpenStack für Infrastructure-as-a-Service (IaaS) und Kubernetes für containerisierte Plattformdienste (PaaS/CaaS). Ihr zentrales Paradigma lautet deklarative Zustandssteuerung statt imperativer Einzelbefehle.

In einer klassischen IT-Umgebung führt ein Administrator nacheinander Befehle oder Skripte aus, um einen Server zu installieren; bricht ein Schritt ab, bleibt das System in einem undefinierten Zwischenzustand zurück. In einer Cloud-Control-Plane übergibt das Betriebsteam oder die GitOps-Pipeline hingegen ein deklaratives Manifest (im JSON- oder YAML-Format) an den zentralen API-Server, das ausschließlich den gewünschten Soll-Zustand beschreibt.

Dieser Soll-Zustand wird in einer hochverfügbaren, über den Raft-Konsensalgorithmus abgesicherten Schlüssel-Wert-Datenbank (wie etcd in Kubernetes) revisionssicher persistiert. Anschließend treten spezialisierte Controller-Prozesse in Aktion, die in einer endlosen Regelschleife (Reconciliation Loop) permanent den realen Ist-Zustand der Infrastruktur mit dem in etcd hinterlegten Soll-Zustand abgleichen.

Meldet ein Worker-Knoten keinen Heartbeat mehr, weil ein Netzteil defekt ist, erkennt der Node-Controller die Abweichung zwischen fünf geforderten und nur noch vier laufenden Instanzen. Der Scheduler bewertet daraufhin in Millisekunden alle verbleibenden Hosts nach freien CPU- und RAM-Reserven, Anti-Affinitätsregeln sowie Storage-Zonen und weist den Kubelet- bzw. Nova-Compute-Agenten eines gesunden Knotens an, die fehlende Instanz sofort neu zu starten.

Architektur-Matrix: Klassische Silo-IT versus moderne Cloud-Infrastruktur

Um die technischen Auswirkungen dieser vier Abstraktionsschichten für Architektur-Boards und Einkaufsverantwortliche strukturiert gegenüberzustellen, vergleicht die folgende Bloomberg-Radar-Matrix die Funktionsweise traditioneller Rechenzentrums-Silos mit einem modernen, auf offenen Industriestandards basierenden Cloud-Stack:

Diese Gegenüberstellung verdeutlicht, warum führende Branchen längst auf softwaredefinierte Cloud-Mechanismen angewiesen sind. In der Telekommunikation bilden KVM, SR-IOV und BGP-EVPN das Rückgrat moderner 5G-Kernnetze, in denen Network Functions Virtualization (NFV) Datenpakete mit deterministischer Mikrosekunden-Latenz auf Standard-Servern verarbeitet.

Ebenso profitieren regulierte Finanzdienstleister und Energieversorger von der deklarativen Selbstheilung. Weiterführende Referenzarchitekturen für den Aufbau unabhängiger Plattformen finden Sie in unserem Themendossier zur Souveränen IT-Infrastruktur und Cloud-Exit-Strategie sowie im Praxisleitfaden zur mandantenfähigen Community Cloud.

Vollkostenrechnung über 60 Monate: TCO-Analyse für 300 Produktiv-Workloads

Die technische Effizienz von Hypervisor-Konsolidierung, Software-Defined Storage und deklarativer Automatisierung schlägt sich unmittelbar in der Fünfjahres-Gesamtkostenrechnung (60 Monate TCO) nieder. Als realistisches Referenzmodell betrachten wir ein mittelständisches Unternehmen mit 300 produktiven Anwendungssystemen, einem Gesamtspeicherbedarf von 400 Terabyte Nettokapazität und hohen Verfügbarkeitsanforderungen.

In einer gewachsenen Silo- und Legacy-Virtualisierungsumgebung erfordert dieses Profil häufig rund 45 bis 60 schwach ausgelastete Dual-Socket-Server, zwei dedizierte Enterprise-SAN-Speichersysteme inklusive Fibre-Channel-Director-Switches sowie teure Core-basierte Software-Abonnements. Über 60 Monate summieren sich Hardware-Abschreibungen (CAPEX), Herstellersupport, SAN-Wartungsverträge, Lizenzgebühren und ein Strombedarf von über 45 Kilowatt auf rund 2,45 Millionen Euro.

Würde dasselbe Unternehmen diese 300 Dauerlast-Workloads unreflektiert im Lift-and-Shift-Verfahren als reservierte Instanzen inklusive Managed Block Storage (EBS) und NAT-Gateway-Traffic bei einem US-Hyperscaler mieten, lägen die monatlichen OPEX-Abflüsse bei durchschnittlich 38.000 bis 44.000 Euro. Über fünf Jahre entspricht dies einem Mittelabfluss von 2,40 Millionen Euro ohne jeden physischen Substanzwert.

Setzt die Organisation stattdessen auf eine hochverdichtete, softwaredefinierte Cloud-Architektur auf Basis von 16 modernen AMD-EPYC- oder Intel-Xeon-Serverknoten mit KVM, Ceph-NVMe-Storage, eBPF-SDN und Kubernetes, sinkt der initiale Hardware-Invest inklusive redundanter 100-GbE-Spine-Leaf-Switches auf rund 380.000 Euro. Zuzüglich Enterprise-Support-Subscriptions, Colocation-Stellfläche, 14 Kilowatt elektrischer Anschlussleistung und automatisierter GitOps-Betriebsführung beläuft sich die 60-Monats-TCO auf rund 890.000 Euro, was einer Einsparung von über 1,5 Millionen Euro (rund 63 Prozent) entspricht.

Make-or-Buy Sourcing-Weiche und regulatorische Anforderungen (BSI C5 & EU Data Act)

Da die Kerntechnologien des Cloud Computings als quelloffene Industriestandards unter dem Dach der Linux Foundation, der Cloud Native Computing Foundation (CNCF) und der IETF dokumentiert sind, sind Unternehmen nicht gezwungen, Cloud-Funktionalität ausschließlich bei außereuropäischen Großkonzernen einzukaufen. Für die Umsetzung haben sich drei klar abgegrenzte Betriebsmodelle etabliert.

Erstens (Eigenbetrieb): Organisationen mit einem qualifizierten Platform-Engineering-Team ab vier bis sechs Spezialisten betreiben ihren eigenen Stack aus KVM/Proxmox oder OpenStack, Ceph und Kubernetes auf eigener Hardware in zertifizierten europäischen Colocation-Rechenzentren. Dies garantiert maximale Datenhoheit, niedrigste TCO bei stabiler Grundlast und vollständige Unabhängigkeit von fremden Lizenzmetriken.

Zweitens (Co-Managed): Unternehmen des gehobenen Mittelstands behalten die physische Hardware-Hoheit und die Anwendungssteuerung im eigenen Haus, vergeben jedoch die 24/7-Bereitschaft für den darunterliegenden Hypervisor-, Ceph- und SDN-Layer an einen spezialisierten europäischen Managed-Service-Partner. Sämtliche Infrastructure-as-Code-Playbooks (OpenTofu, Ansible) verbleiben dabei vertraglich im Git-Repository des Kunden.

Drittens (Managed Service): Teams ohne eigene Infrastruktur-Mannschaft nutzen souveräne europäische Public- oder Private-Cloud-Plattformen, die nachweislich auf offenen Standards wie dem Sovereign Cloud Stack (SCS) oder verwalteten CNCF-zertifizierten Kubernetes-Clustern basieren. So profitieren Entwickler von sofort einsatzbereiten Cloud-APIs, ohne in proprietäre Schnittstellen-Abhängigkeiten zu geraten.

Unabhängig vom gewählten Bereitstellungsmodell unterliegt die technische Funktionsweise strengen regulatorischen Prüfmaßstäben. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert im IT-Grundschutz-Baustein SYS.1.5 (Virtualisierung) sowie im Kriterienkatalog C5 verbindliche Vorgaben zur kryptografischen und logischen Mandantentrennung, zur Härtung der Management-Schnittstellen gegen Hypervisor-Breakout-Angriffe (etwa mittels SELinux/sVirt und Seccomp) sowie zur physischen oder logischen Separierung von Administrations-, Produktions- und Speichernetzen.

Zusätzlich verschärft die Verordnung (EU) 2023/2854 (EU Data Act) in den Artikeln 23 bis 30 die Anforderungen an die funktionelle Äquivalenz und Interoperabilität von Datenverarbeitungsdiensten. Anbieter und interne Plattformbetreiber müssen sicherstellen, dass Workloads, Metadaten und virtuelle Netzwerk-Konfigurationen über offene Schnittstellen ohne künstliche technische Hürden oder Wechselgebühren innerhalb der gesetzlichen Übergangsfristen portiert werden können.

Der 4-Phasen-Umsetzungsfahrplan: Aufbau einer souveränen Cloud-Architektur

Um die beschriebenen Funktionsprinzipien von Compute, SDN, Storage und Orchestrierung ohne operative Risiken im eigenen Unternehmen oder im Verbund mit einem europäischen Hosting-Partner einzuführen, hat sich ein phasenweises Vorgehen über sechs bis neun Monate bewährt.

Phase 1 (Monat 1 bis 2): Hardware-Standardisierung, Spine-Leaf-Design und Bare-Metal-Härtung

Zu Beginn definiert das Infrastruktur-Team ein einheitliches Server-Profil auf Basis von Enterprise-x86-Knoten mit aktivierten Virtualisierungserweiterungen (VT-x/AMD-V, IOMMU), TPM 2.0, Secure Boot und mindestens zwei redundanten 25- oder 100-GbE-Netzwerkkarten. Parallel wird das physische Spine-Leaf-Netzwerk als Layer-3-Fabric konzipiert, um Management-, VXLAN-Overlay- und Ceph-Storage-Verkehr sauber zu isolieren.

Phase 2 (Monat 3 bis 4): Inbetriebnahme des Ceph-Storage-Clusters und CRUSH-Map-Validierung

In der zweiten Phase erfolgt das Deployment des verteilten Speichersystems auf den dedizierten NVMe-Laufwerken. Die Architekten konfigurieren die CRUSH-Failure-Domains auf Rack- oder Brandabschnittsebene, richten separate Speicherpools mit 3x-Replikation für Datenbank-Blockgeräte und Erasure Coding für S3-Objektspeicher ein und validieren die IOPS- und Latenzwerte unter künstlich provozierten Knotenausfällen.

Phase 3 (Monat 5 bis 6): Rollout von KVM-Hypervisor, BGP-EVPN und eBPF-Netzwerkschicht

Anschließend werden die Compute-Knoten mit gehärteten Linux-Kernels und KVM in Betrieb genommen sowie über BGP-EVPN und VXLAN zu einer mandantenfähigen SDN-Fabric verbunden. Auf dieser Basis starten die ersten automatisiert bereitgestellten Kubernetes-Cluster mit Cilium als eBPF-Netzwerk-Plugin, inklusive durchgängiger Verschlüsselung des Ost-West-Datenverkehrs via WireGuard oder IPsec.

Phase 4 (Monat 7 bis 9): GitOps-Control-Plane, Observability und Workload-Onboarding

Im letzten Schritt wird die deklarative Steuerung über GitOps-Controller wie ArgoCD oder Flux sowie Infrastructure-as-Code-Pipelines (OpenTofu) produktiv geschaltet. Begleitet von einer zentralen Telemetrie-Plattform aus Prometheus, Grafana und OpenTelemetry migrieren die Fachteams ihre Applikationen schrittweise auf die neue Plattform und schalten die historischen Hardware-Silos ab.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur Cloud-Architektur

1. Basiert unsere Cloud-Strategie auf offenen Standards oder proprietären Blackbox-Diensten?

Prüfen Sie kritisch, ob Ihre produktiven Workloads auf standardisierten Schnittstellen wie KVM, Kubernetes-APIs, S3-Objektspeicher und PostgreSQL aufsetzen oder tief mit herstellerspezifischen Hyperscaler-Diensten verdrahtet sind. Nur offene Protokolle auf den vier Kernschichten Compute, SDN, Storage und Orchestrierung sichern Ihre technische Handlungsfähigkeit im Sinne des EU Data Act.

2. Wie ist die logische Mandanten- und Netztrennung auf Hypervisor- und Kernel-Ebene abgesichert?

Verlangen Sie von Ihrem internen Plattformteam oder Cloud-Dienstleister einen konkreten Architektur-Nachweis gemäß BSI IT-Grundschutz SYS.1.5. Dazu gehört die Bestätigung, dass Management-Schnittstellen, VXLAN-Mandantentunnel und Ceph-Replikationsnetze strikt voneinander getrennt sind und Gast-VMs über sVirt/SELinux sowie aktuelle Microcode-Patches gegen Seitenkanalangriffe isoliert werden.

3. Übersteht unser Speicherkonzept den gleichzeitigen Ausfall eines kompletten Server-Racks ohne Datenverlust?

Lassen Sie sich die genaue Konfiguration der Ceph-CRUSH-Map bzw. der Storage-Redundanz vorlegen. Bei geschäftskritischen Datenbanken muss eine synchrone 3x-Replikation mit einer Mindest-Schreibquittierung (min_size=2) über drei physisch getrennte Ausfalldomänen hinweg aktiv sein, damit selbst bei Wartungsarbeiten und gleichzeitigem Hardwaredefekt kein Split-Brain-Zustand oder Datenverlust eintritt.

4. Wird die gesamte Cloud-Infrastruktur deklarativ als Code verwaltet und auf Wiederanlauf getestet?

Eine Cloud verdient ihren Namen nur, wenn manuelle Eingriffe auf Einzelsystemen durch deklarative Reconciliation-Loops ersetzt wurden. Stellen Sie sicher, dass sämtliche Netzwerk-, Speicher- und Cluster-Definitionen versioniert in einem Git-Repository liegen und der vollautomatische Wiederaufbau einer Umgebung im Rahmen von NIS-2-Notfallübungen regelmäßig verifiziert wird.

5. Kennen wir den exakten TCO-Wendepunkt zwischen Public-Cloud-Miete und eigener Cloud-Plattform?

Beauftragen Sie das IT-Controlling mit einer ehrlichen 60-Monats-Vollkostenrechnung, die neben den reinen Instanzpreisen auch die oft übersehenen Gebühren für IOPS-Spitzen, Snapshot-Speicher und Egress-Datenverkehr berücksichtigt. Ab einer dauerhaften Grundlast von 150 bis 300 virtuellen Maschinen amortisiert sich eine eigene oder Co-Managed Open-Source-Cloud meist bereits im zweiten Betriebsjahr.

Strategisches Fazit: Technologische Souveränität durch Architektur-Beherrschung

Wer die technische Funktionsweise des Cloud Computings auf den vier Ebenen Hypervisor-Virtualisierung, Software-Defined Networking, verteilter Datenspeicherung und deklarativer Orchestrierung durchdringt, entzaubert das Geschäftsmodell globaler Public-Cloud-Monopole. Elastizität, Hochverfügbarkeit und sekundenschnelle Bereitstellung sind keine exklusiven Eigenschaften amerikanischer Großrechenzentren, sondern das Resultat präzise abgestimmter Open-Source-Komponenten auf standardisierter Server-Hardware.

Für CIOs und IT-Architekten eröffnet dieses Verständnis den Weg aus der passiven Konsumentenrolle. Indem Unternehmen auf offene Industriestandards wie KVM, BGP-EVPN, eBPF, Ceph und Kubernetes setzen, verbinden sie die operative Agilität moderner Cloud-Plattformen mit kalkulierbaren Fünfjahreskosten und uneingeschränkter digitaler Souveränität unter europäischem Rechtsrahmen.

Häufig gestellte Fragen (FAQ) zur Funktionsweise von Cloud Computing