Referential Architecture and Deployment Issues for SAS Viya on OpenShift
Here in this blog, we will learn about referential architecture and deployment Issues for SAS Viya on OpenShift.
SAS has provided a fully containerized analytic platform built on a cloud-native architecture since the release of SAS Viya in 2020. SAS Viya utilizes Kubernetes as the underlying runtime environment due to the platform’s scale and fully benefits from its native features.
Numerous Kubernetes distributions are supported by SAS in both private and public clouds. In fact, a lot of SAS customers prefer to run their application infrastructure in a private cloud environment, partly because of specific use cases that prohibit doing otherwise from a regulatory standpoint and partly because of strategic considerations.
In these situations, OpenShift offers the SAS software stack a strong base. With many highly valued enterprise features, OpenShift offers a hardened version of Kubernetes as an execution platform. It also includes a large ecosystem that supports DevSecOps capabilities.
For over ten years, Red Hat and SAS have had a fruitful collaboration. Although in previous SAS releases, Red Hat Enterprise Linux was the recommended operating system, SAS currently builds its container images around the Red Hat Universal Base Image.
Additionally, SAS integrates with OpenShift’s security approach, which is based on SCCs (Security Context Constraints), as part of their deployments and leverages the OpenShift Ingress Operator, the cert-utils operator, and OpenShift GitOps for deployment (optionally).
SAS Viya’s reference architecture for OpenShift
SAS Viya is a comprehensive platform that encompasses all phases of analytics and artificial intelligence (AI) development. As a result, it is an integrated suite of applications rather than just one. The type of workload SAS Viya contributes to the OpenShift platform is one of the key distinctions here. This influences the requirements for resources (CPU, memory, and storage) and brings with it unique security-specific needs.
Viya now has unprecedented scalability thanks to the migration from SAS to OpenShift, which wasn’t possible with earlier SAS releases. By dividing Viya into various workload categories and advising assigning each workload to a class of nodes, or machine pools, SAS makes use of the scalability of the system. This guarantees that the right resources for particular workloads are available. Figure 1 illustrates how workloads are divided among pools.
Keep in mind that setting up pools is optional, and if the current cluster infrastructure isn’t ready for this kind of split, there may be good reason to disregard the advice. There are many advantages to applying a workload placement strategy using node pools. For example, you can customize the cluster topology to meet workload requirements by selecting different hardware configurations (nodes with GPU cards, extra storage, etc.). Using predefined Kubernetes node labels and node taints will enable the placement of SAS workload classes.
See part 2 of this blog post for a thorough explanation of machine management on OpenShift. It explains how OpenShift’s unique features can make machine management easier and more automated.
Cloud Analytic Services (CAS) SAS Node Pool
Cloud Analytics Services (CAS) is SAS Viya’s central component. This analytics engine is stored in memory. Clients connect to CAS to perform analytical operations on the data after it has been loaded into certain in-memory tables from the necessary data source. It is possible to flush the data that was loaded into memory for CAS to disk. Because it requires persistent storage that is accessible by all nodes hosting CAS pods and is CPU- and memory-intensive, the CAS server typically has the highest resource requirements of all SAS Viya components.
There are two ways that CAS can be set up: as a distributed server in MPP (Massive Parallel Processing) mode or as a single instance server in SMP (Symmetric Multi-Processing) mode. When using MPP mode, multiple CAS pods are used, with one pod serving as a controller and the other pods performing computations. There is just one CAS pod deployed in SMP mode.
When using a CAS node pool by default, each CAS pod operates on a different worker node and immediately consumes over 90% of the CPU and memory resources that are available. Transformer patches installed during deployment restrict CAS’s resource consumption to the desired level or permit CAS to coexist with other workloads on the same node in the event that there isn’t a node pool available for it.
SAS Node Pool for Compute Services
The classic SAS processing powers that were employed in all earlier SAS releases are represented by SAS Compute services. A SAS session can be launched interactively from a web application or in batch mode to carry out user-submitted tasks as a Kubernetes job SAS code for data transformation or analysis. This method makes SAS sessions very parallelizable. The only restriction on the quantity of concurrently operating sessions, or Kubernetes jobs, is the hardware capacity.
If at all possible, the compute node pool should be utilized with the cluster auto scaler. Customers would frequently directly benefit from this by using it to intercept typical usage patterns, such as scaling in over the weekend or out for nightly batch workloads. For more information specific to OpenShift, please see the Autoscaling section in part 2 of this blog.
SAS Web Applications and Microservices (STATELESS NODE POOL)
The majority of services in a SAS Viya deployment are created as 12-factor apps or microservices. They are in charge of offering central services including authentication and auditing. Moreover, a collection of stateless web applications—such as SAS Visual Analytics, SAS Model Manager, and SAS Data Explorer—that are user interfaces accessible to end users are grouped together with these services.
Services for Infrastructure (STATEFUL NODE POOL)
The storage and metadata management services are essentially commodity services. They are built using a number of open-source technologies, including RabbitMQ and Consul for messaging, as well as the internal SAS Postgres database. This is the location of the vital operational data. Because of their high I/O requirements, these services do need persistent storage.