Table of Contents
In this section, we will describe how to configure a ThinLinc cluster with multiple agent servers to allow load-balancing and redundancy.
This section does not address configuration of high availability (HA). For information on configuring your ThinLinc cluster for high availability, see Chapter 6, High Availability (HA) .
A ThinLinc cluster consists of one master server (or multiple master servers in a HA configuration) with multiple agent servers behind it. While ThinLinc in its simplest configuration may be run with both the master and agent installed on the same machine, running ThinLinc in a cluster configuration conveys numerous advantages:
A cluster configuration allows automatic load-balancing of sessions across multiple agents
Having multiple agents offers redundancy; for example, if one agent goes down or is taken out of service for maintenance, other agents are still available to handle user sessions
A cluster configuration is scalable. Since most of the workload is taken up by the agents and not the master, adding more capacity to your ThinLinc installation is generally as easy as installing one or more new agent servers
When configuring ThinLinc servers as a cluster, there are two main configuration options which need to be set, one on the master and one on the agent(s):
This parameter is configured on the master, and contains a space-separated list of all agent servers which will be part of this cluster. Only servers in this list will be considered by the master as available to create sessions on. See Section 14.2.2, “ Parameters in /vsmserver/ ” for details.
This parameter is configured on each agent in the cluster, and contains the name of the master server for the cluster. See Section 14.2.1, “ Parameters in /vsmagent/ ” for details.
Once the two parameters above have been configured, and the vsmagent and vsmserver services have been restarted, these ThinLinc servers will then function as a cluster.
When multiple agents have been configured as part of a cluster, it is usually desirable to keep their configurations synchronised. Instead of making the same change seperately on each agent, ThinLinc ships with the tool tl-rsync-all to ensure that configuration changes can be synchronised easily across all agents in a cluster. See Chapter 13, Commands on the ThinLinc Server for more information on how to use this tool.
The tl-rsync-all command should be run on the master server, since it is the master which has a list of all agents in the cluster (in /vsmserver/terminalservers ). For this reason, it is often useful to configure the master server as an agent as well, even if it will not be used to host user sessions in general. This allows the master to be used as a "template" agent, where configuration changes can be made and tested by an administrator before pushing them out to the rest of the agents in the cluster. In this way, configuration changes are never made on the agents themselves; rather, the changes are always made on the master server, and then distributed to the agents using tl-rsync-all.
An example of how one might implement such a system is to configure the master server as an agent which only accepts sessions for a single administrative user. The steps to do this are as follows:
Configure the master as an agent too. On a ThinLinc master, the vsmagent service should already have been installed during the ThinLinc installation process; make sure that this service is running.
Make sure that the master server is not listed in the parameter /vsmserver/terminalservers . This will ensure that normal users will not be able to create sessions on the master server.
Create an administrative user, for example tladmin . Give this user administrative privileges if required, i.e. sudo access.
Make sure that the master server is explicity selected as the agent for tladmin whenever they create a session. This is done using the parameter /vsmserver/explicit_agentselection . See Section 14.4.9, “ Forcing sessions for some users to certain agent hosts ” for details on this parameter. As an example, the parameter should contain the value tladmin:master.example.com .
In this way, configuration changes are never made on the agents themselves; rather, the changes are always made on the master server, and then tested by logging in as the tladmin user. If successful, these changes are then distributed to the agents using tl-rsync-all.