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:
Disassociate Public 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.
SAS Viya on Microsoft Azure
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.
Configure Azure load balancer
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.
Create load balancer with a new IP address
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.
Backend pools from 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).
Add backend pool configuration
When selecting the Virtual network, you also select the cascontroller as the backend VM.
Add cascontroller VM to backend pool
When complete with the steps, you should see something like the following.
Final backend pool configuration
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.
Select the Health probes setting
Choose an appropriate name and fill in port 5570 as default CAS port. For this test you can keep the other values default.
Health probe settings configuration
Next, you create a load balancing rule by clicking on Load balancing rules from the left-hand menu of the Load Balancer settings.
Load balancing rules from 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.
Load balaning rules configuration
Finally, you will need to grab the public IP of the load balancer from Settings-> Frontend IP configuration.
Frontend IP Address
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).
2.4.81.158 controller.viya.sas
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.
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9. Sign up by March 14 for just $795.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.