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: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
