SAS/CONNECT in SAS Viya 2020.1 (and later)
NOTE - Sept 2022: Since the time of publishing, SAS Viya has already evolved. Some of the content of this article does not apply anymore to recent SAS Viya versions. See the newer article Moving to the cloud with SAS/CONNECT to learn about the changes.
"SAS/CONNECT software is a SAS client/server toolset that provides the ability to manage, access, and process data in a distributed and parallel SAS environment. As a client/server application, SAS/CONNECT links a SAS client session to a SAS server session." This is the first sentence in the official SAS/CONNECT for SAS Viya User’s Guide.
What you do not find in this initial introduction is one of the capabilities that makes SAS/CONNECT so versatile: it can work across different releases and across different operating systems, including the new SAS Viya. For this reason, it is often used as a "bridge" when other connection or integration strategies do not work: If you can't connect, SAS/CONNECT!
One Says Goodbye, One Gets a New Life
With previous SAS releases, starting with SAS 8, SAS Integration Technologies included Integrated Object Model (IOM) servers. IOM provides distributed object interfaces for conventional SAS features, which, in layman's terms, means that a client can access SAS capabilities provided by a remote SAS server thanks to a shared, proprietary protocol.
Thanks to IOM and to the removal of licensing limitation, since late 2019 it is even possible to directly connect SAS Enterprise Guide 8 to a SAS Viya 3 environment, with no additional server-in-the-middle.
While still available, thanks to the inclusion of a SAS Workspace Server in SAS Viya 3 deployments, IOM is a legacy, proprietary protocol that has been replaced with more modern and open REST interfaces that better fit today's API-first, cloud-native, service-oriented architectures.
For this reason, SAS Workspace Servers are not available anymore with the new SAS Viya, and IOM is gone with them.
This leaves a question: how to connect the new SAS Viya with older SAS environments, that were not designed for REST interfaces? Enter SAS/CONNECT, another SAS protocol that has been available to make different SAS sessions talk, even before the introduction of IOM. Now that IOM is no more, SAS/CONNECT may be the easier way to bridge existing environments to the new SAS Viya.
Despite being around for years, SAS/CONNECT is not just "legacy technology": innovations keep coming, including in the latest version of SAS Viya. Starting with the latest release, SAS/CONNECT is now integrated both with Kubernetes and with many other SAS services available with the new SAS Viya. Thanks to this new integration, SAS/CONNECT servers can now be started in two different ways: a modern, cloud-native one, available to newer clients, and a more traditional one for older clients.
Two Ways to Connect
When started from clients within the same deployment and same Kubernetes namespace (which also implies the same software release), SAS/CONNECT servers are launched by the SAS Launcher service, just like a Compute server or a Batch server. This is a new capability with SAS Viya, briefly highlighted in a previous post, SAS Programming Run-Time Architecture with the new SAS Viya.
Clients connect to a SAS/CONNECT spawner, and then the spawner offloads the actual launch to the Launcher service. The launcher service starts a new pod using a specific sas-connect Kubernetes PodTemplate, and the SAS/CONNECT server runs inside this new pod. After initialization, the SAS/CONNECT server opens a new TCP port listening for an incoming connection, and sends the IP address and port information to the original client via the launcher. With this information, the client can connect directly to the server and send it some code to execute.
The following diagram shows this first use case - along with some additional services involved in steps we have not detailed above.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
A SAS/CONNECT server can still be started in the same way that was available with previous releases, i.e. directly spawned by a SAS/CONNECT spawner, with no usage of the Launcher service. The main difference from previous releases is that here everything is using Kubernetes pods instead of physical or virtual machines.
So, in this second way, when a client submits a SIGNON statement to start a new server, the SAS/CONNECT spawner spawns a SAS/CONNECT server directly. This means that the SAS/CONNECT server is started as a new process running inside the spawner pod, in the same container. The SAS/CONNECT server can inherit the TCP connection from the spawner, and so the client is immediately connected with no additional listening ports.
In this second use case, the external client can be at any release, including SAS 9, SAS Viya 3.x, the new SAS Viya 2020.1 and later, or even older release, and on any platform. The only requirement is to have SAS/CONNECT licensed and installed on the client, because the new SAS Viya always includes it by default. Also, the SAS/CONNECT endpoint has to be exposed "outside the cluster" using a Kubernetes Nodeport or LoadBalancer, as explained by Rob Collum in K8S Primer for SAS Viya: Networking.
Requirements to Launch
A few requirements have to be satisfied, for a SAS/CONNECT spawner to use a SAS Viya launcher service to start a SAS/CONNECT server:
- The client should use a new release of the SAS/CONNECT protocol. This includes the new SAS Viya 2020.1 and later clients, but excludes SAS 9 or SAS Viya 3.x clients. We have seen above that a SAS/CONNECT spawner, in SAS Viya, sends the IP address and port of the newly started SAS/CONNECT server back to the client. Earlier versions of the protocol “do not understand” this information, so the client would not be able to connect to the server.
- The client should be in the same Kubernetes cluster as the spawner (and the launched server, obviously). In fact, the final connection from the client to the server happens using a TCP/IP address that is only routable inside the cluster. The client submits a SIGNON to sas-connect-spawner, which is a hostname that Kubernetes can resolve, for internal clients, to a pod running the SAS/CONNECT spawner (in Kubernetes lingo, it is a ClusterIP service whose endpoints are the sas-connect-spawner pods)
Controlling the Launch
There are some new options and variables that can be used to force SAS/CONNECT to only use the new SAS Viya way, or to only use the traditional one.
- TCPNOIPADDR server environment variable (default: either not set or set to zero) When set to any value other than zero, this forces a SAS/CONNECT server to be always spawned in the same pod as the SAS/CONNECT Spawner (not dynamically launched). It could be useful, for example, when a SAS Viya 2020.1 and later client is running in a different cluster than the SAS/CONNECT spawner, but the spawner thinks it is local.
- SERVICELAUNCH spawner option (default: set) When specified, enables the new behavior of SAS/CONNECT spawners to launch SAS/CONNECT servers by using the Launcher service, if possible. Ignored for SAS/CONNECT clients that are not able to handle and connect to the IP addresses obtained by the server’s initialization information (i.e. older versions)
- NOLOCALLAUNCH spawner option (default: not set) When specified, prevents any SAS/CONNECT server from being spawned in the spawner’s pod (i.e. forces the launch by using the Launcher service). As a consequence, it prevents any SAS 9, SAS Viya 3, or remote SAS Viya 2020.1 (and later) clients from connecting.
While the first server variable can be set in SAS code by an end-user, the two spawner options can only be configured by an administrator.
For additional instructions about these options and variables, consult the official documentation.
Sizing and Scaling Considerations
The two use cases – launch or spawn – can require different considerations while architecting and provisioning the environment.
Each launched SAS/CONNECT server instance runs in a new, dedicated pod: from a resource consumption perspective, it is similar to Compute servers. So similar, that launched SAS/CONNECT servers run inside pods assigned to nodes with a label equal to workload.sas.com/class=compute. For this reason, they can have horizontal scalability: the more client connections arrive, the more pods are automatically started and distributed across all compute nodes. In the cloud, for example on Azure, if cluster autoscaling is enabled, additional nodes are automatically added, as required, to the compute pool to support the increased workload.
Spawned SAS/CONNECT servers, on the opposite, always run inside the SAS/CONNECT spawner pod. Multiple sessions all consume resources (CPU, memory, disk) from that same pod. SAS/CONNECT spawners are not included in auto-scaling even when enabling High Availability. It's important to have vertical scalability, or plan in advance: dedicate a node with adequate resources to the SAS/CONNECT spawner pod. To simplify handling of this different use case, SAS/CONNECT spawners are assigned to nodes with a label equal to workload.sas.com/class=connect.
Storage Considerations
SAS/CONNECT can be used to parallelize code execution by starting multiple server sessions. In Kubernetes, sharing intermediate data between those parallel remote sessions by saving it on disk merits special considerations. Traditional programming paradigms may not work anymore; an example is sharing SASWORK directories between sessions, as was suggested in this old trick: https://support.sas.com/rnd/scalability/tricks/connect.html#workpath.
In both SAS Viya 2020.1 (and later) use cases – whether the server is launched or spawned – there may be issues.
- For launched SAS/CONNECT servers, each one runs in a dedicated pod, so it does not see any other pod’s local file systems. This is similar to grid processing with SAS 9.
- For spawned SAS/CONNECT servers, although they all run in the same pod, they execute with LOCKDOWN enabled by default, so each session is only allowed access to a limited list of subdirectories - which does not include other sessions ones.
Possible solutions include:
- follow SAS Grid Manager practices: provision a clustered filesystem, mount it in all SAS/CONNECT containers
- follow cloud practices: use object storage instead of a traditional file system as a staging/sharing area,
- follow SAS Viya practices: load all common data into CAS and offload code execution to it
In the end, the key point is that this should be carefully evaluated with the customer IT department, including security considerations associated with file sharing.
Conclusion
SAS/CONNECT can be a valuable mechanism to connect or integrate existing environments with SAS Viya. Both traditional and new capabilities enable SAS clients from different versions and operating systems to manage, access, and process data in SAS Viya.
Special kudos to the colleagues within the R&D division who have answered our numerous requests for help and clarification.
