Why limiting users as you can isolate them by groups and filesystem?
That are common approaches on the s level. Put all users in a group below home in a separate filesystem. Have their code in separate filesystem and their data. Their you have you quotas.
Within webdav and sas metadata there is no seperation possible. As you need to segregate in dtap and regular users vs analysts you could need many of those.
The machines goals hold be delivering work an service not by limiting and hurting the users.
Is it possible to limit the disk space by each user? we thought we could do this using disk qoutas, but we wonder if there's another way we could do this?
The question you're asking is too general to have a single and definite answer. Do you want to set up quotas on :
1. SASWORK temporary disk space on a per user basis (summation of multiple concurrent sessions for each user) or per user AND per session basis (maximum allowed for each session of a given user with or without a maximum number of sessions / user )
2. SAS permanent Libraries and persistent disk space storage (e g . My Folders) .
3. Both ?
Point 2. is obvious : set up quotas on 'home' (USERPROFILE) directories.
Point 1. is trickier . It might require to use Ramdisk (~ "in-memory") for your SASWORK storage . See MEMLIB system option on Windows or tmpfs/ramfs on Linux (other OSes are presently out of my reach):
In addition to this, you should set up Restricted options in order to assign a given ceiling to each user (Windows) or create Cgroups on Linux to control the amount of memory per user or per session (process). Last but not least,
quotas on SASWORK per user often implies limiting the total number of (concurrent) SAS interactive sessions (Workspace sessions, for instance, launched by SAS Enterprise Guide) which means, for instance, configuring Load-Balancing for your SAS Workspace server (a 1-machine cluster is sufficient).
Ronan, there is no need to do something special on Windows home dirs with roaming profiles as those issues are well understood by windows system admins. Even the Saswork to a local drive location is no problem as that one is also known as a generic one.
The problem arises when going server based or going Unix based.
The problem exists because is not clear in their requirements with user sessions and user profiles. That is a root cause of a lot.
Sas is also not following the common Guidelines to work on Linux Unix systems just see those and see what Sas is doing.
The ibm paper made with Sas is clear on the omission on setting ulimits. Knowing the system level it is possible to correct some things. Ulimits can be set at the usermods.sh script. Sas made a note on that.
The /home filesystem is a common issue Unix os admins are complaining on. It has the storage for system and all service and all user accounts. By that a user could block the system or service accounts using all space. That problem is eliminated by setting up different file systems for each class of accounts. The need or question for quotas is likely eliminated with that.
Cgroups is a total different management topic as it is about workload balancing of resources like memory and cpu. The goal is sharing many different user groups with a minimum agree service level. Allowing many possible resources to be used is optimizing the harware. Why being a dictator disabling functionality of being afraid no capable managing the users and resources?
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
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.