Einheit 8.3: Capstone-Lab - Aufbau des Unternehmenskerns von Ende zu Ende

Einführung

Jedes vorherige Modul hat einen Teil von FinCorps Umgebung isoliert aufgebaut und diesen Aufbau absichtlich schlank gehalten. In dieser Einheit werden die Teile zu einem System. Sie werden den Produktionskern in einem einzigen virtuellen Rechenzentrum aufbauen: die dreistufige Topologie aus Modul 3, die öffentlichen Layer-7- und privaten Layer-4-Lastverteiler, die PostgreSQL Cluster und den In-Memory DB-Cache auf der privaten Datenebene aus Modul 5, ein Managed Kubernetes Cluster aus Modul 6 und die hybriden VPN- und NAT-Gateways, die den Übergang tragen.

Der Abschlussstein wiederholt nicht jeden Aufbau; er bezieht sich auf die Einheit, die dies getan hat. Was er hinzufügt, ist die Sache, die keine einzelne Einheit zeigen konnte: die Reihenfolge der Montage und die Abhängigkeiten zwischen Ressourcen. Der wiederkehrende Fehler, wenn diese Aufbauten aufeinandertreffen, ist nicht ein falscher Feldwert, sondern eine falsche Reihenfolge, ein Lastverteiler, der vor seinem Ziel erstellt wird, ein Gateway, das vor seiner öffentlichen IP reserviert wird, eine Datenbank, die eine Adresse erhält, die mit DHCP kollidiert. Wenn Sie die Reihenfolge richtig haben, wird die Architektur aus Einheit 8.2 real.

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

Die wichtigste Entscheidung bei einem integrierten Build ist die Reihenfolge. Viele IONOS-Ressourcen können nicht erstellt oder funktionieren nicht, bis etwas anderes existiert, und die Plattform ordnet die Arbeit nicht immer für Sie neu. Behandeln Sie den Build als Abhängigkeitsgraph und lösen Sie ihn von unten nach oben.

Vier Reihenfolgeregelungen tragen den größten Teil des Risikos und jede wurde in einer früheren Einheit etabliert:

• Reservieren Sie öffentliche IPs zuerst. Ein öffentlicher ALB benötigt mindestens einen Listener IP, der VPN Gateway und der NAT-Gateway wählen jeweils aus reservierten Adressen, und ein Kubernetes LoadBalancer-Ingress IP sollte reserviert werden, damit das Löschen eines Service es nicht freigibt. Reservierte IPv4 sind regionsspezifisch, also reservieren Sie es in der Region des VDC. Dies ist die Regel hinter den häufigen Fehlern in den Einheiten 3.1, 3.3 und 3.6.
• Das VDC und seine LANs gehen allem voraus. Die dreifache LAN-Topologie aus Einheit 3.1 ist die Grundlage. Server, Datenbanken, Balancer und Gateways sind alle an LANs angeschlossen, die bereits existieren müssen, mit reservierter Adressierung, damit gemanagte Dienste und Gateways Platz haben (der Bereich .2 bis .9 bleibt frei, die Datenebene auf einer stabilen statischen Adresse).
• Ein Balancer benötigt seine Ziele zuerst. Der private Layer-4-NLB aus Einheit 3.4 verteilt auf Datentierserver, die bereits auf ihrer privaten LAN bereitgestellt werden müssen; ein NLB, der auf Ziele zeigt, die nicht existieren, hat nichts zu routen. Das gleiche gilt für die Anwendungsziele hinter dem Layer-7-ALB.
• Das Hybridnetzwerk geht den Workloads voraus, die von ihm abhängen. Das NAT-Gateway muss existieren und die LAN-Standardroute muss darauf zeigen, bevor private Workloads das Internet für die Paketinstallation oder ausgehende API-Anrufe erreichen können; die Änderung der Routing-Regel ist der Schritt, den Teams vergessen.

Diese Regeln erzeugen eine natürliche Reihenfolge: Netzwerk-Substrat, dann Rechenleistung, dann die Datenebene, dann die Balancer, die sie vorbereiten, dann die Container-Plattform, dann die Hybrid-Kante. Der Walkthrough unten folgt genau dieser Reihenfolge.

2. Die Integrierte Architektur, Die FinCorp Baut

Das Ziel ist die kanonische, geschichtete Form aus Einheit 1.2, jetzt mit den spezifischen Produkten bevölkert, die im Laufe des Kurses ausgewählt wurden. Die folgende Tabelle ordnet jedem Tier ein Produkt zu, die Einheit, in der es erstellt wurde, und die Designentscheidung hinter der Wahl, so dass die Durchlaufreferenz anstelle von Wiederholungen verwendet werden kann.

All dies landet in einem VDC, in einer Region, die zurück in Einheit 1.4 ausgewählt wurde, um GDPR- und BSI-Residenz zu erfüllen. Die Datenebene berührt nie ein öffentliches LAN; die einzigen internetfähigen Oberflächen sind der öffentliche ALB und die beiden Gateways' reservierten IPs.

DCD Implementierung Schritt-für-Schritt

Sie werden den gesamten FinCorp-Kern im virtuellen Rechenzentrum (VDC) aus Einheit 2.1 zusammenbauen, indem Sie die Builds aus den Modulen 3, 5 und 6 in Abhängigkeitsreihenfolge zusammenfügen. Anstatt jeden Feldwert noch einmal zu erwähnen, benennt jeder Schritt die Einheit, die den detaillierten Build dokumentiert, und gibt nur an, was die Integration hinzufügt: was bereits existieren muss, wo es angehängt wird und die eine Entscheidung, die es mit seinen Nachbarn verbindet. Behandeln Sie die Schritt-für-Schritt-Anleitungen pro Einheit als Referenz auf Feldebene und diese als die Montagesequenz.

Ziel des Builds: Den FinCorp-Unternehmenskern von Ende zu Ende im Data Center Designer aufbauen, indem die Modul-Schritt-für-Schritt-Anleitungen zusammengefügt werden.

Voraussetzungen: Das FinCorp-VDC aus Einheit 2.1 mit seiner Region festgelegt; die Reserve IP Blocks- und Create Kubernetes Clusters-Berechtigungen; ein importiertes PEM-Zertifikat (einzelnes RSA-Blatt plus passender Schlüssel) im Certificate Manager für den ALB-HTTPS-Hörer; und die Verbindungsdetails für den IKEv2-Peer des Unternehmensrechenzentrums.

Schritte (im Data Center Designer):

1. Reservieren Sie die öffentlichen IPs (machen Sie dies zuerst). Im Menü > Netzwerkdienste > IP-Verwaltung reservieren Sie öffentliche IPv4-Adressen im VDC-Bereich für: den öffentlichen ALB-Hörer, den VPN Gateway, den NAT-Gateway und den Kubernetes-Eingangs-Endpunkt. Sie erhalten Adressen aus dem Pool, anstatt sie auszuwählen, und jede ist an den Bereich gebunden. Dieser einzelne vorherige Schritt entfernt den häufigsten Fehler bei der Reihenfolge über die Einheiten 3.1, 3.3 und 3.6.

2. Bauen Sie die dreifache LAN-Topologie (wie in Einheit 3.1 aufgebaut). Im FinCorp-VDC erstellen Sie den öffentlichen Rand-LAN (den einzigen LAN, der an den Internetzugang angehängt ist), den privaten Anwendungs-LAN und den privaten Daten-LAN. Behalten Sie jedes Standard-/24 bei, lassen Sie .2 bis .9 für gemanagte Dienste und Gateways frei und verbinden Sie keine privaten LAN mit dem Internet. Diese Segmentierung ermöglicht es, dass die gemanagten Lastenausgleichsgeräte und die Datenbank sicher bleiben, ohne dass ein NSG erforderlich ist.

3. Stellen Sie die Anwendungsebenen-Server bereit (wie in Einheit 4.1 aufgebaut). Platzieren Sie die zustandslosen 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 wird zustandslos gehalten, damit Sitzungsdaten im Cache und nicht auf dem Server leben, und VM Auto Scaling kann Replicas frei hinzufügen und entfernen (Einheit 4.3).

4. Stellen Sie die Daten-Ebenen-Server oder Endpunkte auf dem privaten Daten-LAN bereit. Der Layer-4-Lastenausgleich im Schritt 7 benötigt Ziele, die bereits existieren, sodass die Daten-Ebenen-Ziele vor der Erstellung des NLB vorhanden sein müssen. Geben Sie den Daten-Ebenen-Netzwerkkarten stabile statische Adressen außerhalb des DHCP-Bereichs.

5. Bauen Sie die PostgreSQL Cluster (wie in Einheit 5.3 aufgebaut). Unter Menü > Datenbanken > PostgreSQL erstellen Sie eine mehrere Node Cluster auf dem privaten Daten-LAN. Für das FinCorp-Buchhaltungssystem wählen Sie die streng synchrone Replikation mit drei oder mehr Instanzen, legen Sie ein reales Wartungsfenster außerhalb der Hauptzeit fest 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-Replikation; diese Lücke wird im nächsten Schritt geschlossen.

6. Bauen Sie den In-Memory DB-Cache (wie in Einheit 5.5 aufgebaut). Unter Menü > Datenbanken > In-Memory DB erstellen Sie den Cache auf demselben privaten Daten-LAN mit einer einzelnen privaten Verbindung. Dies ist die leseskalierte Hälfte des Musters ohne Lese-Replikation und der externalisierte Zustandsspeicher, der die Anwendungsebene sicher macht, um automatisch skaliert zu werden. Größen Sie ihn nach RAM auf die Arbeitsmenge zu; erfassen Sie die Anmeldeinformationen bei der Erstellung, da sie später nicht geändert werden können.

7. Bauen Sie den privaten Layer-4-NLB vor der Daten-Ebene (wie in Einheit 3.4 aufgebaut). Platzieren Sie ein Netzwerk-Load Balancer mit beiden Schnittstellen auf privaten LANs: dem Hörer auf dem Anwendungs-LAN und dem Backend auf dem Daten-LAN. Fügen Sie die jetzt existierenden Daten-Ebenen-Server als Ziele mit einer TCP-Weiterleitungsregel und einer TCP-Gesundheitsprüfung hinzu. Der NLB beendet nicht TLS, sodass das Zertifikat auf dem Backend bleibt; dies ist das private Ende des geschichteten Pfads.

8. Bauen Sie den öffentlichen Layer-7-ALB am Rand (wie in Einheit 3.3 aufgebaut). Erstellen Sie zunächst die Zielgruppe der Anwendungsserver, dann platzieren Sie einen Anwendungs-Load Balancer mit seiner nördlichen Schnittstelle auf Internetzugang und seiner südlichen Schnittstelle auf dem Anwendungs-LAN. Konfigurieren Sie den HTTPS-Hörer 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 die Standardregel. Der ALB beendet TLS und gibt der API-Gateway-Substitution sein Randstück; er hat keine Zulassungsliste oder NSG, sodass die Filterung auf den Ziel-Netzwerkkarten bleibt.

9. Bauen Sie die Managed Kubernetes Cluster (wie in Einheit 6.2 aufgebaut). Unter Menü > Container > Managed Kubernetes erstellen Sie einen öffentlichen Cluster mit einem Frankfurt-gestützten Steuerungsebenen-Server, um die Steuerungsebenen-Daten in Deutschland zu halten, dann fügen Sie einen Dedicated Core-Node-Pool hinzu. Hängen Sie die Cluster-Node-Pool-LAN innerhalb desselben VDC an. Reservieren Sie die Eingangs-IP aus Schritt 1, deployen Sie einen Ingress-Controller innerhalb des Cluster, der als einzelne LoadBalancer-Dienst festgelegt ist, und beachten Sie, dass ein LoadBalancer-Dienst eine einzelne Node-statische IP ist, kein gemanagter Lastenausgleich; der reale Layer 7 vor dem Cluster ist der separat bereitgestellte ALB, mit dem Ingress-Controller dahinter.

10. Bauen Sie das NAT-Gateway für privaten Egress (wie in Einheit 3.6 aufgebaut). 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. Dann setzen Sie die Standardroute (0.0.0.0/0) des privaten LAN auf das Gateway; ohne diese Routing-Änderung tritt der Egress stillschweigend nie auf. NAT ist SNAT-only, sodass es keinen eingehenden Pfad bietet. Fügen Sie eine UDP-SNAT-Regel hinzu, damit DNS für VMs, die den NAT-Standardpfad verwenden, weiterhin aufgelöst wird.

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

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

Häufige Fehler:

• Ein Verbraucher vor seiner reservierten IP-Adresse zu erstellen. Der ALB-Hörer, beide Gateways und der Kubernetes-Eingang erwarten eine reservierte Adresse; reservieren Sie alle in Schritt 1, im richtigen Bereich, bevor etwas eine davon verbraucht.
• Den NLB vor den Daten-Ebenen-Zielen zu erstellen. Ein Lastenausgleich, der auf fehlende Ziele zeigt, leitet zu nichts weiter; stellen Sie die Daten-Ebene (Schritt 4) vor dem NLB (Schritt 7) bereit.
• Das NAT-Gateway auf das falsche Ziel zu zeigen oder die Standardroute zu vergessen. NAT ist SNAT-only mit keinem eingehenden Pfad und das Gateway tut nichts, bis die Standardroute des privaten LAN auf es umgeleitet wird. Fügen Sie die UDP-SNAT-Regel hinzu, oder DNS bricht für diese VMs.
• Den Kubernetes-LoadBalancer-Dienst als die wahre Eingangstür des Cluster zu behandeln. Es ist eine einzelne Node-statische IP, die auf die Durchsatzleistung dieses Node beschränkt ist; der Produktions-Layer 7-Eingang ist der separat bereitgestellte ALB, mit dem Ingress-Controller dahinter.
• Die Kubernetes-Steuerungsebene in einem US-Rechenzentrum für diese regulierte Workload zu platzieren. Wählen Sie die Frankfurt-Steuerungsebene, damit die Steuerungsebenen-Daten in Deutschland bleiben; die Node-Pool-Daten bleiben im gewählten Bereich, unabhängig davon.
• Eine private LAN mit dem Internet "zum Testen" zu verbinden oder zu versuchen, einen gemanagten ALB oder NLB in eine Netzwerksicherheitsgruppe einzuschließen. Die gemanagten Lastenausgleichsgeräte haben keine NSG; die Sicherheit der Daten-Ebene kommt vollständig von ihrer Position auf einer privaten LAN, sodass eine einzelne Internetverbindung auf der Daten-LAN das Compliance-Argument zerstört.
• Dem PostgreSQL-Cluster oder dem Cache eine Adresse innerhalb des DHCP-Bereichs zuzuweisen. Wiederverwenden Sie die ersten drei Oktette des LAN und wählen Sie eine Adresse, die DHCP nie zuweist (endend mit .3 bis .10); eine Kollision produziert intermittierende, schwer zu diagnostizierende Verbindungsfehler.
• Die VPN-Phase-1- oder Phase-2-Parameter zwischen dem IONOS-Gateway und dem Unternehmens-Peer nicht zu entsprechen oder nach einer IKEv1-Option zu suchen. Es gibt keine IKEv1; die Parameter müssen auf beiden Enden genau übereinstimmen, oder der Tunnel wird nie hergestellt, und das HA-Paar präsentiert eine einzelne IP zum Peer.

Zusammenfassung

Der FinCorp-Kern ist jetzt ein virtuelles Rechenzentrum, das die geschichtete Architektur aus Einheit 1.2 realisiert: ein öffentliches Layer-7-ALB, das TLS am Rand beendet, eine zustandslose Dedicated-Core-Anwendungsebene, ein privates Layer-4-NLB und eine private Daten-Ebene eines streng synchronen PostgreSQL Cluster, das von einem In-Memory DB-Cache vorgerendert wird, mit einem Managed Kubernetes Cluster und den Hybrid-VPN- und NAT-Gateways, die angehängt sind. Die Lektion des Capstone ist nicht irgendein einzelner Feldwert; diese wurden in den per-Modul-Builds etabliert. Es ist vielmehr, dass eine integrierte Umgebung ein Abhängigkeitsgraph ist und dass ein Bottom-up-Aufbau (IPs, dann LANs, dann Rechenressourcen, dann Daten, dann Lastverteilung, dann Container, dann Hybrid-Edge) das ist, was eine Menge korrekter individueller Builds in eine kohärente, konforme, Produktionsarchitektur verwandelt.

Wichtige Punkte:

• Die Build-Reihenfolge ist ein Abhängigkeitsgraph: reservieren Sie öffentliche IPs zuerst, erstellen Sie LANs, bevor etwas angehängt wird, bereitstellen Sie Ziele, bevor der Lastverteiler, der sie bedient, und ändern Sie die Standardroute, bevor Sie NAT-Egress erwarten.
• Die Daten-Ebene berührt nie ein öffentliches LAN; Segmentierung, nicht eine NSG, ist es, was die gemanagten Lastverteiler und die Datenbank schützt, weil die gemanagten Lastverteiler keine NSG haben.
• Der PostgreSQL Cluster hat keine Lese-Replikation; der In-Memory DB-Cache ist die Lese-Skalierungs-Ersetzung und der externalisierte Zustand, der es der Anwendungsebene ermöglicht, sicher zu skalieren und auszufallen.
• Der Kubernetes Cluster's LoadBalancer-Service ist ein einzelner Node-statischer IP, nicht der Produktions-Eintragspunkt; das öffentliche ALB plus ein in-Cluster-Ingress-Controller ist die echte Layer-7-Eingangstür, und eine Frankfurt-Steuerungsebene hält Steuerungsdaten in Deutschland.
• Das Capstone bezieht sich auf jede per-Modul-Einheit, anstatt sie zu wiederholen: die schlanken per-Modul-Labore existieren, damit dieses Integrations-Labor die Synthese tragen kann.

Weitere Lektüre

• Einheit 8.2: Die Referenz-Unternehmensarchitektur (das Design, das in diesem Labor realisiert wird)
• Einheit 3.1, 3.3, 3.4, 3.6: die Netzwerk- und Lastverteilungsbauten, die hier zusammengefügt werden
• Einheit 5.3, 5.5: die relationale Cluster und Cache auf der privaten Datenebene
• Einheit 6.2: der öffentliche Managed Kubernetes Cluster-Bau
• Einheit 7.1: die Verkabelung der Ausfallsicherheit und des Failovers über diesen Kern