Re: High Availability in Guacamole Client
On Sat, Jan 13, 2018 at 11:09 AM, Nick Couchman 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
Re: High Availability in Guacamole Client
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. > > > Let me give you an example: > > > > I have 3 frontend servers (client guacamole). And my users can connect in > a certain connection only 3 at the same time (or 5 or whatever). But as > each time a user connects in a frontend it falls on a different frontend > these 3 connections can reach up to 9 (3 connections x number of frontend). > Think about 20 diferent types of connections in one server > Right, so what you're wanting to do is make sure that, if multiple Guacamole installs are sharing a single database, that they also are updating active connection information among themselves so that, if you set the maximum number of active connections for a connection to 10, you get 10 across all three of the servers and not 10 per server. > > > Today for me to control the use of resources of the servers and the > licensing is VERY DIFFICULT. > > > > I do not know much about programming and in our environment we can not > deploy a solution like hazelcast (because of cost, very expensive). > Don't latch on to Hazelcast. I mentioned it in the past, but there are other options - it was only an example of an in-memory database that can be synchronized across nodes. There are others. The biggest point I was trying to make here is that simply tracking this information in the existing JDBC module inside the database may not be fast enough to scale very well - it would probably work fine for what you're doing, but once you got up to several hundred or several thousand connections and 5 or 10 nodes, waiting for a database write in order to determine the number of active (and, thus, available) slots for a connection may take too long. It may need to be done in memory on the hosts and then synced across the hosts. > > > Today we use Tomcat 8.5 (we can change it if necessary) and pfsense with > HAProxy enabled balancing between them (but no session persistence in case > of a crash or simultaneous access control). > > > Again, it isn't going to matter unless/until Guacamole's code is changed to implement this. -Nick
RE: High Availability in Guacamole Client
Hi Jonathan, I will be very thankfull if some can explain how guacamole manage session and licencing CAL device/user. I m using proxy apache with tomcat 7 and i have a crash with simultanoeus access (4 users).I have 3 servers and 400 potential users. I have no problem if users connect one by one. I m interesting of any advice, Thanks De : Jonathan Hankins Envoyé : mardi 9 janvier 2018 20:31 À : user@guacamole.apache.org Objet : Re: High Availability in Guacamole Client What are your users connecting to on the back end? I have a haproxy sitting between guacamole and our RDP servers (not using connection broker) and am using a combination of group policy session limits and mstshash cookie to create session "stickiness" for our users (i.e., always reconnect to your existing session, with failover.) -Jonathan Hankins On Tue, Jan 9, 2018, 12:28 PM Thiago dos Santos Nunes mailto:thi...@digitalinformatica.com.br>> wrote: I really need help with High Availability for the Guacamole client. 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. Let me give you an example: I have 3 frontend servers (client guacamole). And my users can connect in a certain connection only 3 at the same time (or 5 or whatever). But as each time a user connects in a frontend it falls on a different frontend these 3 connections can reach up to 9 (3 connections x number of frontend). Think about 20 diferent types of connections in one server Today for me to control the use of resources of the servers and the licensing is VERY DIFFICULT. I do not know much about programming and in our environment we can not deploy a solution like hazelcast (because of cost, very expensive). Today we use Tomcat 8.5 (we can change it if necessary) and pfsense with HAProxy enabled balancing between them (but no session persistence in case of a crash or simultaneous access control). Please if you could help me I would be VERY, VERY THANKFUL. Stay with GOD! Aude et Effice! [Assinatura E-mail] This e-mail is intended only for the recipient and may contain confidential or proprietary information. If you are not the intended recipient, the review, distribution, duplication or retention of this message and its attachments is prohibited. Please notify the sender of this error immediately by reply e-mail, and permanently delete this message and its attachments in any form in which they may have been preserved.
Re: High Availability in Guacamole Client
What are your users connecting to on the back end? I have a haproxy sitting between guacamole and our RDP servers (not using connection broker) and am using a combination of group policy session limits and mstshash cookie to create session "stickiness" for our users (i.e., always reconnect to your existing session, with failover.) -Jonathan Hankins On Tue, Jan 9, 2018, 12:28 PM Thiago dos Santos Nunes < thi...@digitalinformatica.com.br> wrote: > I really need help with High Availability for the Guacamole client. > > > > 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. > > > > Let me give you an example: > > > > I have 3 frontend servers (client guacamole). And my users can connect in > a certain connection only 3 at the same time (or 5 or whatever). But as > each time a user connects in a frontend it falls on a different frontend > these 3 connections can reach up to 9 (3 connections x number of frontend). > Think about 20 diferent types of connections in one server > > > > Today for me to control the use of resources of the servers and the > licensing is VERY DIFFICULT. > > > > I do not know much about programming and in our environment we can not > deploy a solution like hazelcast (because of cost, very expensive). > > > > Today we use Tomcat 8.5 (we can change it if necessary) and pfsense with > HAProxy enabled balancing between them (but no session persistence in case > of a crash or simultaneous access control). > > > > Please if you could help me I would be VERY, VERY THANKFUL. > > > > Stay with GOD! > > > *Aude et Effice! *[image: Assinatura E-mail] > > > -- This e-mail is intended only for the recipient and may contain confidential or proprietary information. If you are not the intended recipient, the review, distribution, duplication or retention of this message and its attachments is prohibited. Please notify the sender of this error immediately by reply e-mail, and permanently delete this message and its attachments in any form in which they may have been preserved.
