Einheit 8.3: Abschlusslabor - Aufbau des Enterprise-Kerns von Anfang bis Ende

Einführung

Jedes vorherige Modul hat einen Teil der Umgebung von FinCorp isoliert aufgebaut und diesen Aufbau bewusst schlank gehalten. In dieser Einheit werden die einzelnen Teile zu einem System. Sie richten den Produktionskern in einem einzigen virtuellen Rechenzentrum ein: die dreistufige Topologie aus Modul 3, die öffentlichen Layer-7- und privaten Layer-4-Load Balancer, die PostgreSQL-Cluster und die In-Memory DB-Caches auf der privaten Datenebene aus Modul 5, einen Managed Kubernetes-Cluster aus Modul 6 sowie die hybriden VPN- und NAT-Gateways, die den Wechsel (Cutover) ermöglichen.

Die Abschlussarbeit wiederholt nicht jede einzelne Einrichtung; sie verweist auf die Einheit, die sie durchgeführt hat. Was sie ergänzt, ist das, was keine einzelne Einheit zeigen konnte: die Reihenfolge der Zusammenführung und die Abhängigkeiten zwischen Ressourcen. Der wiederkehrende Fehler, wenn diese Aufbauten aufeinandertreffen, ist nicht ein falscher Feldwert, sondern eine falsche Reihenfolge: ein Load Balancer, der erstellt wird, bevor seine Ziele existieren, ein Gateway, das erstellt wird, bevor seine öffentliche IP reserviert ist, oder eine Datenbank, der eine Adresse zugewiesen wird, die mit DHCP kollidiert. Wenn die Reihenfolge stimmt, wird die Architektur aus Einheit 8.2 Realität.

1. Die Build-Reihenfolge ist ein Abhängigkeitsgraph, keine Checkliste

Die entscheidendste Wahl bei einem integrierten Build ist die Reihenfolge. Mehrere IONOS CLOUD-Ressourcen können erst erstellt oder erst funktionsfähig sein, wenn andere Komponenten bereits vorhanden sind, und die Plattform sortiert die Arbeit nicht immer automatisch um. Behandeln Sie den Build als Abhängigkeitsgraph und lösen Sie ihn von unten nach oben auf.

Vier Reihenfolge-Regeln tragen das größte Risiko, und jede wurde in einer früheren Einheit festgelegt:

• Reservieren Sie öffentliche IPs zuerst. Ein öffentlicher ALB benötigt mindestens eine Listener-IP, das VPN Gateway und das NAT Gateway wählen jeweils aus reservierten Adressen, und die Kubernetes LoadBalancer Ingress-IP sollte reserviert werden, damit das Löschen eines Service sie nicht freigibt. Reserviertes IPv4 ist an eine Region gebunden, daher reservieren Sie es in der Region des VDC. Diese Regel steht hinter den häufigen Fehlern in den Einheiten 3.1, 3.3 und 3.6.
• Der VDC und seine LANs gehen allem voraus. Die Topologie mit drei LANs aus Einheit 3.1 ist das Fundament. Server, Datenbanken, Balancer und Gateways werden alle an LANs angehängt, die bereits existieren müssen, mit reservierter Adressierung, damit verwaltete Dienste und Gateways Platz haben (der Bereich von .2 bis .9 bleibt frei, die Daten-Ebene erhält eine stabile statische Adresse).
• Ein Balancer benötigt zuerst seine Ziele. Der private Layer 4 NLB aus Einheit 3.4 verteilt auf Server der Daten-Ebene, die bereits auf ihrem privaten LAN bereitgestellt sein müssen; ein NLB, der auf Ziele zeigt, die nicht existieren, hat nichts zum Routen. Dasselbe gilt für die Anwendungsziele hinter dem Layer 7 ALB.
• Das hybride Netzwerk geht den Workloads voraus, die von ihm abhängen. Das NAT Gateway muss existieren und der Standard-Route des LANs muss darauf zeigen, bevor private Workloads das Internet für die Paketinstallation oder ausgehende API-Aufrufe erreichen können; die Änderung der Routing-Konfiguration ist der Schritt, den Teams vergessen.

Diese Regeln ergeben eine natürliche Reihenfolge: Netzwerk-Fundament, dann Compute, dann die Daten-Ebene, dann die Balancer, die sie fronten, dann die Container-Plattform, dann der hybride Rand. Die folgende Anleitung folgt genau dieser Reihenfolge.

2. Die integrierte Architektur, die FinCorp aufbaut

Das Ziel ist die kanonische geschichtete Struktur aus Einheit 1.2, die nun mit den im gesamten Kurs gewählten spezifischen Produkten besetzt ist. Die folgende Tabelle ordnet jede Ebene dem jeweiligen Produkt, der Einheit, in der sie aufgebaut wurde, und der Designentscheidung hinter der Wahl zu, damit der Walkthrough darauf verweisen kann, statt sie zu wiederholen.

Alles davon befindet sich in einem VDC, in einer Region, die bereits in Einheit 1.4 gewählt wurde, um DSGVO- und BSI-Residenzvorgaben zu erfüllen. Die Datenebene berührt niemals ein öffentliches LAN; die einzigen internetzugänglichen Oberflächen sind der öffentliche ALB und die reservierten IPs der beiden Gateways.

DCD-Implementierungsanleitung

Sie bauen den kompletten FinCorp-Kern im VDC auf, der in Einheit 2.1 erstellt wurde, und fügen die Builds aus den Modulen 3, 5 und 6 in Abhängigkeitsreihenfolge zusammen. Anstatt jedes Feld erneut aufzuführen, benennt jeder Schritt die Einheit, die den detaillierten Build dokumentiert, und nennt nur, was die Integration hinzufügt: was bereits vorhanden sein muss, wo es angehängt wird und die eine Entscheidung, die es mit seinen Nachbarn verbindet. Behandeln Sie die Einheiten-Anleitungen als Referenz auf Feld-Ebene und diesen Text als Montagesequenz.

Bauziel: Bauen Sie den FinCorp-Unternehmenskern von Anfang bis Ende im Data Center Designer und verknüpfen Sie die Modul-Anleitungen.

Voraussetzungen: Das FinCorp-VDC aus Einheit 2.1 mit fester Region; die Reserve IP Blocks und Create Kubernetes Clusters Berechtigungen; ein importiertes PEM-Zertifikat (ein einzelnes RSA-Blatt plus passender Schlüssel) im Certificate Manager für den HTTPS-Listener des ALB; und die Verbindungsdaten für den IKEv2-Peer des Unternehmens-Rechenzentrums.

Schritte (im Data Center Designer):

1. Reservieren Sie die öffentlichen IPs (machen Sie dies zuerst). Unter Menü > Netzwerk-Dienste > IP-Verwaltung reservieren Sie öffentliche IPv4-Adressen in der Region des VDC für: den öffentlichen ALB-Listener, das VPN Gateway, das NAT Gateway und den Kubernetes-Ingress-Endpunkt. Sie erhalten Adressen aus dem Pool, anstatt sie auszuwählen, und jede ist an die Region gebunden. Dieser einzelne vorab durchgeführte Schritt eliminiert den häufigsten Reihenfolgefehler über die Einheiten 3.1, 3.3 und 3.6 hinweg.

2. Bauen Sie die Topologie mit drei LANs (wie in Einheit 3.1 gebaut). Erstellen Sie im FinCorp-VDC das öffentliche Edge-LAN (das einzige LAN, das an Internet Access angeschlossen ist), das private Anwendungs-LAN und das private Daten-LAN. Halten Sie jede Standard-/24-Subnetzmaske bei, lassen Sie .2 bis .9 für verwaltete Dienste und Gateways frei und verbinden Sie weder das private LAN mit dem Internet. Diese Segmentierung ist es, die es den verwalteten Load Balancern und der Datenbank ermöglicht, sicher zu bleiben, ohne eine NSG.

3. Stellen Sie die Server der Anwendungsebene bereit (wie in Einheit 4.1 gebaut). Platzieren Sie die statelessen Anwendungsserver auf dem privaten Anwendungs-LAN als Dedicated Core-Server. Dedicated Core ist die bewusste Wahl für eine vorhersehbare Leistungsgarantie unter Last; die Ebene bleibt stateless, damit Sitzungsdaten im Cache und nicht auf dem Server liegen, und damit VM Auto Scaling Replikate frei hinzufügen und entfernen kann (Einheit 4.3).

4. Stellen Sie die Server oder Endpunkte der Datenebene auf dem privaten Daten-LAN bereit. Der Layer-4-Load Balancer in Schritt 7 benötigt Ziele, die bereits existieren, daher müssen die Ziele der Datenebene vor der Erstellung des NLB vorhanden sein. Vergeben Sie den NICs der Datenebene stabile statische Adressen außerhalb des DHCP-Bereichs.

5. Bauen Sie den PostgreSQL-Cluster (wie in Einheit 5.3 gebaut). Unter Menü > Datenbanken > PostgreSQL erstellen Sie einen Multi-Node-Cluster auf dem privaten Daten-LAN. Wählen Sie für das Hauptbuch von FinCorp die strikt synchrone Replikation mit drei oder mehr Instanzen, setzen Sie ein echtes Wartungsfenster außerhalb der Spitzenlast und weisen Sie eine private IP zu, die zwischen .3 und .10 endet, damit sie nie mit DHCP kollidiert. Es gibt keinen öffentlichen Endpunkt und keine Lese-Replikate; diese Lücke wird im nächsten Schritt geschlossen.

6. Bauen Sie den In-Memory DB-Cache (wie in Einheit 5.5 gebaut). Unter Menü > Datenbanken > In-Memory DB erstellen Sie den Cache auf demselben privaten Daten-LAN mit einer einzelnen privaten Verbindung. Dies ist die Hälfte der Skalierung für Lesezugriffe des Musters ohne Lese-Replikate und der externalisierte Zustandspeicher, der die Anwendungsebene sicher für das automatische Skalieren macht. Dimensionieren Sie ihn nach RAM entsprechend dem Arbeitsspeicherbedarf; erfassen Sie die Zugangsdaten bei der Erstellung, da sie später nicht geändert werden können.

7. Bauen Sie den privaten Layer-4-NLB vor der Datenebene (wie in Einheit 3.4 gebaut). Platzieren Sie einen Network Load Balancer mit beiden Schnittstellen auf privaten LANs: der Listener auf dem Anwendungs-LAN, das Backend auf dem Daten-LAN. Fügen Sie die nun vorhandenen Server der Datenebene als Ziele mit einer TCP-Weiterleitungsregel und einer TCP-Health-Check hinzu. Der NLB terminiert kein TLS, daher bleibt das Zertifikat auf dem Backend; dies ist das private Ende des geschichteten Pfads.

8. Bauen Sie den öffentlichen Layer-7-ALB am Edge (wie in Einheit 3.3 gebaut). Erstellen Sie zuerst die Zielgruppe der Anwendungsserver, dann platzieren Sie einen Application Load Balancer mit seiner nördlichen Schnittstelle an Internet Access und seiner südlichen Schnittstelle am Anwendungs-LAN. Konfigurieren Sie den HTTPS-Listener auf der reservierten öffentlichen IP aus Schritt 1 mit dem importierten PEM-Zertifikat, fügen Sie eine pfadbasierte Weiterleitungsregel hinzu, die auf die Zielgruppe zeigt, und ordnen Sie spezifische Regeln über der Standardregel. Der ALB terminiert TLS und gibt der API-Gateway-Ersatzlösung seine Edge-Hälfte; er hat keine Allowlist oder NSG, daher bleibt die Filterung auf den Ziel-NICs.

9. Bauen Sie den Managed Kubernetes-Cluster (wie in Einheit 6.2 gebaut). Unter Menü > Container > Managed Kubernetes erstellen Sie einen öffentlichen Cluster mit einer in Frankfurt angesiedelten Steuerungsebene, um Steuerungsdaten in Deutschland zu halten, fügen Sie dann einen Dedicated Core-Knotenpool hinzu. Hängen Sie das LAN des Knotenpools des Clusters innerhalb desselben VDC an. Reservieren Sie die Ingress-IP aus Schritt 1, deployen Sie einen In-Cluster-Ingress-Controller, der als einzelner LoadBalancer Service an diese IP gepinnt wird, und denken Sie daran, dass ein LoadBalancer Service eine statische IP eines einzelnen Knotens ist, kein verwalteter Load Balancer; der echte Layer-7-Eingang vor dem Cluster ist der ALB aus Schritt 8.

10. Bauen Sie das NAT Gateway für privaten Ausgang (wie in Einheit 3.6 gebaut). Fügen Sie ein NAT Gateway hinzu, verbinden Sie es mit dem privaten Anwendungs-LAN, weisen Sie ihm eine reservierte öffentliche IP aus Schritt 1 zu und erstellen Sie eine SNAT-Regel für das Anwendungs-Subnetz. Setzen Sie dann den Standardpfad (0.0.0.0/0) des privaten LANs auf das Gateway; ohne diese Routing-Änderung erfolgt der Ausgang stillschweigend nie. NAT ist nur SNAT, daher bietet es keinen Eingangspfad. Fügen Sie eine UDP-SNAT-Regel hinzu, damit DNS für VMs, die den NAT-Standardpfad verwenden, noch aufgelöst wird.

11. Bauen Sie das VPN Gateway und den Tunnel zum Unternehmens-Rechenzentrum (wie in Einheit 3.6 gebaut). Erstellen Sie ein IKEv2-VPN Gateway auf seiner reservierten öffentlichen IP, hängen Sie es mit einer Gateway-Adresse im Bereich .2 bis .9 am privaten LAN an und erstellen Sie dann einen Tunnel zum Unternehmens-Peer mit einem starken PSK und passenden Phase-1- und Phase-2-Parametern. Listen Sie die CIDRs der Cloud- und Peer-Netzwerke als statischen Routing-Vertrag auf; es gibt kein BGP. Wählen Sie die Hochverfügbarkeits-Variante, damit das aktiv-passive Paar die einzelne Gateway-IP teilt.

12. Stellen Sie das gesamte VDC bereit und validieren Sie es. Stellen Sie die angesammelten Änderungen bereit. Validieren Sie den geschichteten Pfad von Anfang bis Ende: Ein Client erreicht den ALB über HTTPS auf seiner öffentlichen IP, die Anwendungsebene liest durch den Cache und fällt bei einem Miss auf PostgreSQL zurück, der NLB verteilt verschlüsselte Verbindungen an die Datenebene, private Workloads erreichen das Internet nur über das NAT Gateway und das Unternehmens-Rechenzentrum erreicht die privaten LANs nur über den VPN-Tunnel. Die Datenebene ist von nirgendwo öffentlich erreichbar.

Häufige Fehler:

• Erstellen eines Consumers, bevor seine reservierte IP existiert. Der ALB-Listener, beide Gateways und der Kubernetes-Ingress erwarten alle eine reservierte Adresse; reservieren Sie alle in Schritt 1, in der richtigen Region, bevor etwas eine davon verbraucht.
• Erstellen des NLB, bevor die Ziele der Datenebene existieren. Ein Load Balancer, der auf nicht vorhandene Ziele zeigt, routet nirgendwohin; stellen Sie die Datenebene (Schritt 4) vor dem NLB (Schritt 7) bereit.
• Zeigen des NAT Gateways auf das Falsche oder Vergessen des Standardpfads. NAT ist nur SNAT ohne Eingangspfad, und das Gateway tut nichts, bis der Standardpfad des privaten LANs auf es umgeleitet wird. Fügen Sie auch die UDP-SNAT-Regel hinzu, sonst bricht DNS für diese VMs.
• Behandeln des Kubernetes LoadBalancer Service als der echten Eingangstür des Clusters. Es ist eine statische IP eines einzelnen Knotens, begrenzt auf die Durchsatzkapazität dieses Knotens; der produktionsreife Layer-7-Eingang ist der separat bereitgestellte ALB, mit dem In-Cluster-Ingress-Controller dahinter.
• Platzieren der Kubernetes-Steuerungsebene in einem US-Rechenzentrum für diese regulierte Workload. Wählen Sie die Frankfurt-Steuerungsebene, damit Steuerungsdaten in Deutschland bleiben; Knotenpool-Daten bleiben unabhängig davon in der gewählten Region.
• Verbinden eines privaten LANs mit dem Internet "zum Testen" oder Versuch, einen verwalteten ALB oder NLB in eine Network Security Group zu hüllen. Die verwalteten Load Balancer haben keine NSG; die Sicherheit der Datenebene kommt vollständig vom Leben auf einem privaten LAN, daher zersetzt eine einzelne Internetverbindung auf dem Daten-LAN das Compliance-Argument.
• Vergabe einer Adresse innerhalb des DHCP-Bereichs an den PostgreSQL-Cluster oder den Cache. Wiederverwenden Sie die ersten drei Oktette des LANs und wählen Sie eine Adresse, die DHCP nie zuweist (Endung .3 bis .10); eine Kollision erzeugt intermittierende, schwer zu diagnostizierende Verbindungsfehler.
• Nicht übereinstimmende VPN-Phase-1- oder Phase-2-Parameter zwischen dem IONOS CLOUD-Gateway und dem Unternehmens-Peer oder Suche nach einer IKEv1-Option. Es gibt kein IKEv1; die Parameter müssen auf beiden Enden exakt übereinstimmen, sonst wird der Tunnel nie aufgebaut, und das HA-Paar präsentiert dem Peer eine geteilte IP.

Zusammenfassung

Der FinCorp-Kern ist nun ein VDC, der die in Einheit 1.2 beschriebene geschichtete Architektur umsetzt: ein öffentlicher Layer-7-ALB, der TLS an der Kante terminiert, eine zustandslose Application-Tier-Ebene für Dedicated Core, ein privater Layer-4-NLB sowie eine ausschließlich private Daten-Ebene, bestehend aus einem streng synchronen PostgreSQL-Cluster, der durch einen In-Memory DB-Cache vorgeschaltet wird. Zusätzlich sind ein Managed Kubernetes-Cluster sowie die hybriden VPN- und NAT-Gateways angeschlossen. Die zentrale Erkenntnis aus diesem Abschlussprojekt ist nicht ein einzelner Feldwert; diese wurden bereits in den modulbezogenen Builds festgelegt. Entscheidend ist, dass eine integrierte Umgebung ein Abhängigkeitsgraph ist und dass der bottom-up-Aufbau (IPs, dann LANs, dann Compute, dann Daten, dann Balancer, dann Container, dann der hybride Edge) eine Reihe korrekter individueller Builds in eine kohärente, konforme Produktionsarchitektur verwandelt.

Wichtige Punkte:

• Die Build-Reihenfolge ist ein Abhängigkeitsgraph: Öffentliche IPs zuerst reservieren, LANs erstellen, bevor etwas daran angeschlossen wird, Zielsysteme vor dem Balancer provisionieren, der sie bedient, und den Standard-Route neu ausrichten, bevor NAT-Egress erwartet wird.
• Die Daten-Ebene berührt niemals ein öffentliches LAN; Segmentation, nicht eine NSG, schützt die verwalteten Balancer und die Datenbank, da die verwalteten Balancer keine NSG besitzen.
• Der PostgreSQL-Cluster hat keine Lese-Replik; der In-Memory DB-Cache ist der Ersatz für Read-Skalierung und der externalisierte Zustand, der es der Application-Tier-Ebene ermöglicht, sicher zu skalieren und Failover durchzuführen.
• Der LoadBalancer-Service des Kubernetes-Clusters ist eine statische IP auf einem einzelnen Knoten, nicht der Produktions-Einstiegspunkt; der öffentliche ALB zusammen mit einem In-Cluster-Ingress-Controller ist das eigentliche Layer-7-Eingangstor, und eine Steuerungsebene in Frankfurt hält Steuerungsdaten in Deutschland.
• Das Abschlussprojekt verweist auf jede modulbezogene Einheit, statt sie zu wiederholen: Die schlanken modulbezogenen Labs existieren, damit dieses Integrations-Lab die Synthese tragen kann.

Weitere Lektüre

• Einheit 8.2: Die Referenz-Unternehmensarchitektur (das Design, das dieses Labor umsetzt)
• Einheit 3.1, 3.3, 3.4, 3.6: die hier verknüpften Netzwerk- und Load-Balancing-Bausteine
• Einheit 5.3, 5.5: das relationale Cluster und der Cache auf der privaten Datenebene
• Einheit 6.2: der öffentliche Managed Kubernetes Cluster
• Einheit 7.1: die Verdrahtung von Resilienz und Failover über diesem Kern