[wpkg-users] load balancing

Rainer Meier r.meier at wpkg.org
Mon Jul 27 21:10:10 CEST 2009


Hi,

Tomasz Chmielewski wrote:
> I did some experiments with multicasting (copy the file to the local
> machine using multicast), but it didn't work reliably and setup was
> complicated.
> 
> In reality, it perhaps makes sense to split the configuration into
> logical groups (rooms, floors etc.) - and deploy one after another
> (Monday - rooms 1xx, 2xx, Tuesday - 3xx etc.).
> This also prevents you from simple mistakes to some extent: if you made
> a package which doesn't start (i.e. uninstalls the old version, but
> doesn't install a new version, leaving you with no software installed),
> not all users will be affected.

I fully agree to the proposal and would like to add another possibility. If you
frequently need to deploy this amount of data it might even make sense to add
more servers to deploy the software. So groups of clients could access their own
local WPKG server. In easiest case even a workgroup NAS in an office could serve
local clients while WPKG updates are pushed using rsync or similar.

However I don't recommend this approach for large enterprises. It's more
suitable for small or medium sized companies with multiple locations where
remote traffic to the central server should be avoided.

So if your 1500 clients are on the same site as the server adding multiple
profiles to segment the roll-out looks suitable. The easiest way to achieve this
might be to duplicate your WPKG installation into multiple directories and
having each group of clients pointing to another installation. Just creating
multiple profiles is usually not enough since a package can by definition exist
only once in the package tree - so as soon as you update it all clients
referring to this package (no matter from which profile) will trigger an update.


Alternatively deploying more server power (load-balancers etc.) seems to me it
could be overkill since upgrading large packages like OOo is not an every-day task.

Another possibility which comes to my mind is: Why not running the upgrade
manually to spread the load?
Larger enterprises (like yours seem to be) quite often use hardware which
supports WoL (Wake On LAN). So just wake up the machines at midnight and let
them deploy the software. If you can't reach a few of them it does not matter a
lot because the remaining ones would not overload your server in the morning.
On clients which are already running you might remotely run the WPKG service to
initiate the deployment.

Hopefully this gives some hints.


br,
Rainer



More information about the wpkg-users mailing list