Planning for Deployment
How many session servers do you need to deploy? How many MSS servers? Are there other considerations? In this section learn how to optimize your session server and MSS server deployment.
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
| 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.
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.
- 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 values for each these settings.
TLS Options
There are three typical options for handling TLS 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 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.
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.
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.
Understanding Service Interruptions
Note
When considering deployment options be aware that HACloud is composed of multiple services: the session server, MSS and its add-ons, Terminal ID Manager and Metering. By default, MSS, Terminal ID Manager, and Metering run together in a single process, but they can be configured to run in separate processes. The HACloud session server always runs in its own process.
When the session server is stopped, all host sessions on that server are closed. Users that were logged into that server must re-authenticate when the server restarts or when redirected to a new server.
This table describes the effects on end user's abilities when services are unavailable or have been restarted.
| Action | Server down | Server restarted |
|---|---|---|
| MSS | ||
| Login | No | Yes |
| Create new host sessions | No | Yes |
| Use existing host sessions | Yes | Yes |
| Reconnect existing host sessions | Yes (excluding SSH sessions) | Yes |
| Edit sessions | No | Yes (re-login required) |
| Record/Edit user macros | No | Yes |
| Terminal ID Manager | ||
| Connect host session that requires an ID | No | Yes |
| Connect host session that does not require an ID | Yes | Yes |
| Metering Server | ||
| Create new host sessions | No* | Yes |
| Use existing host sessions | Yes | Yes |
*If the metering.host.required property is set to false, new sessions can be created.
If a session server goes down then all sessions for all users connected through the load balancer to that session server will be lost. Each user will have to login to another session server (through the load balancer) and start new sessions.