Scaling Guacamole to hundreds of concurrent RDP connexions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Scaling Guacamole to hundreds of concurrent RDP connexions

Charaoui, Jérôme
Hello,

For september we're considering a large Guacamole deployment with an estimated load of upwards to 500 to 600 RDP connections in an academic environment. It's expected a number of these sessions will be used for 3D graphics and graphics design software. I'm wondering if any of you might have insights to share about how to successfully pull this off?

Since we expect to have to face possibly extreme CPU load, we're looking to place guacd on a single high end bare-metal server with loads of cores such as the recent AMD Epyc series and dual 10GbE NICs.

Would it make sense to instead consider multiple servers and throw load balancing into the mix? I've read some suggesting to look into HAProxy, has anyone used it in the context of Guacamole?

What about the client components, would it be important to also put this on its own load-balanced hardware? At this point I'm leaning towards multiple instances of the client but sharing the same hardware/OS as guacd since that would save us managing the bandwidth requirements between guacd and the clients.

Thanks,

--
Jérôme Charaoui
Technicien en informatique
Collège de Maisonneuve

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Scaling Guacamole to hundreds of concurrent RDP connexions

Charaoui, Jérôme
Another issue I forgot to mention is, what tools could be used to simulate that number of connections, including activity of the remote desktop side?

--
Jérôme Charaoui
Technicien en informatique
Collège de Maisonneuve

________________________________________
De : Charaoui, Jérôme <[hidden email]>
Envoyé : 15 juin 2020 11:58
À : [hidden email]
Objet : Scaling Guacamole to hundreds of concurrent RDP connexions

Hello,

For september we're considering a large Guacamole deployment with an estimated load of upwards to 500 to 600 RDP connections in an academic environment. It's expected a number of these sessions will be used for 3D graphics and graphics design software. I'm wondering if any of you might have insights to share about how to successfully pull this off?

Since we expect to have to face possibly extreme CPU load, we're looking to place guacd on a single high end bare-metal server with loads of cores such as the recent AMD Epyc series and dual 10GbE NICs.

Would it make sense to instead consider multiple servers and throw load balancing into the mix? I've read some suggesting to look into HAProxy, has anyone used it in the context of Guacamole?

What about the client components, would it be important to also put this on its own load-balanced hardware? At this point I'm leaning towards multiple instances of the client but sharing the same hardware/OS as guacd since that would save us managing the bandwidth requirements between guacd and the clients.

Thanks,

--
Jérôme Charaoui
Technicien en informatique
Collège de Maisonneuve

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Scaling Guacamole to hundreds of concurrent RDP connexions

Joachim Lindenberg
I cannot comment on what type of machine you need for that load, but in any
case I´d prefer multiple instances over a SPoF - and often that is also a
cheaper hardware investment, but it takes you additional time to set it up,
but that investment also helps you when you need any type of servicing.
W.r.t. testing: you could have a login script or task that kicks in on
connecting and simulates a real user. I´d assume that load of keyboard is
negligible compared to graphics, therefore as a first iteration you may want
to record some real sessions before and then replay them using a browser.
Just putting this out as a starting idea, others are welcome to contribute..
Best Regards, Joachim


-----Ursprüngliche Nachricht-----
Von: Charaoui, Jérôme <[hidden email]>
Gesendet: Monday, June 15, 2020 6:20 PM
An: [hidden email]
Betreff: Re: Scaling Guacamole to hundreds of concurrent RDP connexions

Another issue I forgot to mention is, what tools could be used to simulate
that number of connections, including activity of the remote desktop side?

--
Jérôme Charaoui
Technicien en informatique
Collège de Maisonneuve

________________________________________
De : Charaoui, Jérôme <[hidden email]> Envoyé : 15 juin 2020
11:58 À : [hidden email] Objet : Scaling Guacamole to hundreds of
concurrent RDP connexions

Hello,

For september we're considering a large Guacamole deployment with an
estimated load of upwards to 500 to 600 RDP connections in an academic
environment. It's expected a number of these sessions will be used for 3D
graphics and graphics design software. I'm wondering if any of you might
have insights to share about how to successfully pull this off?

Since we expect to have to face possibly extreme CPU load, we're looking to
place guacd on a single high end bare-metal server with loads of cores such
as the recent AMD Epyc series and dual 10GbE NICs.

Would it make sense to instead consider multiple servers and throw load
balancing into the mix? I've read some suggesting to look into HAProxy, has
anyone used it in the context of Guacamole?

What about the client components, would it be important to also put this on
its own load-balanced hardware? At this point I'm leaning towards multiple
instances of the client but sharing the same hardware/OS as guacd since that
would save us managing the bandwidth requirements between guacd and the
clients.

Thanks,

--
Jérôme Charaoui
Technicien en informatique
Collège de Maisonneuve

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]