How to Connect SAS Viya in Azure to On-Prem with ExpressRoute – Part 2

Ever dreamt of driving to work on your private express lane, instead of using a jammed, potentially dangerous highway? Your dream is real, in the cloud.

Azure ExpressRoute allows you to physically connect on-premises networks into Azure, over private connections, completely bypassing the public Internet. ExpressRoute connections are more reliable, faster, with consistent lower latencies, and have higher security than typical connections over the Internet.

Read this post to learn how you can connect a SAS Viya on Azure deployment to an "on-premises" network, from the same geopolitical region.

Previously

In Part 1, we introduced Azure ExpressRoute, the connectivity models, including ExpressRoute Direct and a few scenarios customers might consider for ExpressRoute Direct.

Architecture Diagram

We proposed a simple architecture diagram and two scenarios to access from SAS Viya data from "on-premises" databases. SAS Viya is deployed in Azure in the East US region. The databases sit in "on-premises" data centres in the same geopolitical region (US) and in a different one (Australia).

bt_1_ExpressRoute-Direct-Circuit-SAS-Viya-on-prem-1-1024x585.png

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

In Part 2, we will create ExpressRoute Direct, ExpressRoute Circuit, configure Azure Private Peering, add two networks to the circuit and test the connection.

Create ExpressRoute Direct

Enable ExpressRoute Direct Feature

In your Azure subscription, enable the feature if not already active.

Create ExpressRoute Direct

Create the ExpressRoute Direct resource. For convenience, I chose to create it in the same East US resource group as SAS Viya resources.

Next, choose your peering location.

Peering Location: The location where you'll connect to the ExpressRoute Direct resource. For more information about peering locations, review ExpressRoute peering locations and connectivity partners.

According to Eigthy20 Solutions:

…the ExpressRoute circuits peering / meet-me-location is chosen based on the physical location of customer’s on-prem data centers.

I chose a provider from Ashburn, Virginia (VA), a location not far from the Azure East US region data centers, supposedly located in Richmond, Virginia, according to DgtlInfra. I am therefore "meeting" Microsoft in Ashburn, VA.

At this point, I am hesitating between East US, next to the SAS Viya Azure region and West US, next to the on-premises data centre location. I want to add to the ExpressRoute circuit an Azure virtual network in East US, a network from West US and eventually a third network from Australia Southeast.

The same Eigthy20 Solutions suggest:

The “Peering / Meet-me Location” indicates the physical location where customer / connectivity provider peer with Microsoft. This is not linked to “Location” property of the ExpressRoute object created in [the] Azure portal, which refers to the geography where the Azure Network Resource Provider is located. While they are not related, it is a good practice to choose a Network Resource Provider geographically close to the Peering Location of the circuit.

In the next few steps, I will create the ExpressRoute Circuit in East US, although it makes more sense to choose a peering location close to your on-premises data centre. But if you want to add to the same circuit, two data centres, geographically remote, where it is best to place your peering location?

I did not reach a firm conclusion, even after reading through Optimize ExpressRoute Routing. At this point I wonder if it is best to create two separate circuits in two different locations, then connect each network to the closest circuit.

What the Experts are Saying

If you are ready for an in-depth session, watch Stephan's Azure ExpressRoute demystified (part 2) whiteboarding session. Towards the middle of his video, he explains beautifully ExpressRoute, Direct and Global Reach. Be ready for keywords such as VLAN, BGP, ASN, VLAN IDs, tagging, QinQ and Dot1Q.

Generate the Letter of Authorization (LOA)

Support requires documentation, such as a Letter of Authorization, that proves you are allowed to use the resources. You can obtain a LOA after you created your ExpressRoute Direct resource.

A Letter of Authorization (LOA) looks like this:

Change the Admin State of Each Link

You can view the Admin state for each link of the ExpressRoute Direct port pair. The Admin state represents if the physical port is on or off. This state is required to pass traffic across the ExpressRoute Direct connection.

Enable cross-connect links 1 and 2.

Important: Billing will begin when admin state is enabled on either link.

Create the ExpressRoute Circuit

The ExpressRoute Circuit is a logical connection between your on-premises infrastructure and the Azure cloud.

The choice was to create it in the same resource group where SAS Viya resources are deployed, in East US and close to the peering location.

Another option might be to create the ExpressRoute Direct and Circuit closer to your on-premises data centre in West US.

Select the ExpressRoute Direct resource.
Circuit bandwidth is here 1 GB/s.
SKU: Standard, for now, as your objective is to link with virtual networks in the same geopolitical region.

After you've created the ExpressRoute circuit, you can link virtual networks to your ExpressRoute circuit.

With this design, to each ExpressRoute Direct resource you can attach 10 Standard circuits. To each circuit you can link 10 VNETs.

ExpressRoute peering

According to ExpressRoute circuits and peering :

An ExpressRoute circuit has multiple routing domains/peerings associated with it: Azure public, Azure private, and Microsoft. Each peering is configured identically on a pair of routers (in active-active or load sharing configuration) for high availability. Azure services are categorized as Azure public and Azure private to represent the IP addressing schemes.

Azure private peering

Azure compute services, namely virtual machines (IaaS) and cloud services (PaaS), that are deployed within a virtual network can be connected through the private peering domain. The private peering domain is a trusted extension of your core network into Microsoft Azure. You can set up bi-directional connectivity between your core network and Azure virtual networks (VNets). This peering lets you connect to virtual machines and cloud services directly on their private IP addresses.

You can connect more than one virtual network to the private peering domain.

Configure Azure Private Peering

Important: The subnets IP address ranges must not overlap with the address ranges of the networks you want to add to the circuit.

For example, if SAS Viya’s $PREFIX-vnet address space is 192.168.0.0/16, you can have:

ASN: 65020
Ipv4 primary subnet: 192.169.21.16/30
Ipv4 secondary subnet: 192.169.21.20/30

You cannot have:

ASN: 65020
Ipv4 primary subnet: 192.168.21.16/30
Ipv4 secondary subnet: 192.168.21.20/30

Because 192.168.21.16/30 overlaps with 192.168.0.0/16.

After the configuration, you shall see:

bt_13_ExpressRoute_Circuit_Configured_Azure_Peering.png

Virtual Network Gateways (VNG)

Before moving further, you should have created VNGs, of type ExpressRoute, for each network you want to add to the circuit. For more details see Part 1 or Tutorial: Configure a virtual network gateway for ExpressRoute using the Azure portal.

Connect the SAS Viya VNet to an ExpressRoute Circuit

In this step we are going to connect SAS Viya’s $PREFIX-vnet to the ExpressRoute circuit created.

In Settings, you will have to choose the VNG of type ExpressRoute from $PREFIX-vnet:

Connection Success Looks Like This

In the ExpressRoute circuit’s connections, you shall see:

Because the connection is bi-directional, the $PREFIX-vnet's VNG will also show a connected state.

Note: If the connection fails with a message “BGP with Peering Key…”, you need to activate your Azure Peering or check there is no address space overlap between the peering subnets and your network.

Connect the HQ-Network VNet to an ExpressRoute Circuit

Connect the simulated “on-premises” West US data centre’s vnet, to the same ExpressRoute circuit.

Now, two networks are connected to the same ExpressRoute Circuit.

Test SAS Viya Connection to the PostgreSQL Server

Using the example provided in How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 3, in SAS Studio, write the following SAS code. The PostgreSQL Server is represented by the private IP address of the server in HQ-Network (private endpoint). Connect to the default postgres database:

libname GELDBHQ clear;
libname GELDBHQ postgres server='172.16.0.4' port=5432
   user='viyadep@hqnetworksrv' password='fill_in_here'
   database=postgres SSLMODE='prefer';

Connection is successful, and you can access the database inside the PostgreSQL Server, deployed "on-premises", in West US:

bt_20_ExpressRoute_Test_Private_Access_to_West_US_Datacentre.png

Conclusions

SAS Viya deployed in Azure East US can connect to a database, hosted "on-premises" in West US, through the ExpressRoute Direct Circuit.

In this post we:

Created an ExpressRoute Direct resource.
Created an ExpressRoute Circuit.
Configured Azure Private Peering in the circuit
Added two networks to the circuit, one from Azure, the other from the simulated "on-premises" data centre.
Tested the connection from SAS Viya to a database.

In Part 3

Read How to Connect SAS Viya in Azure to On-Prem with ExpressRoute - Part 3, where you will learn how to connect to the same ExpressRoute circuit a network from a different geopolitical region.