One of the features of SAS Grid Manager (and SAS Grid Manager for Platform) introduced in SAS 9.4 M6 is the capability for the grid provider software to handle open-source workloads in addition to traditional SAS jobs. In this post, we’ll take a look at the steps required to get your SAS Grid Manager environment set up to utilize this functionality, and we’ll demonstrate the process of submitting Python code for execution in the SAS Grid.
In Part 1 of this series, Cheryl Doninger described how SAS Grid Manager can extend your investment in the Hadoop infrastructure. In this post, we’ll take a look at how Cloudera Manager helps Hadoop administrators meet competing service level agreements (SLAs). Cloudera Manager lets Hadoop admins set up queues to
SAS Grid Manager for Hadoop is a brand new product released with SAS 9.4M3 this summer. It gives you the ability to co-locate your SAS Grid jobs on your Hadoop data nodes to let you further leverage your investment in your Hadoop infrastructure. This is possible because SAS Grid Manager
SAS recently performed testing using the Intel Cloud Edition for Lustre* Software - Global Support (HVM) available on AWS marketplace to determine how well a standard workload mix using SAS Grid Manager performs on AWS. Our testing demonstrates that with the right design choices you can run demanding compute and
When designing a SAS Grid Manager architecture, there is a requirement that has always been a critical component: a clustered file system. Over the years, vendors have released versions of these systems that are more robust and SAS has increased the minimum IO requirements, but the basic design has never changed—until now.
For those of you who have followed my SAS Administration blogs, you will know that setting up your IO subsystem (the entire infrastructure from the network/fibre channels in your physical server, across your connections, to the fibre adapters into the storage array, and finally to the physical disk drives in
Scalability is the key objective of high-performance software solutions. “Scaling out” is a concept which is accomplished by throwing more server machines at a solution so that multiple processes can run in dedicated environments concurrently. This blog post will briefly touch on several scalability concepts that affect SAS.
Most organizations enjoy a plethora of SAS user types—batch programmers and interactive users, power users and casual—and all variations in between. Each type of SAS user has its own needs and expectations, and it’s important that your SAS Grid Manager environment meets all their needs. One common solution to this
This blog is a continuation of an earlier blog entitled “To grid or not to grid?” In that blog, one of the reasons to say “yes to SAS Grid” is to see if you can gain some performance improvements from modifying your existing SAS processes by converting them to a
Let’s be honest. When well planned, a SAS Grid Computing platform as the basis for a shared, highly available, high-performance analytics environment can pay for itself many times over. However, it is critical that your overall objectives and computing environment be well understood for you to achieve success with your
When I worked for SAS Italy, I was considered an old SAS employee because I started with SAS 8, and I saw all SAS 9 innovations from the beginning. I can even remember using SAS 6.12 a couple of times! Then I moved to the US and I felt like
It was wonderful to see and talk with so many SAS Administrators at SAS Global Forum this year. If you’re like me, you may have finished the conference wondering why it wasn’t possible to be two places at once because there was so much terrific content that it was impossible
SAS 9.4 has been out for some time now, and all SAS grid computing enthusiasts know that one of the new features is that SAS Workspace Server processes can be directly launched on the grid. (See The Top Four User-Requested Grid Features Delivered with SAS® Grid Manager 9.4.) What does
In SAS Grid Manager environments, SAS administrators must often set up separate configurations based on a mix of requirements for departments, client applications and user roles. To accomplish this in previous SAS releases, administrators must define multiple SAS Application Server contexts, each with its own grid server definition and associated options.
With the popularity of SAS Grid Manager, this question often comes up: which clustered or shared file system should we use with the multiple nodes of the SAS Grid? This is a question that needs to be thought through very carefully because the amount of time and effort to fix
In my last post, I introduced the hardware solutions (such as a virtual IP switch or IP load balancer) that enable client applications to access services regardless of whether they are running on a primary or a failover server in a grid-enabled environment configured with high availability. In this post,
Like most SAS users and administrators, you usually don't know where your backend SAS servers are located--probably in some basement server farm or perhaps another building or even another town. But I'm sure you do know that your SAS client application must have a way to reach services running on