Einheit 8.2: Die Referenz-Unternehmensarchitektur

Einführung

Jede vorherige Einheit hat eine Sache isoliert entschieden: eine Compute-Klasse, einen Replikationsmodus, eine Load-Balancer-Ebene, einen Failover-Mechanismus. Diese Einheit bringt sie alle gleichzeitig auf ein einziges Bild. Der Zweck besteht nicht darin, ein Produkt erneut zu unterrichten, sondern zu zeigen, wie sich die Entscheidungen zusammensetzen, wie eine Wahl in einer Ebene eine Wahl in einer anderen einschränkt und wie die ehrlichen Grenzen der Plattform das gesamte Bild formen, nicht nur den Teil, der sie berührt.

Die Referenzarchitektur gehört zu FinCorp: ein deutsches Finanzdienstleistungsunternehmen unter DSGVO- und BSI-Aufsicht, das eine große VMware-Umgebung migriert und eine KI-Fähigkeit aufbaut. Sie ist die Summe aller Entscheidungen aus den Modulen 1 bis 7, dargestellt als ein einzelnes System. Behandeln Sie sie als eine Vorlage, die Sie instanziieren, nicht als ein Diagramm, das Sie kopieren.

1. Das zusammengesetzte System

Das Design ist nach der kanonischen geschichteten Struktur aus Einheit 1.2 organisiert: eine öffentliche Layer-7-Kante, eine zustandslose Berechnungsebene, ein privater Layer-4-Load Balancer und eine nur privat zugängliche Datenebene. Um dieses Rückgrat herum befinden sich die dedizierte VMware-Umgebung, die Container-Plattform, die KI-Ebene und die Hybridverbindungen zu den Räumlichkeiten von FinCorp. Alles befindet sich innerhalb eines einzigen Vertrags (der Governance- und Abrechnungsgrenze aus Einheit 2.1) und ist über Virtuelle Rechenzentren nach Region und Umgebung segmentiert.

1.1 Segmentierung und der geschichtete Pfad

Ein LAN auf IONOS CLOUD ist privat, bis es mit dem Internetzugang verbunden wird (Einheit 3.1). Das Produktions-VDC von FinCorp umfasst drei LANs: ein öffentliches Edge-LAN, ein privates Anwendungslan und ein privates Daten-LAN. Nord-Süd-Verkehr tritt am öffentlichen Edge ein; Ost-West-Verkehr zwischen den Ebenen verbleibt auf privaten LANs und durchquert niemals eine öffentliche IP.

Der Anfragepfad ist bewusst geschichtet. Ein öffentlicher Managed Application Load Balancer (ALB) terminiert TLS an der Kante und routet anhand von Layer-7-Attributen; er dient als Edge-Gerät, das den Nord-Süd-Verkehr in das und aus dem Rechenzentrum heraus verarbeitet. Dahinter befindet sich die zustandslose Anwendungsebene auf Dedicated Core-Berechnung. Diese Server erreichen die Datenebene über einen privaten Managed Network Load Balancer (NLB), der Layer-4-TCP an die Datenbankendpunkte weiterleitet und den Ost-West-Verkehr innerhalb des Rechenzentrums verarbeitet. Die Zusammensetzung aus öffentlichem ALB und privatem NLB (Einheiten 3.3 und 3.4) bildet das Rückgrat der Lastverteilung: inhaltsbewusst an der Kante, wo Routinglogik relevant ist, und schneller TCP-Passthrough intern, wo sie es nicht ist.

Die Anwendungsebene ist bewusst zustandslos. Diese Voraussetzung ermöglicht das automatische Skalieren (Einheit 4.3) und ermöglicht es dem vorgeschalteten Load Balancer, neue Verbindungen auf gesunde Replikate zu verschieben, ohne Sitzungszustände zu verlieren. Sitzungszustände und Lesezustände werden in die In-Memory-Cache-Ebene ausgelagert, statt auf den Servern gehalten zu werden.

1.2 Dedizierte VMware für regulierte Verarbeitung

Der regulierte Kern von FinCorp läuft auf IONOS CLOUD Private Cloud: eine verwaltete dedizierte VMware SDDC (vSphere Enterprise Plus, vSAN, NSX-T) auf Single-Tenant-Hardware, mit eingeschlossener Lizenzierung, nicht mitgebrachter Lizenzierung (Einheit 4.4). Single-Tenancy ist hier der treibende Designfaktor: Die Workloads, die die strengsten Anforderungen an Isolation und Vorhersehbarkeit haben, befinden sich auf Hardware, die kein anderer Tenant teilt. Die Bereitstellung ist ein geführtes Engagement, keine Self-Service-Konsolenaktion, weshalb dieser Teil der Umgebung im Data Center Designer gestaltet und nicht gebaut wird.

Die VMware-Umgebung ist keine Insel. Sie ist über die unten beschriebene Hybridverbindung mit der elastischen Standard-Berechnungsebene verbunden und bietet FinCorp das bewährte Hybridmuster: einen dedizierten VMware-Kern für regulierte, stationäre Verarbeitung plus elastische Standardberechnung für variablen Edge-Last. Der VMware-Stack hier ist NSX-T 3.2 mit vCenter für das In-Cluster-Management; das einzige VMware-Mobilitäts- und Replikationstooling im Geltungsbereich ist das, was die Plattform tatsächlich bereitstellt, abgedeckt unter Migration unten.

1.3 Managed Kubernetes für Container

Neue und refaktorierte Dienste laufen auf Managed Kubernetes (Einheit 6.1). Die Steuerungsebene ist verwaltet und kostenlos; FinCorp zahlt für Node-Pools, die über ein eigenes SLA verfügen, das von der Steuerungsebene getrennt ist. Das Cluster wird über einen separat bereitgestellten Load Balancer plus einen In-Cluster-Ingress-Controller an die geschichtete Struktur angeschlossen, da ein Kubernetes-Manifest keinen IONOS CLOUD verwalteten Load Balancer automatisch bereitstellt. Ein Service vom Typ LoadBalancer löst sich in eine statische IP eines einzelnen Nodes auf, nicht in einen verwalteten Balancer, daher ist der Produktions-Ingress-Pfad ein ALB vor einem In-Cluster-Ingress-Controller. Dies ist die umgesetzte API-Gateway-Ersatzlösung: ALB-Pfadregeln plus In-Cluster-Ingress stehen für ein verwaltetes API-Gateway ein, das IONOS CLOUD nicht verkauft.

Die Sicherheit im Cluster ist ehrlich aufgeteilt. Network Security Groups und NIC-Firewalls sind an die NICs der Worker-Nodes gebunden, nicht an die Clusterabstraktion, daher wird die Pod-zu-Pod-Steuerung mit In-Cluster-Netzwerkrichtlinien durchgesetzt. Container-Images stammen aus der Container Registry, geregelt durch Token-Disziplin (ein eng begrenztes Token pro Pipeline-Stufe, mit Ablauf und Rotation; Tokens werden gelöscht, nicht deaktiviert), da die Registry kein RBAC bietet.

1.4 Die Datenplattform

Die Datenebene ist nur über private Endpunkte zugänglich und besteht aus mehreren verwalteten Engines, die jeweils einem Zugriffsmuster zugeordnet sind:

• Relationale Datenbanken (Managed PostgreSQL / MariaDB): das System der Aufzeichnung. Es gibt keine Lese-Replikate. Replikation erfolgt im Cluster (PostgreSQL asynchron standardmäßig, mit synchronen und strikt synchronen Modi verfügbar; MariaDB nur asynchron) für Dauerhaftigkeit und automatische Intra-Cluster-Promotion, nicht für Lese-Skalierung.
• In-Memory-Cache: die Ebene für Lese-Skalierung und Zustandsauslagerung (Einheit 5.5). Sie schirmt die relationale Ebene ab und nimmt Lese-Last auf, und sie hält den von der zustandslosen Anwendungsebene ausgelagerten Sitzungszustand. Dieser Cache ist das, was sowohl das Muster ohne Lese-Replikate als auch sicheres automatisches Skalieren ermöglicht; er ist keine optionale Dekoration.
• Dokumente (Managed MongoDB): für Workloads, deren Form besser zu einem Dokumentenmodell passt als zu relationalen Zeilen.
• Streaming (Managed Kafka): das Ingestion-Rückgrat und der Ersatz für Change-Data-Capture. Da es keinen verwalteten Datenbank-Change-Stream gibt, veröffentlichen Anwendungen Ereignisse auf Kafka auf Anwendungsebene. Partitionen sind die Einheit der Reihenfolge und der Consumer-Parallelität; das Topic- und Partitionsdesign ist die tragende Entscheidung.
• Objektarchiv (Object Storage): der S3-kompatible Flat-Namespace-Speicher, der als Sicherungsziel, Audit-Archiv, Datensatz- und Artefakt-Speicher sowie als Dead-Letter- und Archivschweif für Kafka dient. Object Lock bietet manipulationsnachweisbare Aufbewahrung.

1.5 Die KI-Ebene

Die KI-Fähigkeit von FinCorp standardmäßig auf verwaltetes Inferencing im AI Model Hub: eine OpenAI-kompatible Inferenz-API, Preiskalkulation pro Token, zustandslos, mit EU-Datenresidenz und Inlandsverarbeitung. Retrieval-augmented generation wird von Kunden aus Plattformteilen selbst gebaut: Embeddings aus dem Hub, Vektoren gespeichert in Managed PostgreSQL, und der Quellkorpus in Object Storage. Die verwaltete Vektor-Speicher-Funktion des Hubs wird zugunsten dieses zusammengesetzten Musters vermieden, das den Retrieval-Speicher unter der eigenen Datenbank-Governance von FinCorp hält.

1.6 Hybridverbindung

Die Räumlichkeiten von FinCorp und seine VMware-Umgebung erreichen die Cloud über die Verbindungspunkte aus Einheit 3.6. Ein VPN Gateway (IKEv2 oder WireGuard, kein IKEv1; aktiv-passive HA mit einer gemeinsamen öffentlichen IP) überträgt verschlüsselten Standort-zu-Cloud-Verkehr. Ein NAT Gateway bietet ausgehenden Egress für private Workloads, die keine öffentliche IP haben; es ist nur SNAT, daher ist es ein Egress-Pfad, niemals ein Eingangspunkt für eingehenden Verkehr. Private Cross-Connect-Links verbinden VDCs in derselben Region und demselben Vertrag über ein gemeinsames privates Interconnect, einschließlich des Cross-VDC-Node-Verkehrs, von dem ein privates Kubernetes-Cluster abhängt.

1.7 Resilienz, Observability und Kosten als operative Hülle

Resilienz (Einheit 7.1) basiert auf Plattformprimitiven, nicht auf einem verwalteten Failover-Produkt, das nicht existiert. Redundante Paare werden in expliziten Verfügbarkeitszonen platziert (niemals Auto, da sie sie zusammenfassen kann), und die verwalteten Load Balancer führen Health-Checks für ihre Ziele durch und stoppen das Routing zu einem fehlgeschlagenen Backend; Cloud DNS bietet Anycast-Auflösung und eine niedrige minimale TTL für schnelle Datensatzverbreitung, führt aber keinen nativen Health-Check-basierten Failover durch. Die Verkehrssteuerungsebene (DNS) wird von der Datenkontinuitätsebene (Sicherungen, Snapshots, PITR, Object Storage-Archiv) getrennt gehalten. Observability (Einheit 7.2) umfasst vier fest umrissene Telemetrie-Ebenen: Metriken, Logs, Audit und Netzwerk-Flow-Logs, die in ein externes SIEM eingespeist werden, da es keine Cross-Vertrags-Aggregation gibt und Kubernetes-Steuerungsebenen-Ereignisse nicht durch den Logging-Dienst fließen. Kosten (Einheit 2.4) werden durch Zuweisung pro Vertrag und VDC, nach Zugriffsmuster gestufte Speicherung und Savings Plans, die an den stationären Boden gebunden sind, gesteuert.

2. Querschnittliche Belange, keine isolierten Funktionen

Die Architektur hält nur zusammen, weil vier Belange durch jede Ebene verlaufen, statt in einer einzelnen Komponente zu stecken.

Hochverfügbarkeit wird komponiert, nicht gekauft. Der Edge-ALB und der NLB sind verwaltet und resilient; redundante Compute- und Datenknoten sind über explizite Zonen verteilt; die verwalteten Load Balancer führen Health Checks für ihre Ziele durch und leiten um, wenn Backends ausfallen; und die dedizierte VMware-Umgebung ergänzt vSAN-Fehlertoleranz und vSphere HA innerhalb ihres Clusters. Kein einzelnes Produkt bietet End-to-End-Hochverfügbarkeit; das Design setzt diese Mechanismen in Schichten ein.

Lastverteilung tritt auf zwei Ebenen aus zwei Gründen auf. Layer 7 am öffentlichen Edge bietet inhaltsbasierte Routing-Funktionen und TLS-Terminierung; Layer 4 intern ermöglicht schnellen TCP-Passthrough, wobei das Backend sein eigenes Zertifikat beibehält. Weder der verwaltete Balancer akzeptiert eine Network Security Group noch eine IP-Allowlist, daher gehört die Filterung zu den Zielen dahinter.

Sicherheit wird dort durchgesetzt, wo sie greift: NIC-Firewalls und NSGs auf Server- und Worker-NICs, In-Cluster-Network-Policies innerhalb von Kubernetes, Token-Disziplin auf der Registry und gruppen- und berechtigungsbasierte Zugriffskontrolle über den gesamten Vertrag. Es gibt keine IAM mit Policy-Sprache und keine Verweigerungsregel; Least Privilege wird erreicht, indem Berechtigungen nicht erteilt werden, und Federation (SAML/OIDC) dient nur der Authentifizierung, sodass der Joiner-Mover-Leaver-Prozess ein manuelles Runbook ist.

Konnektivität verknüpft die Umgebung: private LANs für Ost-West-Tier-Verkehr, VPN für Site-to-Cloud, NAT für privaten Egress und Cross-Connect für Cross-VDC-Links innerhalb derselben Region. Die Topologie selbst ist eine Sicherheitsmaßnahme, denn die Isolation der Datenebene auf einem privaten LAN kompensiert den Mangel an NSG-Unterstützung der verwalteten Balancer.

Die folgende Tabelle ordnet jede IONOS CLOUD-Funktionsgrenze dem nativen Muster zu, das sie in dieser Architektur umsetzt.

Die Migration in den regulierten VMware-Kern nutzt nur die Tools, die die Plattform bereitstellt: VMware Cloud Director Availability (VCDA, Version 4.7.x) für asynchrone Replikation, Migration und Live-Failover zu etwa 50 EUR pro geschützter VM pro Monat; NSX-Ts eingebautes L2-VPN für die Layer-2-Netzwerkerweiterung (eine Standard-NSX-T-Edge-Funktion, kein separat lizenziertes Add-on); und intra-cluster vMotion. vMotion ist nur intra-cluster und keine Cross-Site-Live-Mobilitätsfunktion. Workloads ohne VMware-nativen Pfad werden über Image-Konvertierung und Upload neu gehostet, und Datenbanken werden per Dump und Restore migriert, da der Backup Service verwaltete Datenbanken nicht abdeckt.

Zusammenfassung der Entscheidung

Das tragende Element der Referenzarchitektur ist die dienstbezogene Zuordnung: wo jede Komponente platziert ist und welche BSI-Anerkennung sie genau abdeckt. Compliance wird pro Dienst und pro Rechenzentrumsstandort festgelegt, niemals plattformweit. Daher ist diese Zuordnung das, was ein Prüfer liest. BSI C5 ist eine Type-1-Attestierung (Testat), die am 2023-11-07 erteilt wurde; IT-Grundschutz ist ein ISO 27001-Zertifikat, das am 2022-09-14 erteilt wurde (BSI). Beide gelten für deutsche Rechenzentren, und ihre Geltungsbereiche unterscheiden sich je nach Dienst. IONOS CLOUD ist der erste deutsche Cloud-Anbieter, der beide anerkannten Nachweise hält.

Zwei Leseregeln gelten für diese Tabelle. Erstens bedeutet „im Geltungsbereich“, dass der genannte Dienst in deutschen Rechenzentren über diese BSI-Anerkennung verfügt; es wird niemals ein plattformweiter Anspruch erteilt. C5 deckt genau Compute Engine, Cloud Cubes und S3 Object Storage ab; IT-Grundschutz deckt genau Compute Engine, S3 Object Storage, Backup und Managed Kubernetes ab. Die beiden Geltungsbereiche weichen voneinander ab: Cubes fallen unter C5, aber nicht unter IT-Grundschutz, während Managed Kubernetes und Backup unter IT-Grundschutz, aber nicht unter C5 fallen. Zweitens wird der Souveränitätsfilter aus Einheit 1.4 am Ende auf das gesamte Design angewendet: Jede Komponente wird unter EU-Jurisdiktion betrieben, was eine Eigenschaft des Betreibers und nicht nur der Region ist.

Die beiden Kompositionsfehler, gegen die das zusammengeführte Design geprüft werden muss, sind die Kombination inkompatibler Grundbausteine (zum Beispiel die Erwartung, dass eine NSG einen verwalteten Load Balancer schützt, oder der Versuch, zwei VDCs in verschiedenen Regionen über einen Cross-Connect zu verbinden) und die Platzierung eines funktional korrekten Dienstes außerhalb seines erforderlichen Attestierungsbereichs (zum Beispiel die Ausführung von C5-pflichtiger regulierter Verarbeitung auf einem Dienst, den C5 nicht abdeckt).

Zusammenfassung

Die Referenz-Unternehmensarchitektur stellt den gesamten Kurs als ein einzelnes System dar: ein geschichteter Pfad von öffentlichem L7 bis zu privatem L4 über einer zustandslosen Compute-Ebene und einer privaten Datenplattform, mit einem dedizierten VMware-Kern für regulierte Verarbeitung, Managed Kubernetes für Container, einer KI-Ebene, die standardmäßig verwaltetes Inferencing nutzt, und Hybrid-Verbindungen, die das System mit den Räumlichkeiten von FinCorp verbinden. Hochverfügbarkeit, Lastverteilung, Sicherheit und Konnektivität sind keine Funktionen in einzelnen Bausteinen, sondern Querschnittsaspekte, die sich durch jede Ebene ziehen. Das Set an nativen Substitutionen füllt die Lücken, die die Plattform bewusst nicht als verwaltete Produkte anbietet. Die servicebasierte Platzierungs- und Compliance-Karte ist das Artefakt, das das Design unter Audit-Bedingungen verteidigbar macht.

Wichtige Punkte:

• Die geschichtete Struktur ist das Rückgrat; alles andere (VMware-Kern, Kubernetes, KI, Daten-Engines, Hybrid-Verbindungen) hängt daran an. Segmentierung und der Standard auf Privates bestimmen das Layout.
• Hochverfügbarkeit, Lastverteilung, Sicherheit und Konnektivität sind Querschnittsaspekte: Jeder von ihnen wird über Ebenen hinweg aus Plattform-Bausteinen zusammengesetzt, nicht durch ein einzelnes Produkt bereitgestellt.
• Das Set an nativen Substitutionen wird von End zu End umgesetzt: API-Routing über ALB plus Ingress, Read-Skalierung über Cache, Failover über Health-Checks der Load-Balancer-Ziele über zonierte Endpunkte, CDC über Kafka, VM-Import über Bildkonvertierung, Zugriff über Gruppen- und Berechtigungsvergabe.
• Compliance ist pro Service und pro Rechenzentrumsstandort: C5 (Type 1 Attestation, 2023-11-07) und IT-Grundschutz (ISO 27001 Zertifikat, 2022-09-14) haben unterschiedliche Service-Umfänge, und die Platzierungskarte kodiert beide.
• Der regulierte VMware-Kern verwendet ausschließlich VCDA, NSX-T L2 VPN und intra-cluster vMotion; es gibt keine Live-Mobilität über Standorte hinweg, und Datenbanken werden per Dump und Restore migriert.

Weitere Lektüre

• Einheit 8.1: Architekturentscheidungsrahmen (die Auswahlmatrizen, die dieses Design instantiiert)
• Einheit 8.3: Abschlusslabor, das den FinCorp-Unternehmenskern von Anfang bis Ende im Data Center Designer aufbaut
• Einheit 1.2: Die kanonische geschichtete Architektur; Einheit 1.3: Das Modell der nativen Substitution; Einheit 1.4: Souveränität und Compliance als Entwurfsparameter
• IONOS CLOUD Architecture Center