In a previous article Connecting from SAS9.4 to Azure Quickstart, I showed how to connect from a SAS94 client to the CAS controller in a SAS Viya Azure Quickstart Architecture. As the CAS controller was in a private subnet, we assigned it a public IP address and modified some network security inbound rules, allowing traffic from a well-known SAS94 network to the Azure Virtual Network.
That worked well but IT-departments might not like the idea of assigning a public IP address to an Azure VM running in a private Virtual Network. So in case you followed my steps outlined in the first article, let’s roll back and disassociate the public IP from the CAS controller.
In the Azure console, navigate to the networking Settings of the controller Virtual Machine and click on Network Interface: CASController NetworkInterface. In Network interface screen, click on IP configurations. You should see ipconfig1 with a Private IP address & Public IP address. Double click on ipconfig1.
Next, click the Disassociate button. It’s good practice to take note of the private Virtual Network and private IP address:
As we no longer wish to expose our CAS controller, we need to find alternative Azure solutions. One option is to employ an Application Gateway. In fact, such an Azure Application Gateway is part of the Azure Quickstart and takes the role of a PrimaryViyaLoadbalancer as you might remember from the environment configuration image below.
The Azure Application Gateway operates at the application layer (layer 7 – HTTP(S)). Although we can connect to CAS via REST HTTP calls, here the goal is to make a binary connection to CAS from a SAS94 client. I will show in a future article how to configure the Application Gateway in a way where you connect to the CAS controller with a REST HTTP CAS call.
So with that in mind I switch gears and start looking to Azure load balancers. While creating the load balancer in the Azure portal I had two choices: the Standard Load Balancer or the Basic Load Balancer. Check this comparison table for differences. I successfully tested both options, but I prefer the Standard Load Balancer as it’s built on the zero-trust network security model at its core. The Standard Load Balancer is secure by default and is part of your virtual network as described in the image below.
You can create a new public IP address or use an existing one. This is the address you will use later to connect to the load balancer.
Once the load balancer is created, the next step is to add a backend pool. For simplicity we test using one single Azure VM, the CAScontroller. Select Backend pools from the left-hand menu of the Load Balancer settings.
Make sure you choose the correct Virtual network when adding the backed pool. Choose a name that makes it easy to identify the backend (cascontroller as shown below).
When selecting the Virtual network, you also select the cascontroller as the backend VM.
When complete with the steps, you should see something like the following.
Before creating a load balancing rule to forward an incoming request to the right backend you will need to add a Health probe. Click on the Health probes from the left-hand menu of the Load Balancer settings.
Choose an appropriate name and fill in port 5570 as default CAS port. For this test you can keep the other values default.
Next, you create a load balancing rule by clicking on Load balancing rules from the left-hand menu of the Load Balancer settings.
Configuration of the rule is straightforward as we would like to distribute incoming traffic sent to the load balancer on port 5570 to the cascontroller backend pool with the same backend port. Note, the only backend instances the health probe considers healthy, receive any traffic. The screenshot below provides a sample of the configuration.
Finally, you will need to grab the public IP of the load balancer from Settings-> Frontend IP configuration.
Copy the IP address and, for a test, override the entry of the controller.viya.sas in your C:\Windows\System32\drivers\etc\hosts file (replacing the ip address for your environment). If you followed part1 that entry should already exist (an entry similar to the text below).
In case you didn’t follow part1 you still have to check the network security group for an inbound port rule on port 5570. Make sure it’s open for your IP address or CIDR range.
Also, before you can start submitting CAS statements to the CAS server from SAS 9.4 security certificates must be in place and you must be authorized to connect to the CAS server. For more information, see Configure SAS 9.4 Clients to Work with SAS Viya and Client Authentication Using an Authinfo File.
Or just follow the instructions in part1 for that, search for the sections “setting up the client authentication” and “setting security certificates in place”.
When you re-submit the same sample code as in part1 you will connect to the CAS controller via the Load balancer.
Instead of modifying the initial Azure Quickstart architecture and transferring the CAS controller from a private Azure virtual network to a public one, we are now keeping the CAS controller VM in its private network and are adding an extra Azure Load Balancer to the architecture. It then comes down to configure the Load balancer with the correct backend.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.