BookmarkSubscribeRSS Feed
BStone
Obsidian | Level 7

All,

I have a question regarding the /SASHome binaries and config directories in a Grid deployment on UNIX servers with SAS 9.4.

My question/discussion is around the set up of /SASHome directories and how software stack is installed and configured with Grid, consider the following example:

  1. The deployment contains X8 Grid Nodes on the compute tier, X4 nodes are dedicated to SASGroup2 that can run SAS Foundation solutions, EXCLUDING analytical products like SAS/OR, SAS/STAT, etc.
  2. The SAS deployment contains X2 SAS Server Context based on user usage, i.e. SASGroup1 and SASGroup2.
  3. SASGroup1 can run all SAS solutions and analytical products, INCLUDING SAS/OR, SAS/STAT, etc.
  4. SASGroup2 can only run SAS Foundation solutions, EXCLUDING analytical products like SAS/OR, SAS/STAT, etc.

My questions / discussion points are:

  1. How can we ensure that users in SASGroup2 will not be able to run jobs which includes SAS/OR, SAS/STAT, etc?
  2. If a site is licensed to only run analytics products like SAS/OR, SAS/STAT, etc. on the X4 nodes (SASGroup1), will SAS be able to provide a plan for this type of setup?
  3. Lastly, based on the  case study above, what would be your deployment plan to achieve the best result? [This about the /SASHome binaries and Config directories befor answering this question]

NOTE: This is not a technical question for SAS Support, I am just interested to see what other SAS folks think about such a setup?

1 REPLY 1
jakarman
Barite | Level 11

What you are describing is supporting two (or more) different setinit (license) options in one single installation and configuration.

1/ As you can deploy/install all loadables on a single machine in one SASHOME location (Foundation) that is an easy solvable technical solution.

    You can segregate between those different groups by adding a different setinit to each group. So they only can use the licensed installed software.

    In the sashelp there is a file core.sasbcat that is containing the setinit.  Extending the SASHELP (sas config file) wit an isolated version will bring you to that wanted kind of processing

    The question will be how to manipulated the sasconfig to use this setup. Removing the core.sas7bcat from the original location will bring an additional remember step.

2/ There is no plan from SAS for this kind of setup.

    The trick is using /adding a common shared setup and redeploy/copy this to your other machines (DTAP life cycle management).

3/ In the Foundation usermods config file the should be a core.sas7bcat preset not having the stat/or files but supporting the BI/DI metadata

    In the <SASAPPServer"> (as many as you like) you can set the config usermods having the core.sas7cat license that you want for that appserver.

    With authorization groups you can segregate between those <SASAPPServer>

   Do the same for LSF needing that ksh script running sas.

For the license renewal you cannot use the standard renewal approach.

The easiest is running the setinit as found in the SID  using a X11 session or SAS/connect with the installers key user context.

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 1 reply
  • 1109 views
  • 1 like
  • 2 in conversation