Azure Single Server - Robust
Workbench | Basic
You can configure Posit Workbench to run on a single server using an external database and a networked file system. Both Workbench and user sessions are hosted on the same server. Using external components is optional for a single server implementation. However, this approach provides a more robust architecture that aligns with the best practices and existing processes of many organizations. This architecture also offers flexibility to more easily scale up in the future without needing to migrate the database or application files.
Architectural overview
This architecture uses the following components:
- A single Azure Virtual Machine instance running Workbench
- Azure Database for PostgreSQL Flexible Server, serving as the internal database
- An Azure NetApp Files pool, to provide a networked file system to store file data
Architecture diagram
Sizing and performance
The performance of this architecture is dictated by virtual machine size and the CPU and RAM characteristics of the machine, and the performance of the attached PostgreSQL database and NetApp Files pool.
A more detailed overview on node sizing can be found in the Architecture considerations section.
Node
Ensure the virtual machine instance is large enough to handle peak usage. The size and type of the instance depend on the needs and workloads of end users. For the best experience, estimate the number of concurrent sessions expected and the compute resources required for each session, focusing on CPU and memory. Choose an instance size that supports the maximum number of concurrent sessions at any given time. In practice, a single-server implementation works best for small teams of approximately 10 users.
CPU
Workbench alone consumes only a small amount of system resources. However, when estimating needs, reserve two to six cores for Workbench itself, in addition to accounting for the Python and R processes running in user sessions or Workbench Jobs. Review the considerations in the Number of users section to estimate the total number of CPU cores needed.
RAM
User sessions and Workbench jobs consume memory. The number of users and how they typically work with their data dictate the amount of memory needed. Review the Memory and disk requirements section to estimate the amount of memory needed.
Database
This configuration requires a PostgreSQL database for the Workbench internal database. This configuration puts little stress on the database. Azure Database for PostgreSQL Flexible Server is provisioned in the same virtual network as the virtual machine and reached via a private endpoint, so traffic does not traverse the public internet.
Storage
In this configuration, user home directories and Workbench shared state are stored in Azure NetApp Files, mounted on the virtual machine over Network File System version 4.1 (NFSv4.1). The Workbench file system usage for configuration and state storage is modest, likely less than a few GB for a production system. Therefore, the size of your NetApp Files pool depends almost entirely on end-user usage patterns. Some data science teams store very little in their home directories and only need a few GB per person. Other teams may download large files into their home directories and need much more. Administrators should consult with their user groups to determine the appropriate size.
Azure NetApp Files capacity pools are provisioned in 1 tebibyte (TiB) chunks. This capacity can be shared across all user home directories, Workbench configuration, and Workbench state storage.
For more information on the differences between file systems, please refer to the Cloud-specific recommendations in the Posit Team Storage documentation.
Load balancer
This architecture uses an Azure Application Gateway to provide public ingress to the Workbench instance. TLS is terminated at the gateway using a certificate issued from Azure Key Vault. This single server architecture does not provide redundancy, but the use of an Application Gateway allows additional nodes to be added later.
Configuration details
Networking
The architecture is implemented in an Azure Virtual Network. The Application Gateway and Azure NetApp Files volume each require their own dedicated subnet (enforced by Azure). The virtual machine and database private endpoint may share a subnet or use separate subnets depending on your network isolation requirements. The PostgreSQL Flexible Server and the NetApp Files volume are only accessible from within the virtual network, and ingress to the virtual machine is managed through the Application Gateway.
Resiliency and availability
This architecture does not provide high availability or fault tolerance by itself. If the virtual machine fails or there are outages within the Availability Zone, Workbench is unavailable until service is restored. Because this architecture uses an Application Gateway, additional virtual machines can be added to improve availability.
Unlike the normal Azure Single Server architecture, this architecture uses a Postgres database for the product metadata and a shared file system for storage, making it more robust. This architecture positions Workbench for easier scaling and allows for more robust backup and recovery strategies. Review the Internal Database and Mount shared storage documentation for more information.