In this guest blog post, Art Danielov, CEO of FlashGrid, describes a multi-AZ high-availability architecture for mission-critical Oracle databases on Microsoft Azure and explains how FlashGrid Cluster enables Oracle RAC to span Azure availability zones.
Organizations deploying mission-critical applications that rely on Oracle Database face important choices when selecting a database architecture that meets uptime objectives and budget constraints. Two commonly documented approaches are Oracle AI Database@Azure and a self-managed single-instance database on an Azure Virtual Machine (VM). In both approaches, Oracle Data Guard can protect against an availability zone failure by maintaining a standby database in another zone.
A single Oracle RAC cluster spanning two or three Azure availability zones can provide database high availability (HA) during VM, instance, and availability-zone failures without requiring a complete RAC cluster in each zone. FlashGrid Cluster software supplies the storage and networking layer needed to deploy this architecture on Azure VMs.
Oracle RAC vs. Data Guard replication for database high availability
Active-passive database HA with a local standby is one of several Data Guard use cases. Automatic failover from the primary database to a designated standby requires Data Guard Broker Fast-Start Failover (FSFO) and an Observer. FSFO must be configured and tested for various failure scenarios, which adds operational work and creates configuration risk. Even when FSFO is properly configured, the database is unavailable for seconds to minutes while the switchover or failover between the primary and standby takes place during planned maintenance events (including OS, database home, and Grid Infrastructure home patching) and during unplanned database instance or database server outages.
Oracle RAC is a core Oracle technology for database high availability. It is an essential part of Oracle Maximum Availability Architecture reference architectures at the Gold level and higher. One of the defining features of Oracle RAC is active-active HA that enables zero database downtime during rolling maintenance and near-zero (measured in seconds) RTO during unexpected failures.
This demonstrates significant advantages of using Oracle RAC compared to relying solely on Data Guard for mission-critical database HA.
Multi-AZ architecture options for Oracle Database on Azure
According to Azure recommendations, the use of multiple VMs deployed across multiple availability zones provides the highest uptime SLA. The documented uptime SLA for Azure VMs deployed across two or more availability zones in the same region is 99.99 percent. A mission-critical application must have a multi-Availability Zone (AZ) architecture to be able to leverage this uptime SLA. Even if the target application uptime is much lower than 99.99 percent, a multi-AZ design may be necessary because database infrastructure downtime consumes only part of the application’s total downtime budget.
If Oracle RAC is selected for database HA, then two multi-AZ architectural options described below are available.
Option A: Two Oracle RAC clusters, one per availability zone, with Data Guard replication between them.
Figure 1. Two RAC clusters in different availability zones
This option is available with FlashGrid Cluster (in all Azure regions) and with Oracle AI Database@Azure (only in the regions with Dual zone capability).
It requires duplication of resources between the two clusters and therefore increases infrastructure cost and operational complexity.
It adds the complexity of a self-managed FSFO mechanism (except for Autonomous AI Database Serverless with Autonomous Data Guard). For Oracle AI Database@Azure, network paths and failure scenarios across Azure and OCI-managed infrastructure must be considered when designing observer placement.
The impact of the added Data Guard failover time on the target uptime SLA must be carefully assessed. For illustrative purposes, a 99.99 percent uptime SLA for the database service would allow no more than ten failover or switchover events per year if we assume five minutes of database downtime during a failover or switchover event. Since predicting the number of failover events per year is a difficult task, it is important to perform periodic Data Guard testing and tuning to minimize the failover and switchover times. Because failover times and the business impact of downtime are greater under heavier loads, it is important to allocate sufficient compute and I/O capacity to minimize the failover times during the peak load.
Option B: One Oracle RAC cluster spanning two or three availability zones.
Figure 2. One Multi-AZ RAC cluster spanning three availability zones
This Multi-AZ RAC option is available with FlashGrid Cluster in all Azure regions that have availability zones. It offers the same HA capabilities as a “local” Oracle RAC cluster with the added benefit of protecting against availability zone failures.
Implementing the storage and networking infrastructure required by Oracle RAC in a multi-AZ configuration can raise complexity and supportability concerns. FlashGrid Cluster addresses these concerns by automating deployment of all infrastructure components with an Azure Resource Manager (ARM) template, by automating installation and configuration of software components, and by utilizing only the components that have undergone extensive interoperability and reliability testing as a complete system.
It takes just 30 minutes to deploy a ready-to-use cluster with Oracle AI Database 26ai or 90 minutes with Oracle Database 19c. As a result, deployment of an Oracle RAC cluster across Azure availability zones is simpler and faster than a typical on-premises deployment of Oracle RAC in a single datacenter. The fully automated and repeatable deployment model is beneficial for HA as it helps to avoid costly human errors in the HA configuration.
Network latency and workload design
Spreading Oracle RAC nodes across availability zones increases network latency because of the distance between the AZs. However, based on FlashGrid’s measurements, the network latency between Azure availability zones within a region is less than one millisecond (ms) for most AZ pairs and will not have a critical impact on the performance of many workloads. For example, in the West US 2 region, FlashGrid measured a round-trip latency of less than 0.3 ms for 8 KB transfers between all pairs of availability zones. For workloads that are very sensitive to the latency of Cache Fusion operations, it is possible to configure a preferred database instance. The preferred instance handles all client requests, which minimizes the amount of Cache Fusion operations between the nodes and their impact on the workload performance.
It is important to note that neither option is a complete disaster-recovery (DR) solution. Both can protect against failures limited to a single availability zone, but recovery from a regional outage requires a multi-region DR strategy. For the database tier, this is typically implemented with asynchronous Data Guard or Oracle GoldenGate replication between regions.
Summary
A multi-AZ Oracle RAC architecture on Azure VMs offers all the HA capabilities of a “local” Oracle RAC cluster, including rapid recovery from instance or server failures and support for rolling maintenance, while protecting against an availability zone failure without duplicating an entire RAC cluster in each zone. It also avoids the complexity of Data Guard FSFO configuration required for automatic role transitions. FlashGrid Cluster packages and automates the infrastructure needed to implement the multi-AZ Oracle RAC architecture for mission-critical Oracle databases on Azure. FlashGrid Cluster is available through Microsoft Marketplace in all Azure commercial and Azure Government regions with production Oracle RAC deployments on Azure running since 2017.