Installing SAS Viya 4 (2021.1.2) Locally

I have been wanting to get SAS® Viya 4 running locally on our lab hardware to further investigate the REST APIs, and having just finished the installation, I thought I’d jot down a few notes.

SAS Viya 4 has initially been released for the main cloud providers: Microsoft Azure (AKS) first, and now Amazon (EKS) and Google (GKE) too. I understand that RedHat OpenShift support will be coming later this year.

I’d heard it was also possible to get it running in a local on-premise Kubernetes (K8s) environment with some prep work to get all the requirements setup (this is sometimes referred to as “bare metal” installation in K8s resources I have seen).

Whilst I could have set it up in Azure, it would have been a more expensive platform choice considering we only wanted a small installation for dev/test work, have no real users, and already have lots of spare capacity on our own private servers. Being keen on technical challenges I set aside a few days to see how far I could get. It was a great learning experience and now it’s working I wanted to outline what I used.

I created a 4 node cluster using virtual machines on a reasonably sized host server (Ubuntu 20.04 LTS KVM guests on an Ubuntu 20.04 LTS KVM host using local LVM storage):

  1. K8s Master Node (4x vCPU, 4GB RAM, 500GB local storage) used for deployment, hosting NFS and haproxy
  2. K8s Worker Node #1 (6x vCPU, 28GB RAM, 200GB local storage) for SAS non-CAS workloads
  3. K8s Worker Node #2 (6x vCPU, 28GB RAM, 200GB local storage) for SAS non-CAS workloads
  4. K8s Worker Node #3 (4x vCPU, 28GB RAM, 200GB local storage) labelled and tainted for SAS CAS workloads

This sizing was based on getting the Viya 4 ARK pre-install report happy and overcoming a few pod deployment failures, in earlier iterations, due to insufficient resources. I tried about 3 or 4 deployments before I got it working. I am hoping to reduce this sizing down in future as it will ultimately have very low usage, essentially just exercising the SAS Viya 4 REST APIs.

These are the main steps I went through to get it deployed:

Whilst it took a while to research and get all the components working together, it turned out to be easier than I initially expected. Most of the work was preparing for the SAS installation. The SAS installation part was relatively straightforward in comparison. You can understand why a cloud deployment would be the best and easier choice for most businesses.

I hope you found this post interesting, and if you’ve also installed SAS Viya 4 in-house on your own private hardware, and you have any tips or tricks to share, then please let me know by posting a comment below or contacting me directly.

5 thoughts on “Installing SAS Viya 4 (2021.1.2) Locally”

  1. Hi Paul,

    More than interesting : a real feat ! Thank you so much for sharing the details of the pre-requisites. It is great to see SAS still allows bare metal “on prem” installation for Viya 4, and that it works indeed :-).

    Cheers,
    Ronan

  2. Hi Ronan,

    Thanks for your message. It’s always a pleasure to hear from you.

    I know you already know this, but for the benefit of other readers because I did not make it clear in the post itself, I want to stress that this type of installation is not one that is covered in the SAS documentation and, whilst I don’t know for sure, I suspect may not be supported by SAS. This local installation would definitely not be a recommended approach for most SAS customers who should prefer to use one of the documented and supported cloud-based installations. For those that may require an on-premise installation I think it would be better to wait for the RedHat OpenShift support that I believe is due out later this year. I may ‘shift’ over to OpenShift at that time too (or try OKD).

    I will use this local SAS Viya installation minimally, in a different way to most SAS customers, where I will primarily develop against the REST APIs, so if there are any issues related to other aspects of the installation, due to they way I have installed it, then I may not encounter them (where others may). It is only a suitable installation for me because, as a SAS admin and software developer, I can try to support it myself but also readily discard it (without impacting anyone else) in favour of a supported cloud-based installation if I run into any insurmountable issues.

    Cheers
    Paul

  3. Hi Paul,

    Thanks for explaining your choice. I fully agree the bare metal installation might not be 100% ‘Enterprise-grade’ but it gives you the maximum of flexibility at this point. This way, you can directly exploit every layer from hardware, infrastructure up to platform and service whereas if you are provisioning Viya from a Cloud provider, then you are restricted to the PaaS offer at best, I guess. Installing you own Containers suite on top of ‘bare’ public Cloud VMs makes little sense.
    Doing it your way, that’s more comprehensive, instructive and also self-sufficient, you don’t depend upon K3s or any component version upgrade planned by the Cloud provider, for instance. You’ve cooked with the pure ‘vanilla’ flavor, not the ‘blended’ Cloud version. ;-) Open Shift or OKD once it is available looks like a good compromise, combining Enterprise-Grade and full Private cloud readiness.

    Cheers
    Ronan

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.