Skip to main content

Streaming Gateway Appliance

Organizations who have users on the Internet must determine how their users will access their Frame workload VMs in a private network. For these use cases, organizations can provide their users with corporate VPN access or deploy the Frame Streaming Gateway Appliance (SGA), a secure reverse proxy that supports the Frame Remoting Protocol (FRP). SGA enables organizations to grant their users secure access to their virtualized applications and/or desktops without the use of a VPN.

The guide reviews the design, installation, and configuration scenarios for the Streaming Gateway Appliance in a Private Network with SGA deployment model for both Nutanix AHV and public cloud infrastructures. This guide assumes that the customer has an existing Frame customer or organization entity.

Considerations​

Frame provides two options for deploying one or more SGAs:

  1. For customers who use Frame-managed networking to create a Frame account following the Private Network with SGA deployment model in public cloud, Frame control plane can provision the SGA VPC, SGA VM(s), a load balancer (if more than one SGA VM is specified), security groups/firewall rules, and VPC/VNET peer at Frame account creation.
  2. For customers who chose customer-managed networking, customers must manually deploy their SGAs and a load balancer (if more than one SGA VM is required) and configure their networking/firewall rules.

Administrators should review the following considerations to determine which deployment approach fits their requirements:

Manual SGA DeploymentAuto SGA Deployment
InfrastructureRequired for AHV-based accounts
Optional for public cloud accounts		Applicable for Frame accounts in public cloud infrastructure
NetworkingManual deployment of SGA allowed for Frame accountsUp to four (4) SGA VMs per Frame account
Load balancer automatically provisioned with two or more SGA VMs
SGA VMs are created for each new Frame account
Additional ConsiderationsCustomers utilizing load balancers with their SGA configurations can significantly reduce or eliminate downtime for future upgrades of SGA.
Customers utilizing the Frame Disaster Recovery (DR) Early Access feature may need to configure the DR cluster with its own SGA, depending on the setup.		SGA upgrades require the termination and recreation of SGA VM(s). Scheduled downtime is required.

Network Requirements​

When deploying an SGA VM, the customer's network must allow Internet traffic to reach the SGA VM and from the SGA VM to the network containing the Frame-managed workloads (e.g., Sandbox, test/production pools, Utility Servers). As a best practice, we recommend the SGA VM or VMs (if high-availability is required) be deployed in a DMZ (e.g., VPC, VNET, or VLAN), separate from the workload VM network.

Consult Public Cloud with Private Networking and SGA or Nutanix AHV with Private Networking and SGA to ensure that network routing requirements are satisfied before continuing to installation and configuration.

High Availability​

Customers who wish to implement a high availability SGA solution must use a third-party load balancer. The load balancer is placed in front of one or more SGA VMs. These SGA VMs will act as the pool of SGA VMs ("SGA VM Pool") that will handle the FRP7 session traffic between end users and the Frame workload VMs.

High Availability SGA Architecture (FRP7)

High Availability SGA Architecture (FRP7)

The environment will need the following:

  1. A wildcard DNS A record, publicly resolvable via *.sga.company.com wildcard FQDN to a public IP address on the firewall ("SGA Farm Virtual Public IP Address")
  2. A private IP address on the load balancer ("SGA Farm Virtual Private IP Address", noted as "LBVIP" in the above diagram)
  3. The SGA Farm Virtual Public IP Address network address translated (NAT) to the SGA Farm Virtual Private IP Address (LBVIP) on the load balancer.
  4. Load balancer configured to:
    1. Assign inbound tcp/443 (HTTPS, WSS) request to a specific SGA VM in the SGA VM Pool.
    2. Terminate the TLS connection on the assigned SGA VM and not the load balancer (SSL Passthrough).
    3. Use SSL Persistence (SSL Session ID) to persist the HTTPS/WSS Frame session on a specific SGA VM.
Warning

Customer must prevent the load balancer from switching a user's Secure WebSocket connection (when using FRP7) from one SGA VM to another SGA VM. Switching of the Secure WebSocket connection while a user is in a FRP7 session may cause the session to disconnect (and potentially close) and require the end user to resume their session (or start a new session).

Typical FRP7 Workflow​

A Frame user logs in to the Frame Platform and is directed to their Launchpad. When the user clicks the desktop or application icon in their Launchpad, Frame Platform directs the user's browser to an FQDN based on the SGA subdomain, as configured by Frame Support, for the Frame account.

For example, if the subdomain was sga.company.com and the workload VM had a private IP address of 10.2.1.3, the workload FQDN would be 10-2-1-3.sga.company.com. This workload FQDN resolves from the customer's public DNS server to the public IP address on the customer's firewall. The firewall performs NAT and sends the request to the virtual SGA IP address (LBVIP). One of the load balancers receives the HTTPS request and forwards the request to one of the SGA VMs. The SGA VM then forwards the HTTPS request to the user's assigned Frame workload VM and Frame Agent on the workload VM validates the session start request and switches to a Secure WebSocket connection to begin the Frame session video/audio stream.

The load balancer is configured to keep the HTTPS/Secure WebSocket connection between the end user and the assigned SGA VM.

SGA VM Sizing​

For customers who are manually deploying SGA VMs (customer-managed networking), customers should start with a configuration for each SGA VM:

  • 2 vCPUs
  • 4 GB RAM

This configuration ensures the VM can support ~1 Gbps bandwidth of Frame Remoting Protocol data. Frame recommends a sizing target of 500 Mbps per 2 vCPUs to allow users to burst their bandwidth consumption.

The total number of concurrent users for the 500 Mbps bandwidth per 2 vCPU budget is dependent on the bandwidth consumed for the Frame sessions. Bandwidth consumption may be estimated based on user workload profiles:

  • 1 Mbps per Frame session for office productivity applications, CPU-only VMs, under 30 fps, 2K or less monitors
  • 5 Mbps per Frame session for CAD applications, GPU-backed VMs, up to 60 fps, 2K or less monitors
  • 10 Mbps or greater per Frame session for video editing/animation/sustained playback, GPU-backed VMs, up to 60 fps, 2K or less monitors

In an office productivity use case, for example, where CPU-only VMs are used with standard 1920 x 1080 displays, the default (2 vCPU, 4 GB RAM) VM configuration could support 500 concurrent users. For 1,000 concurrent users, the same organization would need to leverage at least a 4 vCPU, 8 GB RAM VM. An 8 vCPU, 16 GB RAM VM could support 2,000 concurrent users for this use case.

Customers who are deploying SGA VMs behind a load balancer for high-availability can incrementally add SGA VMs as their Frame bandwidth consumption increases.

note

Customers manually deploying SGA VMs in public cloud (customer-managed networking) should ensure they select a non-burstable instance type with sufficient network performance. Public cloud providers may constrain CPU utilization and/or restrict network bandwidth for lower cost instance types.

Internal Access to SGA-enabled Workloads​

Frame administrators may want end users within their private network to access the workloads of an SGA-enabled Frame account at the same time users on the Internet are accessing workloads in the same Frame account. When a Frame account is configured to rely on an SGA, all end users using workload VMs in the Frame account are provided the SGA FQDN by the Frame control plane.

Access to SGA with Internal Users

Access to SGA with Internal Users

To enable end users on your private network to use the SGA-enabled Frame account, determine whether end users on your internal network are able to go to the public IP address associated with the wildcard FQDN of your SGA. If your internal end users cannot reach the public IP address of the wildcard FQDN of your SGA, then configure your internal DNS servers to return the private IP address of the SGA VM (or the virtual private IP address of the SGA on your load balancer) for the SGA subdomain. Simply add the SGA subdomain as a wildcard DNS A record in your private DNS server as you did in your public DNS server.

note

Depending on your network security policies, you may need to update your firewall rules so end users on your private network can reach the SGA VMs. Refer to the network configuration requirements for Public Cloud with Private Networking and SGA, or Nutanix AHV with Private Networking and SGA, row “End user to SGA” for the specific protocols and ports that must be allowed to the SGA VM or the load balancer (if more than one SGA VM). The source IP address of the end user's endpoint would be private IP addresses, instead of a public IP address.

Multi-Frame Account Support​

A manually-deployed SGA can be configured to serve as the reverse proxy for multiple Frame accounts.

When providing the Frame workloads VLAN CIDR in the SGA Toolbox, specify a CIDR value that covers the CIDRs for the individual Frame accounts. For example, if Frame Account #1 uses 10.0.0.0/24 and Frame Account #2 users 10.0.1.0/24, then specify a CIDR of 10.0.0.0/23 for the SGA.