Cascaded Incremental Resynchronization

Edit online

This enhanced functionality, introduced in version 9.4.0 and above, enables Incremental Resynchronization for cascaded PPRC relationships.

Cascaded Incremental Resynchronization use cases

Cascaded Metro Global Mirror (3-site or 4-site)

  • Replaces the existing Metro Global Mirror Incremental Resynchronization Incremental Resynchronization process.
  • Retains the Metro Mirror relationship on the primary avoiding the requirement to copy data from the Global Mirror secondary site.
  • Supports the existence of multiple cascaded PPRC relationships which is not the case with MGM Incremental Resync.
  • Provides an explicitly visible CIR relationship which can be queried to show the OOS tracks target device etc.

Cascaded Global Copy from Metro Mirror

Provides a simpler mechanism for the current cascaded Global Copy migration.

Cascaded migration avoids sending bulk data over the x-site links and extra load on the primary.

Enables Incremental Resynchronization for an unplanned failure of the Metro Mirror secondary – this is not a current scenario but could exist in a 4-site MTMM environment or a reversed 3-site MMTM.

Cascaded Global Copy from Global Mirror

  • Provides a simpler mechanism for the current cascaded Global Copy migration.
  • Cascaded migration avoids sending bulk data over the x-site links and extra load on the primary.
  • Enables Incremental Resynchronization for an unplanned failure of the Global Mirror secondary in a 4-site MGM environment.

Enhanced Cascaded Incremental Resynchronization

Provides enhanced cascaded incremental resynchronization functionality, leveraging multi-target PPRC and supporting various types of cascaded relationships. It enables incremental resynchronization following a Global Mirror secondary failure in a 4-site environment, and allows for local resynchronization of Metro Mirror after a cascaded Incremental Resynchronization in both 3-site and 4-site setups. Additionally, it provides functionality to support a 6-site MTMM and GM topology. This is facilitated by a new Cascaded Incremental Resynchronization relationship, as shown in Figure 1, similar to MTIR, with the DS8000 performing validation both when the relationship is created and during incremental resync operations.

Figure 1.

Establish Cascaded Incremental Resync Relationship

Establish a Cascaded Incremental Resync (CIR) relationship from RS1 to RS3, as shown in Figure 2:
  • Utilize PPRC failover to create the CIR relationship.
  • Allow establishment without paths by creating a placeholder CUTAB.
    Note:
    • Failure if an existing cascaded IR relationship is present.
    • Failure if the limit of allowed PPRC relationships (4) is reached.
    • Failure if RS1, RS2, and RS3 do not all exist.
RS1 to RS3 is displayed as a Suspended Cascaded IR relationship on RS1:
  • This is akin to the current MTIR relationship.
  • Only one relationship of this type is permitted per volume.
  • It can be queried in the same manner as any other PPRC Relationship.

To create a CIR relationship from RS1 to RS3, RS2 must also be CIR-capable (R9.4 or later). RS3 does not have this requirement; however, software may impose additional restrictions to ensure recoveries in any direction.

Figure 2.

Toggling

  • The cascaded IR relationship features a toggling OOS N and N-1 bitmap, the same as an MTIR relationship.
  • Toggling is based on an in-band query from RS1 to RS2, and then to RS3, as shown in Figure 3. RS2 maintains a new counter to indicate when data is moved to RS3. CIR regularly queries this counter and toggles its own bitmap accordingly.
  • The counter on RS2 is updated according to the criteria used for MTIR, whether for Global Mirror or Global Copy, as it transfers data to RS3.
Figure 3.

Incremental Resynchronization

  • Failover from RS3 to RS2, so RS3 is no longer the secondary.
  • Suspend the RS1 to RS2 relationship if it is not already suspended – this is not strictly required unless there are already two active relationships on RS1.
  • Establish the RS1 to RS3 relationship with failback:
    • Validate that RS3 is a suspended primary relative to RS2.
    • Merge RS3 to RS2’s OOS bitmap into the CIR’s OOS bitmap.
    • Merge the RS1 to RS2’s OOS bitmap into the CIR’s OOS bitmap.
    • Merge CIR’s N-1 OOS bitmap into CIR’s OOS bitmap.
    • Convert RS3 into a secondary relative to RS1.
    • Change the RS1 to RS3 relationship from CIR to Duplex Pending.
Figure 4.

Terminating the Incremental Resynchronization Relationship

  • If the RS1 to RS2 relationship is terminated, the cascaded IR relationship will also be terminated.
  • If the CIR detects that the RS2 to RS3 relationship has been terminated, toggling will cease, but the CIR relationship will remain.
  • The CIR relationship can be directly terminated in the same manner as any other PPRC relationship.
Figure 5.

DSCLI and GUI

CLI

To establish CIR, use the -cir flag in the failoverpprc command. For example: 
dscli> failoverpprc -remotedev IBM.2107-1300721 -type gcp -cir 0000-000f:0400-040f
Note: CIR primary is directly visible via lspprc.

GUI

The CIR primaries are directly visible, as shown in Figure 6.

Figure 6.