I am trying to wrap my head around the concept of the buddy update, so I am hoping someone can explain the use case. Is it for very large deployments, so not all updates (firmware) come from a single UMS server? Almost like a firmware updater load balancer?
Hi Barry. The concept is described here kb.igel.com/igelos-11.03.500/en/buddy-update-27245623.html
The idea behind is that e.g. a branch has 200 endpoints, so without buddy update server all 200 will contact UMS and download the new firmware (200 x 1.5 GB over WAN).
With BUS one endpoint in the branch will download the new firmware (1 x 1.5 GB) and all the other 199 will pick it up from that endpoint – so less bandwidth usage, LAN connected.
Unless something has changed, the one issue we see with the buddy setup is that one can’t reboot the machine. I get the reasoning as it needs to be up for other machines to pull the firmware, but there are times a machine needs rebooted. There should be an option for an admin to reboot it.
So, are we not just transferring the problem of overloading the UMS to overloading the buddy server?
Yes the endpoint functioning as a BUS has to be online all time, same as a Wake-on-LAN-Proxy.
Or is this a WAN savings play?
OK – I think I got it now. Thanks @member and @member
WAN saving if the connection is unstable or minimal bandwidth. And update is faster as everything is in the branch-LAN
I think there might be a use case for us. We have moves UMS to AWS, so pulling down firmware updates can get pricey. I assume you can have more than one buddy server? If so, how does the TC choose which buddy server to connect to?
of course you can – we’re IGEL 🙂
Buddy server candidates
kb.igel.com/igelos-11.03.500/en/configuring-the-buddy-update-client-27245636.html
Excellent – thanks again
I guess one other thing is it would be nice if it wasn’t required that it enable all features on the master. We disable unused features in our environment, but a master device will have them all in case another device needs them. I get that, but it still would be nice to not have a device with things we don’t want enabled.
Perhaps an idea for the igelcommunity.slack.com/archives/C8G21NV53
I’ve submitted it before
> We have moves UMS to AWS
Wow cool, so basically UMSaaS? 😄
kinda/sorta!
We use the “Masters” in our company and update/restart them out of band with our “Buddy” clients. Its worked quite well for us.
Is there an easy way to confirm that the updates are being pulled from the buddy server, and not UMS?
when we tested with it, we looked at the WAN traffic for that office
Hrmmmmm – there has to be an easier way….
probably, but it’s pretty easy to do in our environment.
@member Do you know of any way to validate that the update is being delivered via buddy server and not UMS?
You could turn off the buddy server and try updating it. The clients will fail trying to update.
That would do it! Good call.
@member valid point. From the UMS itself no, but on the device. I’m checking where.
This command may help:
Continue reading and comment on the thread ‘What is the IGEL Buddy Update feature?’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!