Using SAS Viya with OpenShift Reference Architecture
Here in this blog, we will learn how to use SAS Viya with open shift reference Architecture.
Principal Framework
Based on the cooperation between Red Hat and SAS, we’ve adopted a thorough strategy for SAS Viya on OpenShift. Now, SAS Viya can be successfully installed and maintained on the majority of x86_64 platforms that support OpenShift. This covers bare metal, OpenShift Virtualization, VMware vSphere, Azure, AWS, and many more public and on-premise cloud platforms along with self-managed OpenShift.
The following is confirmed by the SAS Operations Guide as of right now:
On a platform where OpenShift clusters are supported, use Red Hat OpenShift Container Platform (OCP) 4.13.x–4.14.x. Refer to the relevant OCP installation guide for comprehensive details about these environments: OCP 4.13; 4.14. It is also required to deploy on the verified integrations, which are described in detail at OpenShift Container Platform 4. x Tested Integrations (for x86_64). These OCP versions match the 1.26.x through 1.27.x supported versions for Kubernetes. This advice will change once Red Hat adds support for Kubernetes 1.28.
SAS has only conducted tests using infrastructure that is provided by the user.
Future support for SAS Viya deployments with OpenShift that are provided as managed services on hyperscaler public cloud platforms, such as Red Hat Service on AWS (ROSA), Azure Red Hat OpenShift (ARO), and others, is planned as of the time this document is written. The SAS Support for Alternative Kubernetes Distributions policy currently applies to these.
Check the SAS Operations Guide to see which versions of OpenShift are supported. SAS Viya 2024.03 is compatible with Red Hat OpenShift versions 4.13–4.14 as of the writing of this blog. Within a month or two of a given version release, SAS usually adds support for the most recent updates to OpenShift and strives to match their SAS Viya Kubernetes support levels with it. Only a high-level summary of the prerequisites is given here, as part 2 of this blog contains more information about some of the particular OpenShift components that support the SAS Viya deployment:
- SAS has particular requirements for cookie forwarding during transaction execution, according to OpenShift Ingress Operator. To achieve that, they employed unique methods utilizing the HAProxy. Therefore, support for the OpenShift Ingress Operator is limited to this iteration.
- OpenShift Routes: SAS uses OpenShift Routes because they prefer to use native features in the environments that come with their products.
- cert-utils-operator: SAS needs to manage certificates for keystore creation and transport layer security (TLS) support using this community operator.
- cert-manager: SAS Viya facilitates the use of two separate certificate generators for full-stack TLS enforcement. The default generator, which comes pre-configured from SAS, makes use of OpenSSL. As an alternative, you can deploy and generate the certificates needed to encrypt pod-to-pod communication using cert-manager.
- Security Context Constraints (SCCs): These are necessary for pods to operate and give them permissions. In order to support SAS Viya Services with OpenShift, SAS needs multiple custom SCCs. The SAS documentation provides information about the necessary SCCs to help you understand how they are used in your environment and to address any security concerns. Part 2 of this blog offers more information about the necessary custom SCCs.
Options for Deployment: Red Hat OpenShift
OCP’s versatility makes it a powerful tool. It can run practically anywhere. You can use the Red Hat Hybrid Cloud Console to choose to deploy a cluster in your own data center or in a public cloud provider, and this will serve as a launch point for all installation methods.
Red Hat OpenShift Container Platform can be installed in a number of ways, including:
Interactive: The web-based Assisted Installer, which offers an easy-to-use installation solution straight from the Red Hat Hybrid Cloud Console, can be used to deploy a cluster. For clusters having networks connected to the internet, this is the best method. Installing OpenShift Container Platform is made simplest with the Assisted Installer, which also takes care of pre-flight validations and cluster installation.
For more information and to see an example of how to use the OpenShift Assisted Installer, go to the Red Hat blog OpenShift Assisted Installer is now Generally Available.
Local Agent-based: In disconnected environments or on restricted networks, you can deploy a cluster locally using the Agent-based Installer. You can download and install the Agent-based Installer first, then take advantage of many of the Assisted Installer’s benefits. Utilizing a command-line interface, configuration is completed. This method works best in disjointed environments.
For more information and to see a live demonstration of the OpenShift Agent-based Installer in action, visit the Red Hat blog Introducing a Game-Changing New Way to Deploy OpenShift Clusters in Disconnected Environments.
Automated: The OpenShift installation program can pre-configure and automate the provisioning of the necessary resources when you deploy a cluster on installer-provisioned infrastructure (IPI). The installation program uses the baseboard management controller (BMC) of each cluster host for provisioning when installing on bare metal. Clusters can be installed in environments that are linked or unconnected.
Complete control: The most control over the installation and configuration process is available when deploying a cluster on user-provisioned infrastructure (UPI) that you set up and manage. Clusters can be installed in environments that are linked or unconnected.
OpenShift Hosted Control Planes (HCP): With this new OpenShift control plane architecture, you can run the control planes for several clusters at once on a management cluster. This reduces the total cost of ownership by consolidating the control planes into fewer nodes. The security boundary is reinforced by the separation of the control plane and data plane.
HCP also supports OpenShift worker (compute) nodes running on bare metal and OpenShift Virtualization for on-premises architectures.
See the Red Hat blog article Effortlessly And Efficiently Provision OpenShift Clusters With OpenShift Virtualization for additional details on utilizing OpenShift Virtualization with HCP and to watch a live demonstration of it in action.
The machine management and storage integration features of OpenShift can be configured using the information in Part 2 of this blog.
SAS Viya Deployment Options
The SAS Operations Guide describes various methods for implementing SAS Viya on Red Hat OpenShift:
- manually through the use of kubectl commands
- Employing the Deployment Operator for SAS
- Using the command-line tool sas-orchestration
1. Manual Implementation
Customers who purchase a SAS Viya license are given a set of YAML-formatted deployment templates (referred to as the deployment assets tarball), which they must edit in order to produce the final deployment manifest, which is typically named site.yaml. SAS modifies the templates using the Customize tool. Creating a mirror repository, setting up TLS, high availability, storage, and other site-specific parameters are examples of common modifications. Afterward, kubectl commands can be used to submit the final deployment manifest to Kubernetes.
NOTE: To manage SAS Viya deployments, you must have cluster-admin privileges.
The final manifest includes items like Custom Resource Definitions (CRDs), PodTemplates, ClusterRoleBindings, and others that need elevated privileges to be deployed. As a result, the SAS project team will typically need assistance from the OpenShift administration team to complete the deployment. All resources that must be deployed in accordance with the necessary permissions have been tagged by SAS. This allows the administration team (with cluster-admin permissions) and the project team (with namespace-admin permissions) to share tasks. It’s crucial to remember, though, that this dependency will resurface with, say, future updates.
2. Operator for SAS Deployment
Because of this, employing the SAS Deployment Operator could offer a more advantageous option.To implement and maintain SAS Viya, SAS provides an operator. The SAS Deployment Operator is not available in the Red Hat Marketplace or OperatorHub since it is not (yet) a certified operator.
An automated method for updating and deploying SAS Viya environments is offered by the SAS Viya Deployment Operator. It operates within the OpenShift cluster and keeps an eye out for Custom Resources (CRs) of the SASDeployment type, which are declarative representations of SAS Viya deployments. The Deployment Operator performs an initial deployment or updates an existing deployment to match the state that is described in the CR whenever a new SASDeployment CR is created or an existing CR is updated. All SAS Viya deployments in the cluster can be managed by a single instance of the operator.
NOTE: The Deployment Operator must have cluster-admin privileges in order to supervise SAS Viya deployments.
The operator can lessen reliance on the OpenShift administration team by largely automating deployments and deployment updates as part of a DevOps pipeline. As an illustration, OpenShift GitOps, an OCP component that offers a turnkey CI/CD automation solution for continuous integration (CI) and continuous delivery (CD) tasks, seamlessly integrates with the SAS Deployment Operator. By automatically syncing its contents to the cluster and keeping an eye on a Git repository for modifications to the SAS CR manifest, OpenShift GitOps can be used to add more automation to an SAS Viya deployment. OpenShift GitOps syncs after the CR manifest is pushed to the Git repository. The deployment of the CR to Kubernetes will initiate the Operator and the deployment process. As Figure 2 shows
See the SAS blog post Deploying SAS Viya using Red Hat OpenShift GitOps for more details.
3. The SAS Orchestration Tool
The SAS-orchestration command-line tool combines the best features of both worlds: it can be manually launched on a Linux shell as a container image to create and submit the final deployment manifest (i.e., it combines the kustomize and kubectl actions into one step) or it can be used as a step in a CI/CD pipeline, such as a task in OpenShift Pipelines, Jenkins or GitHub Actions, etc.
NOTE: In order to use the sas-orchestration utility to perform a SAS Viya deployment, you must have cluster-admin privileges.
For more information about the SAS-orchestration utility, go to the SAS blog New SAS Viya Deployment Methods.
SAS Viya Implementation Seen Through a Process Lens
The size and complexity of the software stack make it obvious that deploying SAS Viya is a “team sport activity.” Typically, project teams on OpenShift receive namespace-local permissions from the OCP admin team, but not cluster-wide permissions (admin vs. cluster-admin role). In part 2, we go into further detail about the security requirements, but to put it briefly, it means that the SAS project team will not have the required authorizations to execute an autonomous deployment.
We found the following process approach to be useful, based on our past deployment experiences at customer sites. For the purposes of this blog, Figure 3 depicts the steps involved in a manual deployment:
The deployment process can be divided into three stages: planning, preparing, and performing. The two primary actors in the process are the OpenShift administration team and the SAS project team, which consists of local SAS administrators and system engineers from the SAS Institute.
- Planning: Usually, it’s a good idea to begin with a joint workshop in which the OCP administrators receive a technical overview of SAS Viya from the SAS team. This is the place to talk about things like networking, security, sizing, and storage.
- Preparation: The OCP administrators are usually responsible for the second task, which involves reviewing the requirements and setting up the project. After that, the SAS team can begin creating the deployment manifest, which is essentially a YAML file with site-specific data (like the DNS name or the project/namespace-specific supplemental groups value).
- Performing: Both teams must work together to submit the deployment manifests when they are prepared for submission. The SAS project team will manage all the resources with namespace scope, while the OpenShift administrators can concentrate on resources that need elevated permissions (such as custom SCCs or CRDs). To enable this distinction, predefined selectors are included in the main deployment manifest.
In summary
We’d like to wrap up this first section of our blog with that. We hope this helped you by giving you the fundamental knowledge required to assist your project team in deploying SAS Viya on OpenShift. Kindly refer to our discussion of security and storage considerations in part 2 of this blog.
