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

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

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 Launcher¹ 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.↩︎