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):
- K8s Master Node (4x vCPU, 4GB RAM, 500GB local storage) used for deployment, hosting NFS and haproxy
- K8s Worker Node #1 (6x vCPU, 28GB RAM, 200GB local storage) for SAS non-CAS workloads
- K8s Worker Node #2 (6x vCPU, 28GB RAM, 200GB local storage) for SAS non-CAS workloads
- 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:
- Installed Docker 20.10.7 (via apt) on all nodes: https://docs.docker.com/engine/install/ubuntu/
- Installed Kubernetes 1.21.3 (via apt) on all nodes, created a cluster on the master node, and joined each worker node: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/
- Installed a Container Network Interface (CNI) using Calico: https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises
- Installed MetalLB, a software load-balancer for bare-metal deployments: https://kubernetes.github.io/ingress-nginx/deploy/baremetal/
- Installed Helm to simplify other installations: https://helm.sh/docs/intro/install/
- Installed NGINX Ingress Controller (via Helm): https://kubernetes.github.io/ingress-nginx/deploy/#using-helm
- Installed haproxy 2.0.13 (via apt) on the master node for TLS termination using private server and CA certificates (could have done this instead with nginx during SAS deployment)
- Installed and configured an NFS server on the master node (via apt) for K8s persistent volumes
- Installed nfs-subdir-external-provisioner (via Helm) to make NFS available within K8s: https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
- Configured NFS as the default K8s storage class for the cluster
- Created a dedicated namespace for the SAS viya deployment (sasviyadev)
- Installed the SAS Viya 4 Administration Resource Kit (ARK): https://github.com/sassoftware/viya4-ark
- Ran the SAS Viya 4 ARK pre-installation check until there were no remaining issues
- Installed Kustomize 3.7.0 as detailed in the SAS Viya Operations documentation
- Installed cert-manager (via Helm): https://cert-manager.io/docs/installation/kubernetes/
- Deployed the SAS Viya Deployment Operator as detailed in the SAS Viya Operations documentation
- Installed SAS Viya 4 (2021.1.2) as detailed in the SAS Viya Operations documentation
- Configured SAS Viya 4 to authenticate users, via LDAPS, against Windows 2012 R2 Active Directory, as explained in the SAS Viya Operations documentation
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.
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
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
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
You make some good points Ronan. I also saw a good SAS Communities article today that talks about the pros and cons of the various methods of deploying SAS Viya 4: All roads lead to Rome : Three Tables and one Diagram to review the SAS Viya deployment methods. Well worth a read for anyone looking to deploy SAS Viya 4.
Thanks for sharing this Paul. It will help for sure
Hi Paul,
Nice article, I also intend to deploy the same setup on my lab. Would you know the best reference for starters? The Viya 4 deployment Guide seems to be confusing for someone who is not that well versed with Kubernetes
Thanks,
Hi Lorenz,
I found the Viya 4 deployment guide was the best starting point for the requirements and then I branched off onto other sites for specifics on installing any prerequisites. Most of those are listed in the blog post. I started off with no prior Kubernetes experience but picked up what I required along the way. I think if you are going to deploy using this method then you need to be prepared for a steep Kubernetes learning curve, and be ready to start again and retry a bunch of things, but on the plus side what you learn along the way will be very beneficial ongoing ;)
I read some general Kubernetes intros and then lots of helpful SAS Communities articles posted by SAS people (and re-read some several times). I have listed a bunch on this page: https://platformadmin.com/blogs/paul/2021/07/useful-sas-viya-4-kubernetes-resources/
I hope this helps. I you run into any issues whilst deploying or have any specific questions then post them and if I can help I will do my best to expand on what I did.
Cheers
Paul
Hi Paul, this is by far the best guide I’ve seen anywhere.
Thank you so much for putting it together.
I’ve been trying to deploy SAS Viya to a cloud environment and I feel like I’ve pulled all my hair out in the process, due to getting stuck so many times, in so many different areas.
I’ve just come across this blog today and I’ll be looking to give it a go.
Thanks for the feedback. Good luck with your install.
For cloud-based installed have you seen the various SAS Institute Infrastructure-As-Code (IAC) repositories that you can also use to help get everything setup? e.g.
Another option for Azure is SAS® Viya® on Microsoft Azure Marketplace https://www.sas.com/en_us/software/viya/cloud-marketplaces.html
Hi Paul,
Out of curiosity, did you run into any such error when deploying SAS Viya?
Error from server (RequestEntityTooLarge): error when creating “deploy-sasdeployment.yaml”: Request entity too large: limit is 3145728
I’m installing the software as detailed in the guide
https://documentation.sas.com/doc/en/itopscdc/v_039/dplyml0phy0dkr/p0nid9gu3x2cvln1pzpcxa68tpom.htm
But it looks like I’ve hit the limit set by the AKS API server, which I don’t think I have permissions to change.
Anyway, please let me know if this is something you might have encountered as part of your deployment process.
Thanks a million.
Hi Tee,
I don’t believe I have encountered that error. I have only every deployed SAS Viya locally and not to AWS. I assume you have read the page Deployment Operator Custom Resource Is Too Large https://documentation.sas.com/doc/en/itopscdc/v_039/dplyml0phy0dkr/n0fftk3kycn0ftn1pjafz8kycpfw.htm and shrunk the $deploy directory down as much as possible? If that hasn’t helped then I would suggest contacting SAS Technical Support who may have some other suggestions.
Cheers
Paul
Hi Paul, thank you so much for responding, and thanks for all your help. Especially this blog post. I can’t express enough how helpful it has been.
I’m happy to report that the deployment was successful, and I am thrilled to finally see the SAS home page up and running.
I have one last, final question though
If I have a default cluster issuer set up, do you know how I might go about using this, as opposed to provided sas-viya-issuer issuer.
When I do a describe on the ingress I get this as part of the annotations
Annotations: cert-manager.io/issuer: sas-viya-issuer
Which isn’t my default cluster issuer
Thanks again for all your help and pointers.
Hi Tee,
It’s great to hear that you have your deployment working. Regarding changing the issuer, it is not something I have had to do as yet. If it is something I need to do in future I’ll try and remember to blog about it. In the meantime it’s probably best for you to post a question on communities.sas.com where you can benefit from the experience of the wider SAS admin community or ask SAS Technical Support.
Cheers
Paul