Managing Clusters Running on Different HXDP Versions

Managing Clusters Running on Different HXDP Versions

Scenario—Site A at HXDP 3.0 and Site B at HDXP 2.6

The following terms and abbreviations are used:

  • Site A—Source cluster

  • Site B—Target cluster

  • dr_cleanup tool—Contact Cisco TAC to obtain this tool available in the 3.0 internal support package.

Prerequisites

  • Before upgrading make sure, there are no VMs or groups in Recovered or Halted state.

  • If the VMs are in Halted State, recover and unprotect the VMs or groups.

  • If the VMs are in Recovered state, then unprotect the VMs or groups.

Step

Site A

Site B

Result

1.

At HXDP version 2.6 or lower.

At HXDP version 2.6 or lower.

2.

Upgrade to HXDP 3.0.

3.

Before upgrading Site B, if a disaster happens on Site A.

  1. Execute the command:

    stcli dp peer forget

  2. Recover VMs that are required.

  3. Run the dr_cleanup tool to delete all the VM information from the disaster recovery database.

Workloads are now running on Site B.

4.

Restore Site A.

After Site A is restored, do the following:

  1. Execute the command:

    stcli dp peer forget

  2. Run the dr_cleanup tool to delete all the VM information from the disaster recovery database.

Sites are unpaired.

5.

Upgrade to HXDP 3.0.

6.

Pair the sites.

Site A and Site B can now be re-paired and workloads can be protected.

Scenario—Site A at HXDP 2.6 and Site B at HXDP 3.0

The following terms and abbreviations are used:

  • Site A—Source cluster

  • Site B—Target cluster

  • dr_cleanup tool—Contact Cisco TAC to obtain this tool available in the 3.0 internal support package.

Prerequisites

  • Before upgrading make sure, there are no VMs or groups in Recovered or Halted state.

  • If the VMs are in Halted State, recover and unprotect the VMs or groups.

  • If the VMs are in Recovered state, then unprotect the VMs or groups.

Step

Site A

Site B

Result

1.

At HXDP version 2.6 or lower.

At HXDP version 2.6 or lower.

2.

Upgrade to HXDP 3.0.

3.

Before upgrading Site A, if a disaster happens on Site A.

  1. Execute the command:

    stcli dp peer forget

  2. Recover VMs that are required.

  3. Run the dr_cleanup tool to delete all the VM information from the disaster recovery database.

  • Not all recovery options are available.

  • See Functionality Limitations for more details.

  • Workloads are now running on Site B.

4.

Restore Site A.

After Site A is restored, do the following:

  1. Execute the command:

    stcli dp peer forget

  2. Run the dr_cleanup tool to delete all the VM information from the disaster recovery database.

Sites are unpaired.

5.

Upgrade Site A to HXDP 3.0.

6.

Pair the sites.

Site A and Site B can now be re-paired and workloads can be protected.

Functionality Limitations

Newer functionality in release 3.0 is supported ONLY when both the source and target clusters are on the same HXDP version. It can take a while during upgrade for both the source and target to be on the same version. Review the following functionality limitations:

  • Planned migration for VMs is not supported when peer sites have mismatched versions, such as when the target cluster is on 2.6, and source cluster is on 3.0.

  • When the source is upgraded, all the newer features in release 3.0, such as movein and moveout of group VMs, migration are blocked on the source cluster until the peer is upgraded.

  • If only the target cluster is upgraded, in HX Connect UI, Network Mapping options in the Recovery dialog box will not available until the source cluster is upgraded.