.....(clip) so I was thinking of front-ending the collocated storage pools
with non-collocated pools,...
Isn't that called a diskpool??!? ;>)
Seriously, if you are worried about wear and tear, the easiest (and probably
cheapest) way to solve that problem is just to put a big enough pool of
inexpensive/ATA disks to hold the data until the weekend! No issues with
single-threading, either.
You can go ahead and make your offsite (non-collocated) copy pool backups
while the data is still in the disk pool, so you don't have any exposure to
failure in the disk pool.
WandaWanda Prather
"I/O, I/O, It's all about I/O" -(me)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Harris
Sent: Sunday, September 12, 2004 6:57 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Second level collocation
Hi All,
I'm contemplating the detailed design of the 30-odd major sites that I will
be installing.
These range from hundreds of nodes down to tens of nodes in size. The
biggest will run on AIX or Solaris servers, but most will be on Windows. (As
an aside I'd prefer Linux, but it costs three or more times what windows
does in support costs). I'd like as standardized a design as possible to
keep the complexity down.
I've defined 5 "recovery levels" RL1 through RL5, and there will be five
domains available. A server with any data classified at recovery level 1
will reside in domain RL1 and have access to mgmtclasses RL1 to RL5. A
server not in RL1 with any data classified at recovery level 2 will reside
in domain RL2 and have access to mgmtclasses RL2 to RL5, and so on.
Hopefully, only the critical portions of the data on any given client will
be classified at the higher levels, and the rest will back up to lower
levels.
Recovery level 1 implies a full server recovery (from a TSM point of view)
for a single server in 8 hours or less. This will require filespace level
collocation. RL2 is 24 hours and requires node level collocation. RL3 is 48
hours. RL4 is 72 hours and RL5 is > 1 week.
The idea is that the individual system admins can classify their own data.
RL1 is for very critical production, 2 for Critical production, 3 for normal
production, 4 for test/dev and non-critical production and 5 for retired
nodes.
Now the question is how to organize the collocation. I'd prefer from a wear
and tear point of view not to mount every tape every night (mostly SDLT), so
I was thinking of front-ending the collocated storage pools with
non-collocated pools, so that the collocation happens when the front-end
pool gets to a certain size, or maybe is scheduled over the weekend.
Now I realize that tape to tape pool movement is single threaded until 5.3
comes out, but other than that limitation, can anyone see any reason why
this would not work ? Will it have the desired effect? Is anyone doing
this?
On another front, am I too optimistic to think that local client
administrators will appropriately classify their data?
Your experiences on this front too will be helpful - particularly those
universities out there who have little control over your clients.
TIA
Steve.
Steve Harris
Systems Admin Consultant
Enterprise Backup Project
Queensland Health, Brisbane Australia
****************************************************************************
*******
This email, including any attachments sent with it, is confidential and for
the sole use of the intended recipient(s). This confidentiality is not
waived or lost, if you receive it and you are not the intended recipient(s),
or if it is transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email
in error, you are asked to immediately notify the sender by telephone or by
return email. You should also delete this email and destroy any hard copies
produced.
****************************************************************************
*******
|
