SAS/CONNECT, first released with SAS 6 in 1990, keeps evolving with the SAS Viya platform to adhere to modern enterprise requirements, especially in the cloud.
With the 2024.09 release there have been multiple changes:
- Updated SAS/CONNECT spawner container image to remove unneeded elements
- New availability feature for the SAS/CONNECT spawner
- Data transfer services performance improvements
And we are not counting the continuously released fixes that remove bugs and improve the general user experience.
Let’s review each of these changes.
Updated Connect Spawner container images
The SAS/CONNECT spawner has been enhanced to optimize cloud resource utilization, minimizing the infrastructure footprint required to deploy and increasing performance.
Up to the 2024.08 Stable release, the SAS/CONNECT spawner container image includes binaries and additional files to support locally spawning a SAS/CONNECT server inside the SAS/CONNECT spawner pod. In details, it includes a full copy of SAS executable files.
The ability to locally spawn a SAS/CONNECT server inside the SAS/CONNECT spawner pod was previously deprecated in the 2024.03 release and has finally been removed with the 2024.09 release.
For this reason, it’s now been possible to remove those additional files and trim down the SAS/CONNECT spanner container image.
The results are impressive. The image size has been reduced by 80%, from ~10GB to ~2GB. Here is a comparison between the image sizes for the 2023.10 release (similar to the 2024.08 one) and the 2024.09 releases:
#LTS 2024.09
sh-5.1# podman image list cr.sas.com/viya-4-x64_oci_linux_2-docker/sas-connect-spawner
REPOSITORY TAG ... CREATED SIZE
cr.sas.com/viya-4-x64_oci_linux_2-docker/sas-connect-spawner 1.0.33-20241126.1732636028288 ... 3 weeks ago 2.03 GB
#LTS 2023.10
sh-5.1# podman image list cr.sas.com/viya-4-x64_oci_linux_2-docker/sas-connect-spawner
REPOSITORY TAG ... CREATED SIZE
cr.sas.com/viya-4-x64_oci_linux_2-docker/sas-connect-spawner 0.68.28-20240723.1721760979402 ... 4 months ago 10.6 GB
This size reduction not only saves disk storage on Kubernetes nodes, but it speeds up SAS Viya deployment and maintenance, because the container can be downloaded from source repositories up to 5 times faster.
Internal testing with an on-premises cluster and a local mirror registry has seen image download times reduced from 1m18s to 12.5s (>80% reduction); testing on a cloud environment with a remote registry went from 5m38s down to 1m18s (>75% reduction).
A smaller image also helps with pod scalability, as we’ll see in the next point.
Other than decreasing the container image size, removing the capability to locally spawn a SAS/CONNECT server inside the SAS/CONNECT spawner pod brings additional benefits:
- SAS/CONNECT Spawners no longer require any security context constraint when deployed on Red Hat OpenShift.
- There is no need to configure a workload class or node pool dedicated to SAS/CONNECT.
- SAS/CONNECT workloads will be associated with the compute workload class in all cases.
These and additional considerations are better described in the 2022 article Moving to the cloud with SAS/CONNECT, which covers in great detail the differences between the legacy behavior (locally spawn a SAS/CONNECT server inside the SAS/CONNECT spawner pod) and the current one (launching SAS/CONNECT servers in their own pod). There is one additional consequence that the article highlights and is worth reiterating: connections using the current SAS/CONNECT behavior require modern clients, such as SAS 9.4M7 or later or Viya 3.5. Removing the legacy capability means that SAS 9.4M6 and earlier clients cannot connect anymore to SAS Viya 2024.09 and later. As a result, you should migrate to SAS® 9.4M7 or later. This is explained in the SAS Note https://support.sas.com/kb/68/611.html.
New availability feature for the SAS/CONNECT spawner
Starting with the SAS Viya 2024.09 release, you can configure high availability (HA) for the SAS/CONNECT Spawner by applying the enable-ha-transformer.yaml.
A default SAS Viya deployment configures stateless microservices, such as the SAS/CONNECT spawner, without any high availability.
It is easy to enhance the platform resilience to failure: to enable HA, just add a reference to the enable-ha-transformer.yaml file to the base kustomization.yaml file:
...
transformers:
...
- sas-bases/overlays/scaling/ha/enable-ha-transformer.yaml
...
This increases the number of replicas of almost all stateless pods to two, making the SAS Viya platform more resilient to pod or node failure and increasing its availability. Up until the 2024.08 stable release, the SAS/CONNECT spawner was not included in this transformer, and this service always run with a single pod. Starting with the 2024.09 release, the SAS/CONNECT spawner leverages the HA transformer, and two pods are now started when HA is enabled for the SAS Viya platform.
Note that while this increases service availability, it does not provide full protection from failures. When a client uses the SAS/CONNECT spawner to open a server session, the TCP connection is proxied through the spawner’s pod. If a spawner pod crashes, all the connections that it was proxying are severed and the backend server sessions die. The good news is that with the new HA capability, only half of the connections would be impacted, and not all of them, as with the earlier versions. As always, after a pod failure, Kubernetes will try to restart it, possibly on a new node, and clients will be able to re-connect and restart their backend sessions.
This new capability also increases SAS Viya platform availability during cluster maintenance. If the SAS/CONNECT spawner is started with a single instance, when an administrator wants to perform maintenance on the Kubernetes node where that pod is running, they would have to cause a service disruption to users, to move the single pod to another node. With the new capability, as long as the two SAS/CONNECT spawner pods are started on different nodes, the administrator can perform a graceful shutdown of one of the two pods and move it to another node, all while the remaining pod keeps servicing users’ requests.
Data transfer services performance improvements
Every SAS Viya release contains fixes and improvements to the internal working of the system, but many are hidden from our users, and often not mentioned. I’d like to share this one, since it can have a huge impact on data transfer performance. One of the many features that SAS/CONNECT provides is the capability to transfer data between clients and servers. Data Transfer Services are implemented by using the UPLOAD and DOWNLOAD procedures. One of the key advantages of SAS/CONNECT data transfer services, compared to generic external data movement tools, is the capability to automatically translate the internal data representations between the client and the server computers. As an example, the client and the server could run on different operating environments on incompatible computer architectures or different SAS software releases (such as SAS Viya platform and SAS 9). While migrating existing programs from SAS 9 to SAS Viya, some customers observed that the new version could be considerably slower in handling data transfer. Starting with the SAS Viya 2024.09 release, internal processing has been reviewed and optimized and is now as fast as, if not faster than SAS 9.
Find more articles from SAS Global Enablement and Learning here.
