Informationen zu Netzwerktopologien für Oracle Database@Google Cloud

Erfahren Sie mehr über die verschiedenen Oracle Database@Google Cloud-Netzwerktopologieoptionen, und wählen Sie die für Ihre Unternehmensanforderungen am besten geeignete Option aus.

• Einzelne VPC-Konnektivität
• VPC-Peering-Konnektivität
• Gemeinsame VPC-Peering-Konnektivität
• Hub-and-Spokes-Konnektivität
• Mehrere VPC-Konnektivität

Informationen zur Single VPC-Topologie

Wenn Sie hohe Performance und geringe Latenz benötigen, hosten Sie Ihre Anwendungen in derselben VPC wie Ihre Datenbank. Um die Anwendungsisolation aufrechtzuerhalten, verwenden Sie separate Subnetze für jede Anwendung, während Sie Oracle Database@Google Cloud in derselben VPC gemeinsam verwenden.

Die folgende Architektur zeigt eine einzelne VPC-Topologie:

Beschreibung der Abbildung google-single-vpc-arch.png

google-single-vpc-arch-oracle.zip

Info über VPC-Peering-Topologie

Wenn Sie Oracle Database@Google Cloud als zentralisierten verwalteten Service anbieten möchten, bei dem das Plattformteam die Datenbanken in seinem eigenen Projekt und VPC erstellt, verwenden Sie die VPC-Peering-Topologie. Verschiedene Geschäftsbereiche können ihre Anwendungen, die in einem anderen Projekt und einer anderen VPC gehostet werden, mit VPC-Peering mit der Datenbank verbinden, die in ihrer eigenen VPC und ihrem eigenen Projekt gehostet wird.

Die VPC-Peering-Topologie verbindet Ihre Anwendungen in einer VPC mit der Datenbank in einer anderen VPC. VPC-Peering verbindet zwei VPCs, sodass Ressourcen in jedem Netzwerk im selben Projekt, in einem anderen Projekt derselben Organisation oder sogar in verschiedenen Projekten verschiedener Organisationen miteinander kommunizieren können.

Die folgende Architektur zeigt eine lokale VPC-Peering-Topologie:

Beschreibung der Abbildung google-vpc-peering-arch.png

google-vpc-peering-arch-oracle.zip

Tipp:

Wenn Sie diese Topologie wählen, beachten Sie, dass VPC-Peering Kosten verursacht.

Informationen zur Shared VPC-Topologie

Mit gemeinsam genutzten VPCs können Organisationen Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk in einem Hostprojekt verbinden. Organisationsadministratoren können die Verwaltung von Anwendungen an Service Project-Administratoren delegieren, während sie die zentrale Kontrolle über Netzwerkressourcen behalten. Dadurch wird die Konfiguration vereinfacht, und diese Ressourcen können über eine interne IP-Adresse aus dem Shared VPC-Netzwerk sicher und effizient miteinander kommunizieren.

Gemeinsame VPCs vereinfachen die Netzwerkkonfiguration in Google Cloud. Serviceeigentümer wie Datenbankbenutzer verwenden die von ihren Netzwerkteams definierte Netzwerkkonfiguration, anstatt die Netzwerke manuell zwischen verschiedenen Ressourcen zu konfigurieren. Es reduziert die Notwendigkeit, VPC-Peering und zugehörige Konfigurationen zu aktivieren und zu konfigurieren.

Mit Shared VPC können Sie eine einzelne, zentralisierte VPC in einem Hostprojekt verwalten und gleichzeitig jedem Team kontrollierten Zugriff auf die Bereitstellung seiner Oracle Databases in isolierten Serviceprojekten gewähren. Dies ermöglicht sichere, konsistente Netzwerkrichtlinien (Firewalls, Routen, DNS) über alle Umgebungen hinweg, vereinfacht die Kommunikation zwischen den Services und vermeidet eine Ausbreitung oder doppelte Konfiguration von VPCs.

Die folgende Architektur zeigt ein Beispiel für eine Shared VPC-Topologie mit einer Oracle Autonomous Database:

Beschreibung der Abbildung google-shared-vpc-arch.png

google-shared-vpc-arch-oracle.zip

Hub-and-Spoke-Topologie

Wenn Sie die virtuelle Hubnetzwerk-Appliance (NVA) als zentralen Verbindungspunkt verwenden möchten, verwenden Sie die Hub-and-Spoke-Topologie. Der Hub NVA zentralisiert die Kommunikation von verschiedenen VPCs mit mehreren virtuellen Netzwerkschnittstellenkarten (VNICs) in jedem Spoke-Subnetz und erleichtert die Kommunikation zwischen Anwendungen und Datenbanken.

Um die VNIC für die Oracle Database@Google Cloud-Konnektivität zu erstellen, müssen Sie ein Transitsubnetz in der Transit-VPC erstellen. Als zentraler Verbindungspunkt erleichtert die NVA die Kommunikation zwischen Anwendungen und Datenbanken.

Die folgende Architektur zeigt eine NVA-Hub-and-Spoke-Topologie:

Beschreibung der Abbildung google-nva-hub-and-spoke-arch.png

google-nva-hub-and-spoke-arch-arch.zip

Info über mehrere VPC-Topologien

Wenn Sie Datenbank-Workloads zwischen zwei Geschäftsbereichen unter Verwendung verschiedener Google Cloud-Projekte isolieren möchten, verwenden Sie die mehrere VPC-Topologie. Ein Sales and Marketing-Team kann über ein eigenes Projekt und eine eigene VPC für seine Datenbanken in einem VM-Cluster innerhalb einer Oracle Exadata Database Service-Infrastruktur verfügen.

Um Workloads auf Oracle Exadata Database Service auf VM-Clusterebene zu isolieren, stellen Sie mehrere Cluster in isolierten Projekt-VPCs bereit.

Die folgende Architektur zeigt eine Architektur mit mehreren VPCs:

Beschreibung der Abbildung google-multiple-vpc-arch.png

google-multiple-vpc-arch-oracle.zip

Stellen Sie Folgendes sicher:

• Mehrere VM-Cluster verwenden dieselbe Oracle Exadata Database Service-Infrastruktur.
• Jedes VM-Cluster ist mit einer anderen VPC verbunden.
• Oracle Exadata Database Service-Infrastruktur und VM-Cluster sind Teil verschiedener Projekte.

Topologiekomponenten

Die Topologien verwenden die folgenden wichtigen Netzwerkkomponenten:

• Google Cloud-Region

  Eine Google Cloud-Region ist ein geografisches Gebiet, das Rechenzentren und Infrastruktur für das Hosting von Ressourcen enthält. Regionen bestehen aus Zonen, die innerhalb der Region voneinander isoliert sind.

• Google Virtual Private Cloud

  Google Virtual Private Cloud (VPC) bietet Netzwerkfunktionen für Compute Engine Virtual Machine-(VM-)Instanzen, Google Kubernetes Engine-(GKE-)Container, Datenbankservices und serverlose Workloads. VPC bietet globale, skalierbare und flexible Netzwerke für Ihren cloudbasierten Service.

• Google Cloud-Zone

  Eine Zone in Google Cloud ist ein Deployment-Bereich für Ressourcen innerhalb einer Region. Zonen sind innerhalb einer Region voneinander isoliert und werden als einzelne Ausfalldomain behandelt.

• Google Cloud-Projekt

  Ein Google Cloud-Projekt ist erforderlich, um Google Workspace-APIs zu verwenden und Google Workspace-Add-ons oder -Apps zu erstellen. Ein Cloud-Projekt bildet die Grundlage für die Erstellung, Aktivierung und Nutzung aller Google Cloud-Services, einschließlich der Verwaltung von APIs, der Aktivierung der Abrechnung, des Hinzufügens und Entfernens von Mitarbeitern und der Verwaltung von Berechtigungen.

• ODB-Netzwerk

  Das ODB-Netzwerk erstellt ein Metadatenkonstrukt rund um die Google Virtual Private Cloud (VPC), das als Grundlage für das gesamte Datenbank-Provisioning dient. Das ODB-Netzwerk ermöglicht die Unterstützung von Shared VPC, indem die Netzwerkkonfiguration abstrahiert und zentralisiert wird, wie Subnetze, CIDR-Bereiche und Routing. Dadurch können Netzwerkadministratoren die Konnektivität unabhängig von den Workflows für die Datenbankbereitstellung verwalten.

• Google Cloud Shared VPC

  Mit Shared Virtual Private Clouds (VPCs) können Unternehmen Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk in einem Hostprojekt verbinden. Organisationsadministratoren können die Verwaltung von Anwendungen an Service Project-Administratoren delegieren, während sie die zentrale Kontrolle über Netzwerkressourcen behalten. Dadurch wird die Konfiguration vereinfacht, und diese Ressourcen können über eine interne IP-Adresse aus dem Shared VPC-Netzwerk sicher und effizient miteinander kommunizieren.