guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Couchman (JIRA)" <>
Subject [jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
Date Sun, 19 Mar 2017 21:14:42 GMT


Nick Couchman commented on GUACAMOLE-102:

So, I started working on implementing this within the JDBC authentication module.  Here's
my current working tree:

My current progress just involves adding the weight field to the DB schema and then getting
it to show up in the connection settings interface.  Have not done the actual WRR algorithm,
yet.  Also, the current 

Here are some notes and follow-up questions...

Pretty much anything of the form "add a ___ which is ignored for all but ___" makes me squirm.

Okay, I get this...but this particular attribute is really only applicable if you have a connection
that is part of a balancing group.  It won't be used on individual connections, and won't
be used in organizational groups.  Maybe "ignore" is the wrong word - it seems like adding
this field to the JDBC module and schema, but hiding it from admins when the current connection
is not part of a group of type BALANCING seems to be the least confusing to the user/admin.

Connection attributes are the current mechanism for exposing arbitrary data. That said, if
this balancing mechanism will remain internal to the database auth (as it is currently), then
there is no need to expose the weight at all. It could easily just exist within the database
schema and the internal objects, rather than at the API level.

I went ahead and implemented this as a connection attribute.  It currently shows up in the
"Concurrency Attributes" section...which kind of fits, although I'm not sure that's a good
long-term place.  As far as exposing it or not, it seems like you probably want this to be
accessible via manual configuration (which is what I've done thus far) - some people might
want to manually set up the weight used for given servers, while others will employ an automated
method of adjusting it.

...Rearchitecting the webapp in that way would naturally involve exposing the creation and
balancing of connections at the REST level.

I'm going to proceed with just trying to get this implemented in the JDBC connection at this
point.  I'm just getting comfortable with the webapp and REST stuff, and that seems like biting
off a little more than I can chew at the moment.  If we go this route, eventually, maybe my
work won't be a total waste of time, but, if nothing else, it gets me a little more familiar
with the code and the relationship between the servlet and the AngularJS app...which is something
I've had an oddly hard time wrapping my mind around.

A default of 1 seems wonky to me for a couple reasons...

Definitely good points, here.  Here's what I propose:
- Weight should be done with higher values equaling more preference - so, 1 is less preferred
than 100 which is less than 1000.  The scale should be fairly arbitrary to Guacamole - we
don't care of the admin wants to use a scale of 1-100 or 1-1000 or 1000 to 2000, etc. - we
just use higher numbers to indicate preference.  This should build in scalability - 5 nodes
can be on a scale of 1-10, while 1000 can use a larger scale.
- Negative values should indicate problems with the server that cause it to be ignored in
scheduling.  This would be valuable both for automated balancers, that could fill in a negative
value if the server is down, and also for administrative purposes - you could use a negative
number to manually disable a server for maintenance.  Furthermore, integrating this with an
automated load checking mechanism, you could use a couple of possible values to avoid admins
stepping on the balancer and vice-versa - so -1 can indicate the balancer mechanism cannot
reach the server and has disabled it; -2 can be administratively disabled (and the load balancer
will ignore that server), etc.
- 0 should be a server that is part of an automated load monitoring mechanism, but has not
been polled yet, and should not be used for connections, yet.
- null should be a server that's not part of a weighted connection and just gets scheduled
in a least-connection-first, which is essentially what the current balancing mechanism does.
- Null or zero can be the default.

As far as monitoring goes, a few questions/comments here:
- Should the automated monitoring be something inside the Guacamole client, on the servlet
side?  Maybe something similar to the way the check for expired sessions currently works where
there's an implementation of Runnable that polls every so often?  This would probably be fairly
easy as I'm sure there's a Java SNMP implementation available, and it would have pretty easy
access via the Java code to alter the database fields.
- Or, should the automated load monitoring be a separate executable?  Something like guacd,
written in C, and that then can hook back into the database via either the Guacamole REST
API or a dedicated connection?  I don't like this route as much - I don't like adding some
other component just to add it - but not if there are any gotchas with implementing the load
balancing on the Java side.

Comments?  I'm not particularly attached to any of this, just continuing to throw some ideas
out there to see where everyone thinks this should go.

> Load balancing based on resource
> --------------------------------
>                 Key: GUACAMOLE-102
>                 URL:
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole, guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql,
guacamole-client, RDP
>    Affects Versions: 0.9.10-incubating
>         Environment: CentOS Linux 7 (Core)
> Linux 3.10.0-327.10.1.el7.x86_64
>            Reporter: Werner Novak
>            Priority: Minor
> Implementation of an resource based (CPU, Memory, I/O, Loggedin User) balancing in opposite
to the current implemented guacamole connections round robin. This is needed because of an
large RDP infrastructure (300+ TS), where the terminal server been accessed via multiple RDP
load balancers during migration.
> A prototype has been developed in a guacamole fork

This message was sent by Atlassian JIRA

View raw message