[
https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931966#comment-15931966
]
Nick Couchman edited comment on GUACAMOLE-102 at 3/23/17 3:52 PM:
------------------------------------------------------------------
So, I started working on implementing this within the JDBC authentication
module. Here's my current working tree:
https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-102
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.
Here are some notes and follow-up questions...
{quote}
Pretty much anything of the form "add a ___ which is ignored for all but ___"
makes me squirm.
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
...Rearchitecting the webapp in that way would naturally involve exposing the
creation and balancing of connections at the REST level.
{quote}
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.
{quote}
A default of 1 seems wonky to me for a couple reasons...
{quote}
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.
was (Author: [email protected]):
So, I started working on implementing this within the JDBC authentication
module. Here's my current working tree:
https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-102
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...
{quote}
Pretty much anything of the form "add a ___ which is ignored for all but ___"
makes me squirm.
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
...Rearchitecting the webapp in that way would naturally involve exposing the
creation and balancing of connections at the REST level.
{quote}
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.
{quote}
A default of 1 seems wonky to me for a couple reasons...
{quote}
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: https://issues.apache.org/jira/browse/GUACAMOLE-102
> 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
> https://github.com/wnovak/incubator-guacamole-client.git
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
