Introduction
As part of the Installation of the Launcher Plugin for SLURM it is recommended to install the session components (cf. step 8).
The session components are a separate offering from Posit but in fact include to a very large degree the same content than the complete Posit Workbench Installler packages.
On HPC systems where custom images for the compute nodes are generated, the session components are a good option as they nicely can be integrated into the image and then deployed at scale.
On any HPC systems there already exists shared file systems that hosts essential data like home directories, workspaces and application installs etc... Many admins today are already no longer installing the session components onto the local file system of the compute nodes but deploy it into a shared file system. They then create a symbolic link into /usr/lib/rstudio-server so that Posit Workbench can find the content.
The duplication of content between Posit Workbench Installer packages and the session components has an impact on increased storage utilisation but more importantly on every upgrade you need to upgrade both the Workbench Server AND the Session Components.
In addition to that, the session components contain almost all the files that the main workbench already installs with very few exceptions (e.g. rserver/launcher binaries)
Below we will describe a process how you can set up Workbench and SLURM Launcher without the explicit use of session components.
New approach
- Before starting the Workbench installation, create a NFS share and mount it onto the Workbench Servers and all compute nodes into
/usr/lib/rstudio-server. If mounting directly is not desirable, mount it elsewhere and create a symbolic link. - Follow the Workbench installation as usual and follow the SLURM Launcher integration docs except Step 8 where you only need to ensure that you provide a PostgreSQL client as OS dependency on all Workbench Server(s) and compute nodes.
Benefits
- No need to install the session components any more, you are making use of the main Workbench installation that already contains those elements
- Less storage overhead
- Single-point-of-truth for Workbench installation
- Upgrading Workbench Server automatically updates session components as well
Note 1: The same approach also holds if the Workbench Server is in HA - you need to install the Workbench packages in all nodes that are part of the HA and also upgrade the same during an intended upgrade. Upgrading on ALL HA node is necessary to update the OS package registry and add any changes to files that Workbench deploys that are not in /usr/lib/rstudio-server (e.g. init/systemctl scripts, ...)
Note 2: The approach also can be used with the Altair Grid Engine (AGE) Launcher plugin as well.
Comments