In this topology, PowerOne clusters are always on. If one site goes down, VMs are restarted on surviving servers. Application architecture determines recovery time. For example, this means that monolithic applications that require all VMs to be restarted will have a wait time; whereas distributed, or cloud-native architecture, applications will continue to run without interruption at lower capacity levels until the failed VMs restart.
Figure 2. PowerOne with SRF Metro architecture
The functional requirements for this approach are:
We need to define how we will stretch the network for a Metro scenario. As part of the project design we must determine how to provide layer 2 and layer 3 networking for vSphere, NSX Management, and vMotion networks.
Here are the relevant Dell EMC Best Practices for setting up SRDF/Metro on both workload sites and on a witness site:
Follow Dell Technologies Best Practices (NSX-T Data Center Administration Guide) to set up NSX-T L2 VPN across both sites.
From a network perspective the proposed architecture options and their implications are illustrated in the following examples.
Figure 3. Layer 2 networking example architecture
In this example, a Layer 2 stretched network is implemented using either
If the customer already has a VLAN Layer 2 adjacent between sites, this effectively extends it to the other datacenter, where the other PowerOne system uses the same method for mapping an incoming tag to the virtual network (VXLAN).
Stretching the management VLAN adds complexity to the physical network but has the advantage of retaining identical IP addressing for management components across sites.
Figure 4. Layer 3 networking example architecture
In this example Layer 3 networking can be included to eliminate the need to stretch a VLAN at the physical network level. This example shows how vCenter HA can be used to distribute vSphere Management across sites.
This approach requires that all NSX-T Management components are configured with DNS entries with a short TTL. It also requires a re-IP operation and a DNS update after restarting on Site 2. All workload VMs are restarted automatically in this scenario and are immediately fully functional on the NSX-T L2 VPN.
Management activities such as altering the NSX-T configuration become available once the NSX-T Management VMs are restarted.
Figure 5. Distributed networking architecture example
Another option is to use the third site for witness duties. By centralizing the management components at the third site, they become isolated from the workload sites. In this case, in addition to the PowerMax witness, we have all the vCenter and NSX-T network management elements in this third site, so we will not need to re-start those services if a workload site fails
Protecting the management in the third site is not covered in this example.
All of these vMSC architectures, (as described in Dell EMC Best Practices for SRDF/Metro in a vSphere Metro Storage Cluster ) form a highly available, business-continuous scenario, in which both primary and secondary sites are perceived as one by a PowerOne vSphere host and from a CRG provisioning perspective. Stretching the sites at the storage and network levels enables seamless vMotion and Storage vMotion operations between the two sites.
PowerOne continues to deliver the now-traditional Converged Infrastructure values with extensive automation for site local needs, while simultaneously allowing for seamless integration with outcomes that are not yet provided for in the autonomous operations. All operations related to these stretched CRGs (such as provisioning, expansion, and lifecycle management) can be tailored to extended use cases such as SRDF/Metro through the traditional configuration approaches already widely used in the industry today.