This document provides a reference architecture to help you build theinfrastructure to host a highly available enterprise application that uses anOracle database, with the entire stack deployed on Compute Engine VMs. You canuse this reference architecture to efficientlyrehost (lift and shift) on-premises applications that use Oracle databases to Google Cloud. Thisdocument also includes guidance to help you build an Oracle Database topology inGoogle Cloud that meetsOracle's maximum availability architecture (MAA) requirements. The intended audience for this document is cloud architects andOracle database administrators. The document assumes that you're familiar withCompute Engine and Oracle Database.

If you use Oracle Exadata or Oracle Real Application Clusters (Oracle RAC) torun Oracle databases on-premises, you can efficiently migrate your applicationsto Google Cloud and run your databases on Oracle Database@Google Cloud. For moreinformation, seeEnterprise application on Compute Engine with Oracle Exadata.

Architecture

The following diagram shows the infrastructure for a multi-tier enterpriseapplication that uses Oracle Database. The web tier, application tier, andOracle Database instances are hosted on Compute Engine VMs. The web tierand application tier run in active-active mode on VMs that are distributedacross two zones within a Google Cloudregion.The primary and standby database instances are deployed in separate zones. Thisarchitecture is alignedwith theregional deployment archetype,which helps to ensure that your Google Cloud topology is robust againstsingle-zone outages¹.

Note: You can adapt the architecture in this document to build a topologythat's robust against regional outages by using the multi-regional deploymentarchetype. For more information, seeMulti-regional deployment on Compute Engine and also the guidance in theReliability section later in this document.

The architecture that's shown in the preceding diagram includes the followingcomponents:

Component	Purpose
Regional external Application Load Balancer	The regional external Application Load Balancer receives and distributes user requests to the web tier VMs.
Google Cloud Armor security policy	The Cloud Armor security policy helps to protect your application stack against threats like distributed denial-of-service (DDoS) attacks and cross-site scripting (XSS).
Regionalmanaged instance group (MIG) for the web tier	The web tier of the application is deployed on Compute Engine VMs that are part of a regional MIG. This MIG is the backend for the external Application Load Balancer. The MIG contains Compute Engine VMs in two zones. Each of these VMs hosts an independent instance of the web tier of the application.
Regional internal Application Load Balancer	The regional internal Application Load Balancer distributes traffic from the web tier VMs to the application tier VMs.
Regional MIG for the application tier	The application tier, such as an Oracle WebLogic Server cluster, is deployed on Compute Engine VMs that are part of a regional MIG. This MIG is the backend for the internal Application Load Balancer. The MIG contains Compute Engine VMs in two zones. Each VM hosts an independent instance of the application server.
Oracle Database instances deployed on Compute Engine VMs	The application in this architecture uses a primary-standby pair of Oracle Database instances that are deployed on Compute Engine VMs in separate zones. You bring your own licenses (BYOL) for these Oracle Database instances, and you manage the VMs and database instances.
Google Cloud Hyperdisk Storage Pools	The VMs in each zone (across all the tiers in the application stack) use Hyperdisk Balanced volumes from a Hyperdisk Storage Pool. Creating and managing all the disks in a single storage pool lets you improve capacity utilization and reduce operational complexity while maintaining the storage capacity and performance that the VMs need.
Oracle Data Guard FSFO observer	The Oracle Data Guard Fast-Start Failover (FSFO) observer is a lightweight program that initiates automatic failover to the standby Oracle Database instance when the primary instance is unavailable. The observer runs on a Compute Engine VM in a zone that's different from the zones where the primary and standby database instances are deployed.
Cloud Storage bucket	To store backups of the Oracle Database instances, this architecture uses a Cloud Storage bucket. To facilitate recovery of the database during a region outage, you can store the backups geo-redundantly in adual-region or multi-region bucket.
Virtual Private Cloud (VPC) network andsubnet	All the Google Cloud resources in the architecture use a single VPC network and subnet. Depending on your requirements, you can choose to build an architecture that uses multiple VPC networks or multiple subnets. For more information, seeDeciding whether to create multiple VPC networks.
PublicCloud NAT gateway	The architecture includes a public Cloud NAT gateway to enable secure outbound connections from the Compute Engine VMs that have only internal IP addresses.
Cloud Interconnect andCloud 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, seeChoosing a Network Connectivity product.
Cloud Monitoring andCloud Logging	Cloud Monitoring helps you to observe the behavior, health, and performance of your application and Google Cloud resources.Ops Agent collects metrics and logs from the Compute Engine VMs, including the VMs that host the Oracle Database instances. The agent sends logs to Cloud Logging and sends metrics to Cloud Monitoring.

Products used

This reference architecture uses the following Google Cloud products:

• Compute Engine: A secure and customizable compute service that lets youcreate and run VMs on Google's infrastructure.
• Google Cloud Hyperdisk: A network storage service that you can use to provisionand dynamically scale block storage volumes with configurable and predictableperformance.
• Cloud Load Balancing: A portfolio of high performance, scalable, global andregional load balancers.
• Cloud Storage: A low-cost, no-limit object store for diverse data types.Data can be accessed from within and outside Google Cloud, and it'sreplicated across locations for redundancy.
• Virtual Private Cloud (VPC): A virtual system that provides global, scalablenetworking functionality for your Google Cloud workloads. VPC includesVPC Network Peering, Private Service Connect, private services access, andShared VPC.
• Google Cloud Armor: A network security service that offers web applicationfirewall (WAF) rules and helps to protect against DDoS and application attacks.
• Cloud NAT: A service that provides Google Cloud-managedhigh-performance network address translation.
• Cloud Monitoring: A service that provides visibility into theperformance, availability, and health of your applications and infrastructure.
• Cloud Logging: A real-time log management system with storage, search,analysis, and alerting.
• Cloud Interconnect: A service that extends your external network to theGoogle network through a high-availability, low-latency connection.
• Cloud VPN: A service that securely extends your peer network to Google'snetwork through an IPsec VPN tunnel.

This reference architecture uses the following Oracle products:

• Oracle Database: A relational database management system (RDBMS) thatextends the relational model to an object-relational model.
• Oracle Data Guard: A set of services to create, maintain, manage, andmonitor one or more standby databases.

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

Design considerations

This section describes design factors, best practices, and designrecommendations that you should consider when you use this referencearchitecture to develop a topology that meets your specific requirements forsecurity, reliability, operational efficiency, cost, and performance.

The guidance in this section isn't exhaustive. Depending on the specificrequirements of your application and the Google Cloud and third-partyproducts and features that you use, there might be additional design factors andtrade-offs that you should consider.

System design

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

Region selection

When you choose the Google Cloud regions where your applications must bedeployed, consider the following factors and requirements:

• Availability of Google Cloud services in each region. For moreinformation, seeProducts available by location.
• Availability of Compute Engine machine types in each region. Formore information, seeRegions and zones.
• End-userlatency requirements.
• Cost of Google Cloud resources.
• Cross-regional data transfer costs.
• Regulatory requirements.

Some of these factors and requirements might involve trade-offs. Forexample, the most cost-efficient region might not have the lowestcarbon footprint. For more information, seeBest practices for Compute Engine regions selection.

Compute infrastructure

The reference architecture in this document uses Compute Engine VMs forcertain tiers of the application. Depending on the requirements of yourapplication, you can choose from other Google Cloud compute services:

• Containers: You can runcontainerized applications inGoogle Kubernetes Engine (GKE) clusters. GKE is a container-orchestration engine thatautomates deploying, scaling, and managing containerized applications.
• Serverless: If you prefer to focus your IT efforts on your data andapplications instead of setting up and operating infrastructure resources,then you can useserverless services likeCloud Run.

The decision of whether to use VMs, containers, or serverless services involvesa trade-off between configuration flexibility and management effort. VMs andcontainers provide more configuration flexibility, but you're responsible formanaging the resources. In a serverless architecture, you deploy workloads to apreconfigured platform that requires minimal management effort. For moreinformation about choosing appropriate compute services for your workloads inGoogle Cloud, seeHosting Applications on Google Cloud.

Storage options

For the Compute Engine VMs in the architecture, you can useHyperdisk orPersistent Disk boot volumes. Hyperdisk volumes provide better performance,flexibility, and efficiency than Persistent Disk. WithHyperdisk Balanced,you can provision IOPS and throughput separately and dynamically, which lets youtune the volume to a wide variety of workloads.

To store application binaries, useFilestore.Files that you store in aFilestore Regional instance are replicated synchronously across three zones within theregion.This replication helps to ensurehigh availability and robustness against zone outages. For robustness against region outages, youcan replicate a Filestore instance to a different region. Formore information, seeInstance replication.

When you design storage for your workloads, consider the functionalcharacteristics of the workloads, resilience requirements, performanceexpectations, and cost goals. For more information, seeDesign an optimal storage strategy for your cloud workload.

Network design

Choose a network design that meets your business and technical requirements. Youcan use a single VPC network or multiple VPC networks. For more information, seethe following documentation:

• Deciding whether to create multiple VPC networks
• Decide the network design for your Google Cloud landing zone

Security, privacy, and compliance

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

Protection against external threats

To protect your application against threats like distributed-denial-of-service(DDoS) attacks and cross-site scripting (XSS), you can use Google Cloud Armorsecurity policies. Each policy is a set of rules that specifies certainconditions that should be evaluated and actions to take when the conditions aremet. For example, a rule could specify that if the source IPaddress of the incoming traffic matches a specific IP address or CIDR range,then the traffic must be denied. You can also apply preconfigured webapplication firewall (WAF) rules. For more information, seeSecurity policy overview.

External access for VMs

In the reference architecture that this document describes, theCompute Engine VMs don't need inbound access from the internet. Don'tassignexternal IP addresses to the VMs. Google Cloud resources that have only a private, internal IPaddress can still access certain Google APIs and services by usingPrivate Service Connect or Private Google Access. For moreinformation, seePrivate access options for services.

To enable secure outbound connections from Google Cloud resources thathave only private IP addresses, like the Compute Engine VMs in thisreference architecture, you can useSecure Web Proxy orCloud NAT.

Service account privileges

For the Compute Engine VMs in the architecture, instead of using thedefault service accounts, we recommend that you create dedicated serviceaccounts and specify the resources that the service account can access. Thedefault service account has a broad range of permissions, including some thatmight not be necessary. You can tailor dedicated service accounts tohave only the essential permissions. For more information, seeLimit service account privileges.

SSH security

To enhance the security of SSH connections to the Compute Engine VMs inyour architecture, implementIdentity-Aware Proxy (IAP) andCloud OS Login API.IAP lets you control network access based on user identity andIdentity and Access Management (IAM) policies. Cloud OS Login API lets you controlLinux SSH access based on user identity and IAM policies. Formore information about managing network access, seeBest practices for controlling SSH login access.

Disk encryption

By default, the data that's stored in Hyperdisk volumes is encryptedusing Google-owned and Google-managed encryption keys. As an additional layer of protection, youcan choose to encrypt the Google-owned data encryption keys by using keys thatyou own and manage in Cloud Key Management Service (Cloud KMS). For more information,seeAbout disk encryption.

Network security

To control network traffic between the resources in the architecture, you mustconfigure appropriateCloud Next Generation Firewall (NGFW) policies.

More security considerations

When you build the architecture for your workload, consider the platform-levelsecurity best practices and recommendations that are provided in theEnterprise foundations blueprint andGoogle Cloud Well-Architected Framework: Security, privacy, and compliance.

Reliability

This section describes design factors to consider when you use this referencearchitecture to build and operate reliable infrastructure for your deployment inGoogle Cloud.

Robustness against VM failures

In the architecture that's shown in this document, if a Compute EngineVM in any of the tiers fails, the application can continue to processrequests.

• If a VM in the web tier or application tier crashes, the relevantMIG recreates the VM automatically.The load balancers forward requests to only the available webserver instances and application server instances.
• If the VM that hosts the primary Oracle Database instance fails, theOracle Data Guard FSFO observer initiates an automatic failover to thestandby Oracle Database instance.

VM autohealing

Sometimes the VMs that host your application might be running and available, butthere might be issues with the application itself. The application might freeze,crash, or not have sufficient memory. To verify whether an application isresponding as expected, you can configure application-based health checks aspart of the autohealing policy of your MIGs. If the application on a particularVM isn't responding, the MIG autoheals (repairs) the VM. For more informationabout configuring autohealing, seeAbout repairing VMs for high availability.

Robustness against zone outages

If a zone outage occurs, the application remains available.

• The web tier and application tier are available (and responsive)because the VMs are in regional MIGs. The regional MIGs ensure that new VMsare created automatically in the other zone to maintain the configuredminimum number of VMs. The load balancers forward requests to the availableweb server VMs and application server VMs.
• If an outage affects the zone that has the primary Oracle Databaseinstance, then the Oracle Data Guard FSFO observer initiates an automaticfailover to the standby Oracle Database instance. The FSFO observer runs ona VM in a zone that's different from the zones that have the primary andstandby database instances.
• To ensure high availability of data in Hyperdisk volumes during asingle-zone outage, you can useHyperdisk Balanced High Availability.When data is written to a volume, the data is replicated synchronouslybetween two zones in the same region.

Robustness against region outages

If both of the zones in the architecture have an outage or if a region outageoccurs, then the application is unavailable. To reduce the downtime caused bymulti-zone or region outages, you can implement the following approach:

• Maintain a passive (failover) replica of the infrastructure stack inanother Google Cloud region.

• Use adual-region or multi-region Cloud Storage bucket to store the Oracle Database backups. The backups are replicatedasynchronously across at least two geographic locations. With replicateddatabase backups, your architecture maps toOracle's Maximum Availability Architecture (MAA) Silver tier.

  To achieve faster replication for backups stored in dual-region buckets,you can use turbo replication. For more information, seeData availability and durability.

• If an outage occurs in the primary region, use the database backup torestore the database and activate the application in the failover region.UseDNS routing policies to route traffic to the load balancer in the failover region.

For business-critical applications that must continue to be available even whena region outage occurs, consider using themulti-regional deployment archetype.For the database tier, you can use Oracle Active Data Guard FSFO toautomatically failover to a standby Oracle Database instance in the failoverregion. This approach maps toOracle's MAA Gold tier.

MIG autoscaling

To control the autoscalingbehavior of your stateless MIGs, you can specify target utilization metrics,such as average CPU utilization. You can also configure schedule-basedautoscaling for stateless MIGs.Stateful MIGs can't be autoscaled. For more information, seeAutoscaling groups of instances.

MIG size limit

When you decide the size of your MIGs, consider the default and maximum limitson the number of VMs that can be created in a MIG. For more information, seeAdd and remove VMs from a MIG.

VM placement

To improve the robustness of the architecture, you can create aspread placement policy and apply it to the MIG template. When the MIG creates VMs, it places the VMswithin each zone on different physical servers (calledhosts), so your VMs arerobust against failures of individual hosts. For more information, seeCreate and apply spread placement policies to VMs.

VM capacity planning

To make sure that capacity for Compute Engine VMs is available when VMsneed to be provisioned, you can createreservations. A reservation providesassured capacity in a specific zone for a specified number of VMs of a machinetype that you choose. A reservation can be specific to a project, or sharedacross multiple projects. For more information about reservations, seeChoose a reservation type.

Block storage availability

The architecture in this document uses a Hyperdisk Storage Pool in each zone toprovide block storage for the Compute Engine VMs. You create a pool ofblock storage capacity for a zone. You then create Hyperdisk volumes in thestorage pool and attach the volumes to VMs in the zone. The storage poolattempts to add capacity automatically to ensure that the utilization ratedoesn't exceed 80% of the pool's provisioned capacity. This approach ensuresthat block storage space is available when required. For more information, seeHow Hyperdisk Storage Pools work.

Stateful storage

A best practice in application design is to avoid the need for stateful localdisks. But if the requirement exists, you can configure your persistent disks tobe stateful to ensure that the data is preserved when the VMs are repaired orrecreated. However, we recommend that you keep the boot disks stateless, so thatyou can update them to the latest images with new versions and securitypatches. For more information, seeConfiguring stateful persistent disks in MIGs.

Backup and recovery

The architecture in this document uses Cloud Storage to store databasebackups. If you choose the dual-region or multi-regionlocation type for the Cloud Storage bucket, the backups are replicated asynchronouslyacross at least two geographic locations. If a region outage occurs, you can usethe backups to restore the database in another region. With a dual-regionbucket, you can achieve faster replication by enabling the turbo replicationoption. For more information, seeData availability and durability.

You can use Backup and DR Service to create, store, and manage backups ofCompute Engine VMs. Backup and DR Service stores backup data in itsoriginal, application-readable format. When required, you can restore workloadsto production by directly using data from long-term backup storage withouttime-consuming data-movement or preparation activities. For more information,see the following documentation:

• Backup and DR for Compute Engine instance backups
• Backup and DR for Oracle

More reliability considerations

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

• Google Cloud infrastructure reliability guide
• Patterns for scalable and resilient apps
• Designing resilient systems
• Google Cloud Well-Architected Framework: Reliability

Cost optimization

This section provides guidance to optimize the cost of setting up and operatinga Google Cloud topology that you build by using this referencearchitecture.

VM machine types

To help you optimize the resource utilization of your VM instances,Compute Engine providesmachine type recommendations.Use the recommendations to choose machine types that match your workload'scompute requirements. For workloads with predictable resource requirements, youcan customize the machine type to your needs and save money by usingcustom machine types.

VM provisioning model

If your application is fault tolerant, thenSpot VMs can help to reduce your Compute Engine costs for the VMs in theapplication and web tiers. The cost of Spot VMs is significantly lowerthan regular VMs. However, Compute Engine might preemptively stop ordelete Spot VMs to reclaim capacity.

Spot VMs are suitable forbatch jobs that can tolerate preemption and don't have high availabilityrequirements. Spot VMs offer the same machine types, options, andperformance as regular VMs. However, when the resource capacity in a zone islimited, MIGs might not be able to scale out (that is, create VMs) automaticallyto the specified target size until the required capacity becomes availableagain.

VM resource utilization

Theautoscaling capability of stateless MIGs enables your application to handle increases intraffic gracefully, and it helps you to reduce cost when the need for resourcesis low.Stateful MIGs can't be autoscaled.

Oracle product licenses

You're responsible for procuring licenses for the Oracle products that youdeploy on Compute Engine, and you're responsible for complying with theterms and conditions of the Oracle licenses. For more information, seeLicensing Oracle Software in the Cloud Computing Environment.

Block storage resource utilization

The architecture in this document uses a Hyperdisk Storage Pool in each zone toprovide block storage for the Compute Engine VMs. You can improve theoverall utilization of block storage capacity and reduce cost by usingAdvanced capacity storage pools,which usethin provisioning and data reduction technologies to improve storage efficiency.

More cost considerations

When you build the architecture for your workload, also consider the generalbest practices and recommendations that are provided inGoogle Cloud Well-Architected Framework: Cost optimization.

Operational efficiency

This section describes the factors to consider when you use this referencearchitecture to design a Google Cloud topology that you can operateefficiently.

VM configuration updates

To update the configuration of the VMs in a MIG (such as the machine type orboot-disk image), you create a new instance template with the requiredconfiguration and then apply the new template to the MIG. The MIG updates theVMs by using the update method that you choose: automatic or selective. Choosean appropriate method based on your requirements for availability andoperational efficiency. For more information about these MIG update methods, seeApply new VM configurations in a MIG.

Oracle Linux images

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

Deterministic instance templates

If the instance templates that you use for your MIGs include startup scripts toinstall third-party software, make sure that the scripts explicitly specifysoftware-installation parameters such as the software version. Otherwise, whenthe MIG creates the VMs, the software that's installed on the VMs might not beconsistent. For example, if your instance template includes a startup script toinstall Apache HTTP Server 2.0 (theapache2 package), then make sure that thescript specifies the exactapache2 version that should be installed, such asversion2.4.53. For more information, seeDeterministic instance templates.

Block storage management

The architecture in this document uses a Hyperdisk Storage Pool in each zone toprovide block storage for the Compute Engine VMs. Hyperdisk StoragePools help to simplify storage management. Instead of allocating and managingcapacity individually for numerous disks, you define a pool of capacity that canbe shared across multiple workloads in a zone. You then create Hyperdisk volumesin the storage pool and attach the volumes to the VMs in the zone. The storagepool attempts to add capacity automatically to ensure that the utilization ratedoesn't exceed 80% of the pool's provisioned capacity.

Application server to database connectivity

For connections from your application to Oracle Database, we recommend that youuse the database VM'szonal internal DNS name rather than its IP address. Google Cloud automatically resolves the DNSname to the VM's primary internal IP address. An added advantage with thisapproach is that you don't need to reserve and assign static internal IPaddresses for the database VMs.

Oracle Database administration and support

When you run a self-managed Oracle Database instance on aCompute Engine VM, there are similar operational concerns as when yourun Oracle Database on-premises. However, with a Compute Engine VM youno longer need to manage the underlying compute, networking, and storageinfrastructure.

• For guidance about operating and managing your Oracle Databaseinstances, see the Oracle-provided documentation for the relevant release.
• For information about Oracle's support policy for Oracle Databaseinstances that you deploy in Google Cloud, seeOracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).

Observability for Oracle applications

To implement observability for Oracle workloads deployed in Google Cloud,you can useGoogle Cloud Observability services orOracle Enterprise Manager.Choose an appropriate monitoring strategy depending on your requirements andconstraints. For example, if you run other workloads in Google Cloud inaddition to Oracle workloads, then you can use Google Cloud Observability services tobuild a unified operations dashboard for all of the workloads.

More operational considerations

When you build the architecture for your workload, consider the general bestpractices and recommendations for operational efficiency that are described inGoogle Cloud Well-Architected Framework: Operational excellence.

Performance optimization

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

Compute performance

Compute Engine offers a wide range of predefined and customizablemachine types that you can choose from depending on the performance requirementsof your workloads.

• For the VMs that host the web tier and application tier, choose anappropriate machine type based on your performance requirements for thosetiers. To get a list of the available machine types that support Hyperdiskvolumes and that meet your performance and other requirements, use theMachine series comparison table.
• For the VMs that host the Oracle Database instances, we recommend thatyou use a machine type in theC4 machine series from the general-purpose machine family. C4 machine types provideconsistently high performance for database workloads.

VM multithreading

Each virtual CPU (vCPU) that you allocate to a Compute Engine VM isimplemented as a single hardware multithread. By default, two vCPUs share aphysical CPU core. For applications that involve highly parallel operations or that performfloating point calculations (such as genetic sequence analysis, and financialrisk modeling), you can improve performance by reducing the number of threadsthat run on each physical CPU core. For more information, seeSet the number of threads per core.

VM multithreading might have licensing implications for some third-partysoftware, like databases. For more information, read the licensing documentationfor the third-party software.

Network performance

For workloads that need low inter-VM network latency within the application andweb tiers, you can create a compact placement policy and apply it to the MIGtemplate that's used for those tiers. When the MIG creates VMs, it places theVMs on physical servers that are close to each other. While a compact placementpolicy helps improve inter-VM network performance, a spread placement policy canhelp improve VM availability as described earlier. To achieve an optimal balancebetween network performance and availability, when you create a compactplacement policy, you can specify how far apart the VMs must be placed. For moreinformation, seePlacement policies overview.

Compute Engine has a per-VM limit for egressnetwork bandwidth.This limit depends on the VM's machine type and whether traffic is routedthrough the same VPC network as the source VM. For VMs with certain machinetypes, to improve network performance, you can get a higher maximum egressbandwidth by enablingTier_1 networking.

Hyperdisk storage performance

The architecture that's described in this document uses Hyperdisk volumes forthe VMs in all the tiers. Hyperdisk lets you scale performance and capacitydynamically. You can adjust the provisioned IOPS, throughput, and the size ofeach volume to match your workload's storage performance and capacity needs. Theperformance of Hyperdisk volumes depends on the Hyperdisk type and the machinetype of the VMs to which the volumes are attached. For more information aboutHyperdisk performance limits and tuning, see the following documentation:

• Machine types that support Hyperdisk
• About Hyperdisk performance
• Hyperdisk performance limits
• Optimize Hyperdisk performance

More performance considerations

When you build the architecture for your workload, consider the general bestpractices and recommendations that are provided inGoogle Cloud Well-Architected Framework: Performance optimization.

What's next

• Accelerating cloud transformation with Google Cloud and Oracle
• Oracle MAA Reference Architectures
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Authors:

• Kumar Dhanagopal | Cross-Product Solution Developer
• Samantha He | Technical Writer

Other contributors:

• Andy Colvin | Database Black Belt Engineer, Oracle on Google Cloud
• Jeff Welsch | Director, Product Management
• Lee Gates | Group Product Manager
• Marc Fielding | Data Infrastructure Architect
• Mark Schlagenhauf | Technical Writer, Networking
• Michelle Burtoft | Senior Product Manager
• Rajesh Kasanagottu | Engineering Manager
• Sekou Page | Outbound Product Manager
• Souji Madhurapantula | Group Product Manager
• Victor Moreno | Product Manager, Cloud Networking
• Yeonsoo Kim | Product Manager