Deploying the SPRE in SAS Viya 3.4

5 Likes

In SAS Viya 3.4, SAS Cloud Analytic Services (CAS) is the star of the show, providing lightning fast analytics of in-memory data for SAS Visual Analytics and other software offerings. However, Foundation SAS which is the long-time workhorse of SAS analytics is also offered, referred to as the SAS Programming Runtime Environment (SPRE). The SPRE provides a user interface and data processing environment for executing classic SAS program code. That is, it offers the Foundation SAS software we're all familiar with, including Base SAS, SAS/ACCESS engines, SAS/CONNECT packages, and more as well as the SAS Studio web application. Under the covers, however, there are two different SPRE implementations. One based on legacy SAS 9 Integration Technologies and the other built using the new Viya approach to software architecture.

A Tale of Two SPRE

The SAS Programming Runtime Environment is comprised of two different techniques to access Foundation SAS service: 1) legacy SAS Workspace Server relying on SAS Integration Technologies and 2) a new SAS Compute Server built using Viya architecture principles. Each has its own version of the SAS Studio web application to offer a SAS coding interface for users.

The inventory.ini file lists a set of host groups which represent pre-defined groups of SAS software components to deploy to specified hosts, including...

Legacy SAS 9 runtime host group:

[programming]:
Provides software in support of SAS Studio 4, including legacy SAS/CONNECT, SAS Object Spawner and SAS Workspace Server plus any additional software licensed (SAS/ACCESS, SAS/STAT, etc.). The SAS Workspace Server executes the SAS program code from SAS Studio. These components only come with a the "local" version of the SAS software license, so those components must all exist together on the same one host. Access this SPRE at url:
http://[your Viya34 site].com/SASStudio

New Viya Architecture SAS runtime host groups:

[ComputeServer]:
Provides the SAS Compute Server and SAS Launcher Server. The SAS Compute Server is the modern Viya equivalent of the legacy SAS Workspace Server. For SAS Studio 5, it executes SAS program code.
[ComputeServices]:
Provides the ComputeService and LauncherService microservices in support of the SAS Compute Server and SAS Launcher Server.
[StudioViya]:
Provides the SAS Studio 5 web app software. Relies on the SAS Compute Server and related services as the SAS backend. Access this SPRE at url:
http://[your Viya34 site].com/SASStudioV

As you can see, SAS Viya 3.4 effectively ships with two versions of SAS Studio - one for each flavor of Foundation SAS offered. SAS Studio 4 is the legacy offering with tight dependencies between software components, requiring them all together on the same host. And SAS Studio 5 is the modern Viya equivalent. SAS Studio 5 offers more deployment flexibility as implied by relying on three host groups.

See the SAS Viya 3.4 for Linux: Deployment Guide for information about the inventory.ini file and specifying deploy targets for the various host groups.

Full vs. Programming-only

There are two types of Viya deployment: full and programming-only. Full deployments are typically recommended and are most common. However, programming-only deployments are sometimes a better fit for specific use cases (such as using SAS Data Science).

Among other things, the programming-only deployment provides the [programming] host group in the inventory.ini file to install SAS Studio 4 and the legacy SAS 9 components as well as direct programming interfaces to SAS Cloud Analytic Services (CAS) through RESTful HTTP and languages like Python, R, and Lua.

The programming-only deployment does not provide host groups in the inventory.ini to install visual interfaces like SAS Drive and SAS Visual Analytics, nor does it include SAS Environment Manager or authentication services like SASLogon and Identities which are critical to the rest of Viya. It also does not include SAS Studio 5. The legacy SAS 9 runtime in the [programming] host group is built using pre-Viya software and so they still include their own user authentication capabilities. This means that programming-only deployments will rely on host-based authentication (usually via PAM in Linux hosts).

Interestingly enough, a full deployment of Viya provides host groups to install both SAS Studio 4 [programming] and SAS Studio 5 [StudioViya] along with [ComputeServer] and [ComputeServices]. For a full deployment of Viya, the SASLogon microservice is available to authenticate users with LDAP, Kerberos, OAuth, SAML, PAM, etc.

See "How Deployment Works" in the SAS Viya 3.4 for Linux: Deployment Guide for more explanation about different deployment types. And refer to the SAS Viya 3.4 Administration: Authentication doc to understand authentication options for your deployment.

Considerations for SPRE on multiple hosts

The SAS runtime - either as a legacy SAS Workspace Server delivered in [programming] or the SAS Viya Compute Server [ComputeServer] - can consume significant system resources like CPU, RAM, and especially disk I/O. If there will be heavy usage of the SPRE, then allocate hardware appropriately. For multi-host systems, avoid placing the SPRE on other mission-critical hosts like CAS servers to prevent resource contention.

In some cases, having just one host for the SPRE isn't sufficient. Identifying and eliminating single points of failure are key to improving system availability. Both types of SPRE can be deployed to run on multiple hosts to improve availability of their service. That said, it's important to understand that this does not provide failover protection of individual user sessions. That is, if a host fails, then any user sessions on that host (and their in-flight activities) are lost. To recover, the user would need to sign on a new SAS Studio session, establish a new SAS instance, and resume work from the last known good point.

With either legacy SAS Workspace Server [programming] or the SAS Viya Compute Server [ComputeServer], it is important to provide a shared file system for common data and other files which must be accessible across multiple hosts:

Data Mart: SAS programs run in the SPRE could execute on any deploy target. We must ensure each of those hosts has access to the underlying data that the SAS program expects to work with.
User Home Directories: The users' SAS preferences, the SASUSER libref, and other important files must be available for a consistent user experience.
Performance: We typically exhort our customers to implement shared file systems which are can transfer data simultaneously to every concurrent execution of Foundation SAS at a rate of 100 MB/sec/core or more!
Other: If you're already experienced with SAS Grid Manager implementations, this should all be familiar to you: Viya doesn't offer SAS Grid Manager (yet) and so related concepts like shared SAS binaries and configuration directories, checkpoint-restart, etc. do not apply

For more information about shared file system considerations, see my article: Contemplating shared file systems for SAS.

Deploy SAS Studio 4 and its SPRE to multiple hosts

The SPRE host group for SAS Studio 4 [programming] bundles several pieces of disparate software together: SAS/CONNECT Spawner and Server, SAS Object Spawner, SAS Workspace Server, SAS Studio 4 web app and its own web application server.

By adding multiple deploy targets to the [programming] host group, full copies of all those components are placed on each host. Each deployment of [programming] operates statelessly with no coordination between each other.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

▶ Side note: The [Operations] host group has a dependency on the [programming] host group (relying on some of those components to do its job). However, [Operations] is currently a singleton-only service - meaning it can only run on one host in the Viya environment and cannot be clustered for improved availability. Specify the deploy target for [Operations] that is the same as the first-listed deploy target for [programming].

To ensure that all [programming] hosts get their fair share of user workload, manual effort to configure load balancing in the Apache HTTP Server (or some equivalent) is required as a post-deployment task for programming-only deployments.

In this setup, each new user session is distributed in basic round-robin fashion to the hosts defined for SAS Studio 4. Each user session in SAS Studio establishes its own SAS Workspace Server instance on the same host. Each user's subsequent in-session requests are automatically routed to the same assigned host.

For full deployments of SAS Viya 3.4, the http-proxy microservice will automatically configure the load balancing when more than one [programming] deploy target is running.

Deploy SAS Studio 5 and its SPRE to multiple hosts

Much like a multi-tier deployment in SAS 9, we can deploy SAS Studio 5 and its SPRE host groups onto different deploy targets which are optimized for those workloads. In accordance with modern Viya architecture design, each of these host groups can run on multiple deploy targets with clustering configuration provided automatically by the Viya deployment process. So you don't need to muck about with the Apache HTTP Server proxy configuration at all.

The [StudioViya] host group provides a web application server for running the SAS Studio5 web app. Specify two or more deploy targets to improve availability of the SAS Studio 5 web app. Place this host group alongside other SAS Viya web apps on host(s) optimized for web application hosting.

The [ComputeService] host group provides ComputeServices and LauncherServices microservices for coordinating startup and activities of the the Compute Server and Launcher Server. Specify two or more deploy targets to improve availability of these services. As these services are relatively lightweight, they should be placed alongside other Viya infrastructure services.

The [ComputeServer] host group provides the SAS Launcher Server (similar in part to the SAS 9 Object Spawner) and SAS Compute Server (similar to SAS 9 Workspace Server) software. The SAS Compute Server can require significant system resources - CPU and RAM, of course, but is most often constrained by disk I/O. If you're expecting many concurrent users and/or time-sensitive batch jobs, then provision adequate deploy targets for this service. Specify at least two deploy targets for improved availability or more as needs dictate for workload.

For SAS Studio 5, there is no deterministic workload balancing of the SAS Compute Server… not even round-robin. When multiple deploy targets for [ComputeServer] exist, then SAS Compute Server host selection is random. Watch for improvements in this area coming with SAS Viya 3.5 or later.

Interesting developments

Even though the [programming] components are based on legacy SAS 9 Integration Technologies software with a SAS Object Spawner and SAS Workspace Server included, in SAS Viya 3.4 those components are restricted by a local software license to only work with SAS Studio 4 which resides on the same host machine.

For Viya 3.5 - expected to ship around 19w47 - an enterprise-grade license will be included with the [programming] components which will allow them to accept client connections from other hosts. This should allow SAS clients like SAS Add-in for Microsoft Office and SAS Enterprise Guide to connect to the [programming] SAS Object Spawner and SAS Workspace Server.

That said, the expectation is that the deployment process for the [programming] host group will remain the same in Viya 3.5 - all components included in just one host group.

Summary

The following table summarizes many of these concepts for easy review.

	SAS Studio 4 and its SPRE	SAS Studio 5 and its SPRE
Available in deployment type	In both Full and Programming-only deployments.	Only in Full deployments.
Foundation SAS software provided by...	[programming] > SAS Workspace Server	[ComputeServer] > SAS Compute Server
Multiple SPRE hosts requires shared file system	Yes, for user home directories and common data files.	Yes, for user home directories and common data files.
Multiple SPRE hosts requires manual configuration of Apache HTTP Server proxy definitions	Yes, for Programming-only deployments of SAS Viya. No, Full deployments of SAS Viya include ability to automatically cluster the SPRE.	No, Full deployments of SAS Viya include ability to automatically cluster the SPRE.
SAS Foundation is accessible to SAS Add-In for Microsoft Office and SAS Enterprise Guide	No, with Viya 3.4. Yes, with Viya 3.5.	No.

And as always...

Remember to work with the SAS Enterprise Excellence Center to perform a proper workload estimate and hardware sizing prior to provisioning hardware and deploying SAS software. This will help ensure that the SPRE has adequate resources to accommodate the expected workload and number of concurrent users.

ronan · ‎11-13-2019

Thank you very much for this detailed explanation. Clear & helpful.

chandren · ‎11-20-2019

Thanks Rob for this article.

One question,

In our Viya 3.5 we are having all these hostgroups in the same host.

[programming]

[ComputeServer]

[ComputeServices]

[StudioViya]

While trying to run SAS code via command line batch, which SPRE does it use?

/opt/sas/spre/home/SASFoundation/bin/sas_u8 -sysin load_to_sas.sas

Thanks again

RobCollum · ‎11-20-2019

@chandren, good question.

When you use the batch submit option to run your SAS code, you're down into the common foundation of both SPRE. What I'm saying is that the SAS executable you're running is effectively what both SPRE 4 and SPRE 5 use on that host.

chandren · ‎11-20-2019

Thanks for the clarification, Rob!