Bug 5869 - HA setup shouldn't require a shared IP between masters
Summary: HA setup shouldn't require a shared IP between masters
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-02 16:54 CEST by Karl Mikaelsson
Modified: 2023-06-27 13:22 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Karl Mikaelsson cendio 2016-05-02 16:54:23 CEST
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 both masters.

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 masters.

If the agent were to know about and handle the case where we have multiple masters, we could avoid the dependency on external software.
Comment 1 Karl Mikaelsson cendio 2016-05-02 16:54:43 CEST
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 established connection.

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.
Comment 2 Karl Mikaelsson cendio 2016-05-04 14:01:11 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.