ADSM-L

Re: Geographically diverse TSM server??

2003-04-13 21:16:19
Subject: Re: Geographically diverse TSM server??
From: Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 14 Apr 2003 10:54:57 +1000
I'm soon about to embark on such an odessey.

Two full-strength high-caffiene computer centres too close together but that 
cant be helped.  Shark disk arrays in both connected by dual san fabrics and 
diverse routing.

Application is SAP DB2 (and some oracle stuff too).

All production application disk will be mirrored over the two sites at the AIX 
level - its too expensive to run the dedicated fibre or multiplexers that PPRC 
requires.
For TSM I'm going to have one server and two tape libraries, one at each site 
with the copypools on the remote 3494.  Log and DB disk will be mirrored by 
AIX.  Disk storage pools will be split over two Volume groups, one at each 
site. 

In the event of a problem at the main site, the TSM Server takes over a 
development partition at the second site, we have the mirrored copies of the DB 
and logs and ½ the diskpool to do backups with. 

At least that's the theory.    If you can see any flaws in this scheme I'd be 
pleased to know.  There is a small window where we could lose data on 
diskpools, but I can't justify mirroring them too.

Regards

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia.

>>> <asr AT UFL DOT EDU> 12/04/2003 2:23:56 >>>
Greetings, all.

I'm working on a plan to accomplish the charge to back up a database such that
"No committed transaction is lost", in the case of a disaster.  Beginning to
noodle around the corner cases of the process, it occurred to me that a SAN
environment could make for several interesting possibilities.  For example,
how many of you:

- Put the various mirrors of your database volumes in different buildings?

- Mirror (at the OS level) storage pool volumes?
  (of course, I'm talking here about different buildings too)

Would those of you who have sharks choose shark-y replication before you'd do
these other things?

The trick is that, as soon as TSM feels that it's finished storing a file, I
need to be confident that a single-site disaster will _not_ lose me the file
(for this particular class of file: DB/2 Transaction logs...)  That means the
storage pool, the DB, the DB logs, everything needs to be at least a little
geographically diverse -right- -then-.


- Allen S. Rout



**********************************************************************
This e-mail, 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 e-mail 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 
e-mail in error, you are asked to immediately notify the sender by 
telephone or by return e-mail.  You should also delete this e-mail 
message and destroy any hard copies produced.
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>