SAS Viya deployment Patterns – multiple CAS servers

[#1]

In a previous blog on Cloud Analytic Services (CAS) resource management, see here, we discussed multi-tenancy and using multiple CAS servers. In this post I would like to discuss some of the deployment patterns that can be used with your Viya platform.

In the following we will discuss some deployment patterns for CAS servers when sharing and dedicating resources.

Multiple CAS Servers within a Viya deployment – what is this the best approach?

With the Viya 3.4 release it became possible to have multiple CAS Servers, even with a non multi-tenancy deployment. A non multi-tenancy deployment is sometimes referred to as a single-tenant deployment, the phrase ‘single-tenant deployment’ will be used for this discussion.

In terms of the deployment process, you always start with a single CAS Server (SMP or MPP), “cas-shared-default”, but then you can add new servers where you can install additional CAS Server(s) (SMP or MPP).

Note, as of Viya 3.4 (19w34) it is only possible to configure 2 or more CAS Servers that share host machines (physical or virtual) when a multi-tenancy environment is defined. With a single-tenant deployment you can have multiple CAS Servers, but they MUST be installed on separate dedicated host machines.

So what approach is best for running multiple CAS Servers?

Multi-tenancy deployment patterns

The Viya multi-tenancy implementation was not developed with the concept of data sharing as a requirement, it was developed to provide resource isolation from one tenant to another. For example, for a service provider to host multiple organisations on a single platform.

However, it is becoming more common for organisations to use multi-tenancy to support different environments. For example, development, test and production, or production and discovery.

While having a pool of hardware that is used for the Viya deployment can help reduce IT costs, there are some considerations from a resource usage and allocation perspective. This leads to several patterns for sharing and dedicating resources to the CAS servers.

The first pattern is for shared host machines for the tenant CAS servers. This has been broken down into two sub-patterns. First let's look at Pattern 1A, sharing all the servers allocated to the CAS servers (Figure 1).

Figure 1. Multi-tenancy deployment with shared host machines for CAS (Pattern 1A).

As you can see, in this configuration, if the different CAS Servers are using the same data then it can be loaded into memory multiple times; each CAS server has its own virtual memory address space and the data is mmapped to the physical memory on each server. In this example, both Tenant A and Tenant B are using tables 1 & 2, with Tenant A using additional data depicted as Table 3.

If the processing requirements are not the same for the different tenants, you can use a mix of SMP and MPP CAS configurations across the pool of host machines. For example, you can have a configuration depicted in Pattern 1B (Figure 2).

Figure 2. Multi-tenancy deployment with a shared host for the CAS Controllers (Pattern 1B).

In Pattern 1B, the Tenant B processing requirements are not high so an SMP CAS deployment is all that is needed, in this pattern it is deployed on the same host as the Tenant A CAS controller. While this provides separation of the CAS workers, the Tenant B CAS server could affect the Tenant A CAS controller.

Therefore, in a busy system neither of these configurations provide total workload separation. Providing dedicated resources is the best approach. There are a number of patterns for dedicating resources in multi-tenancy deployments. These are illustrated below.

Figure 3 illustrates Pattern 2A, a multi-tenancy deployment with dedicated CAS works but sharing a host machine for the CAS controllers. This provides reasonable separation as the CAS workers are doing most/all of the heavy lifting.

Figure 3. Multi-tenancy deployment with CAS Worker separation (Pattern 2).

Extending this pattern further, if a secondary CAS controller is needed for availability reasons you have Pattern 2B. By collocating the primary CAS controller from one tenant with the secondary CAS controller from the other tenant you are maximizing the resources for busy systems. This is illustrated in Figure 4.

Figure 4. Multi-tenancy deployment with CAS Worker separation and shared hosts for CAS Controllers (Pattern 2B).

Finally, you can dedicate the host machines. Using this configuration provides true workload separation, with the resource allocation being controlled at the server (host) level. This is the best approach for busy systems supporting a heavy workloads. This is illustrated in Pattern 3.

Figure 5. Multi-tenancy deployment with dedicated host machines (Pattern 3).

Conclusion

There are many patterns for deploying SAS Viya 3.4 and 3.5 – especially when focusing on resource allocation for the different components. Today we have looked at a few of them for CAS server deployments.

It is important to note that any configuration using multiple CAS servers utilizing dedicated resources (host machines) will have an impact on the core-based licensing. This needs to be considered when assessing which deployment pattern to use.

Finally, if designing a multi-tenancy deployment the need for multi-tenancy should be driven by business rules. It might be better to setup user groups, folder structures and use the security rules to control the various users than implementing multi-tenancy. Don’t lose sight of the fact that each tenant is administered separately.