You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@guacamole.apache.org by "Michael Jumper (JIRA)" <ji...@apache.org> on 2017/03/04 22:10:46 UTC

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

    [ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15895894#comment-15895894 ] 

Michael Jumper commented on GUACAMOLE-102:
------------------------------------------

{quote}
* Implement a connection weight field for individual connections, but only reference it when the connection is part of a Connection Group of type BALANCING. ...
{quote}

I don't love the idea of adding an arbitrary weighting field which is ignored for all but balancing groups, especially since the balancing algorithm itself is not dictated by the API (it's left up to the extension implementation).

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

{quote}
... I haven't dug into the parameter vs. attribute vs. arbitrary data issue mentioned in the commit request, but a simple connection weight field that is a positive integer should do the trick.
{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.

Allowing extensions to expose REST endpoints could also provide an arbitrary way for services to note that connections are available vs. under load.

Taking a major step back from the specific idea of load balancing, it may be worth contemplating moving some of the duties of the extension (establishing connections to guacd, implementing balancing, implementing sharing, enforcing permissions, etc.) out of the exclusive domain of extensions and into the web application. Rearchitecting the webapp in that way would naturally involve exposing the creation and balancing of connections at the REST level.

{quote}
Tweak the Guacamole balancer algorithm from round-robin to weighted round-robin, where the default weight of each connection is 1 if not defined, can be set manually for the connection, or can be externally manipulated.
{quote}

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

# If we simply want to have connections sort deterministically based on an arbitrary weight, then you _can_ have a comparator which takes {{null}} into account and sorts it as the highest/lowest possible value, depending on the intent of this weighting. There's no need to have {{null}} be numerically equal to an actual legitimate value.
# If the idea is that an external process will be updating the weighting of each connection, then the lack of a value may well be a bad thing (the remote desktop is so horribly down that the yet-to-be-determined monitoring process is not even pinging the server). It might be better to exclude such connections entirely.

{quote}
... there might be some other existing ways to monitor load that don't require reinventing the wheel.
{quote}

I wholeheartedly agree.


> 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)