graph LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) workbench(Workbench) session(Session) jupyter(Jupyter Session) vscode(VS Code Session) job(Workbench Job) u1---b1 u2---b2 u3---b3 b1---workbench b2---workbench b3---workbench subgraph server[Linux Server] workbench---session workbench---jupyter workbench---vscode workbench---job end classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F class server server class workbench product class session,jupyter,vscode,job session class u1,u2,u3,b1,b2,b3 element
Workbench Architectures
Using Workbench on a single server
In this configuration, Workbench is installed on a single Linux server and enables:
- Access to RStudio, Jupyter Notebook, JupyterLab and VS Code development IDEs
- Multiple concurrent sessions per user
- Use of multiple versions of R and Python
Using Workbench as a cluster
In this configuration, Workbench is installed on two or more Linux servers and enables:
- Load balancing to provide additional computational resources to end users
- High availability to provide redundancy
Requirements to support this architecture:
- Users’ home directories must be stored on an external shared file server (typically an NFS server)
- Session metadata must be stored on an external PostgreSQL database server
The example diagrams below show cluster architectures with and without an external load balancer.
External Load Balancer
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) workbench1(Workbench) workbench2(Workbench) session(RStudio Session) jupyter(Jupyter Session) vscode(VS Code Session) job(Workbench Job) lb(Load Balancer) nfs(Shared Storage) pg(Postgres) u1---b1 u2---b2 u3---b3 b1---lb b2---lb b3---lb lb---workbench1 lb---workbench2 server1-.-nfs server2-.-nfs server1-.-pg server2-.-pg subgraph server1 [Linux Server] workbench1---jupyter workbench1---job end subgraph server2 [Linux Server] workbench2---session workbench2---vscode end workbench1-.-workbench2 classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class server1,server2 server class workbench1,workbench2 product class session,jupyter,vscode,job session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req
Single Node Routing
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) workbench1(Workbench) workbench2(Workbench) session(RStudio Session) jupyter(Jupyter Session) vscode(VS Code Session) job(Workbench Job) nfs(Shared Storage) pg(Postgres) subgraph server1 [Linux Server] workbench1---session workbench1---job end subgraph server2 [Linux Server] workbench2---jupyter workbench2---vscode end u1---b1 u2---b2 u3---b3 b1---workbench1 b2---workbench1 b3---workbench1 server1-.-nfs server2-.-nfs server1-.-pg server2-.-pg workbench1-.-workbench2 classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class server1,server2 server class workbench1,workbench2 product class session,jupyter,vscode,job session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req
Using Workbench with an external resource manager
In this configuration, Workbench is installed on one or more Linux servers, is configured with Launcher1 and a Kubernetes or Slurm cluster backend, and enables:
- Users to run sessions and jobs on an external compute cluster
Requirements to support this architecture:
- Users’ home directories must be stored on an external shared file server (typically an NFS server)
- It is strongly recommended that session metadata be stored on an external PostgreSQL database server
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) workbench(Workbench) rsession(RStudio Session) jupyter(Jupyter Session) vscode(VS Code Session) job(Workbench Job) launcher(Launcher) nfs(Shared Storage) pg(Postgres) u1---b1 u2---b2 u3---b3 b1---workbench b2---workbench b3---workbench subgraph server workbench---launcher end subgraph cluster [Resource Manager] launcher---rsession launcher---jupyter launcher---vscode launcher---job end server-.-pg server-.-nfs cluster-.-nfs classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class server,cluster server class workbench,launcher product class rsession,jupyter,vscode,job session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req
Using Workbench entirely in Kubernetes
In this configuration, Workbench is installed entirely inside a Kubernetes cluster and enables:
- User sessions and jobs run in isolated pods, potentially from different base images
- The entire installation is managed in Kubernetes with tools like Helm
- Optional replicas for high availability
Requirements to support this architecture:
- Users’ home directories must be stored on an external shared file server (typically an NFS server)
- Session metadata must be stored on an external PostgreSQL database server
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) ingress(Ingress Controller <br/> nginx/nginx-ingress) workbench(Workbench <br/> Launcher <br/> ghcr.io/rstudio/rstudio-workbench) rsession(RStudio Session <br/> docker.io/rstudio/r-session-complete) jupyter(Jupyter Session <br/> ghcr.io/rstudio/py-session-complete) vscode(VS Code Session <br/> ghcr.io/rstudio/py-session-complete) job(Workbench Job <br/> docker.io/rstudio/r-session-complete) nfs(Shared Storage) pg(Postgres) u1---b1 u2---b2 u3---b3 b1---ingress b2---ingress b3---ingress subgraph k8s [Kubernetes cluster] ingress---workbench workbench---rsession workbench---jupyter workbench---vscode workbench---job end k8s-..-pg k8s-..-nfs classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class k8s server class workbench product class ingress,rsession,jupyter,vscode,job session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req
Additional Kubernetes Resources
Ready to get started with Workbench and Kubernetes? View the documentation for Integrating Workbench with Kubernetes
Want to use custom Docker images with Kubernetes? View the guide for Using Docker images with Workbench, Launcher, and Kubernetes
Want to learn more about Workbench and Kubernetes? Refer to the FAQ for Workbench with Launcher and Kubernetes
Additional Slurm Resources
Ready to get started with Workbench and Slurm? Proceed to the documentation for Integrating Workbench with Slurm
Want to learn more about Workbench and Slurm? Refer to the FAQ for Workbench with Launcher and Slurm
Interested in Using Apptainer/Singularity? Refer to Workbench with Slurm and Singularity
Footnotes
Launcher is a plugin that allows you to run sessions and background jobs on external cluster resource managers. In addition to Kubernetes and Slurm, Launcher can be extended to work with other cluster resource managers using its pluggable architecture.↩︎