Introduction
While ThinLinc may be installed on a single server, it is common for larger installations to use several servers in a so-called cluster configuration. A cluster consists of one master server, which acts as a session broker, and several agent servers on which the sessions themselves are run.
A cluster configuration has several advantages. For example, sessions are load-balanced across agents in the cluster, which not only spreads the load, but also provides a layer of redundancy. If an agent server goes down for some reason, only the sessions on that agent are lost, and the other agents are still available to launch new ones.
However, there is still a potential single point of failure; the master server. There is only one master server in a cluster, and if it becomes unavailable then no new sessions will be able to be created (although users who are already connected to existing sessions will be unaffected). In order to mitigate this, ThinLinc ships with HA functionality which enables failover to a secondary, redundant master server, in the event that the primary master fails.
Scope and Limitations
Since ThinLinc has no control over the hardware or network configuration, failing over to a new server requires components outside of ThinLinc itself. The ClusterLabs project, as one example, provides packages to assist with this. If you are running virtual servers, your virtualisation platform may provide similar functionality. Setting this up is outside the scope of this article; please refer to the relevant documentation for more information.
ThinLinc High Availability
The role of ThinLinc’s HA functionality is to keep the session database synchronised between the primary (“active”) and secondary (“redundant”) master servers. In the event that the primary master server fails, this synchronisation ensures that the secondary master server has all the information it needs to take over from the primary.
The two servers should be identical. If the primary server fails, the system-level HA should reconfigure the secondary server to take over the network configuration from the primary. Provided that ARP caches are refreshed as part of this process, it should be more or less seamless with minimal downtime.
When the primary server is brought back up again, it should take over once again from the secondary. When this happens, ThinLinc will sync the session database on the secondary server back to the primary again, and continue keeping them in sync.
Configuration
Instructions on how to configure ThinLinc HA can be found in the ThinLinc Administrator’s Guide here.
For more information on ThinLinc’s HA functionality, see High Availability (HA) — The ThinLinc Administrator's Guide 4.14.0 build 2408 documentation
For more information on the industry standard system-level HA projects Pacemaker and CoroSync, see https://clusterlabs.org/