InterConnect is a secure, high throughput, redundant dedicated physical circuit, which is available in a subset of Oracle and Microsoft regions. In other words, it is a dedicated, redundant fiber cord, which bypasses the Internet and connects Microsoft Azure VNET with OCI VCN inside a given region (it does not connect Networks located in different regions). The connection uses the Border gateway protocol dynamic routing. You can find more information about the connection and possible business scenarios here.
What’s interesting, InterConnect utilizes Microsoft’s ExpressRoute and Oracle’s FastConnect technologies, which are dedicated and private connections between a given endpoint and the Cloud provider network. Microsoft and Oracle leveraged the technologies already present in their portfolio to seamlessly connect their Clouds.
Why should you choose InterConnect instead of connecting the Clouds through Internet with an on-premises or VPN gateway? Unlike the Internet, and apart from an extremely low latency, InterConnect comes with predictability in terms of performance, which is crucial in production environments. Another key factor is security. The connection is fully encrypted and goes through a physical connection with no exposure to the Internet.
The diagram below and corresponding table describe all the indispensable components which define the cross-cloud ecosystem.
Depending on the use case, it might be necessary to additionally extend the architecture by OCI Service Gateway or Azure On-premises data gateway.
OCI Service Gateway enables connectivity between VCNs and the services available inside Oracle Services Network, i.e., Autonomous Database.
You will need Azure On-premises data gateway in case your solution utilizes Analysis Services. Make sure to install the gateway on a VM residing in Azure VNET not on the OCI side in order to utilize the Interconnect functionality.
The diagram below visualizes the communication flow between Power BI, Azure Analysis Services, and Autonomous Database in OCI. The flow starts from Power BI, the data then goes through Analysis Services, the gateways, ending on Autonomous Database residing in Oracle Services Network. For the sake of simplicity, the diagram depicts Power BI desktop residing in a VM, but more than likely the enterprise scaled solutions would use Power BI service connecting with AAS via On-premises Data Gateway.
There are a few elements to be aware of when preparing for Multicloud Ecosytem Architecture deployment.
Ensure to select a region where Microsoft and Oracle are interconnected (check here).
Start work on Azure’s side in advance, as prior to provisioning, a screening procedure must take place, which may take up to a few days. OCI allows for provisioning all the components right from the start.
Estimate the costs and plan capacity according to the needs (size of expected workload). Make sure to choose correct bandwidth, SKU, and billing model. Choose Azure FastPath if low latency is an extremely important factor (it is only available with the UltraPerformance SKU).
Be aware that the bandwidth for the connection is the bandwidth value chosen for the ExpressRoute circuit.
It is crucial that the IP addresses do not overlap between OCI VCN and Microsoft Azure VNET.
Once the deployment is complete the costs should be closely monitored, starting from day one, by setting up budgets and notifications.
We highly recommend validating the configuration upon finishing the deployment and suggest the following tools:
1. Using OCI service metrics with oci_fastconnect namespace will allow to verify whether the traffic (i.e. triggered via a report refresh) goes through FastConnect. A bump on PACKETS RECEIVED/SENT and BYTES RECEIVED/SENT chart will be visible.
Please see sample screen below:
2. In the same way, ExpressRoute monitoring metrics of ExpressRoute circuit can be used to check if there has been any traffic registered during the test. Please find sample ExpressRoute connection metrics:
3. To measure the latency, it is best to use the ping utility, send 100 or more packages to get reliable results.
4. To see how the packages are being routed it is best to use tracert (Windows) or traceroute (Linux). This will show through which IP addresses the packages traverse, allowing to confirm whether the traffic goes through InterConnect (not the Internet).
We recommend doing the test before and after enabling InterConnect to compare the results.
5. Lastly, we recommend verifying the InterConnect throughput with a utility called Iperf3. It consists of client and server processes. Start the server on one endpoint and the client on the other one. The client transfers a load to the server so that the application can measure the throughput. Based on the results it will be possible to conclude whether all the capacity settings have been applied as planned.
Below are the sample testing results with iperf3:
As we can see, the use of InterConnect can be very flexible and may be implemented in a simple way. Lingaro, as a technology partner, closely cooperates with Microsoft and Oracle to leverage our competencies and experiences to deliver seamless Multicloud solutions.
