[jira] [Comment Edited] (GUACAMOLE-102) Load balancing based on resource

["Nick Couchman (JIRA)" <ji...@apache.org>]

    [ 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: nick.couchman@yahoo.com):
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)