We have two remote data centers, separated 50km, with 2 Z CECs on each. We have 3 DASD copies, 2 on one DC, and 1 in the other. The key point is the GDPS MM3site Dual Leg between both data centers. During normal conditions, our production workload is only executed in one of the DCs, being resilient by having each CEC in two different isolated DC rooms, and having our sysplex spread across the 2 CECs. Even though our architecture is not totally mirrored, in case of unavailability of the only one DS8K box while we are on that remote DCs, we have also successfully tested Hyperswap to one of the remote DS8Ks. We are also considering having a 4th copy for total symmetry, but this is not possible while IDEA ZGDPS-I-221 is not granted:
https://ibm-z-software-portal.ideas.ibm.com/ideas/ZGDPS-I-221
In a planned planed role-swap (AKA Region-switch) scenario to the remote data center, this architecture is perfect as we obtain RPO=0 and RTO=0. In fact, we no longer name our DCs as Primary and DR, we perform role-swap every 6 months successfully and with zero impact for the business by doing the movement over a low activity time. This is also possible due to the Synchronous copy across the two DCs. In order to do this role-swap with RPO=RTO=0 we just select a low activity time over night/weekend, and we start moving LPAR by LPAR and CF by CF from one DC to the other until the whole sysplex is there. During that limited period of time our service times are elongated as we have cross-region CF requests, but there is no business impact as the activity is very low. Our business goal doing it this way is that, given that we do not stop provide service at any time and there is no business impact for our clients and there is none outage to be notified to regulators. On the opposite, for a role-swap with asynchronous copy that implies RTO different from Zero, we would have outage and our regulation establishes it needs to be notified to the regulator.
However, the trade-off of the Synch copy at distance is that we pay a higher CPU consumption and response times. Even though our businesses accept it nowadays, these concerns would be much alleviated by using asynchronous copy most of the time and, only making it synchronous at planned role-swap times.
The petition is the following: in an asynchronous scenario, could it be possible to have some mechanism to catch up in synchronous mode previously to the planned role-swap? An option in GDPS to “became synchronous” for some time, and then "return to asynchronous”.
This is basically the same idea that was raised by other client in the past:
https://ideas.ibm.com/ideas/ZGDPS-I-93