Extending Layer 2 networking for workload migration to PowerOne systems
Fri, 07 Aug 2020 21:07:34 -0000|
Read Time: 0 minutes
The PowerOne System represents a new paradigm in the way we operate and manage infrastructure life cycle in the data center. Greenfield workload deployments are ideal candidates to adapt to the new operational model, but it is also desirable to include existing business workloads in the new platform.
The default mechanism for connecting a PowerOne System to a customer network is by means of Layer 3. Layer 3 has numerous benefits in terms of scalability, failure domain isolation, and ease of operation.
Figure 1 PowerOne System fabric connection to the customer network
However, against this background, customers may need to leverage traditional Layer 2 technologies at the integration point, in tandem with Layer 3, to satisfy either of the following two key use cases, both of which are described in detail in our white paper:
- Migrating workloads from the customer network into the PowerOne System, without the need to change the identity (the IP addresses) of the virtual machines. The net result is that the customer’s workload IP gateway will migrate to the PowerOne Dell ToR switches, in the guise of VxLAN IP anycast gateways. In this use case, all virtual machines attached to that VLAN are migrated into the PowerOne System.
- Mixed workload & Legacy system use case: In some instances, the customer may be unable to migrate the entire network into the PowerOne System, and only be capable of migrating a portion of the workload. Other components, such as non-virtualized storage, physical Layer 2 firewalls, and load balancers, may not be good candidates for migration, or indeed cannot be migrated.
For this use case, a Layer 2 infrastructure can be configured, in tandem with the Layer 3 architecture, to facilitate Layer 2 communication between virtual devices on the PowerOne System and legacy non-virtualized systems on the customer network. This scenario implies that the default gateway for these networks will remain on the customer network, even for virtualized traffic within the PowerOne domain, though it is entirely possible for the gateway to reside on the PowerOne System.
When a customer adds a PowerOne System to their infrastructure, they can create cluster resource groups (CRGs). (A CRG is an aggregation of compute, storage, and networking infrastructure assets created to satisfy the resource needs of new application workloads.) But what about existing workloads -- the ones that are already running in the customer’s infrastructure? There are instances in which customers do not wish to re-IP or lift-and-shift their workload VMs and subnets in order to migrate them successfully onto a PowerOne system. A re-IP process is generally highly disruptive for existing applications, both operationally and technically.
In order to leverage the considerable intelligent resources available in PowerOne, these existing workloads need to find their way to the PowerOne System. PowerOne standardizes its networking on the principles of Layer 3 because of its inherent ability:
- To scale in the data center (for possible future multi-Pod configurations)
- To provide a native mechanism to integrate into a spine/leaf architecture
Situations also arise in which a customer wishes to natively extend existing Layer 2 constructs from their network into the PowerOne environment. This could include bare-metal server or appliance integrations for service chaining or excess resource allocations. Our white paper also describes how to enable the infrastructure so that customers can seamlessly migrate their applications, with application identity intact, into a PowerOne system, as well as simply extending existing or new VLANs into PowerOne.
Fortunately, when migrating existing workloads to a PowerOne system, it is not necessary to apply new IP addresses to the workload VMs. This simplifies the overall workload network architecture and management, makes migrating workloads a much simpler process, and eliminates unnecessary risk in a re-IP’ing process. In this manner, keeping the virtual machines’ IP addresses the same in both the source and destination workload clusters is all important. Keeping intact the application identity, including its IP, allows us to avoid changes at the DNS level. Using industry standard tools and procedures for migrations, the potential challenges can be overcome.
In many cases we would like to integrate customer Layer 2 constructs into a PowerOne system. This use case shows how customer switch(es) can be connected in order to facilitate Layer 2 extension into, and out of, the PowerOne system fabric.
There are two use cases for extending a customer’s existing Layer 2 network constructs into PowerOne:
- To extend temporarily only the customer’s Layer 2 network, with the goal of migrating existing virtualized workloads into PowerOne. After completing the migration, we have the option to remove the Layer 2 network. The result is that Layer 3 networking operates within the PowerOne ToR switches, as per original PowerOne design, with existing workloads migrated into PowerOne without the need to re-IP the VMs on which they are running.
- To extend permanently the customer’s Layer 2 network AND migrate the entire customer VLAN and associated IP subnet onto the PowerOne infrastructure. In this case, customer switch(es) can be connected to the PowerOne system fabric in order to facilitate Layer 2 extension into, and out of, the PowerOne system fabric.
For more details on these two approaches, please see our whitepaper: Enabling PowerOne Infrastructure for Network Layer 2 Extension
Related Blog Posts
PowerOne and SRDF (Part 3)
Mon, 20 Jul 2020 20:12:56 -0000|
Read Time: 0 minutes
In this third and final blog post on PowerOne and SRDF we will focus on the SRDF/Metro use case. In this post, we explain the network requirements to provide Layer 2 and Layer 3 services and go into some depth with some best practices and recommendations for setting up a PowerOne system in an SRDF/Metro scenario.
First, 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.
The SRDF/Metro use case consists of three sites: two workload sites (local and remote) and a witness site. (Remember that a witness serves to prevent data inconsistencies between local and remote sites. A witness can be virtual or physical.)
Here are the essential Dell EMC Best Practices for setting up SRDF/Metro on both workload sites and on a witness site:
- Where possible, use dedicated ports on each PowerMax for connectivity to the dedicated replication network. The network must meet the latency requirements for SRDF/Metro and VMware Metro Storage Clusters.
- Use non-uniform host access to simplify SAN design and provide predictable I/O latency for workloads.
- Implement vSphere and NSX-T Management as required to meet operational needs and constraints through a dedicated management cluster or through a cluster that is shared with workloads.
- Implement vCenter HA with a witness site or with restart recovery, depending on network architecture and operational needs.
- Follow Dell Technologies Best Practices (NSX-T Data Center Administration Guide) to set up NSX-T L2 VPN across both sites.
- Deploy or migrate workload VMs with NSX-T L2 VPN as the VM Network, for example, for application access.
- Configure workload VMs to leverage a VMware NSX-T L2 VPN or stretched VXLAN implementation in Dell Smart Fabric Services to retain identical IP addressing on both sites.
The proposed architecture options and their implications appear in the following examples.
Figure 1: Layer 2 networking architecture
In this example, a Layer 2 stretched network is implemented using either of the following:
- A BGP eVPN—The network is extended by running a VXLAN tunnel over the top of the Layer 3 handoff from a PowerOne system
- Layer 2 trunking—Dedicated 802.1Q trunk ports can be configured on the Dell S5232-F switches used as leaf devices, mapping incoming 802.1Q tags into the proper VXLAN virtual-networks
- 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 2: Layer 3 networking architecture
In this example, you can include Layer 3 networking 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 that have 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, through vCenter HA, and are immediately fully functional on the NSX-T L2 VPN.
Management activities, such as changing the NSX-T configuration, become available once the NSX-T Management VMs are restarted.
Figure 3: Distributed networking architecture
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 Best Practices for Using Dell EMC SRDF/Metro in a VMware vSphere Metro Storage Cluster) form a highly available, business-continuous scenario. In this kind of scenario, 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 fall outside of 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 traditional configuration approaches widely used in the industry today.
Best Practices and Recommendations
To determine the correct PowerOne technology configuration for the required outcome, we first need to determine the organization’s continuity requirements for a given cluster, in terms of the following:
- Recovery Time Objective (RTO)—How long does it take to get the cluster working again after site failure?
- Recovery Point Objective (RPO)—How much data is the customer prepared to lose?
Designing the architecture means:
- Determining RTO and RPO requirements and site distance constraints
- Working with an organization to understand their continuity requirements and DR needs
- Designing and estimating the price of the appropriate PowerOne configurations to meet those needs
It is typical for an organization to classify its recovery needs on a per-application basis, resulting in collections of applications that have common availability requirements. This maps well to the PowerOne approach in which the cluster is the primary unit of consumption. At the cluster level, one cluster could have an RPO and RTO that is different from that of another cluster, allowing a direct mapping of the recovery needs of applications to the clusters in which they run.
But investment in operational continuity is the starting point. Having confidence that your plan will work is the critical point. Confidence comes from regular testing that is minimally disruptive and performed in a controlled manner.
PowerOne makes possible these various outcomes by making the right set of components and other resources available. This means that the initial sizing work must include understanding the organization’s continuity requirements and how they will be implemented. This will help ensure that the components and configurations needed to fulfill the requirements are incorporated in the system definition and that the correct technologies and capacities are available at implementation.
Operational Continuity: Solutions
To investigate further how an organization’s continuity solution can be provided, let’s examine the best-practice recovery configurations for PowerOne, and how they can be extended to achieve the required outcomes.
We will need to address questions about how we deal with physical connectivity at the storage and network layers, such as how we configure the logical behavior of our vSphere environments to minimize RPO. In order to use the traditional configuration techniques for non-autonomous extended use cases such as SRDF, the PowerOne Controller is invoked to reserve and allow seamless hand-off of components. We rely on well-proven tools such as VMware Site Recovery Manager to automate failover and failback operations, and to configure the production network on the vSphere remote site.
PowerOne with SRDF/Metro provides an organization’s continuity solution in which we can define RPO and RTO as zero or near-zero when VMware vSphere Metro Storage Cluster technology and architecture are also implemented.
There are a number of considerations to take into account when designing a PowerOne system with SRDF/Metro architecture, specifically:
- Compute, storage, and network configuration
- How we design our vSphere environment in terms of vCenter configuration (HA and Platform Service Controller architectures)
- NSX-T management design guidelines
- A few considerations about the SRDF witness
- Potential benefits of including a third site in the architecture design
- Architectural considerations on site design and intersite replication
There is a market demand to provide a way to deploy critical applications in a highly available manner. As an architecture option for building that solution, combining the core Converged Infrastructure and site-local autonomous outcomes of PowerOne with traditional configuration capabilities for SRDF (and VMware SRM), delivers cumulative industry-leading value from each of those components in one solution, all fully supported by Dell Technologies.
For additional in-depth information, please read the supporting white paper: Protecting Business-Critical Workloads with Dell EMC SRDF and PowerOne.
PowerOne and SRDF (Part 2)
Thu, 25 Jun 2020 17:55:46 -0000|
Read Time: 0 minutes
PowerOne with SRDF use cases and associated topologies
In my previous blog post (PowerOne and SRDF Part I) we introduced the business context and technologies involved in a PowerOne with SRDF scenario. In this second blog post we describe two data center use cases and the associated topologies:
- Two sites with SRDF Synchronous (SRDF/S) or Asynchronous (SRDF/A) data replication with Remote Restart (disaster restart protection for virtual infrastructure)
- Two sites in a stretch cluster configuration with synchronous data mirroring (SRDF/Metro). This stretched cluster use case relies on the existence of a third site to perform the witness role.
Protected clusters with SRDF/S and SRDF/A
In this topology, vSphere clusters built using traditional configuration techniques on PowerOne systems are recovered at a defined secondary site on a per-cluster basis. The recovery process can take up to several minutes, depending on the number of servers involved.
The functional requirements for this approach are:
- Deploy two PowerOne Systems with PowerMax, one at the primary site and one at the recovery site. These systems must be licensed for SRDF and VMware SRM.
- Create, modify or delete a cluster at the primary site. Add volumes to the replication set. Select the mode of protection based on RPO with sync for zero data loss (or) async for data loss (from a few seconds of data loss to minutes, depending on the RPO).
- Add stretched application VLAN(s), typically called overlay networks, such as VMware VXLAN using NSX, so that IP addressing will work at the primary or the recovery site. Any mechanism to re-IP and modify DNS entries as needed in the secondary site may also be valid.
- Create, modify or delete remote array connections, called SRDF Groups. Links must be scalable so you can add links to increase throughput.
- Invoke failover/failback to prove all technologies and operational processes are functioning as expected.
- In order to be able to attach the replicated storage volumes for failover and failback, create storage-less clusters and add them to the vCenter instance at the secondary site.
- For non-disruptive failover testing, SRM provides an orchestrated recovery validation mechanism called Bubble. Bubble provides a recovery area using SnapVX clones of R2 volumes without impacting the replication process. Isolate the Bubble recovery to specific VLANs or subnets (so that it does not overlap with production or recovery networks).
This approach describes a typical Disaster Recovery scenario. Through the integration of PowerOne, SRDF/S/A, and VMware SRM, we can create an automated DR architecture that, in case of a site failure, will failover the production CRGs to the secondary disaster site. VMware SRM automates this multi-step recovery of virtual machines. For more details about pre-requisites, supported devices, and configurations, see Implementing Dell EMC SRDF SRA with VMware SRM.
Stretched clusters with SRDF/Metro
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 applications will continue to run without interruption at lower capacity levels until the failed VMs restart.
Figure 1: PowerOne with SRDF Metro architecture
The functional requirements for this approach are:
- Deploy two PowerOne Systems, with PowerMax licensed for SRDF/Metro, within metro distance. Create a low-latency communication channel between them to avoid disk write delays.
- Create, modify, or delete remote array connections, called SRDF Groups, which require redundant ports and replication adapters using Ethernet or Fibre Channel protocols. Links must be scalable so you can add links to increase throughput.
- Create, modify, or delete VMware Metro Storage Cluster(s) using SRDF device pairing. Split servers 50/50 across both systems so that storage is bidirectionally mirrored across both sites.
- Add stretched application VLAN(s), such as VMware VXLAN using NSX, so that IP addressing works regardless of which half of the cluster runs the application VM.
- (Optional) Implement any fine-grained workload migration controls to address restarting the workloads if application-specific needs or dependencies arise.
- Create, delete, or modify SRDF pairs. Suspend and deactivate SRDF/Metro failure recovery controls.
- Implement either a bias or witness mechanism to prevent data inconsistencies with multi-access at both sides. The witness is an external arbitrator reachable by both sites. The witness can be a Virtual Witness (vWitness) or a physical array acting as a witness.
In the third and final part of this blog series, we will explore the network architecture, best practices, and recommendations for the different PowerOne with SRDF scenarios we have presented.