Network and Load Balancing

Installing Redundant Roles

Turbo Server allows installing redundant roles across multiple servers. To install the role on separate servers, run the Turbo Server installer and select the role you would like to install.

The administrator can also add or remove roles on that server after installation. For more information refer to Managing the Domain.

It is recommended to install more than one Portal server for failover purposes, or for a large number of concurrent users (see Portal System Requirements). The number of application servers should depend on the number of concurrent users and the resource requirement of the applications being ran.

For maximum redundancy, a redundant domain should be setup that uses federation to replicate the workspaces and authentication settings from the primary domain.

Network Architecture Overview

Understanding the Turbo Server network architecture is essential for proper security planning, firewall configuration, and infrastructure design. This section provides a comprehensive overview of the system components, communication flows, and network requirements.

System Components

The Turbo ecosystem consists of three main component categories:

Client Components:

• Turbo Desktop Client: Native Windows application for running virtualized applications
• Web Browser: Accesses the Turbo Hub portal and can launch applications via HTML5 client
• Mobile Apps: Native clients for iOS and Android devices

Server Components:

• Turbo Portal: Web interface and entry point for authentication, application discovery, and service coordination
• Turbo Hub: Image repository and distribution service for application containers
• Application Servers: Execute virtualized applications in secure containers and stream them to clients
• SQL Server: Database storing configuration, user data, and system information

Supporting Infrastructure:

• Load Balancer: Distributes traffic across multiple Portal servers for high availability
• Content Delivery Network (CDN): Optional component for faster application image delivery

Network Communication Flow

Communication Paths and Security Requirements

Source	Destination	Protocol	Default Port	Direction	Purpose	Security Notes
Web Browser	Portal/Load Balancer	HTTPS	TCP/443	Inbound	Web portal access, authentication	SSL/TLS encryption required
Web Browser	Portal/Load Balancer	WSS	TCP/443	Inbound	HTML5 client streaming (/tunnelws/rxp)	WebSocket over SSL, WAF exceptions may be needed
Desktop Client	Portal/Load Balancer	HTTPS	TCP/443	Inbound	Service discovery, authentication	SSL/TLS encryption required
Desktop Client	Hub/CDN	HTTPS	TCP/443	Inbound	Application image download	SSL/TLS encryption required
Mobile App	Portal/Load Balancer	HTTPS	TCP/443	Inbound	Mobile portal access	SSL/TLS encryption required
Application Server	Portal	HTTPS	TCP/443	Bidirectional	Configuration sync, coordination	Two-way HTTPS access required
Application Server	Hub	HTTPS	TCP/443	Outbound	Application image access	SSL/TLS encryption required
Application Server	SQL Server	SQL over TLS	TCP/1433	Outbound	Database operations	Encrypted SQL connection recommended
Portal	SQL Server	SQL over TLS	TCP/1433	Outbound	Database operations	Encrypted SQL connection recommended
Hub	SQL Server	SQL over TLS	TCP/1433	Outbound	Database operations	Encrypted SQL connection recommended
Load Balancer	Portal	HTTPS	TCP/443	Outbound	Traffic distribution	Internal SSL termination
Desktop Client	P2P Coordinator	TCP	TCP/6881-6889	Bidirectional	Peer-to-peer image distribution	Hardcoded ports, cannot be changed
Desktop Client	Other P2P Clients	TCP	TCP/6881-6889	Bidirectional	Direct peer-to-peer file sharing	Cross-subnet/VLAN support with proper firewall config

Security Considerations

Firewall Configuration:

• Allow inbound HTTPS (TCP/443) from client networks to Portal/Load Balancer
• Allow WebSocket traffic (/tunnelws/rxp) for HTML5 client functionality
• Ensure Application Servers can reach Portal, Hub, and SQL Server on required ports
• Allow clients to reach Hub directly for image downloads (TCP/443)
• Consider network segmentation between client-facing and internal components
• P2P Requirements (Optional): If peer-to-peer image distribution is enabled:
  • Allow bidirectional TCP traffic on ports 6881-6889 between clients and server
  • Allow bidirectional TCP traffic on ports 6881-6889 between clients for direct peer sharing
  • Note: P2P ports are hardcoded and cannot be changed
  • Ensure corporate proxies allow P2P protocols (commonly blocked by default)
  • Configure QoS rules to not block P2P traffic on these ports

SSL/TLS Requirements:

• All external communication must use HTTPS/SSL
• Internal communication between Application Servers and other components should use encrypted connections
• CDN configurations should maintain encryption end-to-end

Network Isolation:

• Application Servers should be isolated from direct internet access
• Database servers should only be accessible from Application Servers, Portal, and Hub
• Consider placing Portal servers in DMZ with appropriate access controls
• Hub servers may be placed in internal network or DMZ depending on deployment architecture

High Availability:

• Multiple Portal servers behind load balancer for redundancy
• Application Server scaling based on user load and resource requirements
• Database clustering or backup strategies for data protection

Configuring Network

The administrator may want to use a reverse proxy to accesss the internal Turbo Server services. The administrator can configure which URLs the services and clients will use to talk to each other. For more information refer to Domain Addresses.

Configuring Content Delivery Network (CDN)

Turbo SVM images may be delivered over standard content delivery networks. To enable CDN for the Hub block storage, set the Hub CDN URL.

CDN support works best when delivering Turbo images using the Turbo synchronization protocol. Supporting clients will automatically select the Turbo synchronization protocol for objects over the configured Hub CDN Max File Size. Please consult your CDN provider to ensure that the correct max file size is configured. If you chose not to specify a max file size, then the automatic protocol selection will not occur.

For clients that do not support automatic protocol selection, users should have direct download disabled in the Turbo Client configuration.

If direct download is used, be aware that certain CDN providers limit the object size which may be exceeded by certain Turbo images. In that case the image must be delivered by the origin server.

Be aware that images delivered over the CDN may be downloaded from the public internet. Ensure that there is no confidential data in the images when delivering them over a CDN.

Sample CDN Configurations

Here are sample configurations for using Cloudflare, AWS CloudFront, and Azure CDNs with Turbo Server.

Cloudflare

Create a CNAME that resolves the URL of the Turbo Server instance and turn Proxy status on. The CNAME will be the Hub CDN URL in Turbo Server.

Create two Page Rules in Cloudflare:

• Cache Level: Cache Everything
• Edge Cache TTL: a month

Set the Hub CDN URL in Turbo Server to the CNAME address created in Cloudflare. Set the Hub CDN Max File Size to the maximum file size your Cloudflare subscription allows.

Cloudflare

AWS Cloudfront

Create a CloudFront distribution with the following options:

• Origin domain: URL of the Turbo Server instance
• Path pattern: Default (*)
• Viewer protocol policy: Match the HTTP configuration of the Turbo Server instance
• Allowed HTTP methods: GET, HEAD

Set the Hub CDN URL in Turbo Server to the Distribution domain name. Set the Hub CDN Max File Size to the maximum file size your CloudFront subscription allows.

Azure CDN

Create an Azure CDN resource with the following options:

• Pricing tier: Standard Microsoft
• Check Create a new CDN endpoint
• Origin type: Custom origin
• Origin hostname: URL of the Turbo Server instance

Set the Hub CDN URL in Turbo Server to the Endpoint hostname. Set the Hub CDN Max File Size to the maximum file size your Azure subscription allows.

Load Balancing

To load balance Application Servers, install the Application Server role on the desired servers. Then, configure the load balancing strategy as described in Domain Settings.

To load balance Portals, set the Domain URL to an external load balancer.

Understanding the Domain URL

The Domain URL is the URL for any end user or client to access the Turbo Server services. The Domain URL must be accessible on the network the end user is intended to run Turbo applications from. It should map to the server with the Portal role installed. End users can access the web portal through the domain hostname using a web browser. When logging in with the android or iOS application, the end user should put in the Domain URL under the server setting. For example, if the Domain URL is https://mydomain.com, the administrator should assign their dns entry at mydomain.com to the Turbo Server farm's Portal role server. End users can then navigate to https://mydomain.com to view the web portal.

The command line interface (CLI) should be configured using the Domain URL. Run the command turbo config --domain=mydomain.com to set the CLI to the correct domain. For more information refer to Command Line Reference

In addition to being used to accessing the web portal, the Domain URL will also be used to query the service topology for the underlying Turbo Server services. The endpoints that are exposed, using the above example, is the https://mydomain.com/service/settings and https://mydomain.com/service/topology. These endpoints are used to determine what server services are available, such as the Hub's IO service, the login service, and Application Server Broker.

Alternatively, the administrator may leave the Domain URL setting blank to have it be defaulted to the first server with the Portal role installed.

Troubleshooting

The HTML5 client fails to launch with websocket tunnel reconnect error.

Ensure your load balancer is not blocking the WebSocket path /tunnelws/rxp. See how to add a WAF exception.