Co-written with Gordon Cox@gtcox76

Gordon’s 7-yr daughter asked him what he learned in class at SAS Campus a few weeks ago. The subject, even for many SAS geeks like us, can be hard to tackle. Gordon was learning all about SAS GRID architecture, implementations, and usage. Well try to explain this to a 7-yr old. Fortunately for us, Gordon’s daughter is brilliant as she just related GRID to what she knows … Sudoku! Comparing Sudoku and GRID simplifies things for all of us. (However in our comparison, we are only trying to get across how some of the functionality work. There are many mechanisms to further enhance your GRID computing power.)

So let’s compare! For this example, there are nine boxes within the Sudoku game where each represents a GRID NODE. A node, in formal SAS terms, is a “machine that runs a portion of the work allocated to the grid”.

With these 9 nodes, or servers that can run processes, you can distribute jobs between them. To do this with our Sudoku comparison, we need to look into each box of the game to see the 9 smaller boxes. These would represent 9 open job slots on each GRID node.

As jobs get assigned into the grid, they are evenly spaced between the nodes. Then as jobs fill into the grid, the openings between nodes are used in a distributed fashion.

The workload is balanced in the Sudoku example evenly across servers.  Jobs will go round robin across the nodes, once a node is full it can’t take any more jobs, thus that node is now closed.

Queues in SAS Grid

Another way to translate GRID into Sudoku terms is to look at each small square as an available job slot in the queue, with each queue only accepting a job with the same number.   The very first job comes in and goes to the queue “1”, the job can go to any of the 9 nodes (large Sudoku squares).  Another 8 jobs are submitted (the very 1^st job is still running) so all the “1”s are taken.

Now that the 1^st queue is booked solid, it is assigned a CLOSED status. When the second round of 9 jobs are submitted they will automatically get directed to the least busy node.

We could also set up our queues so that the 1-9 represent a  group of users, a SAS Application Server Context, or a variety of other options. In this example there are 9 groups of users. Each group may have a different size, but all groups are considered equal when searching for GRID enabled resources.  We set up a queue for each group with 9 job slots.  Therefore if one group has 20 jobs they need to run, only 9 will be able to run at the same time.  Whereas another group only has 8 jobs, there is one last queue available for one more job.

These examples are intended to enforce some of the Sudoku rules however queues can be set up in a variety of different ways with a variety of different rules.

High Availability

High availability is like using a Sudoku game website that has a hot backup in place. If one of the Sudoku servers crash, you don’t lose your entire game, you just wait a determined amount of time and you automatically switch over to the other back end server.

In the GRID world, all the data is writing to the same shared location, however the metadata process or any other locations that are high availability (HA) enabled are running from two different servers.

So if your SAS Metadata Server is enabled for HA and the first metadata server stops, the grid will attempt to restart it. If the restart is unsuccessful, the system will automatically switch over to the second already running metadata server on another host.

Load Balancing

Ever fill out a Sudoku bracket with another person, taking turns to fill in the next number?  If one person is too busy, then the other can continue on with the puzzle.  In SAS Grid this is the load balancing of multiple processes (i.e. the Workspace Server).  The workload of handling all the incoming requests is spread across multiple processes and the one that is the least busy will be the one to handle it.