Changing the default storage for SAS Viya

1 Like

In this post we will look at changing the default storage for the SAS Viya platform. By default, several of the SAS Viya services make use of the default storage class in Kubernetes. In most cases this will be fine.

Also, having the Viya manifest refer to, or use, the default storage class is good when considering that the default SAS Viya platform configuration should be able to run on any Kubernetes cluster.

But what happens if you need to change this?

Let’s take a look at this.

When running in the Cloud, typically the default storage class for the managed Kubernetes platform will not be the most performant option. For example, in Azure, the AKS platform uses Standard SSD storage, which is better than using HDD storage, but it is not as fast as the premium storage options.

The following table is from the Microsoft Azure documentation. It provides a comparison of the disk types.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

While the Kubernetes documentation describes how to change the default storage class, see here. It is important to understand that in some cases this might not be possible, and/or not desirable to change.

For example, perhaps SAS Viya is running in a shared Kubernetes cluster, with other business applications. In this case, you most likely wouldn’t want to change the default storage class, as this might affect other applications. There could be unintended consequences when deploying new applications and/or redeploying existing applications.

There may also be restrictions in a Cloud managed platform. For example, the Azure documentation notes the following: “AKS reconciles the default storage classes and will overwrite any changes you make to those storage classes.”

In AWS, with EKS 1.30, the default storage class is not set. See this post by Rob Collum: Amazon EKS 1.30 no longer assigns a default storage class

Using Azure as an example, let’s take a look at changing the SAS Viya deployment.

Running in Azure

When you create the Azure Kubernetes Service (AKS) cluster, several storage classes are set up by default. This is shown in the image below.

Figure 1: AKS Storage Classes

In the image, all the storage classes using the provisioners ‘file.csi.azure.com’ and ‘disk.csi.azure.com’ were created when the AKS cluster was created. You can also see the ‘sas-nfs’ storage class, which is exposing the NFS Server storage for my SAS Viya platform.

When I deployed the SAS Viya platform (using the “Deployment using Kubernetes Commands” method), you get the following default PVC bindings.

Here you can see the PVCs that are using the default storage class. You can see that all the Stateful services are using the default storage class by default. Also, the internal Postgres server is using the default storage class.

Note, when using the Deployment as Code (DaC) Git project you will get different PVC bindings.

Let’s say I want to use better storage for Postgres and the Stateful services, say for RabbitMQ and Redis. I wanted to use one of the Premium storage options. Here I have two options:

Use one of the existing storage classes, or
Create a new storage class.

For example, in Azure, to make use Premium V2 storage, you need to create a new storage class. The following is a sample definition, to create a storage class called ‘premium-v2-disk’.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: premium-v2-disk
provisioner: disk.csi.azure.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
  cachingMode: None
  skuName: PremiumV2_LRS
  DiskIOPSReadWrite: "4000"
  DiskMBpsReadWrite: "1000"

Reference: Enable Premium SSD v2 Disk support on Azure Kubernetes Service (AKS) - Azure Kubernetes Service

In the above yaml, you can see the SKU being used is PremiumV2_LRS, and it is using the Azure CSI disk provisioner (disk.csi.azure.com).

Once you have created the new storage class, it can be referenced in the SAS Viya configuration. For my testing, I updated the storage for Postgres and the core stateful services (Consul, RabbitMQ and Redis).

To make the change to Crunchy Postgres there is an example patch transformer in ../sas-bases/examples/crunchydata/storage/, called crunchy-storage-transformer.yaml

I updated the patch transformer to make use of my new (premium-v2-disk) storage class. You would make a change like this to improve Postgres performance.

This is the most likely change you would make. But to demonstrate the ability to update the storage for Consul, RabbitMQ and Redis, you might also change the storage class being used to reference better storage. Using this Azure example, I wanted to use the managed-premium storage class. This storage class is shown in Figure 1 above.

As an aside, the ‘managed-premium’ storage class is specified in the configuration for the SingleStore cluster with a SAS SpeedyStore deployment.

Coming back to configuring the stateful services. Under the sas-bases/examples/rabbitmq/configuration folder, there is a patch transformer provided called: rabbitmq-modify-pvc-size.yaml

Using this patch transformer you can also set the storage class to be used. Here is my configuration.

---
apiVersion: builtin
kind: PatchTransformer
metadata:
  name: rabbitmq-modify-pvc-size
patch: |-
    - op: replace
      path: /spec/volumeClaimTemplates/0/spec/resources/requests/storage
      value:
        2Gi  # This is the default
    - op: add
      path: /spec/volumeClaimTemplates/0/spec/storageClassName
      value:
        managed-premium
target:
  group: apps
  kind: StatefulSet
  name: sas-rabbitmq-server
  version: v1

Note, as I didn’t really want to change the storage request, I could have removed the “- op: replace” section shown above.

Turning my attention to the Consul and Redis configuration. At the time of originally writing this post there wasn't any Redis examples provided for this configuration in sas-bases. So, some investigation or “detective” work is required. However, with SAS Viya 2025.06 (June 2025) there are now example patch transformers to modify the PersistentVolumeClaim size or the StorageClass for the Redis nodes.

Always start by looking at the provided examples, look for any existing patch transformers in the 'sas-bases/examples'. This will provide an example of how to target the required StatefulSet.

In this case, there isn’t an existing patch transformer. So, the next place to look is in the sas-bases/base/components. Looking at the definitions for the component (in this case, Consul and Redis), you can get (or work out) the path to target. This is where having (seeing) the RabbitMQ example patch also helped out.

As the current definition for Consul and Redis don’t specify a storage class, the patch needs to add this definition. For example:

---
apiVersion: builtin
kind: PatchTransformer
metadata:
  name: update-redis-volume
patch: |-
  - op: add
    path: /spec/volumeClaimTemplates/0/spec/storageClassName
    value:
      managed-premium
target:
  group: apps
  kind: StatefulSet
  name: sas-redis-server
  version: v1

I also created a patch transformer to update Consul (sas-consul-server) as the target StatefulSet. It is essentially the same as the Redis patch above.

The results…

After updating the SAS Viya configuration. The new patch transformers need to be referenced in the kustomization.yaml. Then the site.yaml needs to be built and applied.

Looking at the PVCs, you can now see that the new storage class is being used for Crunchy, and Consul, RabbitMQ and Redis are all now using the ‘managed-premium’ storage class.

04_MG_202506_04_updated_pvc_bindings-with-comments-1024x309.png

If you look carefully at the image, you can see that I didn’t update all the Crunchy configuration to use the new storage class. The sas-crunchy-platform-postgres-repo1 PVC is still using the default storage class. This is the pgBackRest PVC, which is used for backup and recovery. Also, the data-sas-opendistro-default-0 PVC is using the default storage class.

Conclusion

One of the nice things about SAS Viya is that making this type of configuration change for a new deployment is relatively easy. Here you have seen how to update the storage class being used for some of the stateful services.

There are limitations with all storage types, some of which are shown in the table above from the Microsoft documentation. One thing to note with the Premium SSD V2 disk, is that, at the time of writing this post, there isn’t the option to use Zone-Redundant Storage (ZRS).

The Microsoft documentation states the following “ZRS for managed disks is only supported with Premium SSD and Standard SSD managed disks”.

In this post, the example deployment was using SAS Viya 2025.03.

Thanks for reading and I hope this is helpful.

Find more articles from SAS Global Enablement and Learning here.

touwen_k

@MichaelGoddard thank you for this clear article which I have read with pleasure. Now I know what core stateful set is of SAS Viya. Not only the cas nodes but also this determines the speed of Viya. When changing the storage class, is it also needed to investigate the size of redis? We have adjusted sas-work and cas disk cache to bigger sizes, but not the core services.

MichaelGoddard

@touwen_k I'm pleased you enjoyed the post. As far as Redis goes the SAS Viya platform only makes use of a subset of the Redis functions, the usage is limited to a temporary cache. I have not seen any examples or guidance of when you would need to change the default values. The best approach would be to start with the defaults and monitor usage.