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
  • Access to RStudio, Jupyter Notebook, JupyterLab and VS Code development IDEs
  • Multiple concurrent sessions per user
  • Use of multiple versions of R and Python

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.

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 the Launcher SDK. AWS Sagemaker and Altair Grid Engine are two example uses of this SDK where a third-party developed a launcher plugin for their respective cluster resource manager.

This enables:

  • Users to run sessions and jobs on external compute cluster(s)
  • Optional replicas for high availability
  • Access to RStudio, Jupyter Notebook, JupyterLab and VS Code development IDEs
  • Multiple concurrent sessions per user
  • Use of multiple versions of R and Python

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
  • Access to RStudio, Jupyter Notebook, JupyterLab and VS Code development IDEs
  • Multiple concurrent sessions per user
  • Use of multiple versions of R and Python

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

Using Workbench with Slurm

In this configuration, Workbench is installed on one or more Linux servers, is configured with Launcher and a Slurm cluster backend, and enables:

  • Users to run sessions and submit jobs via the SLURM Launcher against a SLURM cluster with arbitrary number of compute nodes of a given type
  • Optional replicas for high availability
  • Access to RStudio, Jupyter Notebook, JupyterLab and VS Code development IDEs
  • Multiple concurrent sessions per user
  • Use of multiple versions of R and Python

Requirements to support this architecture:

  • Users’ home directories must be stored on a shared file system (typically an NFS server), shared storage typically includes /home, /scratch, data folders, and session containers
  • Session components will need to be accessible from the Slurm compute nodes (installed or mounted), or Singularity can be used as session containers
  • Users must exist on both Workbench servers and the Slurm cluster node, for example by pointing to the same authentication provider
  • The use of an external PostgreSQL database server is necessary when using multiple Workbench servers
flowchart LR
u1(User)
u2(User)
u3(User)
b1(Browser)
b2(Browser)
b3(Browser)
smn(Slurm Head Node)
workbench(Workbench)
rsession(RStudio Session)
jupyter(Jupyter Session)
vscode(VS Code Session)
job(Workbench Job)
launcher(Launcher)
nfs(Shared Storage)
pg(Postgres)
sj1(submits job)
sj2(submits job)

u1---b1
u2---b2
u3---b3
b1---workbench
b2---workbench
b3---workbench

subgraph hpc [HPC]

    subgraph box [ ]

        subgraph server [Submit Node]
            workbench---launcher
        end 

    %%launcher -- submits job --- smn

    launcher --- sj1 
    sj1 --- smn

    subgraph box2 [ ]

    subgraph main [Head Node]
        smn
    end

    smn--- sj2

    sj2---rsession
    sj2---jupyter
    sj2---vscode
    sj2---job
    

    subgraph cluster [Compute Node]
        rsession
        jupyter
        vscode
        job
    
    end
    end
    end

    server-.-pg
    
    server-.-nfs
    main-.-nfs
    cluster-.-nfs

end

classDef hpc fill:#eeeeee,stroke:#666666
classDef server fill:#FAEEE9,stroke:#ab4d26
classDef product fill:#7494B1,color:#F2F2F2,stroke:#213D4F
classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F
classDef element fill:#C2C2C4,stroke:#213D4F
classDef req fill:#72994E,stroke:#1F4F4F
classDef note fill:#eeeeee,stroke:#333,stroke-width:0px,color:#fff,stroke-dasharray: 5 5
classDef box fill:#eeeeee,stroke:#eeeeee

class hpc hpc
class server,cluster,main server
class workbench,launcher,smn product
class rsession,jupyter,vscode,job session
class u1,u2,u3,b1,b2,b3,lb element
class pg,nfs req
class note,sj1,sj2 note
class box,box2 box

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

Additional Resources

Additional Docker Resources

Want to learn more about running Posit products in containers? Refer to Running Posit Products in Containers

Back to top