ADSM-L

Re: Conceptual question on ADSM scheduling

2000-07-08 11:03:45
Subject: Re: Conceptual question on ADSM scheduling
From: asr AT UFL DOT EDU
Date: Sat, 8 Jul 2000 11:03:45 -0400
Greetings, Daniel; welcome.

=> On Fri, 7 Jul 2000 12:56:13 -0700, Daniel Swan/TM <Daniel.Swan AT TELUS DOT 
COM> said:

> Lets assume I backup 15 NT servers, all of them associated with a schedule
> named "NT-DAILY", which kicks off at midnite sharp, Doesn't this cause a
> huge spike in load at midnight sharp?  Is there a better way to spread this
> load, or do I have to create different schedules like: "NT-DAILY-1AM",
> "NT-DAILY-2AM", and associate them with a few servers each?

> It seems a bit ludicrous to me that similar servers will be backed up
> simultaneously..... can anyone clarify this for me?


Several people have discussed the advantages of spreading start-times.  I'll
present the other side:

We've got a large number of distinct administrative divisions which are served
by our *SM server.  We _do_ spread start times between divisions. e.g.:

Workstations window opens at 8
Middleware-servers window opens at 9
Office of the Registrar, 10
SP cluster at 11
Campus mail
campus web
blah blah blah.

but within divisions we have everything kick off more-or-less simultaneously.

The TSM database is, indeed, the bottleneck for startups. I don't care, it's
my service, and I can thrash it if I want to :)

But all ~150 workstations in my biggest policy domain, working together,
simultaneously, can't do incrementals fast enough to choke any intermediate
resource.

I'll rephrase that in the general case:

For most client incrementals, the bottleneck for session speed is the ability
of the client to find the next file it wants to send.  This is a good thing.

(This depends on having disk pools as your landing pad.  If you only have
serial devices, the equation is all different)

Of course, servers with DB backups, and other goop like that, can saturate a
100M switched segment if they have a mind to.  My generalization does not
extend to them; my server policy domains are much smaller (~16-20 boxen) so
they still run simultaneously, but the multiplier is much lower.



OK, so I've asserted that for some classes of backup, you _can_ pack many
incrementals into "simultaneous" operations.

Why do you care?

Because, as your load grows to infinity (as Moores law asserts, and most of
our experience supports) you have confined the "backup" operation to as small
a segment of the 24-hour cycle as is possible.

This means that, as you develop broader backup needs, you have maximum
scheduling flexibility.

You have the largest amount of wall-clock time to rearrange storage,

The
smallest possible window during which an outage will damage your backups.