SAS Cloud Analytic Services: Concepts

• CAS Controller
• Single-node CAS Server
• CAS Backup Controller
• CAS Workers
• Sizing CAS Server
• CAS Table Rebalancing
• CAS State Transfer
• Backing Store for CAS Memory Allocations
• CAS Roles
  • Superuser Role
  • Data Role
  • Action Role
• Multiple CAS Servers
• Personal CAS Server
• Session Processes
• Paths List
• Caslib Management Privileges
• Standard Configuration Files
• CAS Resource Management
  • Overview
  • Policy Details
  • How Policies Work
• Configuration Properties: cas-shared-default Service

CAS Controller

Controller is one of three roles that can be assigned to a pod for SAS Cloud Analytic Services (CAS): controller, backup controller, and worker. For both server architectures — MPP and SMP — one pod is assigned the controller role. When the server starts, the controller process is started. This process is sometimes referred to as the server controller. The controller accepts connections from clients.

Single-node CAS Server

The single-node architecture uses symmetric multiprocessing (SMP). The functionality for a single-node server is nearly identical to MPP, except that there is no cluster communication. In this architecture, the server acts as a controller. Before a client connects, the server listens on a port for connections.

After a client connects, a session is created and the session connects back to the client. (This is identical to the method that is performed by a CAS server that uses MPP). For more information, see Single-Machine Server in SAS Cloud Analytic Services: Fundamentals.

CAS Backup Controller

A SAS Cloud Analytic Services (CAS) backup controller (sometimes referred to as secondary controller) provides fault tolerance for the CAS controller. A backup controller is used only in a distributed server architecture. Deploying a backup controller is optional. CAS supports one backup controller only.

When CAS starts, the backup controller process is also started. In the event that the controller experiences a disruption (such as a loss of network connectivity, disk full scenarios, and so on) the backup controller enables the CAS server to continue running. When the backup controller takes control of client communication, the transfer is seamless. For more information, see Architecture in SAS Cloud Analytic Services: Fundamentals.

CAS Workers

When a server is running in massively parallel processing (MPP) mode, in addition to a controller, the server also has multiple pods that are assigned the worker role.

The controller parses out work to each worker pod. Each worker pod sends the results of its computations back to the controller. For more information, see Architecture in SAS Cloud Analytic Services: Fundamentals.

Sizing CAS Server

It is recommended that the SAS administrator or an administrator with elevated Kubernetes permissions should have a general idea about sizing CAS. The process to create preliminary estimates on sizing might include the following:

• Gather baseline deployment data for each offering by recording the CPU and RAM allocations and number of pods in a deployed environment.
• Define appropriate CAS, Compute, and storage sizing recommendations. The key points to determine the sizing of CAS, Compute, and data infrastructure are:
  • SMP vs MPP deployment
  • Data size (number of data sets or tables, amount of data used)
  • Number of users
  • CAS server needs dedicated nodes with guaranteed QoS for each controller and worker.

For more information, see the following:

• Resource Guidelines in System Requirements for the SAS Viya Platform
• Storage Requirements in System Requirements for the SAS Viya Platform

CAS Table Rebalancing

This functionality allows the users to change the number of workers that are supported by a distributed CAS server (MPP) on a running CAS server. This helps in managing the cloud expense of maintaining a CAS server and to keep the CAS server ‘right-sized’ for the expected workload.

Key Points:

• To change the number of workers, see Change the Number of Workers for MPP CAS in SAS Viya Platform: Deployment Guide. When the value of the number of workers is changed, the server pauses all sessions when each session reaches an action boundary to allow the data in loaded tables to be rebalanced. To enable rebalancing of the loaded tables, see Enable Table Rebalancing.
• The server waits for all sessions to reach an action boundary. The maximum amount of time that the server waits to decrease or increase the number of workers is controlled by the options removeNodeCancelTimeout and addNodeCancelTimeout, respectively. The default value for both options is 120 seconds.

  If this time-out elapses and any sessions are still running actions, then these running actions are interrupted and are allowed to complete within the second time-out. The second time-out is specified by the options removeNodeKillTimeout and addNodeKillTimeout, which decrease and increase the number of workers, respectively. The default value for both options is 15 seconds.

  If the second time-out elapses, then any sessions that are still running actions are terminated.

• The CAS server is unable to start new actions depending on the following factors:
  • while waiting for actions on every session to reach an action boundary
  • while moving data between the workers to support the change in the number of workers
    Note: Setting appropriate values for removeNodeCancelTimeout, addNodeCancelTimeout, removeNodeKillTimeout, and addNodeKillTimeout options should not disrupt active actions so that the number of workers is changed in a timely manner.

    If the number of workers is reduced, then the data on loaded tables is rebalanced across the worker pods that are not marked to be terminated. cas.SCALEDOWNMODE option controls how the data is moved in the global tables.

    The Kubernetes administrator can choose which worker pods to be terminated by applying the label casoperator.sas.com/scaleDownProposed before altering spec.workers in the CASDeployment custom resource. The worker pods with this label are always selected to be terminated before the worker pods without this label.

    For example, if the administrator wants to scale down from 12 to 8 workers, the label is applied to 4 specific worker pods. After the value of spec.workers is changed from 12 to 8, the worker pods that are labeled are terminated.

    If the number of workers is increased, then the data on loaded tables might or might not be rebalanced across the new set of workers depending on the configuration.

CAS State Transfer

CAS state transfer is a feature that helps to minimize disruptions during CAS server maintenance operations, such as updates or restarts within SAS Viya. It allows seamless transfer of the session state, data, and other relevant artifacts from an old CAS server instance to a new CAS server instance, ensuring continuity and minimizing downtime for users.

Backing Store for CAS Memory Allocations

Generally, when CAS allocates memory, it uses memory allocated from the threaded kernel. The pages are backed by real memory or a configured paging file. In most Kubernetes configurations, containers do not have a configured paging file, which results in memory allocated by CAS being backed by real memory. This increases the probability of CAS session processes being killed by the Linux Out-Of-Memory (OOM) killer. With Kubernetes version 1.28, if a CAS session that is processed in a CAS pod is killed by the OOM killer, then any other CAS session processes as well as the main CAS process in that same cgroup are also killed. Kubernetes does not necessarily terminate the pod. Instead, it attempts to restart the containers as directed by the restart policy. In an SMP deployment of CAS, this effectively restarts the entire CAS server, which significantly interrupts data availability and user access.

You can set a backing store to support memory allocations. The backing store informs the threaded kernel that the files in a specified directory can be used to back up most of the memory allocations. To configure CAS to use a backing store, set the environment variable TK_BACKING_STORE_DIR in the CAS container to the name of a directory where the threaded kernel stores the mapping files (/cas/tkMemory). If your deployment is at 2024.09 or 2024.10, see Configure a Backing Store for Memory Allocations.

In 2024.11, you can enable the backing store in four different scenarios using patch transformer .yaml files. For more information, see Configure a Backing Store for Memory Allocations in SAS Viya Platform: Deployment Guide.

Creation of an emptyDir volume that is backed by memory allows a maximum size to be specified for the volume. Here is an example that shows an entry in the pod's spec.volumes that provides 24GB of space backed by real memory.

- name: tk-backing-store
  emptyDir:
    medium: Memory
    sizeLimit: 24Gi

You can now mount it in the CAS container.

- name: tk-backing-store
  mountPath: /cas/tkMemory

This results in the directory /cas/tkMemory being present in the CAS container, where files are backed by real memory with a maximum memory size limit of 24GB.

The files are unlinked promptly after the following operations:

• When the CAS session process terminates, all of the files that are used to back the threaded kernel memory are released.
• The contents of the files are accessible only to the process that created them.

- name: tk-backing-store-1
  emptyDir:
    medium: Memory
    sizeLimit: 256Gi
- name: tk-backing-store-2
  emptyDir:
    medium: Memory
    sizeLimit: 256Gi
- name: tk-backing-store-3
  emptyDir:
    medium: Memory
    sizeLimit: 128Gi
- name: tk-backing-store-4
  emptyDir:
    medium: Memory
    sizeLimit: 64Gi
- name: tk-backing-store-other
  emptyDir:
    medium: Memory
    sizeLimit: 32Gi

- name: tk-backing-store-1
  mountPath: /cas/tkMemory/1
- name: tk-backing-store-2
  mountPath: /cas/tkMemory/2
- name: tk-backing-store-3
  mountPath: /cas/tkMemory/3
- name: tk-backing-store-4
  mountPath: /cas/tkMemory/4
- name: tk-backing-store-other
  mountPath: /cas/tkMemory

CAS Roles

Superuser Role

Superusers are exempt from all CAS authorization requirements. The Superusers are subject to requirements for the Select permission, except for loadTable actions that meet the following criteria:

• The loadTable action does not cross-load data (load to a destination caslib that is different than the source caslib).
• The loadTable action does not cross-promote data (promote to a different caslib than the source caslib).
• The loadTable action does not specify a WHERE clause on the load.
• The loadTable action does not specify a VARS= list on the load.

Superusers can perform all tasks. The following tasks can be performed only by the Superusers:

• Use the installActionSet and refreshLicense built-in actions. See Builtins Action Set: Details.
• See and manage the paths list. See Paths List.
• Manage role membership. See Manage CAS Role Memberships in SAS Environment Manager: User’s Guide.

In SAS Environment Manager, the Superuser role is never initially or automatically assumed. If you are a member of a CAS server’s Superuser role, you can become a Superuser by explicitly assuming the role for that server. For example, you might assume the role to troubleshoot and resolve an access issue. After the issue is resolved, you relinquish the role.

The account that starts a CAS server is automatically assigned to that server’s Superuser role. Make sure that each CAS server has at least one other designated Superuser.

Initial membership of the Superuser role is as follows:

• SAS Administrators
• Process owner for the server
• Backup Administrator (sas.deploymentBackup)
• Report Distribution Service administrator account (sas.reportDistribution)
• Report Images Service administrator account (sas.reportImages)
• Scheduler Service administrator account (sas.scheduler)
• Report Alerts Service administrator account (sas.reportAlerts)
• CAS Formats Service administrator (sas.casFormats)
• VSD Service administrator account (sas.svi-vsd-service)
• Analytics Gateway Services Group (analyticsGatewayProviders)
• Relationship Service (sas.relationships)
• Data Selection Service (sas.dataSelection)
• Data Quality Service (sas.dataQuality)
• Health Cohort Service (sas.healthCohort)

Data Role

Provides a subset of the abilities of the Superuser role. Data administrators are exempt from all CAS authorization requirements for data objects. The exception is that the Data administrators are subject to requirements for the Select permission, except for loadTable actions that meet the following criteria:

• The loadTable action does not cross-load data (load to a destination caslib that is different than the source caslib).
• The loadTable action does not cross-promote data (promote to a different caslib than the source caslib).
• The loadTable action does not specify a WHERE clause on the load.
• The loadTable action does not specify a VARS= list on the load.

Only Data administrators and Superusers can perform the following tasks:

• See and manage the paths list. See Paths List.
• Manage caslib privileges. See Caslib Management Privileges.

Action Role

Provides a subset of the abilities of the Superuser role. Action administrators are exempt from CAS authorization requirements for action sets and action objects.

Do not use this role. Not all interfaces support the Action role. This role might be deprecated in the future.

Multiple CAS Servers

It is now possible to have multiple instances of CAS deployments within a single instance of SAS Viya platform. For more information, see Add a CAS Server .

What constitutes a CAS server depends on the type of CAS environment that you are running:

• In a symmetric multiprocessing (SMP) environment, a CAS server consists of a controller and runs on a single node.

  Multiple Single-Node CAS Servers (SMP Mode)

  
• In a massively parallel processing (MPP) environment, a distributed CAS server consists of one controller, one or more workers, and one backup controller (optional) each running in separate pods. For more information, see Distributed Server in SAS Cloud Analytic Services: Fundamentals.

Personal CAS Server

A personal CAS server, which is an ephemeral CAS server, is created on demand for a single user. For development purposes in applications such as SAS Studio, you might need to allow data scientists the ability to work with a CAS server that is local to their SAS session. The lifetime of this server is the same as the lifetime of the SAS session with which it is associated. This personal CAS server is just like a regular (shared) CAS server, except that it is simpler, relatively short-lived, and is for only one person.

Key Points:

• A personal CAS server cannot be accessed or shared by more than one user.
• Personal CAS servers run under their own Compute server session and therefore are independent sandboxed instances.
• A personal CAS server runs under the same account that runs the Compute server.

To set up a personal CAS server, see the README file at $deploy/sas-bases/overlays/sas-programming-environment/personal-cas-server/README.md (for Markdown format) or at $deploy/sas-bases/docs/configuring_sas_compute_server_to_use_a_personal_cas_server.htm (for HTML format).

To start a session on your personal CAS server, see Start a Session on a Personal CAS Server in SAS Cloud Analytic Services: User’s Guide.

To switch between a personal CAS server and the shared CAS server, see Switch between a Personal CAS Server and the Shared CAS Server in SAS Cloud Analytic Services: User’s Guide.

SASWORK caslib is automatically created when a personal CAS server is created. The SASWORK caslib points to the WORK directory in your SAS session. You can use SASWORK to transfer data between personal CAS server sessions and shared CAS server sessions. To transfer data from the shared CAS server to the personal CAS server, see SAVERESULT Statement and UPLOAD Statement in SAS Cloud Analytic Services: CASL Reference and save Action in SAS Viya: System Programming Guide.

Session Processes

When a user connects to the server with a client, the server starts a session process for the user. Afterward, the client communicates with the session process.

A server running in symmetric multiprocessing mode (SMP mode) consists of a controller only, and the server starts a session controller process only. It is the session controller process that operates on rows of data.

Even though the sessions have their own operating system processes, the server processes must continue to run. When the server process terminates, the session processes also terminate.

Paths List

From a CAS server session, all access to file system paths (directories that are local to the host and to shared file systems) is through caslibs. By default, all users who lack elevated privileges are denied the ability to create caslibs outside of the paths that are specified in the default allowlist.

To determine the paths that are available to non-administrators when they create a caslib, use one of the following approaches:

• Modify the predefined allowlist of paths that should be available. By default, this list denies access to all users who lack elevated privileges.
• Create a denylist of paths that should not be available.

  If you choose to create a denylist, the new list replaces the predefined allowlist.

You can view and modify the lists for CAS user access using:

• SAS Environment Manager.

  For more information, see Manage Path Lists (Allowlists and Denylists) in SAS Environment Manager: User’s Guide.

• The programming interfaces.

  For more information, see Access Control Action Set in SAS Viya Platform: System Programming Guide.

Here are key points:

• Paths must be absolute.
• Paths must be unique.

  CAS automatically removes any duplicate paths.

• You can only use an allowlist or a denylist, not one of each.
• If a denylist path is changed to a symbolic link, then the denylist should be updated using the fully resolved path.
• All subdirectories of each specified path are affected.
• Paths list constraints do not affect access to existing caslibs.
• Paths list constraints do not apply to users who assume the Superuser role or the Data Admin role.
• Only users who assume the Superuser role for a server can see and manage that server’s paths list.

Caslib Management Privileges

See Also

• Adjust Caslib Management Privileges using SAS Environment Manager

Standard Configuration Files

The configuration home directory includes several files with standard names. The server automatically processes these files when the standard names are used.

The configuration directory is an emptyDir volume mounted inside the container in the /cas/config location. The contents of files in /cas/config are either copied or generated when the sas-cas-server container is initialized. A SAS administrator cannot modify any files in /cas/config because the files are transient to that specific instance of the sas-cas-server container while it is running.

The following table describes the purpose and the use for each of the standard files.

When the server starts, the configuration files that are described in the preceding table are processed. After the configuration is complete, the server runs start-up scripts.

The following table describes the standard names for the start-up files in the configuration home directory. The start-up scripts run before the server accepts any client connections. This is also referred to as session-zero processing.

Session zero runs under the CAS service account. Session zero already assumes the superuser role when the startup scripts are run. Make sure not to drop the role. Because session zero assumes the superuser role, you should be aware of the restrictions for data access for administrators. For more information, see Superuser Role.

The SAS administrator can set the configuration variables and environment variables that can be modified by editing the CAS configuration instances in the SAS Environment Manager. See Edit Configuration Instances.

CAS Resource Management

Overview

You can implement resource management specifically through policies that you create with the SAS Viya platform command line interface. CAS resource management is achieved on the CAS server, with a policy or server option that applies to a specific server. If you have additional CAS servers on which you want to manage resources, then you must create a unique policy or server option definition for each. No steps need to be performed on the client side.

Policy Details

Here are some key details about CAS resource management policies:

• You must have CAS Superuser privileges to create and manage resource management policies.
• Supported on both single-node (SMP) and distributed (MPP) CAS servers.
  IMPORTANT For CAS to use resource management policies, the environment variable, env.CAS_ENABLE_CONSUL_RESOURCE_MANAGEMENT must be turned on. For more information, see env.CAS_ENABLE_CONSUL_RESOURCE_MANAGEMENT.
• Policies are specific to a CAS server.
• Policy limits apply per machine for distributed CAS servers.
• Policies are managed through the SAS Viya platform command line interface and are turned off by default.
  TipWith the CAS command line interface, you can create a policy template that can serve as a starting point for creating your own CAS resource management policies. For more information, see Create Policies from JSON Templates in SAS Viya Platform: Using the Command-Line Interface.
• CAS stores policies as key-value pairs in the SAS Configuration Server (Consul).
• The SAS administrator can query the Consul to know the current settings and to monitor the policies.
• All the Consul settings are persisted across a maintenance update.

How Policies Work

Administrators create policies using the SAS Viya platform command line interface, which stores the policies as key-value pairs in the SAS Configuration Server (Consul).

There are two types of policies:

• global caslibs (globalCaslibs)

  One policy per CAS server that is used to place space quotas on global caslibs.

• priority-level (CAS-server-name-priority-n)

  A maximum of five policies per CAS server that is used to place space quotas on table data.

If policies are defined, a CAS server reads its policy information directly from the configuration server. CAS provides one policy for global caslibs and up to five priority level policies to which sites can assign resources. The administrator can assign users to these priority-level policies based on their identity group memberships, or they can explicitly assign priority-level policies to individual users.

How CAS Policies Work

CAS has built-in functionality to recognize user group names that start with the name of the CAS server as a group related to CAS resource management. When a user authenticates to create a new session, CAS always scans the user’s identity groups searching for resource management user group names. If CAS finds that the user belongs to a resource management user group—a group whose name starts with the CAS server name—then CAS attempts to match the group name with the list of resource management policies.

Relying on this behavior, the administrator can create corresponding custom groups using identical names in SAS Environment Manager and add the appropriate user names to these groups.

If a user is a member of multiple resource management groups, then CAS assigns the lowest priority number. If the user is not a member of a resource management group, then CAS searches for an explicit assignment for the user under the policy definition priorityAssignments section. If the user is not a member of a resource management group, and the user has not been assigned any priority level, then the user has no limits.

Configuration Properties: cas-shared-default Service

contents

Contents of the specified configuration instance. The options that you specify are not validated for correctness. For more information, see Edit Configuration Instances.

name

The configuration instance name that is unique to the server. Do not modify this value unless SAS Technical Support instructs you to change it.