Learn About Network Topologies for Oracle Database@Google Cloud

Learn about the various network topology options and select the one best suited for your organizational needs.

About Single VPC Topology

If you want high performance and low latency, host your applications within the same VPC as your database. To maintain application isolation, use separate subnets for each application while sharing Oracle Database@Google Cloud residing in the same VPC.

The following architecture shows a single VPC topology:

Description of the illustration google-single-vpc-arch.png

google-single-vpc-arch-oracle.zip

About VPC Peering Topology

If you want to offer Oracle Database@Google Cloud as a centralized managed service where the platform team creates the databases within their own project and VPC, use the VPC peering topology. Different lines of businesses can connect their applications hosted in a different project and different VPC to the database that is hosted in it's own VPC and project, using VPC peering.

VPC peering topology connects your applications in one VPC to the database in another VPC. VPC peering connects two VPCs so that resources in each network can communicate with each other in the same project, a different project of the same organization, or even different projects of different organizations.

The following architecture shows a local VPC peering topology:

Description of the illustration google-vpc-peering-arch.png

google-vpc-peering-arch-oracle.zip

Tip:

If you choose this topology, consider that VPC peering incurs costs.

About Shared VPC Peering Topology

If you want to connect your applications from multiple projects and VPCs to a common shared VPC connected to the database, use the shared VPC topology. Shared VPC connects projects of the same organization in the same or different folders to centralize control over the shared VPC.

The following architecture shows a shared VPC peering topology:

Description of the illustration google-shared-vpc-arch.png

google-shared-vpc-arch-oracle.zip

Tip:

f you choose this topology, consider that Shared VPC incurs costs.

About Hub-and-Spoke Topology

If you want the Hub network virtual appliance (NVA) as a centralized point of connectivity, use the Hub-and-Spoke topology. The Hub NVA centralizes communication from different VPC with multiple Virtual Network Interface Cards (VNICs) in each spoke subnet and facilitates communication between applications and databases.

To create the VNIC for Oracle Database@Google Cloud connectivity, you must create a transit subnet in the transit VPC. As a centralized point of connectivity, the NVA facilitates communication between applications and databases.

The following architecture shows a NVA hub-and-spoke topology:

Description of the illustration google-nva-hub-and-spoke-arch.png

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

About Multiple VPC Topology

If you want to isolate database workloads between two lines of businesses, use the multiple VPC topology. A Sales and Marketing team can have their own VPC and subnets for their databases in a VM Cluster inside an Oracle Exadata Database Service infrastructure.

To isolate workloads on Oracle Exadata Database Service at the VM Cluster level, deploy multiple clusters in isolated VPCs.

The following architecture shows a multiple VPC architecture:

Description of the illustration google-multiple-vpc-arch.png

google-multiple-vpc-arch-oracle.zip

You must ensure the following:

• Multiple VM clusters share the same Oracle Exadata Database Service infrastructure.
• Each VM cluster is connected to a different VPC.
• Oracle Exadata Database Service infrastructure and VM clusters are part of the same project.