A direct connection between Azure and OCI clouds is available as part of the Microsoft and Oracle partnership. It allows easily to set up an efficient connection between the infrastructure of both clouds bypassing external suppliers. More information on this subject is available at https://aka.ms/OracleOnAzure or www.oracle.com/cloud/oci-azure.html.
A series of comparative tests was conducted to select the appropriate solution when designing architecture for specific requirements. The purpose of this document is to present the results of these tests as well as the conclusions of the performance analysis performed.
Both network and application layer delays were tested by measuring the communication of the application placed in a virtual machine for the Autonomous Database service operating in the OCI cloud. Network layer tests were performed considering all availability zones/domains in both clouds, while in the database part the most efficient configuration in terms of network latency was used.
Test infrastructure was created in Western Europe / Netherlands Northwest (Amsterdam) region. At the date of creating this document, this region has one Availability Domain in the OCI cloud and three Availability Zones in Microsoft Azure. Tests showed that the connection between the clouds is implemented between one of the zones in Azure (in our case Availability Zone 3), and the only domain Domain Availability 1 in OCI (numbering of zones in Azure may be different depending on the subscription).
For testing purposes, the following environment was created in Western Europe/ Amsterdam region:
On the Azure site:
- Azure – OCI dedicated resource group
- VNET 10.20.0.0/16 with one subnet 10.20.0.0/24 and a subnet for the needs of GW
- three virtual machines azoci-vm3, azoci-vm4, azovi-vm5, each in a different availability zone with Oracle Linux 7.7 installed
- Virtual Network Gateway
- Express Route
- a Routing Table with appropriate entries to allow traffic to the OCI network
- relevant entries in the Network Security Group
- the FastPath option was optionally enabled
On the OCI site:
- dedicated azoci compartment
- VCN 10.30.0.0/16 network with 10.30.0.0/24 and 10.30.1.0/24 subnets
- two azoci-vm1 and azoci-vm2 virtual machines with the Oracle Linux 7.7 operating system
- Security Lists and Network Security Group respectively
- Internet Gateway
- relevant entries in the Routing Table
- Dynamic Routing Gateway
- Fast Connect
The configuration details are presented in the following diagram:
The tests used the Oracle Autonomous Transaction Processing Database and the Swingbench tool (Order Entry Benchmark) run on a server in OCI and AZURE.
Autonomous Database configuration:
- Dedicated Infrastructure: No
- OCPU Count: 2
- Storage TB: 1
- Workload type: Transaction processing
- Database version: 19c
- Auto Scaling Enabled: Yes
- Access Type: Virtual Cloud Network
- Subnet: azocisubnet10_30_0
- Privet IP: 10.30.0.3
- Network Secutity Group: azoci_all
NETWORK LATENCY ANALYSIS
Network delays were studied using the basic mtr and ping system tools. Tests were performed in several configurations by changing the connection parameters on the Azure side (FastPath) and modifying the virtual machine network settings also on the Azure side (Accelerated Networking). Delays were measured between virtual machines located in Azure in different availability zones and a machine operating in OCI.
On the OCI side, a 1Gbps connection was selected, on the Azure side a 50Mbps connection (modification to 1Gbps did not affect the measured delays).
Tests were carried out in 5-minute sequences.
- in most tested configurations the lowest delays were for a machine operating in zone 3, however, with the FastPath option disabled, the delays for machines from each zone are at a similar level (2.5-2.7ms)
- latencies are reduced by approx. 50% (up to 1 ms) with the FastPath option enabled. This applies only to the virtual machine located in zone 3. For the remaining zones, the differences are only 10% and the delays do not fall below 1.9 ms, regardless of whether Accelerated Networking functionality is enabled.
- enabling Accelerated Networking functionality only has a slight impact on delays. The decrease is on the order of several percent. Please note that this functionality is available on D / DSv2 and F / Fs machine sizes for at least 2 vCPU and D / Dsv3, E / Esv3, Fsv2, Lsv2, Ms / Mms and Ms / Mmsv2 for at least 4 vCPU (https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-cli#limitations-and-constraints)
Latency tests were also carried out within the network and within one cloud.
The following aspects should be noted:
- enabling Accelerated Networking functionality does not affect the latency
- latencies between machines within one zone (or between zones 1 and 2) are comparable to latencies occurring in the connection between clouds in the most favorable configuration (i.e. with the FastPath option enabled)
- latencies between zones 1 or 2 and zone 3 are greater and comparable to the latencies occurring in the connection between the clouds in the standard configuration (i.e. when the FastPath option is off)
LATENCY ANALISYS IN THE APPLICATION LAYER
The graphs below present the average delays for all types of transactions measured on the application side as well as the number of transactions per second. The latency consists of the time in which the operation is sent to the database and when the task is performed on the database side.
All tests consisted of transactions such as:
- Customer Registration
- Update Customer Details (najktótsze transakcje)
- Browse Products
- Order Products (najdłuższe transakcje)
- Process Orders
- Browse Orders
Below there are test results for a direct connection – Autonomous Database and Swingbench on a virtual server in the Oracle Cloud in the same network.
Outside the peak, the response times are very stable immediately after the test starts with an average value of 8. The average response time of the shortest transactions (Update Customer Details) was 1.84ms, and the longest (Order Products) reached 16.81ms.
Below there are test results for the azure connection ->Autonomous Database on OCI and Swingbench on a virtual server in the Azure cloud in zone 3 with a 50Mbps connection.
As in the previous chart – except the initial peak – immediately after starting the test, response times are very stable at 23 and 22. The average response time of the shortest transactions (Update Customer Details) was 5.93ms, and the longest (Order Products) reached 49.78ms
Test results for the azure connection -> Autonomous Database on OCI and Swingbench on a virtual server in the Azure cloud in zone 3 with a 1Gbps connection are presented below
The response times are similar and very stable (the same as in the graph above). The connection differed only in bandwidth, which had no significant impact on delays. The average response time of the shortest transactions (Update Customer Details) was 6.28ms, and the longest (Order Products) reached 50.29ms
The final test for azure connection -> Autonomous Database on OCI and Swingbench on a virtual server in the Azure cloud in zone 3 with the FastPath option enabled
Response times are stable on the level circa twice lower than without the FP – 13 option enabled.
The average response time of the shortest transactions (Update Customer Details) was 3.33ms and the longest (Order Products) reached 27.45ms.
The following table summarizes the application tests performed for the average measurement results:
The most efficient configuration is when the application is located closest to the database. Increased latency times entail a decline in executable operations. Tests were carried out under the same conditions of the application (i.e. without changes in its configuration). Modifying the degree of parallelization, the efficiency at the same level of latencies can be increased.
We note the following observations:
- interconnect connection between Azure and OCI clouds is stable with regulated performance, thus allowing to adjust the link type to the application requirements
- zusing the FastPath connection allows to reduce significantly the response time for applications requiring short communication times with the database
- the difference in the number of transactions per second results directly from greater latencies. It can be important for very demanding application environments. The number of transactions per second can be increased by changing the configuration, i.e. increasing the parallelization on the application side (more database sessions)
It follows from the above that thanks to the interconnect functionality between the clouds it is possible to run both applications which are relatively not sensitive to database communication times as well as very demanding applications. This allows the implementation of various combinations of the best Azure products with the best OCI functionalities (such as Oracle RAC or Oracle Autonomous Database)
No comparative tests were performed here for a VPN-based configuration or for an external connection provider between clouds in the same region. Experience shows that the latency times in such configurations are much higher, which may preclude comfortable operation of the application.
Date of document: 19.03.2020
Authors of the analysis:
Oracle department, Advatech
Oracle department, Advatech