Einheit 8.2: Die Referenz-Unternehmensarchitektur

Einführung

Jede vorherige Einheit entschied über eine Sache in Isolation: eine Rechenklasse, einen Replikationsmodus, eine Lastverteilungsschicht, einen Ausfallmechanismus. Diese Einheit stellt sie auf einmal auf einem Canvas dar. Der Zweck ist nicht, ein Produkt noch einmal zu erklären, sondern zu zeigen, wie die Entscheidungen zusammenspielen, wo eine Wahl in einer Ebene eine Wahl in einer anderen einschränkt und wie die ehrlichen Grenzen der Plattform das gesamte Bild prägen, anstatt nur den Teil, der sie berührt.

Die Referenzarchitektur ist die von FinCorp: ein deutsches Finanzdienstleistungsunternehmen unter GDPR und BSI-Aufsicht, das einen großen VMware-Bestand migriert und eine KI-Fähigkeit aufbaut. Es ist die Summe aller Entscheidungen, die in den Modulen 1 bis 7 getroffen wurden, und wird als ein einzelnes System dargestellt. Behandeln Sie es als eine Vorlage, die Sie instantiieren, und nicht als ein Diagramm, das Sie kopieren.

1. Das zusammengesetzte System

Die Konstruktion ist nach der kanonischen, schichtweisen Form aus Einheit 1.2 organisiert: eine öffentliche Schicht 7-Kante, eine zustandslose Rechenschicht, ein privater Schicht 4-Lastenausgleich und eine private Daten-Schicht. Um diese Achse herum befinden sich das dedizierte VMware-Anwesen, die Container-Plattform, die KI-Schicht und die Hybrid-Verbindungen zu FinCorps Gelände. Alles befindet sich innerhalb eines Vertrags (die Governance- und Abrechnungsgrenze aus Einheit 2.1) und ist segmentiert über virtuelle Rechenzentren nach Region und Umgebung.

1.1 Segmentierung und der schichtweise Pfad

Ein LAN auf IONOS ist privat, bis es mit dem Internet-Zugang verbunden ist (Einheit 3.1). FinCorps Produktions-VDC enthält drei LANs: ein öffentliches Kanten-LAN, ein privates Anwendungs-LAN und ein privates Daten-LAN. Nord-Süd-Datenverkehr tritt am öffentlichen Rand auf; Ost-West-Datenverkehr zwischen den Schichten bleibt auf privaten LANs und durchquert nie ein öffentliches IP.

Der Anfragepfad ist absichtlich schichtweise gestaltet. Ein öffentlicher Managed Application Load Balancer (ALB) beendet TLS am Rand und leitet auf Layer 7-Attributen weiter; es dient als Kanten-Gerät, das den Nord-Süd-Datenverkehr in und aus dem Rechenzentrum handhabt. Dahinter sitzt die zustandslose Anwendungsschicht auf dediziertem Core-Rechenzentrum. Diese Server erreichen die Daten-Schicht durch einen privaten Managed Network Load Balancer (NLB), der Layer 4-TCP an die Datenbank-Endpunkte weiterleitet und den Ost-West-Datenverkehr innerhalb des Rechenzentrums handhabt. Die öffentliche ALB-zu-private NLB-Zusammensetzung (Einheiten 3.3 und 3.4) ist die Lastverteilungs-Rückgrat: inhaltsbewusst am Rand, wo Routing-Logik wichtig ist, schneller TCP-Durchlauf intern, wo es nicht wichtig ist.

Die Anwendungsschicht ist absichtlich zustandslos. Diese Voraussetzung ermöglicht es, dass sie auto-skaliert (Einheit 4.3) und dass die vorgelagerte Load Balancer neue Verbindungen auf gesunde Replikate umleiten kann, ohne Sitzungsstatus zu verlieren. Sitzungs- und Lesezustand werden externalisiert auf die In-Memory-Cache-Schicht, anstatt auf den Servern gespeichert zu werden.

1.2 Dediziertes VMware für regulierte Verarbeitung

FinCorps regulierter Kern läuft auf IONOS Private Cloud: ein gemanagtes dediziertes VMware-SDDC (vSphere Enterprise Plus, vSAN, NSX-T) auf Single-Tenant-Hardware, mit Lizenzierung, die enthalten ist, anstatt mitgebracht zu werden (Einheit 4.4). Single-Tenancy ist der Design-Treiber hier: die Workloads, die die strengsten Isolations- und Vorhersehbarkeitsanforderungen haben, sitzen auf Hardware, die kein anderer Tenant teilt. Die Bereitstellung ist eine geführte Aktion, kein Selbstbedienungskonsole-Aktion, deshalb ist dieser Teil des Anwesens entworfen und nicht im Data Center Designer erstellt.

Das VMware-Anwesen ist keine Insel. Es verbindet sich mit der elastischen Standard-Rechenkante über die Hybrid-Verbindung, die unten beschrieben wird, und gibt FinCorp das bewährte Hybrid-Muster: ein dediziertes VMware-Kern für regulierte, stabile Verarbeitung plus elastische Standard-Rechenkraft für variable Kanten-Last. Der VMware-Stack hier ist NSX-T 3.2 mit vCenter für die Verwaltung innerhalb des Cluster; die einzigen VMware-Mobilitäts- und Replikations-Tools im Umfang sind jene, die die Plattform tatsächlich bereitstellt und die unten unter Migration behandelt werden.

1.3 Managed Kubernetes für Container

Neue und rekonstruierte Dienste laufen auf Managed Kubernetes (Einheit 6.1). Die Steuerungsebene ist gemanagt und kostenlos; FinCorp zahlt für Node Pools, die ihre eigene SLA haben, getrennt von der Steuerungsebene. Der Cluster bindet an die schichtweise Form durch eine separat bereitgestellte Load Balancer plus einen Ingress-Controller innerhalb des Cluster, da ein Kubernetes-Manifest kein IONOS-gemanagtes Load Balancer automatisch bereitstellt. Ein LoadBalancer-Typ-Dienst wird zu einer einzelnen Node-statistischen IP aufgelöst, nicht zu einem gemanagten Lastenausgleich, sodass der Produktions-Ingress-Pfad ein ALB vor einem Ingress-Controller innerhalb des Cluster ist. Dies ist die API-Gateway-Substitution realisiert: ALB-Pfadregeln plus Ingress-Controller innerhalb des Cluster stehen anstelle eines gemanagten API Gateway, das IONOS nicht verkauft.

Sicherheit auf dem Cluster ist ehrlich geteilt. Network Security Groups und NIC-Feuerwände binden an Worker-Node-NICs, nicht an die Cluster-Abstraktion, sodass Pod-zu-Pod-Kontrolle mit Ingress-Controller innerhalb des Cluster durchgesetzt wird. Container-Bilder kommen aus dem Container-Repository, das durch Token-Disciplin geregelt wird (ein eng gefasster Token pro Pipeline-Phase, mit Ablauf und Rotation; Token werden gelöscht, nicht deaktiviert), da das Repository keine RBAC hat.

1.4 Die Datenplattform

Die Daten-Schicht ist privat-endpoint-only und besteht aus mehreren gemanagten Motoren, die jeweils einem Zugriffsmuster entsprechen:

• Relationale (Managed PostgreSQL / MariaDB): das System der Aufzeichnungen. Es gibt keine Lese-Replikate. Replikation ist innerhalb des Cluster (PostgreSQL asynchron standardmäßig, mit synchronen und streng-synchronen Modi verfügbar; MariaDB asynchron-only) für Dauerhaftigkeit und innerhalb des Cluster-Auto-Förderung, nicht für Lese-Skalierung.
• In-Memory-Cache: die Lese-Skalierungs- und Zustands-Externalisierungsschicht (Einheit 5.5). Es frontiert die relationale Schicht und absorbiert Lese-Last, und es hält Sitzungsstatus, der von der zustandslosen Anwendungsschicht abgehoben wird. Diese Cache ist es, was sowohl das keine-Lese-Replikat-Muster als auch sichere Auto-Skalierung ermöglicht; es ist keine optionale Dekoration.
• Dokument (Managed MongoDB): für die Workloads, deren Form ein Dokument-Modell besser als relationale Zeilen passt.
• Streaming (Gemanagtes Kafka): die Aufnahmespine und die Änderungs-Daten-Erfassung-Substitution. Da es keinen gemanagten Datenbank-Änderungs-Stream gibt, veröffentlichen Anwendungen Ereignisse auf Kafka auf Anwendungsebene. Partitionen sind die Einheit der Ordnung und Consumer-Parallelität; das Thema- und Partition-Design ist die lasttragende Entscheidung.
• Objekt-Archiv (Object Storage): das S3-kompatible flache-Namensraum-Speicher, das als Sicherungsziel, Prüfarchiv, Datensatz- und Artefakt-Speicher und als toter-Buchstabe- und Archiv-Schwanz für Kafka dient. Objekt-Sperre bietet Manipulations-Evidenz-Retention.

1.5 Die KI-Schicht

FinCorps KI-Fähigkeit standardisiert auf gemanagte Inferenz auf dem AI Model Hub: ein OpenAI-kompatibler Inferenz-API, pro-Token-Preis, zustandslos, mit EU-Daten-Residenz und inländischer Verarbeitung. Retrieval-augmentierte Generation ist kundenseitig aus Plattform-Teilen aufgebaut: Einbettungen aus dem Hub, Vektoren in Managed PostgreSQL gespeichert, und die Quell-Corpus in Object Storage. Die Hub-Managed-Vector-Store-Funktion wird vermieden, um dieses zusammengesetzte Muster zu bevorzugen, das den Retrieval-Speicher unter FinCorps eigener Datenbank-Verwaltung hält.

1.6 Hybrid-Verbindung

FinCorps Gelände und sein VMware-Anwesen erreichen die Cloud über die Konnektivitäts-Primitiven aus Einheit 3.6. Ein VPN Gateway (IKEv2 oder WireGuard, kein IKEv1; aktives-passives HA-Teilen eines öffentlichen IP) trägt verschlüsselten Site-to-Cloud-Datenverkehr. Ein NAT-Gateway bietet ausgehenden Egress für private Workloads, die keine öffentliche IP haben; es ist SNAT-only, sodass es ein Egress-Pfad ist, nie ein eingehender Einstiegspunkt. Private Cross-Connect-Verbindungen verbinden VDCs in der gleichen Region und im gleichen Vertrag über eine gemeinsame private Interconnect, einschließlich des cross-VDC-Node-Datenverkehrs, auf den ein privater Kubernetes-Cluster angewiesen ist.

1.7 Widerstandsfähigkeit, Beobachtbarkeit und Kosten als Betriebsumgebung

Widerstandsfähigkeit (Einheit 7.1) basiert auf Plattform-Primitiven anstatt auf einem gemanagten Failover-Produkt, das nicht existiert. Redundante Paare werden in expliziten Verfügbarkeitszonen platziert (nie Auto, das sie ko-lokalisieren kann), und die gemanagten Lastenausgleichs-Produkte überprüfen die Gesundheit ihrer Ziele und hören auf, auf ein fehlgeschlagenes Backend umzuleiten; Cloud DNS bietet anycast-Auflösung und eine niedrige Mindest-TTL für schnelle Aufzeichnungs-Verbreitung, aber führt keine native gesundheitsbasierte Failover durch. Die Verkehrs-Steuerungsebene (DNS) wird getrennt von der Daten-Continuitäts-Ebene (Sicherungen, Snapshots, PITR, Object Storage-Archiv) gehalten. Beobachtbarkeit (Einheit 7.2) umfasst vier feste Telemetrie-Ebenen, Metriken, Protokolle, Prüfung und Netzwerk-Flow Logs, die in ein externes SIEM eingespeist werden, da es keine cross-Vertrags-Aggregation und Kubernetes-Steuerungs-Plane-Ereignisse gibt, die nicht durch die Logging Service fließen. Kosten (Einheit 2.4) werden durch Zuweisung pro Vertrag und VDC, Speicher-Tiering nach Zugriffsmuster und Sparpläne, die auf den stabilen Boden festgelegt sind, geregelt.

2. Querschnittliche Anliegen, keine isolierten Funktionen

Die Architektur hält nur zusammen, weil vier Anliegen durch jede Ebene verlaufen, anstatt in einem einzigen Modul zu leben.

Hochverfügbarkeit wird zusammengesetzt, nicht gekauft. Der Edge-ALB und NLB sind gemanagt und resilient; redundante Rechen- und Datenknoten werden über explizite Zonen verteilt; die gemanagten Lastenausgleichs-Systeme führen Health-Checks ihrer Ziele durch und umgehen fehlgeschlagene Backends; und das dedizierte VMware-Anwesen fügt vSAN-Fehlertoleranz und vSphere-HA innerhalb seiner Cluster hinzu. Kein einzelnes Produkt liefert eine End-to-End-Hochverfügbarkeit; die Architektur schichtet diese Mechanismen.

Lastverteilung erscheint auf zwei Ebenen aus zwei Gründen. Ebene 7 am öffentlichen Rand bietet inhaltsbewusste Routing und TLS-Beendigung; Ebene 4 intern bietet schnellen TCP-Durchgang mit dem Backend, das sein eigenes Zertifikat behält. Kein gemanagter Lastenausgleich akzeptiert eine Netzwerksicherheitsgruppe oder eine IP-Zulassungsliste, sodass die Filterung auf den Zielen hinter ihnen erfolgt.

Sicherheit wird durchgesetzt, wo sie bindet: NIC-Feuerwände und NSGs auf Server- und Arbeitsstation-NICs, in-Cluster-Netzwerkrichtlinien innerhalb von Kubernetes, Token-Disziplin auf dem Register, und Gruppen- und Zugriffssteuerung über den Vertrag. Es gibt keine Richtliniensprache-IAM und keine Ablehnungsregel; das geringste Privileg wird durch Nicht-Gewährung erreicht, und die Federation (SAML/OIDC) ist nur Authentifizierung, sodass der Joiner-Mover-Leaver-Prozess ein manuelles Runbook ist.

Konnektivität verbindet das Anwesen: private LANs für Ost-West-Verkehr, VPN für Standort-zu-Cloud, NAT für private Ausgang, und Cross-Connect für gleichregionale Cross-VDC-Links. Die Topologie selbst ist eine Sicherheitssteuerung, da die Isolierung der Datenebene auf einem privaten LAN das Fehlen von NSG-Unterstützung durch die gemanagten Lastenausgleichs-Systeme kompensiert.

Die folgende Tabelle ordnet jede IONOS-Fähigkeitsgrenze der natürlichen Muster zu, die um sie herum komponiert werden, realisiert in dieser Architektur.

Die Migration in den regulierten VMware-Kern verwendet nur die Tooling, die die Plattform bereitstellt: VMware-Cloud-Director-Verfügbarkeit (VCDA, Version 4.7.x) für asynchrone Replikation, Migration und Live-Failover für etwa 50 EUR pro geschütztem VM pro Monat; NSX-Ts integriertes L2-VPN für Layer-2-Netzwerkerweiterung (ein Standard-NSX-T-Edge-Feature, kein separat lizenzierter Add-on); und intra-Cluster-vMotion. vMotion ist nur intra-Cluster und keine cross-site-Live-Mobility-Funktion. Workloads ohne VMware-native Pfad werden über Bildkonvertierung und Upload neu gehostet, und Datenbanken migrieren durch Dump und Wiederherstellung, da das Backup Service keine gemanagten Datenbanken abdeckt.

Entscheidungszusammenfassung

Das tragende Artefakt der Referenzarchitektur ist die Dienst-für-Dienst-Karte: Wo jedes Komponente platziert ist und genau welches BSI-Anerkennung es abdeckt. Die Compliance ist pro Dienst und pro Rechenzentrum-Standort definiert, nie jedoch plattformweit, sodass die Karte das ist, was ein Auditor liest. BSI C5 ist ein Typ-1-Attest (Testat), das am 2023-11-07 erteilt wurde; IT-Grundschutz ist ein ISO 27001-Zertifikat, das am 2022-09-14 (BSI) erteilt wurde. Beide gelten für deutsche Rechenzentren, und ihre Gültigkeitsbereiche unterscheiden sich pro Dienst. IONOS ist der erste deutsche Cloud-Anbieter, der beide besitzt.

Zwei Leseregeln regieren diese Tabelle. Erstens bedeutet "im Gültigkeitsbereich", dass der benannte Dienst in deutschen Rechenzentren diese BSI-Anerkennung trägt; es lizenziert nie einen plattformweiten Anspruch. C5 deckt genau Compute Engine, Cloud Cubes und S3 Object Storage ab; IT-Grundschutz deckt genau Compute Engine, S3 Object Storage, Sicherung und Managed Kubernetes ab. Die beiden Gültigkeitsbereiche divergieren: Cubes fallen unter C5, aber nicht unter IT-Grundschutz, während Managed Kubernetes und Sicherung unter IT-Grundschutz, aber nicht unter C5 fallen. Zweitens wird der Souveränitätsfilter aus Einheit 1.4 zuletzt über das gesamte Design angewendet: Jede Komponente wird unter EU-Jurisdiktion betrieben, was eine Eigenschaft des Betreibers und nicht nur der Region ist.

Die beiden Zusammensetzungsfehler, gegen die das entworfene Design überprüft werden muss, sind die Kombination inkompatibler Primitiver (z. B. die Erwartung, dass ein NSG einen Managed-Balancer schützt, oder die Verbindung zweier VDCs in verschiedenen Regionen über einen Cross-Connect) und die Platzierung eines funktional korrekten Dienstes außerhalb seines erforderlichen Attestationsbereichs (z. B. die Ausführung von C5-erforderlichem reguliertem Verarbeitung auf einem Dienst, den C5 nicht abdeckt).

Zusammenfassung

Die Referenz-Unternehmensarchitektur ist der gesamte Kurs als ein System dargestellt: ein schichtweise öffentlicher L7-zu-privater L4-Pfad über eine stateless Compute-Ebene und eine private Datenplattform, mit einem dedizierten VMware-Kern für regulierte Verarbeitung, Managed Kubernetes für Container, einer KI-Ebene, die standardmäßig auf gemanagte Inferenz setzt, und hybriden Links, die sie mit den Räumlichkeiten von FinCorp verbinden. Hochverfügbarkeit, Lastverteilung, Sicherheit und Konnektivität sind keine Funktionen in Kästchen, sondern Belange, die durch jede Ebene verlaufen, und die native-Substitutionsmenge ist es, die die Lücken füllt, die die Plattform bewusst nicht als gemanagte Produkte verkauft. Die service-by-service-Platzierung und die Compliance-Karte sind das Artefakt, das den Entwurf unter Audit defensibel macht.

Wichtige Punkte:

• Die schichtweise Form ist die Wirbelsäule; alles andere (VMware-Kern, Kubernetes, KI, Daten-Engines, hybride Links) hängt daran, und Segmentierung plus privat-per-Standard treiben das Layout an.
• Hochverfügbarkeit, Lastverteilung, Sicherheit und Konnektivität sind querlaufend: Jedes ist über Ebenen von Plattform-Primitiven zusammengesetzt, nicht durch ein einzelnes Produkt geliefert.
• Die native-Substitutionsmenge wird von Anfang bis Ende realisiert: API-Routing über ALB plus Ingress, Leseskalierung über Cache, Failover über Lastbalancer-Ziel-Health-Checks über zonale Endpunkte, CDC über Kafka, VM-Import über Bildkonvertierung, Zugriff über Gruppe-und-Gewährung.
• Compliance ist pro Service und pro Rechenzentrum-Standort: C5 (Typ-1-Attestation, 2023-11-07) und IT-Grundschutz (ISO 27001-Zertifikat, 2022-09-14) haben unterschiedliche Service-Umfänge, und die Platzierungskarte kodiert beides.
• Der regulierte VMware-Kern verwendet nur VCDA, NSX-T L2 VPN und intra-Cluster-vMotion; es gibt keine cross-site-Live-Mobilität, und Datenbanken migrieren durch Dump und Wiederherstellung.

Weitere Lektüre

• Einheit 8.1: Architektur-Entscheidungsrahmen (die Auswahlmatrizen, die diese Konstruktion instantiiert)
• Einheit 8.3: Capstone-Lab, das den FinCorp-Unternehmenskern von Anfang bis Ende im Data Center Designer aufbaut
• Einheit 1.2: Die kanonische geschichtete Architektur; Einheit 1.3: Das Native-Substitutionsmodell; Einheit 1.4: Souveränität und Compliance als Design-Eingaben
• IONOS Cloud Architekturzentrum