Watch this Ask the Expert session to learn how to configure and tune VMWare virtual machines for performant SAS usage.
Watch the Webinar
You will learn:
- How misconfiguration of VMWare can negatively affect SAS system stability and performance.
- What VMWare configurations ensure best performance.
- Specific VMWare tuning for host, network and storage operations.
- Preferred host attachment methods for storage.
We recommend watching Introduction to Making VMware Perform With SAS, as this webinar is a part 2.
The questions from the Q&A segment held at the end of the webinar are listed below and the slides from the webinar are attached.
Q&A
Is using a physical server better in general? Even for Metadata or Mid-tier?
It is best overall to use a single physical server if you have a physical server that's sized for your metadata or mid-tier metadata. Mid-tier usually are small servers. They can run between 4 and 6 CPUs. It's often not practical to put those on their own server because you're not going to deploy A 4 CPU server. Your VM farm's going to go out there and buy 300 or 400 servers that have 32 or 64 cores in them. That's the whole purpose of VM Ware. It does not hurt those things to be in virtual machines. We just want to make sure that they get the resources underneath that they need. They're all contained in one socket, that host and things like that. The hosts that are most highly dependent on being NUMA aware very carefully socket placed are the ones that are driving the most IO and those are your SAS compute nodes and any controller nodes, so it does not have to be.
Also, it sounds like one physical server with all capacity will be the test solution?
If you have a very large compute node. Say for example, I have a virtual machine compute node and I want to put 32 cores in this and run a certain processing group through this one node, it's good to give them their own physical box and put that VM on that physical box. That way they have all the fiber channel card, and that's practical for compute nodes and for large compute nodes, for small compute nodes that only need a few CPUs or for mid-tier servers, metadata servers, things like that. It's smarter to just put those on a VM, let them share the resources. Just make sure that you have the resources underneath.
What if I can’t follow some of the precepts in this webinar? What are the impacts?
Well, that's going to be a very common thing. We have a list of things that we want to make our world perfect in SAS, and we don't always get that. Remember that little statement we had at the beginning of this presentation that says, mom says you get what you get, you don't throw a fit. You want all the stuff, but your mom says no, can't have all that. So, you will have to live with what you have. Sometimes it means that you have grave inconvenience. But if it's all your company can afford and all they're going to give you, you may not have much of a choice. We can work with you to see what they can change. Change as many things as they can. There are things they may not be able to change or may not be willing to change, sometimes for security reasons. But we'll help you navigate through that. Do the best you can to comply with as many recommendations as possible. Is there anything else that you can do to your job stream, or the way your jobs are shaped or coded to maybe even gain some efficiency? So, there's a lot of help available with that and sometimes it is what it is, and you may have to live with some stuff.
Who can help us talk with our VMWare Admins to discuss the tuning guidelines in this webinar?
I can, tony.brown@sas.com. Just reach out to me and we'll help you go through your account manager, because we do have to work with them. It's their account. We're helpers on that account and we're happy to help you have that conversation.
Many of my customers are running a SAS Grid (Platform) on VMs, using Veritas as shared filesystem. Is there any recommendation about this?
They're general recommendations. Veritas has evolved over the years, and it's become quite a complex file system. It hasn't kept up with some things as well as other shared file system vendors in terms of security updates. Some of our customers have had issues with security with Veritas file systems because some of them didn't adhere to the latest security standards. I don't know where that is in development today. They may have caught up with that. But that's one thing I would check on is to make sure that there are no security policies that the customer has that Veritas is not meeting in their software. That's the big thing that comes to mind in terms of performance. We can have a discussion with you and them in the Veritas vendor as a group and say, hey this is the kind of performance profile we need from your file system, and they can tune that accordingly. We don't have a working partnership with Veritas like we do with IBM, Red Hat, and some of the others, but we can work with their administrators and tell them what you need, and they can tune their file system as best they can. It's always worked relatively well with SAS. We really haven't had any performance issues with it as long it's set up right and physicality underneath it is good.
Would the number of users make a difference in the number of luns? Or if it was always 1 and 1 if they are sent appropriately?
Number of users really isn’t the metric. Each LUN has a limit on concurrent requests per LUN, and the limit is generally Very High in modern storage. So, it’s more workload oriented. The bigger issue with 1 LUN is that SAS employs One Writer Thread per LUN, and if you stripe luns, you can get more (i.e., parallel performance).
Recommended Resources
VMware: An Essential Guide
What Is VMware? What Is It Used for?
What is a Hypervisor? | VMware Glossary
4 reasons you should use Kubernetes
Moving from SAS®9 to SAS® Viya®
Move to Viya Board
Please see additional resources in the attached slide deck.
Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q&A, slides and recordings from other SAS Ask the Expert webinars.
