Wissensprüfung - Netzwerk und Konnektivität
FinCorp entwirft ein dreistufiges virtuelles Rechenzentrum: eine öffentliche Web-Ebene, eine private Anwendungsebene und eine private Datenebene. Das Sicherheitsteam möchte, dass die Datenebene nur von der Anwendungsebene aus erreichbar ist, und geht davon aus, dass die Managed Network Load Balancer vor der Datenebene mit einer IP-Zulassungsliste gesperrt werden kann. Was sollte der Architekt ihnen sagen?
NIC-Feuerwände und Network Security Groups binden an Server-NICs und das virtuelle Rechenzentrum, nicht an den gemanagten ALB/NLB oder die Kubernetes-Cluster-Abstraktion. Die richtige Vorgehensweise besteht darin, die Datenebene durch die Topologie (private LAN) zu isolieren und auf den Zielobjekten selbst zu filtern. Die Erwartung, dass das gemanagte Load Balancer die Quellfilterung übernimmt, ist der Grenzfehler, den die Plattform ausdrücklich nicht unterstützt.
Ein selbstverwaltetes Netzwerk Firewall-Gerät muss eine einzelne stabile öffentliche IP präsentieren und zu einer Standby-Instanz übergehen, wenn die aktive Instanz verloren geht. Das Team wird seine eigene Hochverfügbarkeits-Software innerhalb des Geräts ausführen. Welcher IONOS-Baustein passt hierzu, und was müssen sie darüber verstehen?
IP-Failover ist genau das selbstverwaltete aktive-passive-Muster: es bereitstellt eine reservierte öffentliche IP über redundante NICs und lässt die Gast-Hochverfügbarkeits-Software entscheiden, wann sie zu einer Failover-Situation übergeht, weil die Plattform die Dienstgesundheit nicht überwacht. Ein gemanagtes Load Balancer kann keine LAN mit IP-Failover teilen und ist für elastische Ebenen gedacht; das NAT-Gateway ist für ausgehenden Datenverkehr gedacht; das DNS-Failover leitet Namen um, nicht eine einzelne gemeinsame IP auf einem LAN.
FinCorp muss sein lokales Rechenzentrum während der Migration über einen verschlüsselten Site-to-Site-Link mit einem virtuellen Rechenzentrum verbinden. Das lokale Gerät ist derzeit für IKEv1 mit BGP-basierter dynamischer Routing konfiguriert. Was muss der Architekt für den IONOS VPN Gateway planen?
Der IONOS VPN Gateway unterstützt IKEv2 und WireGuard, aber nicht IKEv1, und die Routing erfolgt statisch über die Cloud-Netzwerk- und Peer-Netzwerk-CIDR-Listen; es gibt kein BGP. Der Legacy-Peer muss neu konfiguriert werden, und die gerouteten Subnetze müssen explizit deklariert werden. NAT-Gateway und DNAT sind nicht mit dieser Anforderung verwandt.
Private Anwendungsserver in einem virtuellen Rechenzentrum müssen Betriebssystem-Patches herunterladen und einen externen SaaS API erreichen, dürfen aber nie von dem Internet aus erreichbar sein und dürfen keine öffentlichen IP besitzen. Der Architekt bereitstellt ein NAT-Gateway mit einer reservierten öffentlichen IP und einer SNAT-Regel, aber die Server können das Internet immer noch nicht erreichen. Was ist die wahrscheinlichste Ursache?
Ein NAT-Gateway ist SNAT-only und leitet Datenverkehr nur weiter, wenn die privaten virtuellen Maschinen internetgebundenen Datenverkehr an es weiterleiten; die Routing-Änderung (Standardroute zum Gateway oder pro-Ziel-Routen) ist der Schritt, der am häufigsten übersehen wird. Eine DNAT-Regel existiert nicht in diesem Produkt, und die Zuweisung öffentlicher IPs würde das Ziel des privaten Egress konterkarieren.
Ein Architekt benötigt eine private Verbindung mit geringer Latenz, um Daten zwischen zwei virtuellen Rechenzentren (VDCs) von FinCorp auszutauschen. Die beiden VDCs befinden sich in verschiedenen Regionen und, für eine Abrechnungsisolierung, unter verschiedenen Verträgen. Welche Option ist machbar?
Private Cross-Connect ist kategorisch auf VDCs in der gleichen Region und unter dem gleichen Vertrag beschränkt, die einen IP-Bereich teilen; es kann keine Regionen oder Verträge überspannen. Die Anforderung, Regionen und Verträge zu überspannen, schließt es aus, sodass der Architekt ein anderes Konnektivitätsmodell verwenden muss. Das NAT-Gateway bietet ausgehenden Internet-Zugriff und keine private VDC-zu-VDC-Verbindung.
FinCorp benötigt ein automatisches Failover für einen öffentlichen Dienst, wenn der Endpunkt der primären Region ausfällt und die Clients zum Endpunkt der sekundären Region umgeleitet werden. Es gibt kein gemanagtes Failover-Produkt. Wie sollte der Architekt dies entwerfen, und was ist der dominierende Hebel für die Wiederherstellungszeit?
Ohne ein gemanagtes Failover-Produkt ist das native Muster ein kundenseitig orchestriertes DNS-Failover: Eine externe Gesundheitsprüfung (zum Beispiel aus der Lastverteilungsebene) steuert die Änderung des Cloud DNS-Eintrags auf einen gesunden Endpunkt, und die Eintrag-TTL begrenzt, wie schnell umgeleitete Clients die Änderung übernehmen, wodurch sie der dominierende Wiederherstellungszeithebel wird. Cloud DNS selbst ist nicht gesundheitsbewusst. Da DNS nur neue Verbindungen steuert, muss die vorgelagerte Ebene zustandslos sein. IP-Failover ist an eine Region und einen LAN gebunden, und NAT/Lastverteilungshebel berücksichtigen nicht das Failover von Endpunkten zwischen Regionen.