With the July version of SAS Viya (stable 2024.07), a nice change has been made in the section of the SAS Viya Operations guide that covers the customizations of a deployment.
Before this version, the "Common Customizations" page just provided a long list of all the customizations (outside of product-specific customizations) that should be considered for a deployment.
But now this "Common Customizations" content has been divided in two parts :
Required customizations
Optional customizations
While many customizations are optional, a few of them should be decided in advance (and they sometimes can’t be made without specific pre-requisites in place).
This documentation change helps to identify some of the key decisions that MUST be made (in a way that corresponds to the customer needs or requirements) before starting any new Viya deployment.
So, I thought it would be great opportunity to revisit and discuss these architecture decisions and deployment pre-requisites through the review of these six "Required customizations" and explain why they would form the basis of a Viya environment Architecture design document.
As we often say during our GEL workshops:
"The deployment of SAS Viya by itself is usually a matter of hours (or even minutes). However, the discussions, decisions and preparation leading to that moment can take days or even weeks..."
TLS Mode
Host and port for Cluster Ingress
CAS topology and workload strategy
Internal or external PostgreSQL?
Internal or external OpenSearch?
StorageClass to use for RWX PVC ?
"Recap" table
Note: In this post we don't explain HOW these customizations are implemented as it is already nicely explained in our documentation or in the README files.
TLS mode ?
TLS (Transport Layer Security) allows to encrypt data in motion and is used in the SAS Viya platform to secure communications with internal and external components.
3 options are possible : "Full stack TLS", "Front door TLS", or "no TLS".
By default (using the kustomization.yaml example file provided in the documentation), your Viya environment will be automatically configured with "Full stack TLS". It means that all the microservices and web applications implement HTTPS in their communications. In this mode, all network connections from outside and even inside the Viya environment are secured.
With "Front door TLS", only the components that are intended to accept connections from outside the Kubernetes cluster (such as the Ingress controller and CAS server) are configured to only accept encrypted network connections.
In both cases, the customer can use the default certificate issuer (openSSL) or use another certificate issuer (cert-manager). The customer can also provide their own certificates if they prefer to secure the ingress.
The customer should always be advised to use TLS to secure the network traffic ("No TLS" should never be used as the traffic would be in clear text and easily intercepted by anyone). However, most of the time, customers are very sensitive about security and opt for the "Full stack TLS option".
Reference :
SAS Doc : https://go.documentation.sas.com/doc/en/itopscdc/default/itopssr/n18dxcft030ccfn1ws2mujww1fav.htm#n0w1os9ufnn7xwn1an3qbhxjxze9
Host and port for Cluster Ingress
As part of the deployment, you need to provide a small set of parameter’s values in your initial kustomization.yaml file.
In the officially documented example, they are represented as place holders under this form: {{ PLACE_HOLDER }}.
One of them is the {{ NAME-OF-INGRESS-HOST }}
How can you find this value ?
I wrote a couple of posts (part 1 and 2) to answer this question, here is an extract :
{{ NAME_OF_INGRESS_HOST }} corresponds to the URL base that the customer wants to expose to the SAS applications users. The {{ PORT }} parameter is optional, as the HTTP schema is usually determined by the start of the url (“http” or “https”).
However, the important thing to understand here is that {{ NAME_OF_INGRESS_HOST }} also correspond to a DNS name that must be associated to the external IP address exposed by the Ingress controller.
When you install the Ingress controller in a Cloud environment, an external IP address is automatically provisioned by the Cloud provider (You can see this address in the EXTERNAL-IP column when you describe the ingress controller service).
A DNS name then needs to be mapped to the ingress public IP by the site’s IT team configuring their DNS services. The exact components of the FQDN will likely be shaped by the site’s DNS standards, for example: https://viya.your_dept.your_site.com/ and Viya accommodates that.
But there must be a DNS entry associated with this IP address. It is a key pre-requisites that should not be overlooked during the deployment planning process.
CAS topology and workload strategy
As the main analytics and data management engine of the SAS Viya platform, CAS is a cornerstone of the environment. A CAS Server is required at the start-up time of Viya : it is a pre-requisite to have at least one CAS Server defined otherwise the Viya platform will not work for any user (whether the users plan on using CAS or not).
Some choices must be made at a minimum for the CAS topology and the CAS workload strategy.
While, by default (using the kustomization.yaml example file provided in the documentation) the CAS server consists of a Single-node (SMP : for Symmetric Multi-Processing), it is possible to opt for a Multi-node CAS server (MPP: for Massively Parallel Processing) to spread the Analytics processing and data across multiple CAS nodes.
This choice is mostly driven by the amount of data to process (remember that with CAS, the data are loaded into memory to be processed by CAS, and a single machine may not have enough RAM to hold them) and an official sizing is a key input in this decision.
Note that more sophisticated CAS topologies are also possible such as:
Adding a secondary CAS controller into a CAS MPP deployment (to improve the CAS Server availability)
Adding new CAS server(s), for example to isolate and specialize the different kind of workloads (ex: 1 CAS server for the reports, 1 other for the Visual forecasting, etc…)
Now, regarding the CAS workload strategies, several options are also possible. The SAS general recommendation is to choose the default "auto-resourcing" configuration. This approach ensures that each CAS instance (Controllers and workers) is running on a dedicated host and can leverage all its capacity (in a similar way as with a Viya 3.x deployment). While this is ideal for maximum performance, it might be overkill for dev/test environments.
Note that options are also available to have a differentiated workload classes for the CAS controller(s) and the workers. The goal is to optimize the costs by using distinct node pools and smaller machines for the CAS controller(s) that usually don’t require as much CPU and memory as the workers.
The CAS topology and workload management topics are a key part of the Architecture design and should be discussed with your site’s IT team to make sure the associated decisions meets your site’s needs and constraints.
Another exciting benefit of running Viya 4 as containerized workloads in a Kubernetes cluster on virtualized hardware is that changing your deployment topology can be effected simply by submitting configuration changes programmatically. This should give your site’s administrators confidence to try new workload configurations in pursuit of best performance, efficiency, and cost.
If these concepts are not clear to you, the SAS Viya Architecture course has dedicated modules to cover them.
References :
CAS Server Topology Changes And CAS Table Balancing: https://communities.sas.com/t5/SAS-Communities-Library/CAS-Server-Topology-Changes-And-CAS-Table-Balancing/ta-p/903549
Internal or external PostgreSQL?
The SAS Viya platform relies on an instance of PostgreSQL for its SAS Infrastructure Data Server. This instance can be either internal or external.
By default, SAS Viya is installed with the internal PostgreSQL instance that relies on Crunchy data server which is shipped with the SAS order. But the SAS Viya platform can also be configured to use an external instance of PostgreSQL such as the Azure PostgreSQL Flexible Server.
This post, from my colleague Edoardo Riva, lists some of the considerations associated to the choice of an internal versus external instance.
It is worth noting that many SAS Solutions also require an additional PostgreSQL server instance for the Common Data Store (aka CDS), which requires its own PostgreSQL instance. When deploying a SAS Solution, the location of the Common Data Store instance (internal or external) - as well as any additional potential instances, for Airflow for example - must also be discussed and addressed.
Internal or external OpenSearch?
The SAS Viya platform also relies on an instance of OpenSearch to create and store search indices (for example for the SAS Information Catalog and Visual Investigator).
Starting with 2023.03 it is possible to use an external instance of OpenSearch.
Once again, you can find a nice post from Edoardo, comparing the use of an internal versus an external instance of OpenSearch.
The decision between : letting the SAS Viya deployment install and manage OpenSearch (default) versus using an existing external instance, must be made before the deployment.
StorageClass to use for RWX PVC ?
The last item of the "Required customizations" covers another key decision : which kind of storage to use for the Viya component that requires a ReadWriteMany (aka RWX) storage class.
As a reminder, the RWX storage type can be seen as the equivalent of a shared file system in the bare OS world. It corresponds to a kind of storage that supports concurrent access by multiple pods running on different nodes.
Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.
Since the SAS Viya PersistentVolumeClaims don’t specify a StorageClassName, the default storage class specified by your Kubernetes configuration is used.
This
is convenient because most of the Managed Kubernetes platforms that we support in the Cloud come with a default storage class. On the other hand, it’s not often the ideal choice because the usual default storage class is backed up by managed disks, which has only RWO access(standard-rwo in GCP, managed-csi in Azure, etc..).
While many of the SAS Viya platform volumes only need storage with RWO access, some of them require RWX storage…As a consequence, if you don’t do anything regarding the storage class when deploying for example in AKS, GKE or EKS, your deployment will fail.
So, for them we need to provide an alternative RWX storage class and make the associated configuration changes, as in the example below :
See how the annotationSelector is used to target the PVC that requires this RWX access.
So, the associated architecture decision is: "What storage class should I use for the Viya components that require RWX access ?"
Several options are possible, they depends on the Kubernetes platform. You can have a look at this table from the Kubernetes documentation to get a first list of RWX compatible volumes plug-ins, but options mostly depends on the Cloud provider.
Note that if you are using the viya4-iac-x (IaC) or viya4-deployment (aka DaC) tools, you don’t have to tweak the Kustomize Transformer files : the DaC automatically configures a new RWX storage class and make it the default. In this case, the new storage class is backed up by an NFS Client provisioner pointing to either a Cloud Managed File services (such as Azure NetApp, GCP File store or EFS in AWS) or to an NFS server running on a Cloud VM (depending on your IaC storage choice).
The available DaC options may correspond to the customer’s needs and requirements. Otherwise, it is required to identify a RWX storage class and make the configuration changes so it is used for the Viya volumes that requires it. Note that you can also use distinct RWO and RWX storage classes for the different volumes required by the Viya platform.
Other key decisions
Finally, it is important to remember that there several key decisions that are NOT reflected by a specific requirement listed in the new "Required Customization" section.
Some of them (Kubernetes platform, dedicated or shared cluster, etc…) are critical and early to decide, with downstream implications on the other aspects of the architecture and deployment (networking, storage, etc…).
While it is probably not an exhaustive list, the decisions listed below correspond to the customer’s specific requirements or constraints and must also be made during the design phase (before the deployment) :
Kubernetes Platform ? AKS? GKE? EKS ? OpenShift ? other ?
Dedicated or shared Kubernetes cluster ?
Cadence (LTS or stable) ?
Storage : used for the Viya platform components and for things like input/output data, user’s home directory, etc…as an example, for production environments, block storage (instead of NFS based storage) is strongly recommended for specific SAS Viya components (OpenSearch, Redis and RabbitMQ) volumes !
Network : kubelet or CNI ? (Note that the question is not relevant for deployment of SAS Viya on Upstream Opensource Kubernetes cluster, where only the Calico CNI is supported.)
Identity provider and authentication mechanism : various options are available for the integration with the Identity provider (LDAP or SCIM) and for the authentication.
We have added this decisions into our recap table below.
Recap and advice
The table below lists the key decisions that should be made before performing the initial deployment with their default value, pre-requisites and discuss whether they could be changed after the initial deployment.
Decision
Default value
Pre-requisites
Can be changed after the initial deployment?
TLS mode
“Full-stack” TLS
Custom certificates (in .pem format) and the associated private key must be provided if the customer wants to use their own certificates for the ingress (instead of the default ones).
Yes. The TLS mode can be changed afterwards, however it is recommended to agree on a TLS mode before the deployment to avoid any outage.
Ingress host name and DNS
None
The customer needs to associate a DNS name to the Ingress controller service external IP , available
Yes. However if the INGRESS_HOST is wrong, nobody will be able to login to the deployed environment from the outside.
CAS Topology and Resource Management strategy
SMP, CAS-autoresourcing
None
Yes. The topology and workload placement strategy can be changed but it will impact the deployment and users (outage and need to reload the data).
Internal or External PostgreSQL instance(s)?
Internal
None with the internal instance. For external: extensions, number of connection, pre-created SharedServices database, etc…see this page
Yes but only in one way. SAS has created the PostgreSQL Data Transfer Tool for the SAS Viya Platform to move content from the internal instance of PostgreSQL to an external instance. But it is not possible to change from external to internal.
Internal or External OpenSearch instance?
Internal
No. Be careful, after the deployment has completed, you cannot modify your deployment to use a different OpenSearch instance.
RWX Storage class to use for the SAS Viya Persistent Volumes ?
There is usually no default RWX storage class available in the cluster. But the IaC tool for opensource Kubernetes and the DaC tool creates one for the SAS Viya volumes.
A RWX storage class must be made available otherwise the deployment will fail.
Maybe but not easily…while some volumes can be rebuilt from scratch, other may hold user’s data that needs to be migrated to new storage devices.
Kubernetes platform ?
None
A supported Kubernetes platform should me made available with cluster-wide privileges
No. If the Kubernetes platform is changed, SAS Viya must be redeployed (however a full-system migration could be done from one Cloud provider to another).
Dedicated or shared Kubernetes cluster ?
NA
When multiple Viya versions are sharing the same cluster, there are some caveats to be aware of. Keeping all the Viya environments at the same version is strongly recommended.
See above.
LTS or stable cadence ?
None
To remain fully supported an update of the version N of SAS Viya must be made before the version N+4 is released. It means that customers on the stable cadence must update their Viya at least version every 3 to 4 months to avoid to be in limited support.
Yes it is possible to change the cadence (under certain conditions).
Storage strategy for the platform data and the user’s data
NA
Storage classes or PV types to use for the Viya platform volumes as well as input/output data must be made available
Possible but requires tests, backup, outage and migration of the content.
Network type ? kubelet ? CNI
As of today, kubenet is usually the default for Managed Kubernetes Services in the cloud.
In some cases (SAS with SingleStore, deployment with open-source Kubernetes) a CNI plugin is required. So always check the latest documentation version for requirements.
Changing from one CNI implementation to another may be possible depending on the Cloud provider but requires tests, backup, outage and migration of the content. Refer to the specific cloud provider’s documentation.
Identity provider and authentication mechanism
NA
The requirements depends on the type of identity provider and authentication, see the official documentation
The identity provider cannot be changed for an “in-use” system. authentication mechanism can be changed in some cases but could require an outage and rebuild and re-apply the deployment manifests
My final advice would be to make sure that you have captured at minima the architecture decisions listed in this table (and prepared the associated pre-requisites) before starting your SAS Viya deployment process.
Also keep in mind that some post-deployment tasks are usually required as well before users can start to access the SAS Viya applications. They also depend on the offering and products that are deployed. See this page in the official documentation for a list of post-deployment steps.
Hope that helped ! Thanks for reading 😊
Find more articles from SAS Global Enablement and Learning here.
... View more