Here's some really good news: SAS is announcing support for dynamic IP address assignment in SAS Viya 3.5. As you might recall, I've written about this topic before. I explained some of the benefits we could expect if SAS Viya 3.5 were allowed to tolerate dynamic IP address assignment. And I'm pretty excited it's worked out because now it's here! See the SAS® Viya® 3.5 Administration document for Support for Dynamic IP Addresses.
Brief History
Networking features were revamped from the ground up in SAS Viya 3.5. From this point, all network identification and communication now follow a common set of rules and APIs that are applied throughout the codebase. This not only eliminates some weird edge case problems with the previous approach, but also offers additional functionality to help configure SAS Viya to operate as needed in various networking environments. In particular, the configuration variables which enable SAS Viya 3.5 to tolerate dynamic IP address assignment are:
SAS_BIND_ADDR:
Provides the exact IP address for the SAS Viya host. Defaults to 0.0.0.0 (i.e. accept any traffic).SAS_BIND_ADDR_IF:
Identifies the network interface. When set, then SAS_BIND_ADDR will take the first IP address assigned to the network interface.SAS_BIND_ADDR_CIDR:
Describes a range of IP addresses. When set, then SAS_BIND_ADDR will take the first IP address in the range.- And their
_EXTERNAL_ equivalents, too.
Enabling Toleration of Dynamic IP Address
There are a few ways to approach this. In this post, I'll keep it at a high-level, but you can read a lot more detail about configuration and use of these variables in Understanding Network Binding Variables in Viya 3.5.
Default behavior
If you're deploying SAS Viya 3.5 software to a host machine with a single network interface, then you don't actually need to specify any additional configuration to allow for toleration of dynamic IP address assignment. If there's no specification for the networking configuration variables, then SAS_BIND_ADDR defaults to value "0.0.0.0" which means listen for all incoming traffic to the machine regardless of actual the IP address value.
That's right - SAS Viya 3.5 was built with this capability in mind from the get-go.
Do not explicitly set SAS_BIND_ADDR=0.0.0.0 yourself. It's not needed and the documentation warns against it (instead suggesting to simply leave it undefined or set as an empty string).
Typical approach
It's pretty common for enterprise-grade hardware for production use to employ more than one network interface card. This allows for separation of traffic and guaranteed level of service. There are some SAS services which require positively identifying a single network interface (and won't work if SAS_BIND_ADDR=0.0.0.0 on hosts with multiple NICs). So one approach I expect we'll see used most often in the field is to configure SAS_BIND_ADDR_IF to specify the identifier of the desired network interface for SAS Viya. Usually this is something like "eth0" or "bond1" or "ens32". Setting this parameter causes the SAS Viya software to look at the current IP address assigned to that interface and then implicitly set SAS_BIND_ADDR to that value.
External SAS Viya services
A few SAS services present public (or external) facing network APIs. In a SAS Viya 3.5 deployment, most of the communication happens between the various SAS services, but there are some which are meant for direct user access, such as CAS port 5570, the web server on port 80/443, etc. So there are a set of SAS_EXTERNAL_BIND_ADDR variables for these as well, just in case you want them to use a different network route.
That said, a proven practice is to set SAS_EXTERNAL_BIND_ADDR=0.0.0.0 to ensure that no matter which network interface a request comes in on, the service will be able to respond back to it. To be clear, this is not a contradiction with the advice to avoid explicitly setting SAS_BIND_ADDR=0.0.0.0 above. They're different variables and this is one area where they have distinct behaviors and goals.
For existing sites
The new SAS documentation provides steps to Configure Support for Dynamic IP Addresses. If you've configured SAS Viya 3.5 networking before, it should look familiar, but take a close look if you're running a clustered SAS Infrastructure Data Server (i.e. HA PostgreSQL) as additional followup is needed there.
Limited Support
The documentation explains that support is limited to some specific scenarios. But fortunately, those are the most likely scenarios where dynamic IP address assignment for SAS Viya will be very useful.
Specifically, dynamic IP address assignment is supported for SAS Viya 3.5 deployments running on hosts with Red Hat Enterprise Linux 7.x and where the SAS Viya Administration Resource Kit (SAS Viya ARK) has been applied.
Further, the IP address cannot just change whenever - but under the control of DHCP where the IP address is assigned when the host machine boots up. This includes running SAS Viya 3.5 on virtual machines as well.
And finally, a list of core SAS Viya 3.5 software products is given in the documentation which are known to support dynamic IP address assignment. Generally, the idea is that SAS solution offerings release on their own timelines and may implement older technology so they aren't currently included in the limited support statement yet.
Oh, and one more crucial point: hostname changes (i.e. rehoming) are not included in this new policy. That's a different topic - and really isn't needed for most scenarios.
Use Cases and Benefits
The most obvious use case with immediate benefits for our customers will come from the ability to clone the virtual machines running the SAS Viya 3.5 deployment.
Prior to this new policy, the only supported approach for duplicating a SAS Viya 3.5 environment was to 1) perform a new installation of SAS Viya 3.5 and 2) sync the content from the original to the new. Step № 1 was a bit of a hassle as it means standing up additional hardware and step № 2 was not for a fixed point in time - you can only sync the current content, not some past known-good state.
But now a whole new raft of opportunities is possible. To cherry pick one that's been discussed a lot, let's briefly look at disaster recovery.
Cloning the virtual machines that host SAS Viya 3.5 gives you a snapshot in time of the software as it's deployed and configured, as well as the state of the content of the system. There's many potential uses for such snapshots - and if you've taken a GEL workshop with hands-on exercises running on machines in RACE, then you've experienced it firsthand already.
This idea could be extended further to help recover from a disaster event where a recent snapshot of the SAS Viya 3.5 deployment could be brought online in short order to get back to work. Because this approach relies on snapshots, the customer doesn't need to keep additional physical machines on warm standby per the original content syncing approach, instead firing up the new virtual machines only when they're needed.
Of course, there's much, much more to creating a robust disaster recovery process than simple VM snapshots. But having them simplifies part of that process and substantially reduces costs as well.
Coda
This is a meaningful change in support policy to allow for dynamic IP address assignment with SAS Viya 3.5. When the networking subsystems were rewritten for SAS Viya 3.5, the ability to tolerate dynamic IP address assignment was baked into the original design… and now we can use it in production environments. To enjoy this feature, be sure to update SAS Viya with the latest hotfixes as improvements have been added since 3.5 was first released.
Find more articles from SAS Global Enablement and Learning here.
