Matrix Co-Existence with VMware vCenter Site Recovery Management (SRM)

Technical white paper | Matrix Co-Existence with VMware vCenter Site Recovery Management (SRM)

After the recovery failover operation is complete, the VMs will be running on the recovery site and the VMs are no longer

being protected by SRM.

Configuring protection after a failover

In the case of a Planned Migration failover, after the Recovery operation completes SRM will inform you that it’s necessary

to configure protection again. In the Recovery Plan screen, simply click on Reprotect to configure protection again.

In the case of a Disaster Recovery failover, the Recovery operation is considered to be incomplete even though the VMs will

have been powered up on the recovery site. SRM will inform you that you must correct the problem on the protected site

first and run Recovery again. It is necessary to successfully complete the Recovery operation before you are permitted to

configure protection again. Once Recovery completes successfully and protection is configured again, the VMs are

considered to be running on the protected site and the placeholder shadow VMs are on the recovery site. It is important to

understand that the protected site and recovery site roles have now been reversed.

The procedures described in this whitepaper must be followed to keep Matrix synchronized with SRM after an SRM Failover

process.

Tested configuration

Testing was performed with the following versions of Matrix and VMware software.

• Matrix Operating Environment 7.3.2

• ESXi 5.1.0 build 1483097

• vCenter 5.1 build 799731

• SRM 5.1.0 build 941848

• SRM Plugin build 941848

• HP 3PAR Storage Replication Adapter (SRA) Software 5.1.0.7

The environment was tested in two different configurations.

1. One Central Management Server (CMS) at the primary site:

A. The CMS managed a 2-node ESXi cluster on each SRM site.

B. In Matrix insight orchestration (IO) a separate Server Pool was created for each ESXi cluster.

2. Two CMSs (one at each site):

A. Each CMS managed a 2-node ESXi cluster at their respective SRM site.

B. In IO, a Server Pool was created for the ESXi cluster on the primary site only.

Known issue when using HP Capacity Advisor

After an SRM Disaster Recovery failover, some VMs may not resume data collection until the SRM Disaster Recovery process

is completed and the VMs are protected again. There is a procedure documented in this whitepaper which will minimize the

chance of this happening and may prevent it altogether.

Limitations when using a two CMS configuration

There are some significant limitations to what can be done while running on the secondary site with respect to how Matrix

manages the VMs. After an SRM Recovery failover has been completed from the primary site (managed by the primary CMS)

to the secondary site, the VMs are powered on by SRM and accessible on the secondary site. On the primary CMS, the Matrix

infrastructure orchestration services which created those VMs will simply appear to be in a down state. Matrix IO will just be

aware that the underlying VMs have been powered off or otherwise inaccessible. But it is equally important to note that the

secondary CMS will not be aware of the VMs as logical servers or as part of any IO services that had created them on the

primary CMS. The secondary CMS will only be aware that the VMs have been powered on and are associated with their ESXi

hosts on the secondary site.

There are certain operations that should not be done while the VMs are running on the secondary site since they will not be

recognized by Matrix infrastructure orchestration after failing back to the primary CMS.