Oracle E‑Business Suite with Oracle Database on Compute Engine VMs

Last reviewed 2025-04-17 UTC

This document provides reference architectures to help you build the infrastructure to run Oracle E‑Business Suite applications with Oracle Database on Compute Engine VMs 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 Database and the Oracle E‑Business Suite technology stack and architecture.

If you need to use Oracle Exadata or Oracle Real Application Clusters (Oracle RAC), you can migrate your applications to Google Cloud and run your databases on Oracle Database@Google Cloud. For more information, see Oracle E‑Business Suite with Oracle Exadata in Google Cloud.

Architecture

Depending on your use case and requirements for availability and disaster recovery (DR), you can choose one of the following Google Cloud deployment archetypes to run Oracle E‑Business Suite applications on Google Cloud:

  • Zonal: Your applications run within a single Google Cloud zone. This deployment archetype is well suited for development and test environments and for non-critical applications that don't need high availability.
  • Regional: Your applications run independently in two or more zones within a single Google Cloud region. We recommend this deployment archetype for applications that aren't mission-critical but need robustness against zone outages.
  • Multi-regional: Your applications run independently in multiple zones across two or more Google Cloud regions, either in active-active or active-passive mode. This deployment archetype is ideal to support DR scenarios. We recommend this archetype for mission-critical applications that need resilience to region outages and disasters.

Choosing a deployment archetype helps to simplify your subsequent decisions regarding the Google Cloud products and features that you need for your architecture.

The following sections present four architecture options. Each option is based on one of the deployment archetypes:

Zonal architecture

The following diagram shows an architecture for Oracle E‑Business Suite applications with Oracle Database running in a single zone within a Google Cloud region. This architecture is aligned with the zonal deployment archetype.

An architecture for Oracle E‑Business Suite applications runs in a single zone within a Google Cloud region.

The architecture in the preceding diagram includes the following components:

Component Description
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 applications against threats like DDoS attacks and 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. Each VM hosts an independent instance of the application layer. The boot disk for each VM is a Google Cloud 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 zonal instance contains the application binaries and data. The Filestore instance is mounted on the Compute Engine VMs that host the application-layer components. The Filestore instance is replicated to the failover region.
Oracle Database (BYOL)

The Oracle E‑Business Suite applications use an Oracle Database instance that's deployed on a Compute Engine VM. The boot and data disks for the VM are Hyperdisk volumes.

You bring your own license (BYOL) for the Oracle Database instance, and you manage the VM and the database.
Application and database backups Backups of the application data and the database are created, stored, and managed by using Backup and DR Service.
Virtual Private Cloud (VPC) network and subnets

All of the Google Cloud resources in the architecture use a single VPC network. The VMs that host the application layer and the database use separate subnets.

Depending on your requirements, you can choose to build an architecture that uses multiple VPC networks. For more information, see Deciding whether to create multiple VPC networks.
Public NAT gateway The architecture includes a public Cloud NAT gateway for secure outbound connections from the Compute Engine VMs, which have only internal IP addresses. For example, the VMs can access the Oracle Linux Yum server to download OS packages.
Cloud Interconnect and 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.

Zonal architecture with a DMZ

The following diagram shows an architecture with two independent Oracle E‑Business Suite application layers running on Compute Engine VMs. One of the application layers is a demilitarized zone (DMZ), which serves external users of the Oracle E‑Business Suite applications. The other layer serves internal users. Both of the application layers run within a single zone in a Google Cloud region and use a single Oracle Database instance. Like the architecture in the preceding section, this architecture is aligned with the zonal deployment archetype.

An architecture for Oracle E‑Business Suite applications runs in a single zone with a DMZ within a Google Cloud region.

The architecture in the preceding diagram includes the following components:

Component Description
Regional external Application Load Balancer The external load balancer receives and distributes requests from external users to the external-facing application layer.
Regional internal Application Load Balancer The internal load balancer receives and distributes requests from internal users to an internal application layer.
Google Cloud Armor security policy The Google Cloud Armor security policy helps to protect your applications against external threats like DDoS attacks and 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. Each VM hosts an independent instance of the application layer. The internal and external applications are served from distinct sets of VMs. 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 zonal instance contains the application binaries and data. The Filestore instance is mounted on the Compute Engine VMs that host the application-layer components.
Oracle Database (BYOL)

The Oracle E‑Business Suite applications use an Oracle Database instance that's deployed on a Compute Engine VM. The boot and data disks for the VM are Hyperdisk volumes.

You bring your own license (BYOL) for the Oracle Database instance, and you manage the VM and the database.
Application and database backups Backups of the application data and database are created, stored, and managed by using Backup and DR.
Virtual Private Cloud (VPC) network and subnets

All of the Google Cloud resources in the architecture use a single VPC network. The VMs that host the application layer and the database use separate subnets.

Depending on your requirements, you can choose to build an architecture that uses multiple VPC networks. For more information, see Deciding whether to create multiple VPC networks.
Public NAT gateway The architecture includes a public Cloud NAT gateway for secure outbound connections from the Compute Engine VMs, which have only internal IP addresses. For example, the VMs can access the Oracle Linux Yum server to download OS packages.
Cloud Interconnect and Cloud VPN To connect your on-premises network to the VPC network in Google Cloud, you can use Cloud Interconnect or Cloud VPN. Administrators and internal application users use these connections to access the resources and applications, respectively. For information about the relative advantages of each approach, see Choosing a Network Connectivity product.

Regional 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. Both of the application deployments use a primary Oracle Database instance that runs on a VM in one of the zones. Oracle Data Guard manages replication and failover of the database to a standby Oracle Database instance in the second zone. This architecture is based on the regional deployment archetype.

An architecture for Oracle E‑Business Suite applications runs in two zones within a Google Cloud region.

The architecture in the preceding diagram includes the following components:

Component Description
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 applications against threats like distributed DDoS attacks and 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. 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.
Oracle Database (BYOL)

The Oracle E‑Business Suite applications use a primary-standby pair of Oracle Database instances that are deployed on Compute Engine VMs in separate zones. The boot and data disks for the VM are Hyperdisk volumes.

Oracle Data Guard manages replication and failover of the database from the primary instance to the standby instance.

You bring your own licenses (BYOL) for the Oracle Database instances, and you manage the VMs and databases.
Application and database backups Backups of the application data and database are created, stored, and managed by using Backup and DR.
Virtual Private Cloud (VPC) network and subnets

All of the Google Cloud resources in the architecture use a single VPC network. The VMs that host the application layer and database use separate subnets.

Depending on your requirements, you can choose to build an architecture that uses multiple VPC networks. For more information, see Deciding whether to create multiple VPC networks.
Public NAT gateway The architecture includes a public Cloud NAT gateway for secure outbound connections from the Compute Engine VMs, which have only internal IP addresses. For example, the VMs can access the Oracle Linux Yum server to download OS packages.
Cloud Interconnect and 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.

Multi-regional active-passive (DR) 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. Both of the application deployments use a primary Oracle Database instance that runs on a VM in one of the zones. Oracle Data Guard manages replication and failover of the database to a standby Oracle Database instance in the second zone. The architecture includes a smaller scale replica of the application stack in a remote (failover) region for DR. Like the architecture in the preceding section, this architecture is based on the regional deployment archetype.

An architecture for Oracle E‑Business Suite applications runs in two zones within a Google Cloud region, with a replica in a remote region for DR.

The architecture in the preceding diagram includes the following components:

Component Description
DNS failover routing policy A Cloud DNS public zone that's configured with a failover routing policy routes user requests to the load balancer in the region that's currently serving requests.
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 applications against threats like distributed DDoS attacks and 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 in the primary region 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 in the primary region.
Oracle Database (BYOL)

The Oracle E‑Business Suite applications use a primary-standby pair of Oracle Database instances that are deployed on Compute Engine VMs in separate zones in the primary region. The boot and data disks for the VM are Hyperdisk volumes.

Oracle Data Guard manages replication and failover of the database from the primary instance to the standby instance.

You bring your own licenses (BYOL) for the Oracle Database instances, and you manage the VMs and databases.
Application and database backups Backups of the application data and the database are created, stored, and managed by using Backup and DR.
Virtual Private Cloud (VPC) network and subnets

All of the Google Cloud resources in the architecture use a single VPC network. The VMs that host the application layer and database use separate regional subnets.

Depending on your requirements, you can choose to build an architecture that uses multiple VPC networks. For more information, see Deciding whether to create multiple VPC networks.
Public NAT gateway The architecture includes a public Cloud NAT gateway in each region for secure outbound connections from the Compute Engine VMs, which have only internal IP addresses. For example, the VMs can access the Oracle Linux Yum server to download OS packages.
Cloud Interconnect and 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.

Products used

These reference architectures use the following Google Cloud products:

  • 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.
  • 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 Interconnect: A service that extends your external network to the Google network through a high-availability, low-latency connection.
  • Cloud VPN: A service that securely extends your peer network to Google's network through an IPsec VPN tunnel.

These reference architectures use the following Oracle products:

  • Oracle E-Business Suite: A suite of applications for business operations like finance, human resources, and supply chain.
  • Oracle Database: A relational database management system (RDBMS) that extends the relational model to an object-relational model.
  • Oracle Data Guard: A set of services to create, maintain, manage, and monitor one or more standby databases.

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 these reference architectures to develop a topology that meets your specific requirements for security, reliability, operational efficiency, cost, and performance.

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 architectures in this document use Compute Engine VMs to host the applications and databases. Depending on the requirements of your application, you can choose the following other Google Cloud compute services.

  • Containers: 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.
  • Serverless: If you prefer to focus your IT efforts on your data and applications instead of setting up and operating infrastructure resources, then you can use serverless services like Cloud Run.

The decision of whether to use VMs, containers, or serverless services involves a trade-off between configuration flexibility and management effort. VMs and containers provide more configuration flexibility and control, but you're responsible for managing the resources. In a serverless architecture, you deploy workloads to a preconfigured platform that requires minimal management effort. The design guidance for those services is outside the scope of this document. For more information about service options, see Application Hosting Options.

Database migration

When you plan to migrate on-premises Oracle Database deployments to 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 to Oracle database deployments in Google Cloud, you can use standard Oracle tools like Oracle GoldenGate.

Storage options

The architectures that are shown in this document use Hyperdisk volumes for the boot disks of all the Compute Engine VMs and for the data disks of the VMs that host Oracle Database instances. Hyperdisk volumes provide better performance, flexibility, and efficiency compared to Persistent Disk. For information about Hyperdisk types and features, see About Hyperdisk.

For application data and binaries, all of the architectures in this document use 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 architectures that are shown in this document use 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 these reference architectures to design a topology in Google Cloud that meets the security and compliance requirements of your workloads.

Protection against external threats

To help protect your 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 the 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 web application firewall (WAF) rules. For more information, see Security policy overview.

External access for VMs

In the reference architectures that this document describes, the VMs that host the applications and databases 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, you can use Secure Web Proxy or Cloud NAT.

VM image security

To help ensure VM image security, you can use trusted images. Trusted images are images with software that meets your policy or security requirements. To ensure that your VMs use only trusted images, you can define an organization policy that restricts the use of images in specific public image projects. For more information, see Setting up trusted image policies.

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.

Disk 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.

Network security

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

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 these reference architectures to build and operate reliable infrastructure for your deployment in Google Cloud.

Robustness of the application layer against VM failures

With all of the architecture options in this document, if some (but not all) of the application VMs 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 of the database against VM failures

In a zonal architecture, if the database VM fails, you can restore the database to production on a new VM by using the backups that are stored in Backup and DR. After you restore the database, you need to connect the applications to the new database instance.

If data consistency is a priority, then set up a primary and a standby database instance, preferably on VMs that are in different zones as shown in Regional architecture. For replication and failover to the standby database instance, use Data Guard. Data Guard helps to ensure consistency by replicating transactions to the standby instance before acknowledging them on the primary instance. The primary-standby database architecture involves additional costs for infrastructure and licensing.

In a regional or multi-regional architecture, if the VM that hosts the primary database fails, Oracle Data Guard initiates a failover to the standby Oracle Database instance. During the failover process, the applications can't access the database.

Robustness against zone outages

In a zonal architecture, if the zone that hosts your deployment has an outage, the applications and the database are down. You can restore the applications and database to production in a different zone or region by using the backups that are stored in Backup and DR.

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 and the database are unavailable. You can restore the applications and database to production in a different region by using the backups that are stored in Backup and DR. To reduce the downtime, use the multi-regional active-passive (DR) architecture. After you bring up the applications and the database, you need to update the DNS routing policy to route traffic to the load balancer in the failover region.

For business-critical applications that can't tolerate downtime even when a region outage occurs, use the multi-regional active-active deployment archetype.

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.

Data durability

The architectures in this document use 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:

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 these reference architectures.

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 products 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.

More cost considerations

When you build the architecture for your workload, also consider the general best practices and recommendations that are provided in Google Cloud Architecture Framework: Cost optimization.

Operational efficiency

This section describes the factors to consider when you use these reference architectures 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.

Application server to database connectivity

For connections from your applications to Oracle Database, we recommend that you use the database VM's zonal internal DNS name rather than its IP address. Google Cloud automatically resolves the DNS name to the VM's primary internal IP address. An added advantage with this approach is that you don't need to reserve and assign static internal IP addresses for the database VMs.

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 Oracle workload on Google Cloud, consider the general best practices and recommendations for operational efficiency that are described in Google Cloud Architecture Framework: Operational excellence.

Performance optimization

This section describes the factors to consider when you use these reference architectures 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 workloads.

  • For the VMs that host the applications and the database, 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.
  • For the VM that hosts the Oracle Database instances, we recommend that you use a machine type in the C4 machine series from the general-purpose machine family. C4 machine types provide consistently high performance for database workloads.

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.

Hyperdisk storage performance

The architectures that are described in this document use Hyperdisk volumes for all of the boot disks of the VMs and for the database VM's data disks. 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 Google Cloud Architecture Framework: Performance optimization.

What's next

Contributors

Author: Kumar Dhanagopal | Cross-Product Solution Developer

Other contributors: