Informationen zum Netzwerkdesign

OCI-Netzwerkinfrastrukturkomponenten wie VCNs, Subnetze und Gateways, die ohne ordnungsgemäße Planung mit den Standardparametern erstellt werden, können nach dem Deployment zu Problemen führen, die schwer zu lösen sind. Ein gut geplantes Netzwerkdesign hilft bei der Einrichtung einer erfolgreichen Implementierung und erleichtert die Nutzung durch Ihr Team und Ihre Organisation.

Führen Sie Ihr Netzwerkdesign frühzeitig aus

Wenn Sie Ihr Netzwerk vor dem Deployment vollständig entwerfen, können Sie Probleme frühzeitig erkennen und Hindernisse für eine erfolgreiche Bereitstellung beseitigen. Es ist zwar möglich, einige OCI-Netzwerkdesignelemente später zu ändern, kann jedoch erheblichen Aufwand erfordern und den Geschäftsablauf vorübergehend stören.

Oracle empfiehlt für Ihr OCI-Netzwerkdesign Folgendes:

1. Planen Sie angemessene Zeit und weisen Sie ausreichend Ressourcen in Ihrem Projektplan zu, um Ihr OCI-Netzwerk ordnungsgemäß zu entwerfen.
2. Umfassen Sie mindestens das Layout, die Topologie, die Größe von VCNs und Subnetzen, Domain Name Service (DNS) und jede externe Netzwerkkonnektivität zu On-Premise- oder anderen CSPs.
3. Ziehen Sie in Betracht, mit Ihrem Oracle-Accountteam zusammenzuarbeiten, um zu prüfen, ob Oracle OCI-Netzwerkspezialisten zur Verfügung stellen kann, die Sie unterstützen.

Im Folgenden finden Sie ein Beispiel für ein Netzwerkdesigndiagramm.

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

Tipp:

Suchen Sie nach relevanten Referenzarchitekturen für Ihr spezifisches Deployment, die als Ausgangspunkt verwendet werden sollen. Beispiel: Oracle verfügt über viele Referenzarchitekturen für gängige Oracle OCI-Deployments wie Oracle E-Business Suite, Siebel und ExaCS im Oracle Architecture Center.

Hub-and-Spoke-VCN-Design berücksichtigen

Die Best Practice und Empfehlung von Oracle für die meisten OCI-Deployments besteht darin, ein Mehrfach-VCN-Design in einer Hub-and-Spoke-Topologie zu verwenden, die das DRG für die Konnektivität verwendet.

Die folgenden Vorteile eines VCN-Hub-and-Spoke-Designs mit dem DRG:

• Isolieren und segmentieren Sie verschiedene Umgebungen.
• Stellen Sie allgemeine Services im Hub-VCN bereit, die alle Spoke-VCNs gemeinsam verwenden können, wie Logserver, DNS und Dateifreigabe.
• Skalieren Sie Ihr Netzwerk einfach, da Sie mit dem DRG eine Verbindung zu bis zu 300 VCNs herstellen können. Sobald Sie ein Hub-and-Spoke-VCN-Design haben, können Sie ganz einfach zusätzliche VCNs hinzufügen.
• Platzieren Sie Netzwerksicherheits-Appliances wie Firewalls im Hub-VCN, um Traffic zu prüfen, der für die Spoke-VCNs bestimmt ist oder aus diesen stammt.

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

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

Oracle empfiehlt Folgendes:

• Entscheiden Sie, wie und wo Sie verschiedene Netzwerkumgebungen segmentieren möchten, und stellen Sie jedes in ein eigenes VCN. Im Folgenden finden Sie allgemeine Kundenbeispiele für die Verwendung separater VCNs für Umgebungen:
  • Produktions- und Nicht-Produktionsumgebungen
  • Interne oder externe Kunden
• Wenn Sie ein sehr einfaches oder kleines OCI-Deployment wie einen Proof of Concept (POC) haben und keinen der hier diskutierten Vorteile benötigen, ist die Verwendung eines einzelnen VCN ein guter Ansatz. Selbst bei einem einzelnen VCN können Sie in Zukunft immer eine Umgebung in einem anderen VCN platzieren, um diese Empfehlungen zu nutzen.

Standard-OCI-Benennungskonventionen verwenden

Wenn Sie die erforderlichen Netzwerkressourcen in OCI bereitstellen, wie VCNs, Subnetze, Sicherheitslisten und dynamische Routinggateways (DRGs), werden Sie aufgefordert, einen Ressourcennamen einzugeben. Die Verwendung einer Standardbenennungskonvention für Ihre OCI-Ressourcen hilft Ihnen und anderen OCI-Benutzern, den Zweck und den Speicherort von Ressourcen zu verstehen und zeigt auch an, wie sich eine Ressource von anderen unterscheidet.

Einige dieser Ressourcennamen können später geändert werden, andere jedoch nicht, wie DNS-Label. Andere, wie der VCN-Name, müssen mit der Befehlszeilenschnittstelle (CLI) geändert werden.

Oracle empfiehlt Folgendes:

1. Verwenden Sie ein beschreibendes Akronym irgendwo im Namen, um den Zweck einer Ressource zu beschreiben. Beispiel:
   • VCN irgendwo im VCN-Namen (VCN-Name: VCN-prod-ashburn)
   • DRG irgendwo im DRG-Namen (DRG-Name: DRG-ashburn)
   • sl irgendwo in Ihrem Sicherheitslistennamen (Sicherheitslistenname: web-sn-sl)
2. Stellen Sie sicher, dass die Benennungskonvention für OCI-Netzwerkressourcen Teil der allgemeinen Benennungskonvention für OCI-Ressourcen ist.
3. Verwenden Sie Tags, um Metadateninformationen zu Ressourcen hinzuzufügen.

Hybrid-DNS mit OCI Private DNS entwerfen

Das Standardverhalten von OCI ist auf die Ausführung einer internen DNS-Auflösung im VCN mit oraclevcn.com als Standarddomain beschränkt. Dies kann später zu Konnektivitätsproblemen führen, da Sie die DNS-Namen für Ressourcen in anderen VCNs oder On-Premise-Umgebungen nicht auflösen können.

Der OCI Private DNS-Service bietet die Möglichkeit, DNS zwischen OCI und On-Premises-Infrastruktur nahtlos aufzulösen:

• Erstellen und verwalten Sie benutzerdefinierte DNS-Domains und -Datensätze in Ihren VCNs (wie oci.customer.com).
• Integrieren Sie die DNS-Auflösung über VCNs hinweg mit On-Premise-DNS und anderen Umgebungen wie CSPs oder vertrauenswürdigen Partner-DNSs.

Oracle empfiehlt Folgendes:

• Nehmen Sie DNS als Teil Ihres frühen Netzwerkdesigns auf und beziehen Sie Ihre DNS-Administratoren ein.
• Berücksichtigen Sie alle Umgebungen, in denen Sie eine nahtlose DNS-Namensauflösung (in oder von On-Premise-Umgebungen, OCI-VCNs, anderen CSPs usw.) wünschen, und verwenden Sie OCI Private DNS, um eine hybride DNS-Lösung zu ermöglichen.
• Betrachten Sie die Vorbehalte früh und bestimmen Sie die Richtung, in die Sie fortfahren möchten. Legen Sie fest, ob Sie den Standarddomainnamen oraclevcn.com oder einen benutzerdefinierten Domainnamen verwenden möchten.

Das folgende Diagramm zeigt eine Beispielarchitektur mit benutzerdefinierten Domainnamen, die einen privaten DNS-Resolver zur Auflösung lokaler, interner Ressourcen mit benutzerdefinierten Domainnamen verwenden:

Beschreibung der Illustrationsarchitektur-deploy-private-dns.png

Tipp:

Wenn Sie einen benutzerdefinierten OCI-Domainnamen verwenden, erfolgt die Verwaltung der benutzerdefinierten Zonen und Datensätze manuell. Die Standard-oraclevcn.com ist automatisch.

Subnetztypen vor dem Provisioning bestimmen

VCN-CIDRs müssen in mindestens ein Subnetz unterteilt werden, um Ressourcen zu organisieren. Bei den Subnetzen kann es sich um regionale oder Availability-Domain-(AD-)spezifische Subnetze handeln. Sie können auch öffentliche oder private Subnetze sein.

Entscheidungen zu regionalen oder AD-spezifischen Subnetzen sowie zu öffentlichen oder privaten Subnetzen können später nicht mehr geändert werden. Stellen Sie sicher, dass sie korrekt sind, wenn Sie sie anfänglich bereitstellen, um Störungen und Komplexität zu einem späteren Zeitpunkt zu minimieren.

Oracle empfiehlt Folgendes:

• Ermitteln Sie, ob Sie öffentliche oder private Subnetze benötigen, bevor Sie sie erstellen. Berücksichtigen Sie potenzielle Verkehrswerte und den Ort, an dem der Datenverkehr bezogen oder bestimmt wird.
• Platzieren Sie Ressourcen, die eine bestimmte Anforderung für eingehende Internetkonnektivität haben, in öffentlichen Subnetzen und allen anderen Ressourcen in privaten Subnetzen.
• Stellen Sie regionale Subnetze bereit, es sei denn, Sie haben eine bestimmte Anforderung, die die Verwendung AD-spezifischer Subnetze erfordert.

Tipp:

Um später Änderungen vorzunehmen, müssen Sie die Subnetze beenden und sie dann erneut bereitstellen. Sie müssen auch die in den Subnetzen bereitgestellten Ressourcen beenden und dann die Ressourcen in den neuen Subnetzen erneut bereitstellen.

Subnetze entwerfen und skalieren

Entwerfen und skalieren Sie Ihre Subnetze, um sowohl aktuelle als auch zukünftige Anforderungen zu erfüllen. Die richtige Größe von VCNs und Subnetzen während Ihres Designs hilft Ihnen dabei:

• Bereiten Sie sich auf zukünftiges Wachstum und Expansion vor
• Vereinfachen Sie die IP-Zuweisung, indem Sie zusammenhängenden und zusammenfassbaren IP-Adressierungsraum verwenden

Oracle empfiehlt Folgendes:

• Bestimmen Sie vor dem Erstellen eines VCN die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen und Subnetze, die Sie im VCN bereitstellen möchten.
• Stellen Sie sicher, dass ein gewisses zukünftiges Wachstum innerhalb der Subnetze und VCNs möglich ist.
• Vorzugsweise neigen Sie dazu, ein größeres CIDR als zu klein zu erstellen.
• Sie können einem VCN bis zu fünf CIDRs hinzufügen. Wenn Sie jedoch später weitere CIDRs hinzufügen, um das Wachstum zu unterstützen, kann dies je nach Zuweisung Ihrer IP-Adresse zu nicht aufeinander folgenden CIDRs führen.
  • Beispiel: Sie haben einem VCN 10.0.0.0/24 zugewiesen, um mit dem Testen einer Workload zu beginnen. Wenn Sie die Workload nach erfolgreichen Tests auf weitere VMs erweitern möchten, sind mehr IPs und Subnetze erforderlich. Der nächste IP-Block 10.0.1.0/24 wurde jedoch in Ihrem IP-Adresswerkzeug für einen anderen Zweck zugewiesen. Daher müssen Sie dem VCN ein nicht aufeinanderfolgendes CIDR hinzufügen.
• Verwenden Sie nach Möglichkeit CIDR-Blöcke, die sich innerhalb des privaten RFC 1918-Standard-IP-Adressraums befinden.
• Verwenden Sie nicht den 169.254.0.0/16 IP-Adressraum. Viele Provider, einschließlich Oracle, verwenden denselben IP-Speicherplatz in ihrem Netzwerk. Dies kann zu Problemen führen.
• Wählen Sie eindeutige CIDR-Blöcke aus, die sich nicht mit anderen Netzwerken (in OCI, Ihren On-Premise-Data Centern oder einem anderen CSP) überschneiden.
• Berücksichtigen Sie beim Entwerfen der Subnetze den Trafficfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an.

Benutzerdefinierte Routentabellen und Sicherheitslisten für jedes Subnetz verwenden

Beim Provisioning von Subnetzen werden Sie aufgefordert, eine VCN-Routentabelle und eine Sicherheitsliste für jedes Subnetz auszuwählen.

OCI stellt eine Standardroutentabelle und eine Standardsicherheitsliste bereit, die bei Verwendung mit allen mit ihnen verknüpften Subnetzen gemeinsam verwendet wird. Die Verwendung dieser Standardoptionen eignet sich für ein einfaches Deployment oder für den Einstieg, ist jedoch kein empfohlener Ansatz für ein Produktionsdesign, das mehrere Subnetze umfasst. Wenn Sie VCN-Routentabellen und Sicherheitslisten verwenden, die für jedes Subnetz spezifisch sind, können Sie granulares Routing und Sicherheitskontrolle für die einzelnen Subnetze verwalten, anstatt dass sie diese Ressourcen gemeinsam verwenden.

Beispiel:

• Möglicherweise soll ein privates Subnetz eine Standardroute zu einem NAT-Gateway haben, und ein öffentliches Subnetz hat eine Standardroute zu einem Internetgateway, was separate VCN-Routentabellen erfordern würde.
• Möglicherweise möchten Sie einen bestimmten Verkehrswert für ein Subnetz zulassen, aber nicht für ein anderes, was separate Sicherheitslisten erforderlich machen würde

Oracle empfiehlt Folgendes:

• Erstellen und verknüpfen Sie eine eindeutige VCN-Routentabelle für jedes Subnetz
• Eine eindeutige Sicherheitsliste für jedes Subnetz erstellen und zuordnen

Tipp:

Erstellen und verknüpfen Sie diese eindeutigen VCN-Routentabellen und Sicherheitslisten, wenn Sie die Subnetze bereitstellen, da es später schwieriger wird, sie von den Standard-Routentabellen zu ändern.