本文介绍了如何通过 Oracle 云互连将您的 Azure 网络连接到 Oracle 云基础设施 (OCI)。许多中大型组织运行基于 Oracle 软件的应用程序。当这些组织迁移到云时，他们可能会选择将 Oracle 工作负载用于 Oracle 云，而将其他所有工作负载用于 Azure。本文探讨了如何连接 Azure 工作负载到 Oracle 工作负载，并使用 Oracle 云互连来最小化延迟。

📢 **Oracle 云互连：连接 Azure 和 OCI** Oracle 云互连（OCI）是一种连接 Azure 工作负载到 Oracle 工作负载的解决方案。它通过 Microsoft 和 Oracle 的私有“站点到站点”连接机制（Azure ExpressRoute 和 Oracle FastConnect）实现。OCI 允许跨云连接，无需与 ISP 联系租赁 ExpressRoute 线路，因为线路已存在。您只需为使用付费，例如在 Azure 中，通过为 ExpressRoute 线路 Azure 资源付费。

📡 **位置、位置、位置：确定互连区域** OCI 互连机制会影响您可以部署 ExpressRoute 线路和 FastConnect 资源的位置，因为性能和延迟至关重要。因此，存在对哪些 Azure/Oracle 区域可以互连以及线路必须终止位置的限制。当前，支持的区域包括 Azure 西欧、Azure 美国东部、Azure 美国中部、Azure 英国南部、Azure 欧洲西部和 Azure 亚洲东南亚。选择靠近 Oracle 云基础设施区域和 Azure 区域的 ExpressRoute 对等位置，以最大程度地减少延迟。

📣 **配置 ExpressRoute：选择 SKU 和速度** 在配置 ExpressRoute 时，您需要选择合适的 SKU 和速度。ExpressRoute 有两种类型：本地和标准。本地 SKU 提供无限的数据传输，但按带宽计费，而标准 SKU 提供计量或无限的数据传输，并按使用量计费。选择合适的 SKU 取决于您的数据传输需求和预算。此外，您还需要选择支持的速度，包括 1、2、5 或 10 Gbps。ISP 将是 Oracle 云 FastConnect。

📤 **连接过程：从 Azure 连接到 Oracle** 连接过程涉及在 Azure 中创建 ExpressRoute 网关和 ExpressRoute 线路，并配置 BGP 地址。BGP 地址的配置需要两个 /30 前缀，这些前缀在您的 OCI/Azure 网络中未使用。您需要两个前缀，因为 Azure 和 Oracle 在后台运行高可用性资源，每个资源都需要一个 IP 地址来通过 BGP 从 OCI 网关进行地址前缀的通告/接收，反之亦然。配置完 BGP 地址后，需要等待 ExpressRoute 线路状态变为“已预配”，然后才能创建线路和 ExpressRoute 网关之间的连接。一旦完成，您将看到 Oracle 已将已知地址传播到您的 Azure ExpressRoute 网关，并传播到任何未阻止来自网关的传播的子网。

📥 **其他支持事项：支持的 Oracle 服务和限制** Oracle 云互连支持多种 Oracle 服务，包括 E-Business Suite、JD Edwards EnterpriseOne、PeopleSoft、Oracle Retail 应用程序和 Oracle Hyperion Financial Management。然而，它也有一些限制。例如，您的 OCI 和 Azure 网络必须没有重叠的前缀，并且您无法使用互连从 Azure 或 OCI 路由到内部部署。此外，您只能使用互连从 Azure 路由到 Oracle 网络，然后路由到对等的 Oracle 网络（中心和辐射式）。

This post will explain how you can connect your Azure network(s) with Oracle Cloud Infrastructure (OCI) via the Oracle Cloud Interconnect.

Background

Many mid-large organisations run applications that are based on Oracle software. When these organisations move to the cloud, they may choose to use Oracle Cloud for their Oracle workloads and Azure for everything else.

But that raises some interesting questions:

How do we connect Azure workloads to Oracle workloads?If Oracle is hosting data services, how do we minimise latency?

The answer is: The Oracle Cloud Interconnect (OCI).

Microsoft documentation.Oracle documentation.

Azure ExpressRoute and Oracle FastConnect

Microsoft and Oracle are inter-connected via their respective private “site-to-site” connection mechanisms:

Azure: ExpressRouteOracle: FastConnect

This is achieved by both service providers sharing a “meet me” location where each cloud’s edge networks allow a “cross-connection”. So, there is no need to contact an ISP to lease an ExpressRoute circuit. The circuit already exists. There is no need to sign a circuit contract. The ISP is “Oracle” and you pay for the usage of it – in the case of Azure by paying for the ExpressRoute circuit Azure resource.

Location, Location, Location

The inter-connect mechanism is obviously play a role in where you can deploy your ExpressRoute Circuit and FastConnect resource. But performance also comes into play here – latency must be kept to a minimum. As a result, there is a support restriction on which Azure/Oracle regions can be inter-connected and where the circuit must be terminated.

At the time of writing, the below list was published by Microsoft:

What does this?

Let’s imagine that we are using OCI Amsterdam. If we want to connect Azure to it then we must use Azure West Europe.

Now, what about keeping that latency low? The trick there is in selecting a Peering Location that is closeby. Note that the Oracle docs do a better job at defining the Azure peering location (see under Availability).

In my scenario, the peering location would be Amsterdam2. According to Microsoft:

Connectivity is only possible where an Azure ExpressRoute peering location is in proximity to or in the same peering location as the OCI FastConnect.

That means you must always keep the following close to be able to use this solution:

The Oracle Cloud Infrastructure regionThe Azure regionThe peering location of the ExpressRoute circuit & FastConnect circuit

Configuring ExpressRoute

You have few options to decide between. The first is the SKU of ExpressRoute that you will choose.

You also have to choose one of the supported speeds for this solution: 1, 2, 5, or 10 Gbps.

The ISP will be  Oracle Cloud FastConnect.

So do you choose Local or Standard? I think that really comes down to balancing the cost. Local has unlimited data transfer but it is billed based on bandwidth. The entry cost per month in Zone 1 is €1,111.27/month with 1 Gbps and unlimited data transfer.

The entry point for a Standard metered plan is €403.76/month. That is €707.51 cheaper than the Local SKU but that savings has to cover your outbound data transfer cost in Azure. At €0.024/GB, that leaves you with (707.51/0.024) 29,479 GB of outbound data transfer per month until the Local SKU is more affordable.

The safe tip here is choose Local, monitor data usage, and consider jumping to Standard if you are using a small enough amount of outbound data transfer to make the metered Standard SKU more affordable.

Note that you can upgrade from Local but you cannot downgrade to Local.

Getting Connected (From Azure)

I’ll talk about the Azure side of things because that’s what I know. I will cover a little bit about Oracle, from what I have learned.

You will need an ExpressRoute Gateway in the selected Azure region. Then you will create an ExpressRoute Circuit in the same region:

Your chosen SKU/billing model. The speed from 1, 2, 5, or 10 Gbps.The Provider is Oracle Cloud FastConnect. The peering location from the Oracle docs.

Retrieve the service key and then continue the process in the OCI portal. There is one screen that is very confusing: configuring the BGP addresses.

You are going to need two /30 prefixes that are not used in your OCI/Azure networks. I’m going to use 192.168.0.0/30 and 192.168.0.4/32 for my example. You need two prefixes because Azure and Oracle are running highly available resources under the covers. The ExpressRoute Gateway is two active/active compute instances. Each will require an IP address to advertise/receive addresses prefixes via BGP from the OCI gateway, and vice versa.

What addresses do you need? Oracle requires you to enter:

Customer (Azure) BGP IP Address 1Oracle BGP IP Address 1Customer (Azure) BGP IP Address 2Oracle BGP IP Address 2

Here’s how you calculate them:

Customer (Azure) BGP IP Address 1: Usable IP #2 from Prefix 1Oracle BGP IP Address 1: Usable IP #1 from Prefix 1.Customer (Azure) BGP IP Address 2: Usable IP #2 from Prefix 2Oracle BGP IP Address 2: Usable IP #1 from Prefix 1

The below is not the final answer yet! But we’re getting there. That would lead us to caclulating:

Customer BGP IP Address 1: 192.168.0.2Oracle BGP IP Address 1: 192.168.0.1Customer BGP IP Address 2: 192.168.0.6Oracle BGP IP Address 2: 192.168.0.5

But the Oracle GUI has an illogical check and will tell you that those addresses are wrong. They are correct – it’s just the Oracle GUI is broken by design! Here is what you need to enter:

Customer BGP IP Address 1: 192.168.0.2/30Oracle BGP IP Address 1: 192.168.0.1/30Customer BGP IP Address 2: 192.168.0.6/30Oracle BGP IP Address 2: 192.168.0.5/30

You finish the process and wait a little bit. The ExpressRoute circuit will eventually change status to Provisioned. Now you can create a connection between the circuit and the ExpressRoute Gateway. When I did it, the Private Peering was automatically configured, using 192.168.0.0/30 and 192.168.04/30 as the peering subnets.

Check your ARP records and route tables in the circuit (under Private Peering) and you should see that Oracle has propagated its known addresses to your Azure ExpressRoute Gateway, and on to any subnets that are not blocking propagation from the gateway.

And that’s it!

Other Support Things

The following Oracle services are supported:

E-Business SuiteJD Edwards EnterpriseOnePeopleSoftOracle Retail applicationsOracle Hyperion Financial Management

Naturally, your OCI and Azure networks must not have overlapping prefixes.

You can do transitive routing. For example, you can route through the interconnect to an Oracle network and then on to a peered Oracle network (a hub and spoke).

You cannot use the interconnect to route to on-premises from Azure or from OCI.

The post Azure & Oracle Cloud Interconnect first appeared on Aidan Finn, IT Pro.