Re: Quick cfengine poll...

[Gregory P. Smith]

> view lack of ability) to scale to very large scale systems.  Could any
> of you out there give me some numbers in terms of systems which you
> are managing with cfengine.  Something like a cfengine client to cfd
> server ratio would be greate.  Anyone with systems spread over a wide
> area would also be a plus since in our situation we have host systems
> in various places around the US and Europe.

In my previous job our setup (which is still running according to my
friends still working there) had 300 or so clients all using a single
cfd server.  They would each make hundreds of requests to cfd once an
hour and the cfd machine (a sun ultra 2) never broke a sweat, its load
from cfd was always less than 0.10.

The important things in the setup were:

* make sure all clients poll at a different time.  We used cronjobs
  created on installation with a random minute after the hour.  I
  believe cfengine itself has some 'delay randomly' mechanism but we
  weren't using that.
* use checksum on files so that you only download new copies when
  things change (with better reliability than date synchronization).
* make sure the cfd machine is well connected.  This setup would use a
  significant portion of a 10mbit/second link due to the cfengine v1
  protocol being -way- more bandwidth intensive than it really needs
  to be (it always sends things in zero-padded 4k chunks, even if its
  only a short 42 byte query).  On a 100mbit/second link it worked
  flawlessly.  [protocol design issues are known and should be dealt
  with in cfengine v2]
* We used perl-cfd (http://perl-cfd.sourceforge.net/) as the cfd
  process.  If you have any stability issues with cfengine's cfd I
  recommend checking it out.  (note: perl-cfd doesn't support SSL)

As someone else suggested, with a multi tier setup (a handful of cfd
servers that get their updates for redistribution from one central
one) you could serve 100x more machines.  For a WAN situation just
making sure there is at least one cfd server in each major
installation site should be fine (and save on your expensive WAN
bandwidth).

-G

-- 
Gregory P. Smith   gnupg/pgp: http://electricrain.com/greg/keys/
                   C379 1F92 3703 52C9 87C4  BE58 6CDA DB87 105D 9163