That should work, I am wondering why you are stopping with TSM replication
because as mentioned by Matthew moving away from the application
integration has it's downsides.
So can you share the reasons with us?
On the plus side, you get something close to continues replication so
things like DB log backups are offsite the moment they are done locally
something that TSM replication does not currently support.
For me, the biggest thing you lose is that you lose the recovery of damaged
data on the local server from the replica, an automatic mechanism with TSM
replication.
That would mean you have to have a copypool locally to protect the data in
the same way.
This would be an important point for me, if you are running the directory
containerpool the impact on housekeeping might be limited but I find the
impact of a large copypool with deduplicating file device type storagepools
to be a disaster.
On Fri, Apr 28, 2017 at 1:02 AM, Harris, Steven <
steven.harris AT btfinancialgroup DOT com> wrote:
> 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.
>
|
