In trying to offer better support to SAS users, many customers’ IT departments are looking to consolidate all their SAS desktop users onto a centralized Windows, UNIX or Linux server.
This option is a very practical strategy, but implementing it satisfactorily requires a lot of assessment on how the SAS users are using SAS on their desktop--especially if you want them to be happy when they are asked to migrate to the new centralized server! Please make sure that you add time in your project planning to do a detailed inventory and analysis of how the SAS desktop users are currently using SAS. This step is critical to ensuring there are enough computer resources on the new centralized server to assure SAS users will be productive and happy with this new infrastructure.
Determine number of cores. The most important thing that you need to do is to determine how frequently and how long it takes for each desktop user to run their SAS applications. If each one of these users is submitting SAS jobs on their desktop that run for hours and consume at least one full core on their machine, then you will need to make sure the new centralized server can support all those individual SAS users concurrently.
If you find out that you will have more than 20 concurrent SAS sessions, each taking over an hour from start to finish, you should consider implementing a SAS Grid environment so that you can spread the SAS users over multiple instances of an operating system for optimal performance. Please note that setting up a SAS Grid environment will add complexity to your new infrastructure as a clustered file system will be required to share data between the multiple operating system instances.
Evaluate IO throughput. In addition to making sure you have enough cores to support all the users in this new centralized environment, you need to make sure that you have enough IO throughput on the new centralized server to support the concurrent SAS sessions. Again, understanding the IO throughput requirements of each SAS desktop user will make this task easier. For example, you’ll want to understand whether desktop SAS users are submitting jobs that are mostly reading data sets or whether their jobs involve writing or updating large volumes of data.
SAS staff will be presenting a presentation on this topic at SAS Global Forum 2015 in Dallas, TX. For those of you who have done this consolidation in the past, please share with us your “lessons learned” so that we can incorporate it into this new SAS presentation.
As always, please let us know if you have any questions or comments on the above.
5 Comments
Hi,
Thanks for sharing. I wonder if alternative options shouldn't be considered also ?
1) Load-balancing Workspace Server, available out of the box with any IT Client/Server offer (BI Server, Office Analytics)
2) SAS High Performance Analytics with hadoop cluster
3) even scalability at OS level with latest Intel Xeon chips and affinity tuning : cgroups with Linux servers running on Intel Xeon latest models (up to 15 cores on each socket!) might perhaps be adequate sometimes - but restricted in terms of horizontal scaling (new users)
Automating the Workload "IT orchestration process" (or whatever it's called) with a Grid manager or Round-Robin algorithm won't eliminate the basics of need assessment. Mapping users groups on a kind on QoS scaling : for instance, putting up high performance resource for hardcore users , medium sized power for regular users and remaining power for less frequent users on the 3-level scale. Resource contention issues causing disatisfied users might often occur when different classes of users are put together.
Margaret, very good post and question.
The intention is indeed in this direction going to server-based Linux/Unix. Often this is a vision/ believe coming from IT people. The problem is the do not understand analytics environments and are locked in a box of the old classic cobol approach.
Using new buzzword doesn't help for a change.
-
The real problems arise when they are becoming aware of a shared usage shared dwh and programming (analyses) modeling by non-IT people. For the shared usage a well understood design according to business policies (iso27k) should be there. This commonly fails, there are no good examples at the SAS-site for that.
-
The reaction will be isolating eveyr used to his own server/machine getting a lot of those without really support by the IT departments.
-
It doesn't help that the installation process of SAS is that complicated (SDW) and unique. It is not one that is commonly used in Unix/Linus like RedHats rpm. To rebuild this SDW is a time consuming often done activity. release management is a difficult process to understand.
-
It would great trying to remove those hurdles
Jesper, That is a nice machine you are having. I am wondering the reason why you would like a clockspeed change. Even the fasted processor will not run more as two times faster. Do not expect increase on that, it doesn't since 2003. No, no moore anymore but Herb Sutter.
Decrease in response times / turnaround times must come from better algorithmes. With this you still easily can see getting improvements of a 10 fold (10%) of the original processing time.
Better coding better parallel processing better planning.
Ohh, I forgot. We have about 200 users on the system. Not all running SAS at the same time, though. I guess that we have about 20 hardcore user per server on a daily basis, on EOM, EOQ and EOY much more (and then especially the I/O is challenged).
We did this at Nykredit (a mid-size danish bank) 1½ yr ago. The two major problems we had (still have!) is CPU clock-speed and number of I/O channels to the external diskarray (a SAN I suppose).
We are using two IBM servers, each having 24 1.87GHz cores, 1 TB Ram and 1TB internal SSD for workspace and like. Only running classic SAS and EG on top of that.
Looking back I would trade number of cores for a higher clock-frequency and more I/O channels. And I would go more into the capabilities on the external diskarray, actually I would prefer a high-performance DAS to SAN. But it depends on your IT- and BI-strategy (and the size of your wallet), and who's "running" your server (your company or someone else).
All in all we see a consolidation as at great advantage as it much easier to manage your SAS eviroment this way.