Ricky
I have something similar at my current gig.
Database and landing storage pools are on V840 flash and migrate to Protectier
VTL. The V840 data is remote copied and the VTL uses its own replication
mechanism. Recovery is to bring up the instance on hot AIX LPARs using the
replicated database at the remote site. This is used for multiple TSM
Servers, in both directions.
DR has been tested twice by others, and appears to work. I'll find out for
myself in a week or so, change control willing.
Cheers
Steve
Steven Harris
TSM Admin/Consultant
Canberra Australia.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matthew McGeary
Sent: Friday, 28 April 2017 6:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DR Rebuild please chime in.
If I'm understanding correctly, your DR site will have a storage-level copy of
all your TSM storage pools, database, logs, etc.
In that case, yes, what is being proposed should work. However, you're trading
a replication that can be monitored and validated to a storage-level model that
isn't application aware.
AND, if you're not doing anything on the DB2 side during replication (ie:
quiescing) then the server will do a crash-recovery startup at the DR site.
Crash-recovery has always worked for me in DB2, but it's not as fool-proof as
DB2 HA/DR replication, recovering from a DB2 backup or using the TSM
replication that you're ripping out. There may come a time when you do a DR
test or actual DR and your TSM database won't recover properly from that
crash-level snapshot. Then what do you do?
Why in god's name is this change happening?
__________________________
Matthew McGeary
Senior Technical Specialist - Infrastructure Management Services PotashCorp
T: (306) 933-8921
www.potashcorp.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Plair, Ricky
Sent: Thursday, April 27, 2017 1:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] DR Rebuild please chime in.
All,
Our last DR was a disaster.
Right now, we do the TSM server to TSM server replication and it works fairly
well but, they have decide we need to fix something that is not broken.
So, the idea is to upgrade to SP 8.1 and install on a zLinux machine. Our
storage is on an IBM V7000, and where we were performing the TSM replication,
we are trashing that and going to IBM V7000 replicating to V7000.
Now, the big twist in this is, we will not have a TSM server at our DR
anymore. The entire primary TSM server will be backed up to the V7000 and
replicated to our V7000 at the DR site.
There is no TSM server at the DR site so, IBM will build us one when we have
our DR exercise and then according to our trusty DB2 guys we should just be
able to break the connection to the Primary TSM server, do a little DB2 magic
and WOLA the TSM server will be up.
This is my question, if the TSM server is built in DR and the primary TSM
servers database in on the DR V7000, then that database will still have to be
restore to the TSM server. You're not going to be able to just bring it up
because its DB2 and point to the TSM server and it work, right?
Please let me know your thought's. I know I have left a lot of details out but
I'm just trying to get some views. If you need more information I will be happy
to provide it.
I appreciate your time.
Ricky M. Plair
Storage Engineer
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
CONFIDENTIALITY NOTICE: This email message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information and/or Protected Health Information (PHI) subject to
protection under the law, including the Health Insurance Portability and
Accountability Act of 1996, as amended (HIPAA). If you are not the intended
recipient or the person responsible for delivering the email to the intended
recipient, be advised that you have received this email in error and that any
use, disclosure, distribution, forwarding, printing, or copying of this email
is strictly prohibited. If you have received this email in error, please notify
the sender immediately and destroy all copies of the original message.
This message and any attachment is confidential and may be privileged or
otherwise protected from disclosure. You should immediately delete the message
if you are not the intended recipient. If you have received this email by
mistake please delete it from your system; you should not copy the message or
disclose its content to anyone.
This electronic communication may contain general financial product advice but
should not be relied upon or construed as a recommendation of any financial
product. The information has been prepared without taking into account your
objectives, financial situation or needs. You should consider the Product
Disclosure Statement relating to the financial product and consult your
financial adviser before making a decision about whether to acquire, hold or
dispose of a financial product.
For further details on the financial product please go to http://www.bt.com.au
Past performance is not a reliable indicator of future performance.
|
