Selecting Availability Zones to minimize latency between Oracle RAC nodes on Azure

Introduction

Availability zones are an essential building block for highly available application architectures on Azure cloud. For Oracle databases they also present an opportunity to achieve a database service level objective of 99.99% or higher by combining with Oracle RAC active-active database clustering technology and by spreading RAC nodes across two or three availability zones. FlashGrid Cluster enables the Multi-AZ Oracle RAC architecture on Azure. (Note that Oracle Database@Azure does not offer the Multi-AZ RAC capability, while implementing a self-built Oracle RAC solution on Azure VMs would be prohibitively complex and impractical for production use.)

However, Azure states that they strive to achieve round-trip latency between zones of less 2 ms without providing more detailed information by region or specific pair of availability zones. This uncertainty presents a challenge to architects because Oracle RAC is sensitive to latency between the RAC nodes and the stated 2 ms latency may be too high for many applications.

To eliminate the uncertainty and help with selecting an optimal architecture, FlashGrid measured the latencies between availability zones in all Azure regions. Our results show that, with rare exceptions, the actual P99 RTT latencies between AZs are well below 0.5 ms, which makes Multi-AZ clustering suitable for Oracle RAC. This article provides the measurement results and methods for your reference.

Additionally, when deploying a FlashGrid Cluster with two Oracle RAC nodes across availability zones, database performance can be further optimized by placing the database nodes in AZs that have the lowest network latency between them. This will help to minimize the latency of storage and Cache Fusion data transfers between the database nodes.

Using East US as an example (see table at end of document), we would deploy the RAC nodes to Zone B & Zone C based on the measured latency (note: we reference "Zone B" rather than "Zone 2",  as Zone mappings vary by customer subscription):

• Zone A ⇿ Zone B at 0.50ms
• Zone A ⇿ Zone C at 0.39ms
• Zone B ⇿ Zone C at 0.32ms

The higher latency between the quorum node and the database nodes has no impact on database performance.  

How Availability Zones are allocated to an Azure Subscription

Important! You must perform your own latency measurements to confirm actual latencies between availability zones in each of your Azure subscriptions.

Please consult with FlashGrid Support team when carrying out this testing to confirm results.

Azure maps physical Availability Zones randomly to the Availability Zone numbers 1, 2, 3 for each Azure subscription. The FlashGrid measurements in this document are represented by "Zone A", "Zone B" and "Zone C" and can be used for reference only.

There are no API or other published methods to identify which physical AZs are assigned to your Availability Zone numbers. 

If using two or more subscriptions under one Azure account, they are likely to map to different AZ's - you can compare the AZ allocations between two subscriptions using the dedicated ARM API called checkZonePeers.

How to measure inter-AZ latencies in your subscription

Microsoft recommends using sockperf in their article Test network latency between Azure VMs. Use of the ping tool is not recommended due to a difference in the way ICMP traffic is prioritized within the Azure network. FlashGrid recommends comparing UDP latency rather than TCP.

Use the following steps to performing your own testing:

1. Create a Resource Group in the region
2. Deploy a server to each Zone
   • use a common operating system (for instance, Oracle Linux 9.7),
   • on same size instances (for instance, Standard_D2s_v6).
3. Enable Accelerated Networking on the network interface
4. Build the sockperf tool as outlined in the above Microsoft article, and place a copy on each of the servers
5. on each server, start the sockperf listener process:

   • Temporarily allow sockperf connections on port 11111 (UDP & TCP). Traffic is blocked on this port by default on OL9.7:

     sudo firewall-cmd --add-port=11111/udp
     sudo firewall-cmd --add-port=11111/tcp

   • Start the listener:

     sockperf server --ip 0.0.0.0 --port 11111 --daemonize

6. from the server in zone 1

   • initiate a sockperf test to the server in zone 2. This will run for 101 seconds with a payload of 350 bytes:

     sockperf ping-pong -i REMOTE_PRIVATE_IP_ZONE2 -m 350 -t 101 -p 11111 --mps=2000

   • initiate a sockperf test to the server in zone 3

     sockperf ping-pong -i REMOTE_PRIVATE_IP_ZONE3 -m 350 -t 101 -p 11111 --mps=2000

7. from the server in zone 2

   • initiate a sockperf test to the server in zone 3

     sockperf ping-pong -i REMOTE_PRIVATE_IP_ZONE3 -m 350 -t 101 -p 11111 --mps=2000

Use the "percentile 99.000" output from each test to determine the network latency between the VMs. Sockperf will return results in us (microseconds), divide by 1000 for ms (milliseconds).

Selecting optimal AZ assignment when deploying a FlashGrid Cluster

Once you have measured the latency between the different AZ pairs, determine which pair of AZs has the lowest latency.  When deploying your cluster using the FlashGrid Launcher, select that AZ pair for the database nodes. 

For instance, if Zone 2 and Zone 3 have the lowest inter-AZ latency, then you should place the two database nodes in AZ 2 and 3, and the quorum node in AZ 1 as demonstrated below:

Inter-AZ latency results by Azure region

FlashGrid measured the following latencies between Azure AZs in September 2026. The list below includes all Azure commercial regions that supported AZs at the time of publication.

As mentioned above, there are no API or other published methods for identifying which physical AZs are assigned to Availability Zone names in your Azure subscription. FlashGrid measurements in this document are therefore represented by "Zone A", "Zone B" and "Zone C".

We recommend you collect your own results before choosing the best pairing. Please consult with FlashGrid Support when using this method to determine optimum placement.

About FlashGrid Cluster for Oracle RAC on Azure

FlashGrid Cluster is a virtual clustered appliance that enables deployment of Oracle RAC on Azure VMs for mission-critical transaction processing workloads. Oracle RAC nodes can be distributed across Azure Availability Zones to support database uptime of 99.99% or higher, depending on the deployment architecture and availability requirements. Deployment is fully automated using Infrastructure-as-Code and typically completes in 30 to 90 minutes. FlashGrid provides 24/7 technical support covering the complete infrastructure stack used by the cluster. First introduced on Azure in 2017, FlashGrid Cluster for Oracle RAC is available in all Azure regions, including Azure Government and Azure China.

Additional Information

FlashGrid Cluster for Oracle RAC on Azure: Architecture

Technical blog: Multi-AZ RAC: the missing part in Oracle MAA Reference Architectures

Technical blog: Multi-AZ vs. Multi-Region in the Cloud

Technical blog: Migration of mission-critical Oracle databases to AWS, Azure, or Google Cloud – comparing platform options

Comparing FlashGrid Cluster with Oracle Database@Azure for running mission-critical Oracle databases on Azure

Microsoft Marketplace: FlashGrid for Oracle RAC and Database HA