Bugzilla – Bug 5869
Remove external software requirement for HA setups
Last modified: 2016-05-04 14:01:11
You need to
before you can comment on or make changes to this bug.
ThinLinc HA is described by the documentation as "synchronization of the
ThinLinc session database across two VSM servers." This part of the HA equation
is configured by setting /vsmserver/HA/nodes to both participating masters, on
Agents are configured by /vsmagent/allowed_clients (which masters they should
be allowed to create sessions) and /vsmagent/master_hostname (the address on
which it can find a master).
The problem here is that Agent is completely unaware about HA setups, so the
master_hostname configuration is specified as a single hostname. In order to
avoid the single point of failure, we recommend that you add a resource IP
address and use external software to share it between the participating HA
If the agent were to know about and handle the case where we have multiple
masters, we could avoid the dependency on external software.
I'm thinking about a solution that would allow the agent to know about multiple
masters at the same time:
> /vsmagent/masters = master-1 master-2
The downsides of this is that we would have to add complexity to handle the
cases where a master does not respond. Possible workarounds for that could be
to try connections to all masters at the same time and use the first available
This means we can also get rid of the /vsmagent/allowed_clients configuration
variable and reuse the same masters variable as an access control list for
who's allowed to do master things, as a way to simplify the configuration.
Since there were some confusion about the intentions of this bug, allow me to
try to clarify.
My idea of this bug was to investigate/explore the possibilities of providing
the entire HA functionality ourselves rather than depending on third-party
software for the resource IP part. This is not limited to master<->agent
communication; client<->master communication is also affected/require this for
a "full HA" setup.
The description should have been expanded to also speak of master<->clients,
but I forgot all about that problem when describing this.
Comment #1 is an embryo of a thought, which does not handle the master<->client
parts of the equation.