Oracle E-Business Suite with Oracle Exadata in Google Cloud

Last reviewed 2025-04-08 UTC

This document provides a reference architecture to help you build the infrastructure to run Oracle E-Business Suite applications with low-latency connectivity to Oracle Cloud Infrastructure (OCI) Exadata databases that run in Google Cloud. Oracle E-Business Suite is a suite of enterprise applications for business functions like finance, human resources, supply chain, and customer relationship.

The intended audience for this document is cloud architects and administrators of Oracle databases and Oracle E-Business Suite applications. The document assumes that your team is familiar with Oracle E-Business Suite technology stack and architecture and Oracle Exadata Database Service.

If you use Oracle Exadata or Oracle Real Application Clusters (Oracle RAC) to run Oracle databases on-premises, you can efficiently migrate your applications to Google Cloud and run your databases on Oracle Database@Google Cloud. Oracle Database@Google Cloud is a Google Cloud Marketplace offering that lets you run Oracle Exadata Database Service and Oracle Autonomous Database directly inside Google Cloud.

Architecture

The following diagram shows an architecture where Oracle E-Business Suite applications run in active-active mode on Compute Engine VMs that are distributed across two zones within a Google Cloud region. The application uses Oracle Exadata databases in the same Google Cloud region.

All the components in the architecture are in a single Google Cloud region. This architecture is aligned with the regional deployment archetype. You can adapt this architecture to build a topology that is robust against regional outages by using the multi-regional deployment archetype. For more information, see Multi-regional deployment on Compute Engine and also the guidance in the Reliability section later in this document.

Oracle E-Business Suite applications run in active-active mode on Compute Engine VMs.

The architecture in the preceding diagram includes the following components:

Component Purpose
Regional external Application Load Balancer The load balancer receives and distributes user requests to the Oracle E-Business Suite applications.
Google Cloud Armor security policy The Google Cloud Armor security policy helps to protect your application stack against threats like distributed denial-of-service (DDoS) attacks and cross-site scripting (XSS).
Oracle E-Business Suite (BYOL)

The Oracle E-Business Suite application-layer components (Oracle HTTP Server, Oracle WebLogic Server, and a concurrent processing server) run on Compute Engine VMs that are distributed across two zones in the primary region. Each VM hosts an independent instance of the application layer. The boot disk for each VM is a Hyperdisk volume.

You bring your own licenses (BYOL) for Oracle E-Business Suite, and you manage the VMs and the applications.
Application binaries and data A Filestore regional instance contains the application binaries and data. The Filestore instance is mounted on all of the Compute Engine VMs that host the application-layer components in both zones.
Application backups Backups of the application are created, stored, and managed by using Backup and DR.
Virtual Private Cloud (VPC) network All of the Google Cloud resources in the architecture use a single VPC network. Depending on your requirements, you can choose to build an architecture that uses multiple networks. For more information, see Deciding whether to create multiple VPC networks.
Oracle Database@Google Cloud

The applications read data from and write to Oracle databases in Oracle Exadata Database Service. You provision Oracle Exadata Database Service by using Oracle Database@Google Cloud, a Cloud Marketplace offering that lets you run Oracle databases on Oracle-managed hardware within a Google Cloud data center.

You use Google Cloud interfaces like the Google Cloud console, Google Cloud CLI, and APIs to create Exadata Infrastructure instances. Oracle sets up and manages the required compute, storage, and networking infrastructure in a data center within a Google Cloud region on hardware that's dedicated for your project.
Exadata Infrastructure instances Each Exadata Infrastructure instance contains two or more physical database servers and three or more storage servers. These servers, which aren't shown in the diagram, are interconnected using a low-latency network fabric. When you create an Exadata Infrastructure instance, you specify the number of database servers and storage servers that must be provisioned.
Exadata VM Clusters

Within an Exadata Infrastructure instance, you create one or more Exadata VM Clusters. For example, you can choose to create and use a separate Exadata VM Cluster to host the databases that are required for each of your business units. Each Exadata VM Cluster contains one or more Oracle Linux VMs that host Oracle Database instances.

When you create an Exadata VM Cluster, you specify the following:

  • The number of database servers.
  • The compute, memory, and storage capacity to be allocated to each VM in the cluster.
  • The VPC network that the cluster must connect to.
  • IP address ranges of the backup and client subnets for the cluster.

The VMs within Exadata VM Clusters are not Compute Engine VMs.
Oracle Database instances You create and manage Oracle databases through the OCI console and other OCI interfaces. Oracle Database software runs on the VMs within the Exadata VM Cluster. When you create the Exadata VM Cluster, you specify the Oracle Grid Infrastructure version. You also choose the license type: either bring your own licenses (BYOL) or opt for the license-included model.
OCI VCN and subnets When you create an Exadata VM Cluster, an OCI virtual cloud network (VCN) is created automatically. The VCN has a client subnet and a backup subnet with IP address ranges that you specify. The client subnet is used for connectivity from your VPC network to the Oracle databases. The backup subnet is used to send database backups to OCI Object Storage.
Cloud Router, Partner Interconnect, and OCI DRG Traffic between your VPC network and the VCN is routed by a Cloud Router that's attached to the VPC and through a dynamic routing gateway (DRG) that's attached to the VCN. The traffic flows through a low-latency connection that Google sets up using Partner Interconnect.
Private Cloud DNS zone When you create an Exadata VM Cluster, a Cloud DNS private zone is created automatically. When your applications send read and write requests to the Oracle databases, Cloud DNS resolves the database hostnames to the corresponding IP addresses.
OCI Object Storage and OCI Service Gateway By default, backups of the Oracle Exadata databases are stored in OCI Object Storage. Database backups are routed to OCI Object Storage through a Service Gateway.
Public Cloud NAT gateway The architecture includes a public Cloud NAT gateway to enable secure outbound connections from the Compute Engine VMs, which have only internal IP addresses.
Cloud Interconnect or Cloud VPN To connect your on-premises network to the VPC network in Google Cloud, you can use Cloud Interconnect or Cloud VPN. For information about the relative advantages of each approach, see Choosing a Network Connectivity product.
Cloud Monitoring You can use Cloud Monitoring to observe the behavior, health, and performance of your application and Google Cloud resources, including the Oracle Exadata resources. You can also monitor the resources in Oracle Exadata resources by using the OCI Monitoring service.

Products used

This reference architecture uses the following Google Cloud products:

  • Cloud Load Balancing: A portfolio of high performance, scalable, global and regional load balancers.
  • Google Cloud Armor: A network security service that offers web application firewall (WAF) rules and helps to protect against DDoS and application attacks.
  • Virtual Private Cloud (VPC): A virtual system that provides global, scalable networking functionality for your Google Cloud workloads. VPC includes VPC Network Peering, Private Service Connect, private services access, and Shared VPC.
  • Cloud NAT: A service that provides Google Cloud-managed high-performance network address translation.
  • Cloud Monitoring: A service that provides visibility into the performance, availability, and health of your applications and infrastructure.
  • Cloud Interconnect: A service that extends your external network to the Google network through a high-availability, low-latency connection.
  • Partner Interconnect: A service that provides connectivity between your on-premises network and your Virtual Private Cloud networks and other networks through a supported service provider.
  • Cloud VPN: A service that securely extends your peer network to Google's network through an IPsec VPN tunnel.
  • Compute Engine: A secure and customizable compute service that lets you create and run VMs on Google's infrastructure.
  • Google Cloud Hyperdisk: A network storage service that you can use to provision and dynamically scale block storage volumes with configurable and predictable performance.
  • Filestore: A service that provides high-performance, fully managed file storage on Google Cloud that you can connect to a variety of client types.
  • Backup and DR Service: A secure, centrally-managed backup and recovery service for Google Cloud workloads that helps protect backup data from malicious or accidental deletion.
  • Cloud DNS: A service that provides resilient, low-latency DNS serving from Google's worldwide network.

This reference architecture uses the following Oracle products:

  • Oracle E-Business Suite: A suite of applications for business operations like finance, human resources, and supply chain.
  • Exadata Database Service on Dedicated Infrastructure: A service that lets you run Oracle Database instances on Exadata hardware that's dedicated for you.
  • Object Storage: A service for storing large amounts of structured and unstructured data as objects.
  • VCN and subnets: A VCN is a virtual and private network for resources in an OCI region. A subnet is a contiguous range of IP addresses with a VCN.
  • Dynamic Routing Gateway: A virtual router for traffic between a VCN and external networks.
  • Service Gateway: A gateway to let resources in a VCN access specific Oracle services privately.

You're responsible for procuring licenses for the Oracle products that you deploy in Google Cloud, and you're responsible for complying with the terms and conditions of the Oracle licenses.

Design considerations

This section describes design factors, best practices, and design recommendations that you should consider when you use this reference architecture to develop a topology that meets your specific requirements for security, reliability, operational efficiency, cost, and performance. When you build the architecture for your workload, consider the best practices and recommendations in the Google Cloud Well-Architected Framework.

System design

This section provides guidance to help you to choose Google Cloud regions for your deployment and to select appropriate Google Cloud services.

Region selection

When you choose the Google Cloud region for your deployment, consider the following factors and requirements:

Some of these factors and requirements might involve trade-offs. For example, the most cost-efficient region might not have the lowest carbon footprint. For more information, see Best practices for Compute Engine regions selection.

Compute infrastructure

The reference architecture in this document uses Compute Engine VMs to host the Oracle E-Business Suite applications. Depending on the requirements of your application, you can run containerized applications in Google Kubernetes Engine (GKE) clusters. GKE is a container-orchestration engine that automates deploying, scaling, and managing containerized applications. The decision of whether to use VMs or containers involves a trade-off between configuration flexibility and management effort. The design guidance for alternative compute services is outside the scope of this document. For more information about service options, see Application Hosting Options on Google Cloud.

Database migration

When you plan to migrate on-premises databases to Oracle Database@Google Cloud, assess your current database environment and get configuration and sizing recommendations by using the Database Migration Assessment (DMA) tool.

To migrate on-premises data or data across platforms, including Unix systems, to Oracle database deployments in Google Cloud, you can use standard Oracle tools like Transportable Tablespaces. For more information about Transportable Tablespaces and its limitations, see Migrating Data Using Transportable Tablespaces.

Before you use the migrated databases in a production environment, verify connectivity from your applications to the databases.

Storage options

The architecture that's shown in this document uses Hyperdisk Balanced volumes for the boot disks of the Compute Engine VMs that host Oracle E-Business Suite applications. Hyperdisk volumes provide better performance, flexibility, and efficiency compared to Persistent Disk. Hyperdisk Balanced provisions IOPS and throughput separately and dynamically, which lets you tune the volume to a wide variety of workload. For information about Hyperdisk types and features, see About Hyperdisk.

For application data and binaries, the architecture in this document uses Filestore. The data that you store in a Filestore Regional instance is replicated synchronously across three zones within the region. This replication ensures high availability and robustness against zone outages. You can also store shared configuration files, common tools and utilities, and centralized logs in the Filestore instance, and mount the instance on multiple VMs.

When you design storage for your workloads, consider the functional characteristics of the workloads, resilience requirements, performance expectations, and cost goals. For more information, see Design an optimal storage strategy for your cloud workload.

Network design

When you build infrastructure for a multi-tier application stack, you must choose a network design that meets your business and technical requirements. The architecture that is shown in this document uses a simple network topology with a single VPC network. Depending on your requirements, you can choose to use multiple VPC networks. For more information, see the following documentation:

Data analytics

For advanced analytics, you can use the Google Cloud Cortex Framework to ingest data from your Oracle E-Business Suite applications into BigQuery. For more information, see Cortex Framework: integration with Oracle E-Business Suite.

Security, privacy, and compliance

This section describes factors to consider when you use this reference architecture to design a topology in Google Cloud that meets the security and compliance requirements of your workloads.

Protection against external threats

To protect your Oracle E-Business Suite applications against external threats like DDoS attacks and XSS, define appropriate Google Cloud Armor security policies based on your requirements. Each policy is a set of rules that specifies the conditions to be evaluated and actions to take when the conditions are met. For example, a rule could specify that if the source IP address of incoming traffic matches a specific IP address or CIDR range, then the traffic must be denied. You can also apply preconfigured WAF rules. For more information, see Security policy overview.

External access for VMs

In the reference architecture that this document describes, the VMs that host the Oracle E-Business Suite applications don't need direct inbound access from the internet. Don't assign external IP addresses to those VMs. Google Cloud resources that have only private, internal IP addresses can still access certain Google APIs and services by using Private Service Connect or Private Google Access. For more information, see Private access options for services.

To enable secure outbound connections from Google Cloud resources that have only private IP addresses, like the Compute Engine VMs in this reference architecture, you can use Cloud NAT as shown in the preceding architecture diagram, or use Secure Web Proxy.

For the subnets that are used by the Exadata VMs, Oracle recommends that you assign private IP address ranges.

Service account privileges

For the Compute Engine VMs in the architecture, instead of using the default service accounts, we recommend that you create dedicated service accounts and specify the resources that the service account can access. The default service account includes a broad range of permissions that aren't necessary in this instance, whereas you can tailor dedicated service accounts to have only the permissions needed. For more information, see Limit service account privileges.

SSH security

To enhance the security of SSH connections to the Compute Engine VMs in this architecture, implement Identity-Aware Proxy (IAP) forwarding with OS Login. IAP lets you control network access based on user identity and IAM policies. OS Login lets you control Linux SSH access based on user identity and IAM policies. For more information about managing network access, Best practices for controlling SSH login access.

Data encryption

By default, the data that's stored in Hyperdisk volumes and in Filestore is encrypted using Google-owned and Google-managed encryption keys. As an additional layer of protection, you can choose to encrypt the Google-owned and managed key by using keys that you own and manage in Cloud Key Management Service (Cloud KMS). For more information, see About disk encryption for Hyperdisk volumes and Encrypt data with customer-managed encryption keys for Filestore.

By default, Exadata databases use Transparent Data Encryption (TDE), which lets you encrypt sensitive data that's stored in tables and tablespaces.

Network security

To control network traffic between the resources in the architecture, you must configure appropriate Cloud Next Generation Firewall (NGFW) policies.

Database security and compliance

The Exadata Database service includes Oracle Data Safe, which helps you manage security and compliance requirements for Oracle databases. You can use Oracle Data Safe to evaluate security controls, monitor user activity, and mask sensitive data. For more information, see Manage Database Security with Oracle Data Safe.

More security considerations

When you build the architecture for your workload, consider the platform-level security best practices and recommendations in the following documentation:

Reliability

This section describes design factors to consider when you use this reference architecture to build and operate reliable infrastructure for your deployment in Google Cloud.

Robustness of the application layer against VM failures

If some (but not all) of the VMs that host the Oracle E-Business Suite applications fail, the applications continue to be available because the load balancer forwards requests to other application VMs.

Sometimes an application VM might be running and available, but there might be issues with the application itself. The application might freeze, crash, or not have enough memory. In this scenario, the VM won't respond to load-balancer health checks, and the load balancer won't route traffic to the unresponsive VM.

Robustness against zone outages

In a regional architecture, if one of the zones has an outage, the load balancer forwards requests to instances of the applications that run in the other zone. Filestore continues to be available because the architecture uses the Filestore Regional service tier.

To ensure high availability of data in Hyperdisk volumes during a single-zone outage, you can use Hyperdisk Balanced High Availability. When data is written to a Hyperdisk Balanced High Availability volume, the data is replicated synchronously between two zones in the same region.

Robustness against region outages

If a region outage occurs, the applications are unavailable. To reduce the downtime caused by region outages, you can implement the following approach:

  • Maintain a passive (failover) replica of the application tier in another Google Cloud region.
  • Create a standby Exadata Infrastructure instance with the required Exadata VM Clusters in the same region that has the passive replica of the application stack. Use Oracle Data Guard for data replication and automatic failover to the standby Exadata databases. If your application needs a lower recovery point objective (RPO), you can backup and recover the databases by using Oracle Autonomous Recovery Service.
  • If an outage occurs in the primary region, use the database replica or backup to restore the database to production and to activate the application in the failover region.
  • Use DNS routing policies to route traffic to an external load balancer in the failover region.

For business-critical applications that must continue to be available even when a region outage occurs, consider using the multi-regional deployment archetype. You can use Oracle Active Data Guard to provide a read-only standby database in the failover region.

Oracle manages the infrastructure in Oracle Database@Google Cloud. For information about the service level objectives (SLOs) for Oracle Exadata Database Service on Dedicated Infrastructure, see Service Level Objectives for Oracle PaaS and IaaS Public Cloud Services.

VM capacity planning

To make sure that capacity for Compute Engine VMs is available when you need to provision VMs, you can create reservations. A reservation provides assured capacity in a specific zone for a specified number of VMs of a machine type that you choose. A reservation can be specific to a project, or it can be shared across multiple projects. You incur charges for reserved resources even if the resources aren't provisioned or used. For more information about reservations, including billing considerations, see Reservations of Compute Engine zonal resources.

Database capacity

You can scale Exadata Infrastructure by adding database servers and storage servers as needed. After you add the required database servers or storage servers to Exadata Infrastructure, to be able to use the additional CPU or storage resources, you must add the capacity to the associated Exadata VM cluster. For more information, see Scaling Exadata Compute and Storage.

Data durability

The architecture in this document uses Backup and DR to create, store, and manage backups of Compute Engine VMs. Backup and DR stores backup data in its original, application-readable format. When required, you can restore workloads to production by directly using data from long-term backup storage and avoid the need to prepare or move data.

Backup and DR supports two methods for creating backups:

  • Backup vault storage: The backup data is stored within the same region as the source data, and the data can't be changed or deleted.
  • Self-managed storage: Authorized users can modify or delete the backup data, and you can store data in multiple regions.

For more information, see the following documentation:

To ensure the durability of the application binaries in your Filestore instance, you can create backups and snapshots of the instance.

By default, backups of databases in Oracle Exadata Database Service on Dedicated Infrastructure are stored in OCI Object Storage. To achieve a lower RPO, you can backup and recover the databases by using Oracle Autonomous Recovery Service.

More reliability considerations

When you build the cloud architecture for your workload, review the reliability-related best practices and recommendations that are provided in the following documentation:

Cost optimization

This section provides guidance to optimize the cost of setting up and operating a Google Cloud topology that you build by using this reference architecture.

VM machine types

To help you optimize the utilization of your VM resources, Compute Engine provides machine type recommendations. Use the recommendations to choose machine types that match your workload's compute requirements. For workloads that have predictable resource requirements, you can customize the machine type to your needs and save money by using custom machine types.

Oracle product licenses

You're responsible for procuring licenses for the Oracle E-Business Suite applications that you deploy on Compute Engine, and you're responsible for complying with the terms and conditions of the Oracle licenses. When you calculate the licensing cost, consider the number of Oracle Processor licenses that are required based on the machine type that you choose for the Compute Engine VMs that host the Oracle products. For more information, see Licensing Oracle Software in the Cloud Computing Environment.

Database costs

When you create an Exadata VM Cluster, you can choose to BYOL or to provision license-included Oracle databases.

Networking charges for data transfer between your applications and Oracle Exadata databases that are within the same region are included in the price of the Oracle Database@Google Cloud offering.

More cost considerations

When you build the architecture for your workload, also consider the general best practices and recommendations that are provided in Well-Architected Framework: Cost optimization pillar.

Operational efficiency

This section describes the factors to consider when you use this reference architecture to design a Google Cloud topology that you can operate efficiently.

VM images

For your VMs, you can use Oracle Linux images that are available in Compute Engine or you can import Oracle Linux images that you build and maintain. You can also create and use custom OS images that include the configurations and software that your applications require. You can group your custom images into a custom image family. An image family always points to the most recent image in that family, so your instance templates and scripts can use that image without you having to update references to a specific image version. You must regularly update your custom images to include the security updates and patches that are provided by the OS vendor.

Database administration

Oracle manages the physical database servers, storage servers, and networking hardware in Oracle Exadata Database Service on Dedicated Infrastructure. You can manage the Exadata Infrastructure instances and the Exadata VM Clusters through the OCI or Google Cloud interfaces. You create and manage databases through the OCI interfaces. The Google Cloud console pages for Oracle Database@Google Cloud include links that you can use to go directly to the relevant pages in the OCI console. To avoid the need to sign in again to OCI, you can configure identity federation between OCI and Google Cloud.

Oracle documentation and support

Oracle products that run on Compute Engine VMs have similar operational concerns as Oracle products that run on-premises. However, you don't need to manage the underlying compute, networking, and storage infrastructure.

Observability

To implement observability for your Oracle E-Business Suite deployment on Google Cloud, you can use Google Cloud Observability services or Oracle Enterprise Manager. Choose an appropriate monitoring strategy depending on your requirements and constraints. For example, if you run other workloads in Google Cloud in addition to Oracle E-Business Suite applications, then you can use Google Cloud Observability services to build a unified operations dashboard for all of the workloads.

More operational considerations

When you build the architecture for your workload, consider the general best practices and recommendations for operational efficiency that are described in Well-Architected Framework: Operational excellence pillar.

Performance optimization

This section describes the factors to consider when you use this reference architecture to design a topology in Google Cloud that meets the performance requirements of your workloads.

Compute performance

Compute Engine offers a wide range of predefined and customizable machine types that you can choose from depending on the performance requirements of your Oracle E-Business Suite applications.

Choose an appropriate machine type based on your performance requirements. To get a list of the available machine types that support Hyperdisk volumes and that meet your performance and other requirements, use the Machine series comparison table.

Network performance

Compute Engine has a per-VM limit for egress network bandwidth. This limit depends on the VM's machine type and whether traffic is routed through the same VPC network as the source VM. For VMs with certain machine types, to improve network performance, you can get a higher maximum egress bandwidth by enabling Tier_1 networking. For more information, see Configure per VM Tier_1 networking performance.

Network traffic between the application tier VMs and the Oracle Exadata network is routed through a low-latency Partner Interconnect connection that Google sets up.

Exadata Infrastructure uses RDMA over Converged Ethernet (RoCE) for high bandwidth and low latency networking among the database servers and storage servers. The servers exchange data directly in main memory without involving the processor, cache, or operating system.

Hyperdisk storage performance

The architecture that is described in this document uses Hyperdisk volumes for all of the boot disks of the VMs that host the Oracle E-Business Suite applications. Hyperdisk lets you scale performance and capacity dynamically. You can adjust the provisioned IOPS, throughput, and the size of each volume to match your workload's storage performance and capacity needs. The performance of Hyperdisk volumes depends on the Hyperdisk type and the machine type of the VMs to which the volumes are attached. For more information about Hyperdisk performance limits and tuning, see the following documentation:

More performance considerations

When you build the architecture for your workload, consider the general best practices and recommendations that are provided in Well-Architected Framework: Performance optimization pillar.

What's next

Contributors

Authors:

Other contributors: