VCN-Topologie und -Spezifikationen identifizieren

Wählen Sie eine VCN-Topologie und -Spezifikationen aus, die Ihren Geschäftsanforderungen am besten entsprechen.

Einzelne Netzwerkarchitektur

Wenn Ihr Netzwerk für einen Proof-of-Concept (PoC) oder einen Schnelltest gedacht ist, funktioniert eine Single-Network-Architektur – ohne eine dedizierte Firewall zwischen On-Premises und OCI oder zwischen VCNs – gut. Bei Bedarf können Sie später weitere VCNs anhängen.

Das folgende Diagramm zeigt ein Beispiel für eine Single-Network-Architektur:

Beschreibung der Abbildung single-vcn-topology.png

Hinweis:

Oracle empfiehlt die Verwendung von Oracle Cloud Infrastructure Web Application Firewall (OCI WAF) oder OCI Network Firewall aus Sicherheitsgründen, wenn Sie internetseitige Anwendungen (öffentliche IPs) verwenden.

Hub-and-Spoke-Netzwerkarchitektur

Oracle empfiehlt eine Hub-and-Spoke-Architektur für Deployments, die möglicherweise in Zukunft skaliert werden müssen. Diese Topologie unterstützt zentralisierte Firewalls, Trafficprüfungen, Managementknoten und ermöglicht Firewall-Software zwischen On-Premises und OCI oder zwischen VCNs (Ost-West-Traffic).

Das folgende Diagramm zeigt ein Beispiel für die Verwendung einer Hub-and-Spoke-Netzwerkarchitektur:

Beschreibung der Abbildung hub-and-spoke-topology.png

Hub-and-Spoke-Netzwerkarchitektur ist die von Oracle empfohlene Architektur für die meisten Deployments. Verwenden Sie eine Hub-and-Spoke-Netzwerkarchitektur, wenn Ihr Unternehmen Folgendes benötigt (keine exklusive Liste):

• Verwenden Sie mehrere VCNs (oder planen Sie die Verwendung), um Workloads zu trennen.
• Zentralisieren Sie internetseitigen Traffic in einem Hub-VCN, in dem Netzwerkfirewall, internetseitige Load Balancer, WAF- und Internetgatewayressourcen verwaltet werden.
• Aufrechterhaltung der Netzwerktrennung für Produktions-, Test- und Entwicklungsumgebungen.

Spezifikationen für virtuelles Cloud-Netzwerk

Oracle empfiehlt, dass Sie alle verfügbaren OCI-Funktionen nutzen, um die Resilienz der Architektur zu maximieren. Entwerfen Sie in Regionen mit drei Availability-Domains Ihr VCN, sodass seine Subnetze alle Domains umfassen können.

Die folgende Abbildung zeigt, wie Sie die Nutzung von Availability-Domains für High Availability-Designs maximieren können.

Beschreibung der Abbildung vcn-network-design-example.png

Oracle empfiehlt:

• Verwendung regionaler Subnetze, die sich über alle Availability-Domains erstrecken, für High Availability.
• Erstellen separater VCNs für verschiedene Workloads.

Hinweis:

Verwenden Sie für Regionen mit einer einzelnen Availability-Domain Faultdomains, um die Resilienz zu verbessern.

Größe Ihres VCN oder Ihrer Subnetze festlegen

Planen Sie Ihre VCNs für eine zukünftige Erweiterung, und wählen Sie einen IP-Adressbereich aus, der Überschneidungen mit Ihren On-Premise- oder anderen Netzwerken vermeidet.

In der folgenden Tabelle wird beschrieben, wie Sie Ihre VCNs je nach Bedarf skalieren können.

VCN-Größe	Netzmaske	Subnetzgröße	Anzahl Subnetze im VCN	Verwendbare IPs pro Subnetz
Klein	/24	/27	8	29
Mittel	/20	/24	16	253
Groß	/18	/22	16	1.021
Sehr groß	/16	/20	8	4.093

Verschiedene Subnetze in einem VCN können unterschiedliche CIDR-Blockgrößen verwenden, um für bestimmte Workload-Anforderungen zu optimieren.

Hinweis:

OCI reserviert in jedem Subnetz drei IP-Adressen.

Sicherheitslisten und Netzwerksicherheitsgruppen

Mit Sicherheitslisten können Sie eine Gruppe von Sicherheitsregeln definieren, die für alle Ressourcen in einem Subnetz gelten.

Verwenden Sie NSGs für eine detailliertere Sicherheit auf Anwendungsebene. Mit NSGs können Sie Regeln für bestimmte VNICs, Load Balancer, Datenbanksysteme usw. definieren.

Die folgende Grafik zeigt ein Beispiel dafür, wie Sie die Subnetzarchitektur des VCN von den Sicherheitsanforderungen mit NSGs trennen und nur Ressourcen zulassen, die NSG_DB1 verwenden, um mit NSG_App1 eine Verbindung zur Ressource herzustellen.

Beschreibung der Abbildung vcn-subnet-app-security-nsg-isolation.png

Sie können sowohl Sicherheitslisten als auch NSGs verwenden, um den Zugriff auf Ihre Ressourcen in privaten und öffentlichen Subnetzen zu kontrollieren. Wenn Sie sowohl NSGs als auch Sicherheitslisten verwenden, werden die kombinierten Übersichtsregeln aus der NSG und der Sicherheitsliste als Ergebnis verwendet.

Oracle empfiehlt die Verwendung von NSGs für:

• Trennen Sie die VCN-Subnetzarchitektur von den Sicherheitsanforderungen der Anwendung.
• Definieren Sie ein Set von Ingress- und Egress-Regeln, die für bestimmte VNICs gelten.

Tipp:

Wenn Sie Sicherheitslisten verwenden, empfiehlt Oracle, eine einzelne Sicherheitsliste pro Subnetz anstelle einer kombinierten Liste für alle Subnetze zu verwenden.

Routentabellen

Routentabellen sind sowohl auf VCN- als auch auf DRG-(Dynamic Routing Gateway-)Ebene vorhanden. Auf DRG-Ebene können Routentabellen statische Anweisungen sein oder über Importroutenverteilungen dynamisch importiert werden. Sie leiten Traffic von einem Anhang an den Zielanhang weiter, basierend auf dem in der Routentabelle festgelegten IP-Präfix. Erstellen Sie spezifische Routentabellen für jeden Anhang. Verwenden Sie automatisch generierte Standardroutentabellen nur zum Testen oder für einfache Prototypen.

Tipp:

Oracle empfiehlt, Routen mit Importroutenverteilungen zu importieren.

Das folgende Diagramm zeigt Routentabellen, die auf DRG-Ebene verknüpft sind:

Beschreibung der Abbildung drg-level-route-table.png

Routentabellen auf DRG-Ebene verwalten:

• VCN-Anhänge
• FastConnect/Virtual Circuit-Anhänge
• IPSec-/VPN-Anhänge
• Remote-Peering-Verbindung (RPC) - Anhänge

Hinweis:

Eine statische Route in einer Routentabelle kann nicht auf FastConnect- oder IPsec-Anhänge verweisen. Verwenden Sie stattdessen die Importroutenverteilung.

Verwenden Sie in einem VCN/Subnetz statische Routen, um Traffic an Gateways weiterzuleiten. Weisen Sie jedem Subnetz einzelne Routentabellen zu, um den ausgehenden Traffic zu steuern. Ressourcen innerhalb desselben VCN können ohne explizite Routen (implizites Routing) kommunizieren. Es müssen jedoch entsprechende Sicherheitsregeln vorhanden sein.

Das folgende Diagramm zeigt Gateways, mit denen Routentabellen sowie andere Ressourcen verknüpft werden können:

Beschreibung der Abbildung individuell-route-traffic-vcn.png

Routentabellen sind normalerweise pro Subnetz verknüpft, um den Traffic von jedem bestimmten Subnetz zu steuern. Sie können das erweiterte Routing von Ressourcen innerhalb eines Subnetzes oder zu Ressourcen innerhalb eines Subnetzes konfigurieren.

Routentabellen können verknüpft werden mit:

• Subnetz
• VCN (Inress), das an den DRG-Anhang angehängt ist. Wird normalerweise verwendet, wenn Traffic zu einer Firewall erzwungen wird.
• Internetgateway
• NAT-Gateway
• Servicegateway
• LPG
• VNIC
• IP-Adresse