When we migrated from our 8870 to the 8910 we used a similar approach. As a small shop (2 LPARs) we took an outage to do the actual swing. We used global mirror to replicate the 8870 to the 8910 (async replication between2 boxes 10 feet apart, across a couple fibers is really fast). We had fibers between the z14 and the 8910 already laid and ready to plug into the z. When the cutover came we shut down the z, unplugged the 8870 from the z, plugged the 8910 in the same Ficon ports and brought the z back up.
BTW, at least in our case (and our business partner said this is normal) IBM provided a no-charge limited license for global mirror for this express purpose. As far as the DR configuration, you may want to consider whether you want to use the 8884 for DR. They're falling off support at the end of this year. We currently have that exact configuration - an 8910 at the primary site and an 8884 at the DR site. We're looking at upgrading the 8884 - probably with another 8910 at DR. In our case, we are using a couple fiber channel ports out the back of the 8910 into a Brocade switch (IBM branded) and over our WAN link to the alternate site. A second Brocade takes the data into the 8884. Rex -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Timothy Sipples Sent: Friday, January 21, 2022 2:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: migrate from DS8884 to DS8910F Zoran Trifunović wrote: >We have two z14 and IBM DS8884 and ds8190f. Can you briefly explain how >to migrate from IBM DS8884 to ds891f using copyservice. >And another question how to make dr solution where IBM DS8884 and one >z14 would be dr center and ds8190f and z14 would be primary center also >using copyservices Richard Pinion wrote: >Not sure if this is the correct answer for you. But, we recently moved >all of our data from a Hitachi Data Systems G1500 box to a Hitachi Data >Systems 5100 (some say 5100 others say 5500) box. We used TDMF. Zoran, your first point of call ought to be the folks who sold you your IBM DS8190F storage unit(s). It's quite likely they would be able to advise you well on migration and DR options. That said, here's an introductory answer. I agree with Richard that TDMF is quite useful particularly if planned service interruptions are unacceptable or at least undesirable, and you want to reduce or eliminate outages. However, you mentioned Copy Services, so I'll answer that way. One basic approach for migration is: 1. You configure Global Mirror replication from your IBM DS8884 to your IBM DS8190F. Why Global Mirror? Because it's asynchronous, so it doesn't require as much forethought and planning since it's lower impact than synchronous replication. 2. After the Global Mirror pairing is humming along nicely, you shut down the IBM Z server. This can be on a LPAR by LPAR basis, typically starting with a Development LPAR. 3. You wait for Global Mirror replication to "drain," so that the target storage device is caught up to the primary. This shouldn't take long at all. 4. You sever the mirroring. 5. You swing the new storage unit (which now has all the replicated volumes) into the primary role. 6. You start up your IBM Z server again, LPAR by LPAR typically. (Migrating the storage volumes for each LPAR in turn.) 7. You decommission or repurpose your IBM DS8884. (Donate it to me! :-)) Storage growth is quite common, and ideally you would configure your new IBM DS8190F so that you'd use larger volume sizes, notably EAVs, for your next growth phase instead of assuming you add any more Mod9s or whatever. But of course you can carry forward the existing volume sizes. There are some more detailed specifics about how you attach the storage units (cables, ports, switches if any, etc.) Ideally you would have everything cabled up and ready to go so that you're not actually doing anything physically when you shut down and restart your IBM Z LPARs since that part tends to be time critical. Having both storage units available would also let you restart the LPAR(s) again with the IBM DS8884 if for whatever reason you can't relaunch the LPAR(s) on the IBM DS8910F. Disaster Recovery (DR) is another whole topic, and there are many choices available. The two big "numbers" for DR are Recovery Time Objective (RTO) and Recovery Point Objective (RPO). If you have consensus agreement in your organization what those metrics need to be, you should be able to configure and deploy an IBM Z environment that meets or exceeds them. RTO means basically "what is the maximum time delay tolerable to restore end user service in a disaster," and RPO means "what is the maximum tolerable amount of data loss (if any) for committed transactions in a disaster." For example: RTO = 4 hours RPO = zero (no data loss) would be one pair of objectives. To get to RPO = zero for transaction processing systems that exhibit at least tolerable end user responsiveness requires careful attention to the "fiber distance" between sites. It'd be wonderful to put one site in Zurich and the other in Vancouver, for example, but the fiber distance between those two locations imposes significant delays that don't really work for transaction processing systems typically found on IBM Z servers. (And on other servers too, for that matter.) If your primary and secondary data centers are at "metro distance" -- a few kilometers apart, or tens of kilometers -- then you can probably get to RPO = zero if need be. Beyond that it gets "interesting." (I happen to work with a few customers that need RPO=zero over intercontinental distances for very selective, extremely high value transactions. Can be done, but you have to be a little clever.) In certain circumstances you can get RTO down to zero, too, if need be. To get RTO down below several hours requires automation. Generally speaking you need a bigger budget and more operational excellence the lower your RTO and RPO numbers. Thus there's some balancing of costs versus risks, and that's ultimately a business decision (or public policy decision if you're a government agency). There's heightened interest in recovering from logical data corruption events given increasing malware and ransomware threats. That's a hot topic right now, and there are excellent IBM Z-based answers to defend against and quickly recover from all sorts of logical data corruption events. But whatever approach you take I would think about what your RTO and RPO needs are with respect to this class of disasters, too. All disasters count some, some more than others. Finally, DR is a journey for everyone. Some DR capability is better than none, and better is better. There are many customers that start with something basic then, over time, progressively improve it. OK, with that background, what sort of primary/secondary site fiber distance(s) do you currently have, and what are you thinking in terms of RTO and RPO? - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
