hypflsho

8/13/2019 hypflsho

http://slidepdf.com/reader/full/hypflsho 1/2

Avoiding Potential Data Loss When Using the z/VM Hyperswap

function and FlashCopy

Abstract

IBM has identified a hardware configuration which could affect z/VM users, z/VM guests and other System zoperating systems using the combination of HyperSwap and Flashopy replication and certain IBM dis!subsystem logical configurations" Specifically, there is a small timing window in which a Flashopy replicationcommand e#ecuting during a dis! swap operation could be redirected to the other dis! subsystem $i"e", the%%& partner dis! subsystem' and incorrectly o(erwrite data on this dis! subsystem that was not intended to beo(erwritten" )his issue is not specific to any particular release or le(el of z/VM, nor any particular release orle(el of IBM dis! subsystem hardware or licensed internal code $*I', nor any particular release or le(el of dis!swap enablement software $+%S or IBM )i(oli Storage %roducti(ity enter for &eplication'"

Details

)he following users are not affected-

• .sers that do not use HyperSwap

• .sers that do not perform Flashopy from their %%& de(ices $neither their primary nor their secondary%%& de(ices'"

• .sers that only perform Flashopy from their %%& de(ices when the %%& pairs are suspended $e"g", fordisaster reco(ery testing or prior to a resync operation'"

)his issue will also only arise in the conte#t of specific dis! subsystem configurations" Specifically, the logicalsubsystem $*SS a"!"a" control unit address/.0' and the channel connection address $0' used for the%%& primary and secondary de(ices must meet certain criteria"

1" If the *SS/0 for each and e(ery %%& primary de(ice is different than the *SS/0 for its correspondingsecondary de(ice then Flashopy commands issued during the swap window will be re2ected by IBM dis!subsystems causing the operation to fail but there are no data o(erwrite implications" &efer to %age 1 of theattached file"

3" If the *SS/0 for each and e(ery %%& primary de(ice is the same as the *SS/0 for its correspondingsecondary de(ice, then-

 0" If the Flashopy target (olume is a %%& de(ice, then this issue will not arise" &efer to %age 3 of theattached file"

B" If the Flashopy target (olume is not a %%& de(ice and no de(ice e#ists in the %%& partner dis!subsystem that has the same *SS/0 as the Flashopy target de(ice, then Flashopy commandsissued during the swap window will be re2ected by IBM dis! subsystems causing the operation to fail, butthere are no data o(erwite implications" &efer to %age 4 of the attached file"

" If the Flashopy target (olume is not a %%& de(ice and a de(ice does e#ist in the %%& partner dis!

subsystem that has the same *SS/0 as the Flashopy target de(ice, then Flashopy commandsissued during the swap window will o(erwrite the de(ice, in the %%& partner dis! subsystem, that hasthe same *SS/0 as the Flashopy target de(ice" )his is not an issue if this de(ice in the %%&partner dis! subsystem is a Flashopy target de(ice" Howe(er, if this de(ice is intended for otherpurposes, then a Flashopy operation that is issued during the HyperSwap window can o(erwrite dataon this de(ice" epending on the data in(ol(ed, this could cause impacts including system outages orloss of application data" &efer to %age 5 of the attached file"

4" If there is a mi# of matching *SS/0s and mismatching *SS/0s for the %%& primary and secondaryde(ices within a dis! subsystem pair, then a Flashopy operation that is issued during the swap window cano(erwrite data on a (olume other than the one intended" )his is true regardless of whether or not the

8/13/2019 hypflsho

http://slidepdf.com/reader/full/hypflsho 2/2

Flashopy target de(ice is a %%& de(ice" epending on the e#act data in(ol(ed, this could cause impactsincluding system outages or loss of application data" &efer to %age 6 of the attached file"

Mitigation

)he issue can be a(oided by adhering to the following recommended dis! subsystem configuration" )herecommended configuration is one in which the *SS/0 for each and e(ery %%& primary de(ice is the same

as the *SS/0 for its corresponding secondary de(ice" 7ith this configuration, users that are performingFlashopy operations from %%& de(ices to non8%%& de(ices must also ensure that all de(ices in the %%&partner dis! subsystem that ha(e *SS/0s that match the Flashopy target (olumes are intended forFlashopy"

 0 configuration in which the *SS/0 for each and e(ery %%& primary de(ice is different than the *SS/0 forits corresponding secondary de(ice also circum(ents the issue" 7ith this type of configuration, Flashopycommands issued during the swap window may fail but there are no data o(erwrite implications"

 0n e#isting dis! subsystem configuration that is e#posed to the issue can be reconfigured without a loss ofaccess to the %%& primary production (olumes, but with a disruption to the swap/disaster reco(eryen(ironment, using the following procedure-

5" )erminate the %%& pairs"

6" &econfigure the secondary dis! subsystem as re9uired":" &e8establish the %%& pairs and perform a full copy"

Resolution

)his issue is resol(ed for z/VM users and z/VM guests by 0%0& VM:6;63" %)Fs will be pro(ided for z/VMreleases 6"5, :"3 and :"3" )arget a(ailability is ecember <th, 3;11"

)he 0%0& te#t will be updated with the details of the solution when they are a(ailable"