1. Regionalübergreifende private Konnektivität zwischen Mandanten konfigurieren
  2. Regionalübergreifende private Konnektivität zwischen Mandanten konfigurieren

Regionalübergreifende private Konnektivität zwischen Mandanten konfigurieren

Aus geschäftlichen und technischen Gründen müssen Sie möglicherweise eine private Konnektivität zwischen Ihren virtuellen Netzwerken in der Cloud aktivieren und sicherstellen, dass der Verkehr zwischen den Netzwerken niemals das öffentliche Internet durchquert. Beispiel: Sie benötigen eine private Konnektivität zwischen Netzwerken in zwei Regionen innerhalb Ihres Mandanten oder zwischen Netzwerken in Ihrem Mandanten und Netzwerken im Mandanten einer kooperierenden Organisation.

Oracle Cloud Infrastructure unterstützt zwei netzwerkbasierte Modelle:

  • Lokales VCN Peering

    Virtuelle Cloud-Netzwerke (VCNs) innerhalb einer Region können mit lokalen Peering-Gateways (LPG) verglichen werden. Die an solche Peered VCNs angeschlossenen Ressourcen können über private IP-Adressen kommunizieren, ohne den Datenverkehr über das öffentliche Internet weiterzuleiten. Die VCNs können sich im selben Mandanten oder in verschiedenen Mandanten befinden.

  • Remote-VCN Peering

    VCNs in verschiedenen Regionen können über private IP-Adressen kommunizieren, ohne den Datenverkehr über das öffentliche Internet weiterzuleiten. Sie können Peering zwischen zwei VCNs in verschiedenen Regionen einrichten, indem Sie eine Remote-Peering-Verbindung (RPC) für jedes der dynamischen Routing-Gateways (DRG) konfigurieren, die an die VCNs in der Peering-Beziehung angehängt sind. Remote VCN Peering wird in der Regel verwendet, um zwei VCNs über Regionen desselben Mandanten hinweg zu verbinden. In bestimmten Szenarien müssen Sie möglicherweise VCNs in zwei verschiedenen Mandanten über Regionen hinweg verbinden.

Architektur

In dieser Architektur ist die private Netzwerkkonnektivität zwischen zwei Mandanten und über zwei Regionen hinweg konfiguriert.

Beschreibung von xregion-private-connectivity-oci.png folgt
Beschreibung der Abbildung xregion-private-connectivity-oci.png

Die Architektur verfügt über folgende Komponenten:

  • Mandant

    Ein Mandant ist eine sichere und isolierte Partition, die Oracle in Oracle Cloud einrichtet, wenn Sie sich für Oracle Cloud Infrastructure anmelden. Sie können Ihre Ressourcen in Oracle Cloud in Ihrem Mandanten erstellen, organisieren und verwalten.

    Diese Architektur hat zwei Mieten, eine für die Firma A und die andere für die Firma B.

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Rechenzentrum (Availability-Domains) enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

    Diese Architektur hat zwei Regionen. Unternehmen A verfügt über seine Cloud-Ressourcen in einer einzigen Region, US East (Ashburn). Die Ressourcen des Unternehmens B verteilen sich auf zwei Regionen: US East (Ashburn) und India West (Mumbai).

  • Virtuelles Cloud-Netzwerk (VCN)

    Ein VCN ist ein anpassbares privates Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region eingerichtet haben. Wie herkömmliche Rechenzentrumsnetze geben VCNs Ihnen die vollständige Kontrolle über Ihre Netzwerkumgebung. Sie können VCNs in Subnetze segmentieren, die für eine Region oder eine Availability-Domain Geltungsbereich haben können. Sowohl regionale Subnetze als auch domainspezifische Verfügbarkeitssubnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein.

    In dieser Architektur hat Unternehmen A VCN 10.0.0.0/16 in der Region US East (Ashburn). Unternehmen B verfügt über zwei VCNs in einer anderen Region: VCN B 172.16.0.0/16 in US East (Ashburn) und VCN C 192.168.0.0/16 in India West (Mumbai). Beachten Sie, dass jedes VCN in dieser Peering-Architektur ein eindeutiges CIDR-Präfix hat.

  • Dynamisches Routinggateway (DRG)

    DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerkverkehr zwischen VCN und einem Netzwerk außerhalb der Region bereitstellt, wie VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

    In dieser Architektur werden VCN B in Ashburn und VCN C in Mumbai ferngesteuert mit DRGs verglichen.

  • Lokales Peering-Gateway (LPG)

    Mit einer LPG können Sie ein VCN mit einem anderen VCN in derselben Region peeren. Peering bedeutet, dass die VCNs mit privaten IP-Adressen kommunizieren, ohne dass der Datenverkehr das Internet oder Routing durch Ihr On-Premise-Netzwerk durchläuft.

    In dieser Architektur werden VCN A und VCN B (beide innerhalb der Ashburn-Region) lokal mit LPGs verglichen.

  • Routentabellen

    Virtuelle Routentabellen enthalten Regeln zur Weiterleitung des Traffics von Subnetzen an Ziele außerhalb eines VCN, typischerweise über Gateways.

    Diese Architektur umfasst Routentabellen, um den Datenverkehr über die VCNs hinweg zu leiten.
    • VCN A hat Routenregeln, um Traffic über die LPG zu VCNs B und C zu leiten.
    • VCN B hat Routenregeln, um Traffic über die LPG zu VCN A und über DRG zu VCN C zu leiten.
    • VCN C hat Routenregeln, um Traffic über DRG zu VCNs A und C zu leiten.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

  • Identitäts- und Zugriffsverwaltung (IAM)

    Sie können eine IAM-Policy so konfigurieren, dass Benutzer in nur einer bestimmten Gruppe Verbindungen von einer LPG im Compartment des Anforderers (Kompartiment A) zu einem bestimmten Mandanten initiieren können. Ordnen Sie die Policy dem Mandanten des Anforderers (d.h. dem Compartment root) zu, und nicht dem Compartment des Anforderers.

  • VCN

    Legen Sie beim Erstellen des VCN fest, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Notation Classless Inter-Domain Routing (CIDR) eine Subnetzmaske und einen Netzwerkadressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressbereich, der sich im standardmäßigen privaten IP-Adressraum befindet.

    Wählen Sie einen Adressbereich, der sich nicht mit einem anderen Netzwerk überschneidet (in Oracle Cloud Infrastructure, Ihrem On-Premise-Rechenzentrum oder in einem anderen Cloud-Provider), zu dem Sie private Verbindungen einrichten möchten.

  • Sicherheitsregeln

    Zur Steuerung des Netzwerkverkehrs können Sie Sicherheitslisten oder Netzwerksicherheitsgruppen (NSGs) verwenden. Die Regeln, die Sie in einer Sicherheitsliste angeben, gelten für alle VNICs im Subnetz, denen Sie die Sicherheitsliste zuordnen. Wenn Sie Firewalls auf granularerer Ebene benötigen, verwenden Sie Netzwerksicherheitsgruppen (NSGs). Die Regeln in einem NSG gelten nur für die VNICs, die Sie angeben. Oracle empfiehlt, NSGs zu verwenden, da sie es Ihnen ermöglichen, die Subnetzarchitektur von den Sicherheitsanforderungen Ihrer Workload zu trennen.

Überlegungen

Beachten Sie bei der Implementierung dieser Architektur die folgenden Faktoren:

  • Skalierbarkeit

    Beachten Sie die Servicelimits für VCNs und Subnetze für Ihren Mandanten. Wenn Sie mehr Netzwerke benötigen, fordern Sie eine Erhöhung der Grenzwerte.

  • Sicherheit

    Verwenden Sie geeignete Sicherheitsmechanismen, um Ihre Topologie zu schützen.

    In der Architektur, die Sie mit dem angegebenen Terraform-Code bereitstellen, ermöglicht die Standardsicherheitsliste von VCN SSH-Traffic von 0.0.0.0/0 und ICMP nur von beiden Mandanten. Passen Sie die Sicherheitsliste an, damit nur Hosts und Netzwerke mit SSH-Zugriff (oder Zugriff auf andere erforderliche Serviceports) auf Ihre Infrastruktur zugreifen können.

  • Performance

    Innerhalb einer Region wirkt sich die Anzahl der VCNs nicht auf die Performance aus. Wenn Sie VCNs in verschiedenen Regionen vergleichen, sollten Sie Latenz in Betracht ziehen.

Bereitstellen

Der Terraform-Code für das Deployment dieser Architektur ist in GitHub verfügbar.

  1. Gehen Sie zu GitHub.
  2. Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
  3. Befolgen Sie die Anweisungen im Dokument README.

Mehr erfahren

Change Log

Dieses Log listet signifikante Änderungen auf: