[Systems] Randomised backup - puppet
David Farning
dfarning at gmail.com
Sat Feb 27 11:15:36 EST 2010
On Sat, Feb 27, 2010 at 9:52 AM, Sascha Silbe <
sascha-ml-ui-sugar-systems at silbe.org> wrote:
> On Sat, Feb 27, 2010 at 09:20:28AM -0600, David Farning wrote:
>
> [Backup timing]
>
> We have a number of options for dealing with this issue. The first and
>> easiest to implement is to have puppet pick a time random(X) minutes after
>> midnight local time to trigger a job. (The same can apply to build runs)
>>
> How long is a single backup run?
> For the buildslaves (which took ~1h for all packages when run in parallel)
> I've assigned start times manually, 2h apart -- this gives plenty of room to
> grow and the current trend is less packages, not more as our dependencies
> finally start appearing (in suffciently recent versions) in the distros.
> This (manual schedule) gives fully deterministic resource usage without
> spikes / bursts.
>
>
> Non-deterministic things seem like they might be evil to the sysadmin way.
>>
> Full ack. :)
I guess that this is an example of the simple, cheap and obvious answer
_not_ being the best. :) I'll set if puppet can handle a construct such as:
for node in nodes_to _be_backed_up{
set node backup_start_time = midnight + delay
delay = delay + delay_interval
}
> But, one area it might be useful is providing build VMs 'on demand'
>>
> Is it worth the effort? Would using some Cloud stuff reduce the overhead on
> bender significantly?
The answer might very well be yes as each KVM instance tends to take a few
> percent of CPU (with Fedora seeming to take about twice the amount the
> Debian ones do) for a reason I haven't investigated yet.
> As of now I'm unsure whether
>
> a) investigating the cause of the background CPU consumption and fixing it
> if possible (e.g. NOHZ / dyntick / tickless timer) or
> b) instantiating VMs only on demand (how does this work? will cron jobs
> continue to work?)
>
c) what about memory? My limited understand is that because the vm never
fully sleeps, much of the vm remains in memory rather than swapping out.
> will provide better bang-for-buck.
>
+1. In my mind, the only reason for for using eucalyptus is if it provide a
sane and easy method of instantiating vms on demand. It has been rather
difficult to figure this out. One has to wade though a lot of marketing
propaganda to find any useful articles on clouds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/private/systems/attachments/20100227/47b17223/attachment.htm
More information about the Systems
mailing list