Introduction to Native OS Installers for SAS Viya

4 Likes

SAS Viya is the exciting new platform for the latest SAS technologies and solutions. It represents an entirely different approach to how SAS software will deliver the ability to execute the analysis of data. And so SAS has also taken this opportunity to rework how our software is deployed into customer environments. For SAS Viya, software deployments will rely on native OS installers which is a big move away from the SAS 9 approach of using Java-based apps as an OS-independent interface for delivering software. So let's take a look at comparing the new deployment technologies with our legacy tools.

Overview

As we know, SAS Viya is still rapidly evolving. While the overall vision is stable, new best-of-breed tools and improved practices are still being discovered and implemented. Keep that in mind when reading this post - it's meant to showcase the current state-of-the-art as we know it for the 16w38 shipevent. For example, right now SAS Viya is limited to Red Hat Enterprise Linux versions 6.7+ and 7.1+ - with CentOS as an alternative OS distribution. Beyond the 16w38 delivery timeframe, expect that support for additional operating systems, new cloud technologies, and other capabilities will be added.

This blog post assumes we're all following proven practices and methodology to provide a consistent and superior experience for your customer. This means a clear requirements gathering phase in which SAS products - SAS 9, SAS Viya, or even both - have been clearly identified. Furthermore, before the request for new software is submitted, a software architecture has been drafted which identifies which components will be deployed to which host machines. All of this information has been vetted, approved, and signed off by the appropriate parties.

So here's a simple chart showing SAS 9-era deployment tools alongside their analogues for SAS Viya:

In most cases, the functionality shown does not map perfectly 1-to-1 from one technology to another, but for purposes of this blog post, it should help with basic understanding of new concepts.

Selecting SAS software

During the requirements phase, we identified the relevant SAS products which will include SAS 9 and/or SAS Viya.

For SAS 9, software for a customer is selected with associated licenses using the MakeOrder web site. For customer orders, the SAS Contracts department performed this action. For internal-to-SAS orders for testing or other use, any SAS employee could use the site as well.

For SAS Viya, this software ordering process is essentially unchanged.

Distributing SAS software components

With the software architecture diagram in hand from the requirements gathering effort, then we can describe that distribution of software components to the installation utilities.

For SAS 9 deployments which rely on the SAS Business Intelligence platform - that is, work with the SAS Metadata Server and other middleware - there is a possibility that the SAS software components must be split up and deployed to physically separate host machines. The technique for managing this requirement is to create a plan.xml file using the SAS Planning Application. The SAS Planning Application is run as a web site with access which is limited to SAS employees, select SAS partners, and other restricted personnel. Besides the plan.xml file, the SAS Planning Application also generates documentation which describes the sequence to follow for installation, architecture diagrams showing which software components will be deployed to which host machines, and more.

For SAS Viya deployments, we won't use the SAS Planning Application's click-and-drag UI. Instead, the task of identifying which hosts receive which software is performed by editing specific plain-text files. The MakeOrder process for SAS Viya will send an email which includes a number of files and of those we're talking about two in particular:

"hosts" (and "host_local"): Identifies the host machines (and groups of hosts) in the environment. Written in INI format.
"vars.yml": Identifies which SAS Viya software components (and groups of components) are deployed to which hosts (or groups of hosts) in the environment. Written in YAML format and referred to as an Ansible playbook.

Acquiring the SAS software

Where does software come from? Do you remember the days when SAS shipped a book of DVDs to customers? Or how about the stack of 3.5" floppies before that? These days, we rely on electronic file transfer over the Internet for the majority of software delivery.

In SAS 9, after the software order is cut, the customer's SAS Site Representative receives an email with the information needed to install the SAS Download Manager software. Once the SAS Download Manager is installed and ready, it is used to create a SAS Software Depot in the local environment and all of the many gigabytes of SAS software components are downloaded from SAS.com and placed in it. The SAS Software Depot then acts as a central repository for that customer to use for installing most SAS products in their environment.

For a SAS Viya order, an email is also sent to the customer's SAS Site Representative. The information included in the email includes several attachments. They include the playbook files for running Ansible as well as the SAS Viya order license. The email also includes a couple of ".pem" files which provide digital X.509 certificates and keys which are necessary for accessing the SAS Viya package repositories. Now for SAS Viya, we don't require customers to download a copy of something like the SAS 9 Software Depot. Instead, the package manager (for RHEL, that's yum) can be configured to recognize the remote SAS Viya repository hosted somewhere in SAS.com as a direct installation source. Ansible will automatically handle this task for us (as described in the SAS Viya 3.1 Deployment Guide) - but if you want to see what steps are involved, Red Hat provides some general instructions for managing repositories. This approach simplifies a typical SAS Viya deployment as compared to SAS 9 because it eliminates making a staging copy of the SAS Viya software source when it's not really needed.

On the other hand, it's common to find that many servers at a customer site might be sequestered so that they do not have direct-to-Internet connections. If they cannot see the Internet, then they cannot directly use the SAS Viya repositories hosted at SAS.com. We refer to these as "dark sites". That's okay as it's fairly routine aspect of the job which many system administrators deal with. What we can do then is make a mirror of the SAS Viya repository on a host machine in the customer environment which does have direct-to-Internet access and then point those machines without Internet access to the mirror.

Deploy the SAS software

Once we have a central location of software components available, then we're ready to actually install and configure the software for the end-users.

Deploying SAS 9 software is a two-phase task. The first phase installs the software - essentially creating directories and then copying executable files, shared libraries, and many other items to disk - and looks pretty much identical site to site. The second phase configures the software - creating files with attributes of the environment, databases with key parameters, and much more - which directs the software to work in a way unique to this site. We use the SAS Deployment Wizard to run the tasks of both phases - and it does so after asking you to answer dozens and dozens of questions.

We also need to perform installation and configuration phases for SAS Viya software. However, instead of the SAS 9 Deployment Wizard, we use a third-party product (open-source, freely available) called Ansible. Remember the "hosts" inventory file and the "vars.yml" configuration files we identified earlier? Ansible uses those files to perform the software deployment. For the installation phase, Ansible relies on the standard OS package management utilities (like yum and RPM for RHEL). Ansible also directs the configuration phase of the deployment of SAS Viya as well. If you're not yet familiar with the concept of idempotence, then read about it here - it's a powerful approach to administering a software system.

Relying on industry standardized tools

For most of SAS' history we've rolled our own in-house developed solutions to software challenges. In some ways this has served us well and allowed us to differentiate our software offerings in the market. However, one of the founding tenets of the SAS Viya platform is a commitment to standardized and open software which will allow us to focus on making SAS do what it does best - as well as give our customers confidence that they're working with familiar tools and processes, vetted for security and stability.

--

Rob Collum is a Principal Technical Architect with the Global Architecture & Technology Enablement team in SAS Consulting. When he's not installing software for the umpteenth time, he enjoys sampling coffee and m&m’s from SAS campuses around the world.