On Sat, Jan 13, 2018 at 11:09 AM, Nick Couchman <vn...@apache.org> wrote:
> On Tue, Jan 9, 2018 at 1:28 PM, Thiago dos Santos Nunes < > thi...@digitalinformatica.com.br> wrote: > >> I really need help with High Availability for the Guacamole client. >> > > Based on what you've said below, what I believe you mean by "High > Availability" is that you need the number of active connections for a > connection configured in the database (JDBC) to be shared across multiple > Tomcat instances. > > >> >> >> How could I implement this? Mainly regarding the maintenance of the >> session of the users independent of the server that it connects and also >> the maintenance of the number of concurrent users that a connection can >> receive. >> > > If my "implement" you mean, "What do I need to install/configure to get > this working?," the answer is, you can't. Given the way Guacamole is > written at present, what you are trying to do is not possible without > changes to the Guacamole code. > > As I've mentioned before, right now, Guacamole tracks active connections > completely in-memory. Changing this would require code changes that would > store this information elsewhere, in a database or some other system that > could track it across multiple Tomcat (/JBOSS/Jetty/Weblogic) and Guacamole > Client instances. Also, the changes required to support this are not > quick/easy changes. They are probably easier after some recent changes > that Mike made, but it still isn't just a matter of, "Oh, go change these > 10 lines of code and it'll work," it involves moving the mechanism from > memory to database and all of the stuff that has to happen to support that, > and that's going to take some effort to accomplish. And that's assuming > that we (Guacamole developers) come to a consensus that it's something we > should actually do. > > To clarify a bit here, from the user's perspective, there are two primary aspects to high availability / scaling with respect to Guacamole: 1) Being routed to the correct Tomcat/Guacamole instance (or syncing session state across Tomcat/Guacamole instances) 2) Being routed to the correct guacd (if joining a shared connection) Whether these are issues in practice depends on the use case. If you are OK with losing the ability to share active connections, then simply placing several guacd nodes behind any TCP balancer will do wonders. If you need screen sharing, then either (1) the existing JDBC auth needs to be modified such that it handles its own balancing across guacd nodes (and thus knows which guacd to route each connection to), or (2) you would need to implement your own purpose-specific extension which handles its own balancing across guacd's (which is not as hard as you might think). Regarding session state, again depending on the use case, synchronizing this may not actually be necessary, particularly in the case where administration is not performed through the Guacamole UI, authentication is performed externally through some identity provider or application, etc. Known-good configurations which will work for high availability / scaling are: * Sacrifice screen sharing, put guacd nodes behind a balancer, use only one Tomcat node. * Sacrifice screen sharing, put guacd nodes behind a balancer, put Tomcat nodes behind a balancer with support for sticky sessions. * Sacrifice screen sharing, pair Tomcat and guacd together on each node, with all nodes behind a balancer with support for sticky sessions. * Don't sacrifice screen sharing, implement your own extension which authenticates and routes users exactly as you desire, multiple nodes for guacd and Tomcat. Beyond that, for things to work with the standard extensions and feature set, Nick is correct that changes would be need to be made within the extensions in question, and those changes would be non-trivial enough that they will likely involve a good amount of discussion before the right solution is found. - Mike
