SAS Viya on Red Hat OpenShift Service for AWS (ROSA)

In this article, we provide essential “how to” technical information for deploying SAS Institute's SAS Viya platform, on Red Hat OpenShift Service on AWS (ROSA) as well as provide a reference architecture. For some general security, machine management and storage considerations when deploying SAS Viya on Red Hat OpenShift please take a look at our previous two part series (part 1, part 2).

Based on the collaboration between Red Hat and SAS, we have adopted a holistic approach to SAS Viya on OpenShift. SAS Viya can now be deployed and supported on most x86_64 platforms where OpenShift can be used. This includes both managed and self-managed OpenShift with on-premise and public cloud platforms, including bare metal, Red Hat OpenShift Virtualization, VMware vSphere, Azure, AWS and ROSA.

For more information please check the SAS blog, and for the latest system requirements please check the official SAS Viya documentation found in the SAS Operations Guide.

Make sure to check the SAS Operations Guide and the ROSA life cycle dates to determine which versions of OpenShift that are supported. At the time this article was written, SAS Viya 2024.03 and ROSA both support OpenShift versions 4.13 - 4.15. SAS works to align their SAS Viya Kubernetes support levels with OpenShift and typically adds support for the latest OpenShift version updates within 1-2 months of a given OpenShift version release.

What is ROSA?

ROSA is a fully managed turnkey application platform that helps organizations to increase operational efficiency, refocus on innovation and quickly build, deploy and scale applications in a native AWS environment. Utilizing SAS Viya on ROSA not only allows you to take advantage of running in the public cloud, it also allows you to take advantage of a fully managed application platform that is jointly supported and operated by Red Hat and AWS.

OpenShift provides an optimal foundation for the SAS software stack. It also offers both a hardened Kubernetes with many highly valued enterprise features as an execution platform, and an extensive partner ecosystem with a particular focus on supporting DevSecOps capabilities.

ROSA is a first-party service that’s available to order directly from the AWS management console using your AWS account. It provides pay-as-you-go flexible pricing and an on-demand hourly or annual billing model. There is no upfront commitment, but, you can take advantage of pricing discounts with 1 or 3 year reserved-instance pricing. Refer to the Red Hat OpenShift Service on AWS pricing page for more information.

ROSA is available in two deployment models—ROSA with hosted control planes (ROSA with HCP), and ROSA classic. ROSA with HCP offers a more efficient control plane architecture that allows for faster cluster creation times and reduces the AWS infrastructure costs for ROSA. This is made possible by hosting a highly available control plane within a Red Hat-owned AWS account instead of the customer’s AWS account. For more information about ROSA with HCP, please refer to the blog  Red Hat OpenShift Service on AWS with hosted control planes now available.

If you would like to learn more about ROSA, you can start a free 8-hour hands-on experience with a ROSA cluster and browse the ROSA learning hub for more resources.

What is SAS Viya?

SAS Viya is a cloud-native, AI, analytic and data management platform that covers the entire AI and analytics lifecycle. It is not just a single application, but a suite of integrated applications. It’s fully containerized, runs on Kubernetes, and is supported by continuous integration and continuous delivery (CI/CD). SAS Viya makes it possible for users of all skills and at every level of the organization—from data scientists, to business analysts, to executives—to collaborate and scale while operationalizing discovery and decision-making.

From a technical point of view, SAS Viya is deployed in a single Kubernetes namespace, either on dedicated cluster infrastructure or on infrastructure shared with other workloads. SAS Viya on OpenShift can be deployed in different ways, ranging from a manual approach (which we used for our validation deployment) or fully automated using a deployment operator provided by SAS.

SAS Viya on ROSA reference architecture

SAS takes advantage of the scalability provided by ROSA by breaking Viya down into different workload types and recommends assigning each workload to a class of nodes, i.e., to machine pools. This makes sure that the proper resources are available to specific workloads. Figure 1 shows the optimal separation of workloads to such pools.

Figure 1. SAS Viya on ROSA reference architecture

Applying a workload placement strategy by using node/machine pools as shown above provides a number of benefits, and is considered a best practice.  The placement of SAS workload classes can be enabled by applying predefined Kubernetes node labels and node taints.

The following node/machine pools are created along with their corresponding SAS workload classes. Please refer to part 1 from our previous two part series, for an explanation of the workload classes mentioned in this diagram:

• SAS Cloud Analytic Services (CAS) (CAS MACHINE POOL)
• SAS Compute Services (COMPUTE MACHINE POOL)
• SAS Microservices and Web Applications (STATELESS MACHINE POOL)
• Infrastructure Services (STATEFUL MACHINE POOL)
• DEFAULT MACHINE POOL

A Git repository is provided with machine pool definitions for the recommended SAS workload classes that take advantage of the machine management and automation capabilities within ROSA. The machine pool definitions include the necessary node labels and node taints for proper workload placement.

The ROSA with HCP deployment type was used for this environment. The control plane runs within the ROSA service account, while the worker/compute nodes and other infrastructure and services run within the customer AWS account. Please note, however, that the information provided in this article is not specific to ROSA in HCP mode.

Amazon Relational Database Service (RDS) for PostgreSQL was configured to make use of the native AWS managed service for use with SAS Viya. SAS requires a PostgreSQL database for storing the environment’s metadata. Using the RDS service is a preferred option for running SAS Viya on AWS—being a managed service, RDS can take care of most typical requirements like scalability, high availability, backup and restore, etc.

More details on the system requirements can be found in the External PostgreSQL section of the SAS documentation.

Amazon Elastic Container Registry (ECR) access was also configured for staging the SAS Viya container images prior to the deployment. While not mandatory, most SAS customers choose to use a “local” mirror registry instead of pulling the SAS images directly from the SAS container registry. Consider using a mirror registry if:

• You have to follow existing security policies which require vulnerability scanning on container images before pulling them to the cluster
• You are concerned about the image pull latency
• You need to “pinpoint” the deployed software stack, especially when managing multiple environments (e.g. dev/test/prod tiers)

SAS provides a command-line utility, SAS Mirror Manager, for working with mirror registries. Please refer to the section Using a Mirror Registry in the SAS documentation for more information.

For persistent storage within ROSA, the AWS EBS and EFS services were configured to provide the RWO and RWX types of storage required by SAS Viya. We also tested more advanced configuration options for providing fast storage for the SASWORK and the CAS disk cache volumes. Please see the transformer patches in the Git repository which accompanies this article.

Deployment process

The details for the ROSA and SAS Viya deployment are available from the following Git repository: https://github.com/redhat-gpst/sas-viya-rosa.

Figure 2. Deployment process

Here are the steps that will be used to deploy ROSA and SAS Viya, at a high level.

ROSA

ROSA prerequisites:

1. Associate AWS account with a Red Hat account (if you plan to use the web interface to create a ROSA cluster)
2. Enable ROSA from the AWS console
3. You have installed and configured the AWS CLI version 2
4. You have installed and configured the latest ROSA CLI (rosa)
5. You have logged in to your Red Hat account by using the ROSA CLI
6. Create a virtual private cloud (VPC). A single AZ was used, but a multi AZ method could also be used.
7. Create Account-wide roles
8. Create an OIDC configuration
9. Create Operator roles

ROSA deployment using either the ROSA CLI or the web UI on the Hybrid Cloud Console. The deployment type used is ROSA with HCP.

ROSA post-install configuration:

1. Create additional machine pools
2. Enable the AWS EFS CSI Driver Operator
3. Configure AWS RDS service
4. Configure ROSA to pull images from AWS ECR
5. Install cert-utils-operator
6. Apply SCCs (Security Context Constraints) required by SAS Viya. Review the section Preparing for OpenShift in the SAS Viya Operations Guide to understand which ones you need to apply.

SAS Viya (manual deployment)

After purchasing a SAS Viya license, customers receive a set of deployment templates (known as the deployment assets tarball) in YAML format which they need to modify to create the final deployment manifest (usually called site.yaml). SAS uses the kustomize tool for modifying the templates. Common customizations include the definition of a mirror repository, configuring TLS, high-availability, storage and other site-specific settings. The final deployment manifest can then be submitted to Kubernetes using multiple kubectl commands.

NOTE: This section assumes that you have cluster-admin privileges on the ROSA cluster to manage the deployment of SAS Viya.

1. Use SAS Mirror Manager to pull the Viya container images and push them to your own container registry, e.g. to AWS ECR (this is an optional step).
2. Download the SAS Viya deployment templates (a.k.a. the “deployment assets tarball”) from the SAS web site using the entitlements contained in your license.
3. Prepare your build environment. This could be a small Linux machine on AWS EC2 or your Windows laptop. Make sure your build environment can connect to the ROSA cluster. Our Git repository has a section describing the tools you should install.
4. Create a new OpenShift project, e.g. oc new-project viya4
5. Untar the deployment assets and prepare a basic directory structure for the site-specific contents (usually a folder called site-config).
6. You need to create site-specific content describing your infrastructure and merge it with the deployment assets downloaded previously. We use the kustomize utility for this. See our Git repository for example patches.
7. At a minimum, you need to prepare transformer patches for:
   1. Certificate handling (TLS) - you can have SAS Viya generate a self-signed certificate or provide your own TLS web server certificate.
   2. Local storage and shared storage (RWO and RWX). For deployments on AWS, EBS and EFS can be used, but there are other options as well. Make sure that the storage classes are in place (for EFS see above: ROSA post-install configuration).
   3. Configuring an internal or external PostgreSQL database. We recommend configuring an external PostgreSQL database to store the metadata generated by the SAS Viya platform. On AWS, the Amazon RDS for PostgreSQL service can be used.
   4. Configuring an authentication and identity provider. There are many options, but the simplest case would be to deploy a local LDAP server based on OpenLDAP on ROSA.
   5. Make sure your fsGroup setting matches the project’s setting.
8. Create a kustomization.yaml file and use kustomize to merge your patches with the deployment templates.
9. Submit the resulting manifest (“site.yaml”) to the ROSA cluster.
10. Get a cup of coffee while you wait for the deployment to finish. 🙂

Conclusion

With that we’re done! We hope this has given you the basic know-how you’ll need to support your project team in deploying SAS Viya on ROSA.

For some general security, machine management and storage considerations when deploying SAS Viya on OpenShift please take a look at our previous two part series (part 1, part 2).