Just to add to Skip's comments; In the event of a Primary to Secondary XRC suspension (not unheard of) whilst you are running a DR test from the Tertiary, you must consider your DR test environment sacrificial. In this situation you should flash your Secondary to Tertiary (killing the DR test) so that you have a consistent (albeit aged) recovery position should you lose your primary site during the XRC re-sync window.
Andrew -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Skip Robinson Sent: 13 November 2013 23:20 To: [email protected] Subject: Re: Global Mirror for DR A terminology level set. By 'Global Mirror' I assume that you mean XRC, where a DFSMS task called SDM continuously transfers data updates from production disk controllers, stores the updates in journal data sets, then writes out to 'DR' DASD volumes in consistency groups. In order to 'pull' data via XRC, you need a running CPU at the DR location to host SDM. We've been doing this for most of this century ;-) using all IBM DASD, currently DS8* The minimum workable configuration requires a total of three DASD copies: Primary, Secondary, and Tertiary used as follows: Primary copy--the actual production family jewels that constitute business as usual Secondary copy--the 'mirrored' copy written out by SDM in consistency groups at the DR site Tertiary copy--produced by flash-copying the Secondary when you're ready to run your DR system(s) as test or for real The key is that you never touch the Secondary copy. You IPL your DR system(s) only from the Tertiary copy. That way you can run DR testing for as long as you like without disturbing the Secondary. You can refresh the Tertiary and reIPL whenever you wish because the Secondary is guaranteed to be a pristine copy of production. You do not need any other copies unless you have some other (unstated) goal in mind. In particular, you must never IPL from the Secondary. First, that would require terminating XRC, so your Secondary would become staler by the hour. Worse yet, you would have to resynchronize the Secondary at some point. During the resync window, you have *no* usable DR environment at all because the Secondary volumes remain in an unpredictable state until full mirroring is achieved. Depending on your technology, that may take many hours. To paraphrase Dirty Harry, Are you feeling lucky today, Dr Murphy? Does this configuration really work? We recently moved all of our production to another site. First the new site was set up as the DR site. All production was mirrored to this site's Secondary copy. Then we shut down production and brought up the DR systems on the Tertiary copy. These DR systems were tweaked to remove their 'DR-ness', then shut down and reIPLed as production. That's where we run today. I highly recommend GDPS to manage all this. We lumbered along for years with home grown processes. GDPS make it all much faster and more reliable. And don't forget about 'going back'. In a true DR situation, you probably want to return to the production site once it's usable again. The process is essentially the same in reverse. Don't forget additional DASD licenses for both XRC and flash copy. And you also need enough DASD at the production site to hold both Secondary and Tertiary copies for mirroring back. . . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Tom Sims <[email protected]> To: [email protected], Date: 11/13/2013 09:10 AM Subject: Global Mirror for DR Sent by: IBM Mainframe Discussion List <[email protected]> I am wading into Global Mirror for the first time, for a client interested in a 2-site disaster recovery solution, and it has been a challenge pulling "executive summary" details out of vendors and documentation. The production site is a multiple-LPAR, basic sysplex with DS8000 DASD, for which the goal is a remote mirror at a site with compatible hardware including a backup CPU. The client wants to be able to test DR procedures multiple times per year. Management understands, and more to the point so do I, I think, the need at the remote end for twice as much DASD capacity as locally, in order to maintain a consistency set comprised of the two primary copies and a second, "Flashed" copy at the remote site. Up to now we have collectively believed that remote Flashcopy-maintained set of volumes could be used to IPL remotely for DR testing purposes, without disrupting the global mirror between the local and remote primary DASD. Enter once again the vendors, who are now telling us that we will need a *third*, flashed copy for this purpose, in order not to disrupt the global mirror during testing. My understanding (and the standard disclaimers apply here!) is that DR can be tested remotely without IPLing from a copy of the copy, details admittedly TBD. If true, that the remote DS8300 requires not two but THREE times the DASD as in production locally, can someone out there please digest for me an executive explanation I could use to justify the increased cost to management? Thanks in advance, Tom Sims "Feedback is a gift." ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
