3.3 Planning for Deployment

How many session servers do you need to deploy? How many MSS servers? What authentication method are you employing? Are there other considerations? In this section learn how to optimize your session server and MSS server deployment.

In this section:

3.3.1 About Authentication

Before you begin deployment, you should determine what authentication mode you want to use. Authentication validates the user's identity based on some credentials, such as a username/password combination or a client certificate.

HACloud supports these authentication modes: LDAP, Single Sign-on through IIS, Single Sign-on through Windows, X.509, SiteMinder, and SAML.

You have the option to not require users to authenticate. Select None to allow any user to access their assigned sessions without being prompted for credentials.

You can find more information on authentication in Select a method to authenticate users.

3.3.2 Scaling and High Availability

Determining how many session servers and MSS servers you require to meet your needs is the first task in planning for deployment. Whatever your needs Host Access for the Cloud can be deployed to provide both capacity and high availability.

Your solution depends on your needs, but read High Availability Deployment Blueprint for an illustration of a scalable and highly available deployment.

The main questions that you need to answer are:

What is the peak number of host sessions that will be used concurrently?
How many users will be using the system?
How available does the system need to be in the event of a failure in various areas of the system?

Scaling

Scalability is a system’s ability to handle various amounts of load. To increase capacity, a system can be scaled up (vertically) by running on a more powerful server or scaled out (horizontally) by adding more servers or nodes.

There are trade offs to consider with each case:

Scaling up offers the simplicity of fewer servers, however it also increases the risk of a significant failure if a server goes down.
Scaling out involves more servers but spreads the risk over many servers so when one goes down, a smaller number of users are affected.

Due to the increased resiliency, we recommend scaling out by adding more servers or nodes when increasing capacity.

High Availability

High availability (HA) is a system’s ability to continue providing services when a failure occurs somewhere in the system. HA is achieved by adding redundancy to key components of the system.

NOTE:This guide discusses providing high availability of the core Host Access for the Cloud services, however true high availability relies on redundancy at many layers in all areas of the systems, which is beyond the scope of this document.

High availability in Host Access for the Cloud is achieved by:

Deploying enough session servers and MSS servers to provide the needed capacity, with headroom (free capacity) for failures
Ensuring proper headroom so when a server does fail and the load fails over to the remaining servers, they are not compromised by the extra load
Using load balancers to distribute the load and direct users to other servers in the event of a failure
Replication of data between MSS servers, which is handled by MSS clustering

See the High Availability Deployment Blueprint section for an illustration of how to accomplish these requirements.

Session Server Sizing

The number of session servers you need is determined by the number of concurrent host sessions you are running. Host sessions generate more load on the session server than users do, therefore we are focusing on the number of required host sessions instead of the number of users.

Number of concurrent host sessions	Number of session servers required
Up to 3000	2 session servers
More than 3000	(Number of host sessions needed) / 2000 +1 (Minimum of three)

A single session server supports 2000 concurrent host sessions.
A session server has built-in headroom to handle 1000 additional host sessions in the event of a failover scenario.
A minimum of two session servers are required for high availability.

MSS Server Sizing

The number of MSS servers you need is determined by the number of concurrent users.

Number of concurrent users	Number of MSS servers required
Up to 30,000	3 MSS servers
More than 30,000	(Number of users needed) / 10,000 +1 (must be an odd number)

A single MSS server supports 10,000 concurrent users.
A MSS server has built-in headroom for an additional 5000 users in the event of a failover scenario.
A minimum of 3 MSS servers are required for high availability.
An odd number of MSS servers are required for high availability due to the need for a database quorum.

3.3.3 Deployment Options

You can deploy session servers in one of two ways:

Using the traditional method of installing each session server onto a dedicated server
Using Docker to run each session server in a container. Docker provides a number of benefits including more flexibility around how many session servers you can run on a single server. See Using Docker for more information.

3.3.4 Using Load Balancers

You will need to provide load balancers for both session servers and MSS. There are common settings you should be aware of:

Load Balancing Algorithm - The algorithm determines which server to send new traffic to. We recommend “Least Connections” or something similar. Verifying this setting is properly distributing load is essential for overall system stability. If the load balancer is not configured properly or working effectively, you run the risk of an individual server becoming overloaded.
Session Persistence (Affinity/Sticky Sessions) - This is the ability to send the same user to the same server through multiple requests. Both the session server and MSS are stateful applications and require sticky sessions to be enabled on their load balancers. Noted below.
Health Check Endpoint - This is the URL on the target service that is used to determine if the instance is healthy and should remain in service. Each server type provides its own health URL.

The High Availability Deployment Blueprint section provides recommended setting values for each load balancer.

TLS/SSL options

There are three typical options for handling TLS/SSL on a load balancer. The option you choose depends on your needs.

Your certificate needs to be installed on the load balancer in the first two options. The third option, TLS passthrough, does not require a certificate on the load balancer.The HA Blueprint uses TLS Bridging to provide end-to-end TLS while still allowing cookie-based persistence. The options are:

TLS Termination/Offloading - This option ends the HTTPS connection at the load balancer and continues to the service by means of HTTP.
TLS Bridging (Re-encryption) - This option ends the HTTPS connection at the load balancer and re-establishes a new HTTPS connection between the load balancer and the service. This provides end-to-end TLS while still allowing the load balancer to inject a cookie for session persistence.
TLS Passthrough (Required for X.509) - The load balancer proxies the TLS connection without decrypting it. The downside to this option is that since no cookie can be injected, persistence must be based on source IP or something similar.

TLS/SSL with X.509 Single Sign-On

When using X.509 authentication, the TLS Passthrough option is required on Host Access for the Cloud and MSS load balancers since client certificates must be presented to the servers in the backend. Because TLS Passthrough is required, you will need a non-cookie based method for session persistence, such as source IP for both the session server and MSS load balancers. This is necessary because with TLS Passthrough there is no chance for the load balancer to decrypt the connection to set or even view a cookie.

3.3.5 Terminal ID Manager

The Terminal ID Manager does not currently support HA. You can set up a passive server, but the state of the IDS will not be replicated from the active server. When the active server is unavailable, you will still be able to access the passive server, but the IDs will not maintain their current state.