A couple of challenges for SAS Viya in AWS today
As continuous improvement and continuous delivery (CI/CD) marches ever onward, it can be challenging to keep up. And such is the case with changes that Amazon has made recently for their Elastic Kubernetes Service (EKS). They're not a major problem right now, however, not knowing about these changes could lead to some churn as you try to figure out what's wrong, what's right, what's supported, and what's not. Let's talk about what's happening and what it means for SAS Viya now and in the future.
As of August 2022, Amazon Web Services (AWS) has made some improvements that affect a couple of major components of its EKS offering that SAS Viya relies on. In particular, if you rely on the viya4-iac-aws project to provision your infrastructure in AWS, then read on.
EKS v1.23 requires the EBS CSI Driver
Amazon announced that its Elastic Kubernetes Service now supports Kubernetes 1.23. One significant change is that Amazon is now using the CSI (Container Storage Interface) technology to replace the old approach using the in-tree driver mechanism for accessing EBS (Elastic Block Storage) volumes. In short, Amazon now requires that the EBS CSI Driver must be installed if you want to use EBS in your EKS 1.23 cluster.
Impact to SAS Viya
As of this writing, if you currently attempt to deploy SAS Viya into an EKS 1.23 cluster with infrastructure provisioned by the IaC project, then you'll find that the services won't be able to start up completely. After investigating what the hang up is, you'll eventually see that the sas-crunchy-data-postgres-backrest-shared-repo pod is unable to schedule to a host node because the PVC (persistent volume claim) it's using references the "gp2" storage class which is defined to use EBS storage. Without the EBS CSI driver, the "gp2" storage class as it's currently defined won't work.
If Postgres isn't running properly, then many of the core SAS Viya infrastructure services will never run either. This same problem is encountered by any other services trying to use the "gp2" storage class as well. The IaC team is aware of this problem and working towards resolution soon.
Short-term workarounds for SAS Viya
The simplest workaround is to avoid using EKS 1.23 for now. Instead deploy SAS Viya to EKS 1.22.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
As you can see, AWS expects to support EKS 1.22 until May 2023, so there's plenty of time yet to work out a migration to using the EBS CSI Driver.
Expected long-term fix for SAS Viya
In order for SAS Viya (and other Kubernetes-based services which rely on EBS storage) to work in EKS 1.23, then the EBS CSI Driver must be installed. The IaC team is working on implementing this through the use of Terraform and so keep an eye on the viya4-iac-aws project for support of EKS 1.23 soon. Amazon also provides instructions for implementing the EBS CSI Driver as well as a migration plan for existing deployments to upgrade.
AWS is retiring the Classic Load Balancer (eventually?)
This month, August 2022, AWS announced that it has retired the EC2-Classic Networking. One of the steps that Amazon recommends is that the Classic Load Balancer (CLB) must be migrated from EC2-Classic Networking to VPC Networking.
So the IaC project currently provisions a CLB in the infrastructure for SAS Viya into a VPC network already. Customers who are aware of Amazon's plans to retire EC2-Classic Networking therefore are asking about the perception that the CLB is retiring as well and what that means for SAS Viya. But as Amazon explains, the CLB is still supported (i.e. not retired) in VPC networking.
Even so, the writing's on the wall, right? So while there's no urgent need to avoid the CLB right now, the IaC team is already looking into provisioning either a Network Load Balancer and/or Application Load Balancer for SAS Viya use instead.
Impact to SAS Viya
Currently, there's no technical impact to SAS Viya. However, customers will raise valid questions and they'll need some education as well as assurances that SAS has appropriate plans. While the IaC team is working on implementing more modern load balancers for SAS Viya in AWS, it's important that we can adequately explain the current situation (CLB are still supported, not retired).
Short-term workarounds for SAS Viya
Allow the IaC project to continue provisioning the Classic Load Balancer because it's still supported in VPC networking.
Expected long-term fix for SAS Viya
Referring to the OSI (open systems interconnection) model, the Classic Load Balancer can operate as either a Level 4 Transport or Level 7 Application load balancer.
For SAS Viya, we only use the CLB as a Level 4 Transport load balancer - and as such it can be setup in support of the NGINX Ingress Controller (which interestingly enough operates at Level 7 Application level) as well as for the binary port (:5570) that can be optionally configured for direct programmatic access to the CAS Controller.
Looking beyond the CLB, we can elect to use the AWS Network Load Balancer (NLB) which provides Level 4 Transport service instead to meet the same needs.
The AWS Application Load Balancer (ALB) provides Level 7 Application service and theoretically could be used to replace the NGINX (or other brands) Ingress Controller - except that it currently is limited to up to 100 service endpoints and SAS Viya requires many more than that. It's unlikely that SAS Viya will need to rely on ALB in the near future.
Coda
SAS Viya is engineered to be flexible in support of a variety of cloud environments and deployment options. Even so, ongoing improvements in the technology stack of our partners, vendors, and open-source projects can still lead to challenges which need addressing. The updates to Amazon Web Services covered here provide improved operation and service. SAS Viya will soon handle these improvements as well.
Find more articles from SAS Global Enablement and Learning here.
