Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Supported SRDF Topologies
The SRDF SRA supports a wide variety of SRDF topologies that customers can leverage to protect their VMware environment.
Supported 2-site SRDF configurations:
Supported 3-site SRDF configurations:
If a configuration is not included here, it is not supported. Some examples of unsupported configurations:
When configuring 3-site solutions where the initial R1/R2 pair is using Asynchronous or Active SRDF, the entire SRDF group should be replicated to the third Asynchronous site. Partial group replication should not be used. Take the following example:
SRDF group 3 contains 4 pairs from array A to array B:
A second SRDF group 4 is configured from array A to array C. The customer desires to concurrently replicate only devices 00128 and 00129 from group 3 to array C. Although SRDF will permit this configuration, the SRDF SRA will be unable to perform planned migrations or failovers (test failovers are not impacted). This is because Asynchronous and Active SRDF groups can only be acted upon as a whole. It is impossible to failover only two devices of the four. When the SRDF SRA issues the failover command it will not succeed and the recovery plan will error. Manual intervention would be necessary. If the above configuration is desired, the customer should create a separate SRDF group for devices 00128 and 00129 from array A to array C and then concurrently replicate them in group 4.
Note: The SRDF SRA requires that in a Cascaded configuration, represented by array A to array B to array C, that array A is able to recognize array C as a remote array. This is not a requirement outside of the SRDF SRA.
Note: The SRDF SRA does not support combining 2-site and 3-site SRDF configurations in a single Protection Group.
Note: The SRDF SRA does not support devices that are currently involved in a Non-Disruptive Migration (NDM)/PowerMax data mobility session. Any migration operation must be completed and terminated before successfully discovering pairs in SRM.
Table 3 shows the full details of the Concurrent SRDF support with the SRDF SRA. The table shows the configurations that are supported for discovery and recovery. For the given configuration the “primary leg” is the target site for recovery.
Star/Non-Star | Primary leg | Secondary leg (bunker site) |
Non-Star | Synchronous | Synchronous |
Non-Star | Synchronous | Asynchronous |
Non-Star | Active | Asynchronous |
Non-Star | Asynchronous | Synchronous |
Non-Star | Asynchronous | Asynchronous |
Non-Star | Synchronous | Adaptive Copy |
Non-Star | Asynchronous | Adaptive Copy |
Star | Asynchronous | Synchronous |
Star | Synchronous | Asynchronous |
Star | Asynchronous | Adaptive Copy |
Star | Synchronous | Adaptive Copy |
Table 4 shows the supported Cascaded SRDF modes for the SRDF SRA. The target recovery site is indicated for each given configuration.
Star/Non-Star | First Hop (A-->B) | Second Hop (B-->C) | Target recovery site |
Non-Star | Synchronous | Asynchronous | “B” site |
Non-Star | Synchronous | Asynchronous | “C” site |
Non-Star | Asynchronous | Adaptive Copy | “B” site |
Non-Star | Synchronous | Adaptive Copy | “B” site |
Star | Synchronous | Asynchronous | “B” site |
Star | Synchronous | Asynchronous | “C” site |
Star | Synchronous | Adaptive Copy | “B” site |
Since SRM is, by design, a 2-site paradigm, only two of the three SRDF sites in a 3-site solution can be directly managed by the SRDF SRA at once. In other words, recovery can only occur between two of the three SRDF sites, which sites those are depends on where the compute resources[9] are physically located. It is not possible to configure both sites. Switching between sites requires a reconfiguration of SRM and the SRA.
While the recovery ESXi hosts must be in the same physical location as the configured recovery array[10], it is possible for the vCenter server and SRM server to be located elsewhere. This type of configuration, however, is highly discouraged. If these management applications are in a physically separate location from the recovery storage and compute, it is possible that they could be in the failure domain of the protected site resources. If so, a disaster would render failover through SRM and the SRDF SRA impossible. It is important to locate the vCenter and SRM servers in the same location as the recovery storage and compute.
Cascaded and concurrent configurations are inherently more complicated than 2-site, and therefore the following tables are included for reference. These tables can also be found in the Release Notes of the SRA.
Three site (initial configuration) | Three site (after reprotect) | |||
R11 -> R2 (1st mirror) | R11 -> R2 (2nd mirror) | R1 -> R21 (1st mirror) | R21 -> R2 (2nd mirror) | VMware SRM Recovery Site |
Synchronous | Asynchronous | Synchronous | Asynchronous | Synchronous |
Synchronous | Asynchronous | Adaptive Copy | Asynchronous | Asynchronous |
Synchronous | Adaptive Copy | Synchronous | Adaptive Copy | Synchronous |
Synchronous | Synchronous | Synchronous | Adaptive Copy | Synchronous |
Asynchronous | Asynchronous | Asynchronous | Adaptive Copy | Asynchronous |
Asynchronous | Adaptive Copy | Asynchronous | Adaptive Copy | Asynchronous |
Active | Asynchronous | Not Supported | Not Supported | Not Supported |
Three site (initial configuration) | Three site (after reprotect) | |||
R1 -> R21 (1st mirror) | R21 -> R2 (2nd mirror) | R11 -> R2 (1st mirror) | R11 -> R2 (2nd mirror) | VMware SRM Recovery Site |
Synchronous | Asynchronous | Synchronous | Asynchronous | Synchronous |
Synchronous | Adaptive Copy | Synchronous | Adaptive Copy | Synchronous |
Asynchronous | Adaptive Copy | Asynchronous | Adaptive Copy | Asynchronous |
Three site (initial configuration) | Three site (after reprotect) | |||
R1 -> R21 (1st mirror) | R21 -> R2 (2nd mirror) | R1 -> R21 (1st mirror) | R21 -> R2 (2nd mirror) | VMware SRM Recovery Site |
Synchronous | Asynchronous | N/A | N/A | Asynchronous (reprotect not supported) |
SRDF/Star provides both data protection and disaster recovery across three geographically dispersed data centers in a triangular configuration. The following tables include the valid SRDF/Star states for device discovery and test and recovery operations for sync and async configurations.
Note: Reconfiguration of an SRDF/Star environment between concurrent and cascaded is not supported through the SRA and must be done manually.
SRDF/Star state | Sync target site state | Async target site state |
Protected | Protected | Protected |
Tripped | PathFailed | PathFailed |
Tripped | PathFailed | Protected |
Tripped | Protected | PathFailed |
Unprotected | Disconnected | Protected |
Unprotected | Connected | Protected |
Unprotected | Protected | Protected |
Unprotected | Halted | Halted |
Unprotected | Isolated | Protected |
Unprotected | Protected | Isolated |
Unprotected | Isolated | Disconnected |
SRDF/Star state | Sync target site state | Async target site state |
Protected | Protected | Protected |
Tripped | PathFailed | PathFailed |
Tripped | PathFailed | Protected |
Tripped | Protected | PathFailed |
Note: Only if site A is down or partitioned from site B can the mode of operation change from cascaded to concurrent SRDF/Star. To return to cascaded, a manual operation is required.
SRDF/Star state | Sync target site state | Async target site state |
Protected | Protected | Protected |
Tripped | PathFailed | PathFailed |
Tripped | PathFailed | Protected |
Tripped | Protected | PathFailed |
Unprotected | Protected | Connected |
Note: Only if site B is down can the mode of operation change from cascaded to concurrent SRDF/Star. To return to cascaded, a manual operation is required.
The following sections are specific to SRDF/Metro configurations in 2 and 3-site configurations and provide important information for those SRM environments.
SRDF/Metro devices, by design, have the same device identity (external WWN/Mobility ID) and geometry which enables the SRM stretched storage features. The SRDF SRA supports both bias and witness SRDF Metro configurations. In bias configurations, the bias site is always the R1 device and the non-bias site the R2 device. When a witness is configured, however, the SRA will report that both devices are source devices so that either SRM site could be the protected site. Dell recommends using the witness functionality in SRDF/Metro configurations.
Note: Proper care should be exercised when using RDF Metro devices in VMware vSphere environments, as situations may arise which are unique to this feature. For example, a condition may occur where the SRA device discovery fails to match a datastore with the underlying device. One reason this can occur is if the RDF device was previously part of an SRDF/Metro relationship as an R2 (target). Normally, after an SRDF/Metro is completely severed, the original WWN/Mobility ID is restored as the external WWN/Mobility ID; however if this does not happen then the R2 would still retain the external identity of the R1. SRM (and ESXi) can only see the external WWN/Mobility ID and therefore does not know the “real” WWN of the device and is unable to match it to the datastore. It is important, therefore, to follow the proper procedure when dissolving an SRDF/Metro relationship. Always consult the Dell documentation concerning SRDF/Metro, including both product documentation and the SRDF/Metro Technical Note.
In an SRDF/Metro 3-site configuration, the goal is to have one pair providing high availability, and the other disaster recovery. Therefore one of the device pairs will be in SRDF/Metro mode, or Active, and the other in a traditional RDF mode, Asynchronous. In this configuration it is possible to configure SRM to either failover to the Active site, or failover to the Async site, not both; however the SRM capabilities for the Async site are not as complete as the Active site. To this end, the only SRM workflows available when failing over to the Async site are test failover and planned or unplanned recovery. Once failed over it is not possible to run a SRM re-protect workflow as it is not supported. Any re-protect must be done manually which may include downtime, though options are available which may make this unnecessary (e.g., Storage vMotion, FT). SRM objects such as Protection Groups and Recovery Plans, however, may need to be re-created. Note this does not impact the test failover functionality as that is distinct from recovery operations and therefore fully operational.
SRDF/Metro Smart DR, more commonly known as MetroDR, combines two arrays running SRDF/Metro between them with a third site connected with SRDF/A from both Metro legs. Each Metro site is capable of sending data to the third site, though only one does so unless there is a failure. The configuration of MetroDR with the SRDF SRA differs slightly from that of a 3-site SRDF/Metro environment. Those differences will be noted in the remaining sections of the chapter