With the recent release of Viya 3.3, it is to be expected that many more existing SAS customers will get to embrace this exciting new platform. It’s also likely that fresh new customers will get to meet SAS through Viya alone. However, these greenfield customers will have one less choice to make, and so they are not the focus of my writing today.
Instead, I want to talk today about customers who have an existing SAS 9.X environment, who are now adding SAS Viya to their Analytics footprint. Therefore, if you are such a customer, or if you are one of the people likely to advise them, this post is written with you in mind.
If you are in the situation I describe, the one big question on your mind is likely to be:
Should I run Viya on dedicated server(s), or should I run it on the same server(s) as my SAS 9.X environment?
The question is applicable whether the servers involved are physical machines or virtual machines. For example, even if you have 2 VMs running on a single vSphere host, I will consider this to be 2 distinct and dedicated servers.
The short of it
If you trust in the advice of this technical architect and don’t care about the details, then it’s going to be a short read for you:
Overall, it will be better if you get new and dedicated hardware for the Viya environment.
Simple, eh?
The rationale of it
Of course I’m not going to make such a claim without justifying it.
The above is my advice, and it’s based on my experience and my familiarity with SAS 9.X, Viya, customer interactions, and feedback from my colleagues who implement SAS Solutions at customers.
The rest of this post will go through the various considerations you should have in mind when making this decision. Either you will find my justifications obvious, or you might disagree and decide to not follow my advice, but at least you will have been informed of the potential pitfalls of not doing so.
Advantages of shared servers
– Cost
It will come as absolutely no surprise to anyone that servers cost money. However, for the sake of completeness, I have to mention that NOT having to buy a new server, or NOT having to stand up a new Virtual Machine, or a new Cloud Instance will effectively save money. Duh.
– Early start
So this one will not be surprising either, but even if a customer is willing to invest in new hardware, it can take time for this hardware to be ready. Although Cloud and Virtualization can speed up the process of obtaining fresh new servers, there are also a lot of customers who prefer physical machines (often for performance reasons). This may take a certain amount of time to be ready. But, obviously, it is true that nothing would be ready faster than something that is already up and running. 🙂
However, I don’t want to give the impression here that anyone can start installing Viya within a minute of connecting to a server. Regardless of how you obtained your servers and of whether they are shared of dedicated, there will be some critical prep work to execute before launching the Viya install. In fact, when I facilitate our internal Deployment workshops, I encourage my colleagues to worry more about the prep work than the actual deployment. For example, ensuring that ports are available and open across servers, users are pre-created, Linux packages are installed, and OS settings such as ulimits are properly configured are all key activities to ensure a smooth deployment.
Advantages of dedicated servers
– Having more hardware, the generic advantage
I think we can all agree that if you had 2 laptops, one to run Excel, and another to run Word, you would get better performance than if you had both Word and Excel on the same laptop. What is this? You’re not convinced? I don’t blame you. There is an advantage, but it is so negligible that you would not notice it. But that’s because either of these programs only ever use a small fraction of your laptop’s capacity. (say 10% each). So even if you run both simultaneously, you still have 80% of the capacity available. However, the cost of buying 2 laptops, and the impracticality of having 2 distinct computers, all of it to gain an imperceptible performance increase, is probably not something anyone would do.
However, you can’t and should not compare running SAS on a server and running Office on a laptop. Over time, SAS has made its analytics execute as fast as possible. This is possible due to the way SAS is designed to make use of all the computing resources at its disposal.
(quick aside #1: I started my career programming in SAS 6.12 on a PC, and I can tell you that while my programs were running on it, there were barely enough resources left for me to compose an e-mail. Oh, and when I could compose an e-mail, I’d put semi-colon at the end of each line.)
(quick aside #2: I know, you had nightmares about dropping your stack of punch cards on the floor. It’s not a competition.)
For this reason, and without any administrative overhead, it’s fair to say that running SAS 9.X and Viya on dedicated environments is likely to result in much better performance since you will have more hardware overall.
– Sizing concerns
SAS offers its customers the option to perform a sizing exercise. This allows you to get an idea for the required size of a particular environment, given a particular amount of data, number of users, and desired execution time. Although sizing is more than just the number of cores (it’s also the network, memory, storage), we often use cores as a proxy for the rest.
What we typically see at customers is that their existing SAS 9.X environments are far from idle: over the years, with the addition of users and data, it’s not rare to see a high (75-99%) rate of utilization for SAS servers. Which is what you want: if you utilization was 10%, you’d probably be oversized.
But that means that, if the Viya sizing comes back with a requirement for a certain performance (say, as a short example, 16 cores, and 256 GB of RAM), then you would need to make sure that your existing SAS 9.X environment has that spare capacity to take on the additional Viya load.
It is possible that you are able to increase the size of your server, to add enough capacity to it, to account for the Viya footprint. This would require downtime to allow the server(s) to be upgraded, which would see the SAS 9.X environment being temporarily unavailable.
It’s possible that new Viya processing “replaces” existing SAS 9.X processing over time. In that case, the demand on resources should not really increase. However, it’s also possible that existing SAS 9.X workloads keep running unchanged, and the Viya environment is used for newer and additional processing.
– Accommodating distinct requirements on shared servers
SAS 9.X and SAS Viya both have requirements in terms of Operating System, disk space, networking and OS settings. If you will install both on the same set of machines, you will have to carefully parse the requirements for each from the Documentation, and make sure that the single environment meets the requirements of both.
This might make things difficult, or plain impossible. Let me give a few examples:
- For many SAS 9.X products, the documentation asks you to set the sshd setting “maxstartups” to 1000. The Viya documentation asks you to set it to 100. What do think the number should for an environment that has both? The highest? The sum of both? The average?
- SAS 9.4 can be installed as any Linux user, part of any Linux group. So you might have deployed SAS 9.4 as a user called “sas”, which could be part of a group called “install”.
However Viya requires that a user “sas” exist and that its primary group be “sas”. In such a situation, it would therefore become quite cumbersome to have to change the primary group of the account “sas” and if not handled properly, could have a very negative impact on the SAS 9.4 environment.
- Some of the static ports used in Viya are the same as those used in SAS 9.4. Therefore, one has to pick alternative values for these static ports before starting the Viya deployment.
- If your SAS 9.X is running on an OS that is not supported by Viya, you simply will not be able to run both of them on the same machine.
Most of these are not showstoppers. But they complicate things and increase the potential for issues, not just on deployment day, but further down the road as well.
– Workload Management
If you have ever worked with SAS Grid Manager, you probably have an appreciation for the concerns of Workload Management. Without specific workload management, everyone using a system has a full access to the environment on a first-in basis. And since anyone’s processing is liable to use up all the hardware resources, it can lead to unpleasant behavior. For example, a big but non-critical analytic job could use up 99% of the resources for a long period of time, therefore slowing down the legally-required regulatory report from the usual 5 minute to something like 1 hour.
These concerns would have to be addressed within your SAS 9.X environment and within Viya deployment. But, if both SAS 9.X and Viya share the same environment, then it needs to be managed across both worlds. Having SAS 9.X and Viya on dedicated server means that there is almost no way that newer Viya analytics workload can impact existing SAS 9.X workloads. This alone, is likely going to save both the users and the administrators a lot of work.
Furthermore, even if you make the effort to actively manage your workload, there is no magic there: the solution to overloaded machines is to prioritize some workloads over others. You’d have to choose if you give priority to SAS 9.X or to Viya. Having them on separate and dedicated hardware means you don’t have to choose.
Conclusion
I could probably go on, but I think I’ve hit the most salient points, and I don’t want to bury the message. Yes, SAS supports SAS 9.X and Viya on the same hardware and some customers will do this. Saving money on the purchase of newer hardware is always going to be appealing, I can’t deny it. But before choosing to do that, you should carefully weigh the real operational advantages and business value of having dedicated hardware. In my opinion, the amount of the hardware saving would have to be pretty high for it to yield a better TCO and overall business value.
