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