07-24-2013 03:41 AM
What is underlying requirement for splitting them up? Is is security related? Is it to provide faster resources to one group of users, or perhaps more generally spread the work load over multiple storage volumes? The -work option has some builtin abilities to distribute the work directories over multiple locations. There are some links to documentation in this blog post: Spreading the WORK load
For more complex requirements you could look at custom per-user/per-group configurations using something like metadata access controls on multiple application servers or restricted options.
Are they mutually exclusive sets of users? Do any DI users use EM or any EM users use DI? If they are different sets it makes it easier because then you can use different SAS application servers (e.g. SASDI & SASEM) with different work configurations (and maybe other settings too) and then use metadata access controls to hide the SASDI app server from the EM users and vice versa. If there are some users that use both DI and EM then it becomes more of a training issue where you could train the users to use different app servers depending on the client app they are using (I have often thought it would be nice to also have client/application level access controls or flags that tell the clients which app servers they are allowed to use).
You can see an example of using metadata access controls to direct users to different application servers in the SAS Global Forum 2010 paper A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment. The application servers have different config files and so can have different -work option settings.
There's also the potential to use restricted options to dynamically change the -work option for different users or groups. I did a blog post about it in relation to the -xcmd option (but you can us the same method for the -work option): SAS Restricted Options on UNIX. Although the post was originally about UNIX, if you check the comments there are also some links to SAS 9.3 documentation for restricted options with Windows.
07-24-2013 07:17 AM
The tools are quite different. AS/DI (ETL) and Miner are behaving technicallly completely different and are for a different type of usage. Altough ETL is needed to get data delivered data that is possible to be used by Miner. Differences:
- ETL is thougt to be a planned process that will become into scheduled operations.
- The miner part can cause a heavy load some parts can use mp-connect options aside threading. All is user inititated and not being planned/scheduled. That is how mining behaves it is the functional job. It can have basic fucntionality being solved by using Eguide.
It would make sens to use SAS/DI in a classic development approach. Develop Test Accept and Production. By that you are getting segregated environments (D,T,A,P).
Mining is not applicable to that classical approach as it just makes sense having real data not faked data. You will always use "production" (shadowed) data. When deploying the models (the result of mining) it will need the real "production" connection.
As the hardware should be designed for the expected usage http://support.sas.com/rnd/papers/sgf07/sgf2007-iosubsystem.pdf The IO part shoud be well evaluated. With Unix there is a lot do with filesystems and mounts. GRID-computing is the ultimate.
Segregation by app-servers (See Paul Homes) is the first option to segregate usage ub user groups.
It is quite normal (see all the examples) too have many of those appservers. The default installation configurationstep however is for just 1.
Each appserver context can be set up with different settings each WS or Sp server can be tuned with differnt settings. DI and Miner both use a WS (part of app-server context) by default. Your platformadmin should help you with that... (if it is not you).
With 9.3 there are many ".._usermod" files at the OS-level to achieve that. These are manual changes (editting).