Only Minor flaw I can see is having just one TSM server. If you mirror at
AIX level across sites and lose the server, the storage (at the secondary
site) will be inaccessable due to volume group locks created by the server
at the primary site. The only supported way around this is to implement a
HA/CMP cluster.
Cheers
Andy Wilcox
Midrange Services
Aquila Networks Services Ltd
> -----Original Message-----
> From: Steve Harris [SMTP:Steve_Harris AT HEALTH.QLD.GOV DOT AU]
> Sent: 14 April 2003 01:55
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Geographically diverse TSM server??
>
> 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.
> **********************************************************************
>
>
> **************************************************************************
> **************************
> Confidentiality: This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity
> to whom they are addressed. If you have received this e-mail in error,
> use of this information (including disclosure, copying or distribution)
> may be unlawful. Please notify postmaster AT aquila-networks.co DOT uk. and
> delete the message immediately.
>
> Security: Internet e-mail is not a 100% secure communications medium.
>
> Viruses: This e-mail (and any attachments) has been checked (using Sophos
> Sweep 3.63 + patches) and found to be clean from any virus infection
> before leaving.
> Therefore neither Aquila Networks Services Ltd nor Midlands Electricity
> plc or any of their group undertakings (as defined by the Companies Act
> 1989) (together referred to as the "Companies") accept legal
> responsibility for this message or liability for the consequences of any
> computer viruses which may have been transmitted by this e-mail.
>
> Monitoring: All electronic communications with the Companies may be
> monitored in accordance with the UK Regulation of Investigatory Powers
> Act, Lawful Business Practice Regulations, 2000. If you do not consent to
> such monitoring, you should contact the sender of this e-mail.
>
> Aquila Networks Services Limited,
> Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB
> Registered in England and Wales number 3600545
> This e-mail may be sent on behalf of any of the Companies.
> **************************************************************************
> **************************
|
