microsoft hyper-v live migration and emc vplex geo · considerations for supporting microsoft...

White Paper

Abstract

This white paper discusses the configuration and architectural considerations for supporting Microsoft Failover Clustering. Deployments of distributed Windows geographically dispersed cluster solutions with EMC® VPLEX™ Geo additionally provide support for Hyper-V live migrations across site boundaries. Active/active solutions of this style provide enhanced capabilities for customers to be able to implement load-balancing solutions in addition to the core high-availability and disaster-recovery features of Windows Failover Clustering. June 2011

MICROSOFT HYPER-V LIVE MIGRATION WITH EMC VPLEX GEO

2 Microsoft Hyper-V Live Migration with EMC VPLEX Geo

Copyright © 2011 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. VMware and ESX are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number h8266


Table of Contents

Executive summary.................................................................................................. 4

VPLEX product offerings ........................................................................................... 6

VPLEX Local, VPLEX Metro, VPLEX Geo ................................................................................ 6

VPLEX Local .................................................................................................................... 7

VPLEX Metro with AccessAnywhere ................................................................................. 7

VPLEX Geo with AccessAnywhere ................................................................................... 7

Architecture highlights ....................................................................................................... 8

VPLEX Geo ............................................................................................................... 9

VPLEX Geo setup ................................................................................................... 10

Using detach rules for setting the cluster preference ........................................................ 11

VPLEX Witness .................................................................................................................. 11

Hyper-V requirements ............................................................................................ 11

Failover Clustering requirements ...................................................................................... 12

Creating highly available virtual machines........................................................................ 12

Hyper-V manual VM move ...................................................................................... 13

Hyper-V quick migration ........................................................................................ 14

Hyper-V live migration ........................................................................................... 14

Cluster Shared Volume ..................................................................................................... 15

Deployment configuration ..................................................................................... 16

Resource DLL ........................................................................................................ 18

Live migration scenarios ........................................................................................ 19

User-initiated live migration ............................................................................................. 19

Failure of a VPLEX cluster without preference ............................................................... 20

Failure of a VPLEX cluster with preference ..................................................................... 21

VPLEX inter-cluster link failure .......................................................................................... 22

VPLEX Witness failure scenarios ....................................................................................... 23

Networking considerations .................................................................................... 24

Rename the default network interface .............................................................................. 25

Dedicate network interfaces by traffic patterns ................................................................. 25

Enabling Jumbo Frames .................................................................................................... 25

Network Adapter Teaming ................................................................................................ 25

Conclusion ............................................................................................................ 26

References ............................................................................................................ 26


Executive summary At the highest level, EMC® VPLEX™ has unique capabilities that storage administrators value and can use to enhance their data centers. It delivers distributed, dynamic, and smart functionality into existing or new data centers to provide storage virtualization across geographical boundaries.

VPLEX is distributed because it is a single interface for multivendor storage and delivers dynamic data mobility, which is being able to move applications and data in real time, with no outage required.

VPLEX is dynamic because it provides data availability and flexibility as well as maintains business through failures that traditionally have required outages of manual restore procedures.

VPLEX is smart because its unique AccessAnywhere technology can present and keep the same data consistent within and between sites and enable distributed data collaboration.

Because of these capabilities, VPLEX delivers unique and differentiated value to address three distinct requirements within our target customers’ IT environments:

The ability to dynamically move applications and data across different compute and storage installations, whether they are within the same data center, across a campus, within a geographical region – and now, with VPLEX Geo, across even greater distances.

The ability to create high-availability storage and a compute infrastructure across these same varied geographies with unmatched resiliency.

The ability to provide efficient real-time data collaboration over distance for such “big data” applications as video, geographic/oceanographic research, and more.

EMC VPLEX technology is a scalable, distributed-storage federation solution that provides nondisruptive, heterogeneous data movement and volume management functionality.

Insert VPLEX technology between hosts and storage in a storage area network (SAN) and data can be extended over distance within, between, and across data centers.

The VPLEX architecture provides a highly available solution suitable for many deployment strategies including:

Application and data mobility — Defined as the movement of virtual machines (VM) without downtime. An example is shown in Figure 1.

Storage administrators have the ability to automatically balance loads through VPLEX, using storage and compute resources from either cluster’s location. When combined with server virtualization, VPLEX allows users to transparently move and relocate virtual machines and their corresponding applications and data over distance. This provides a unique capability allowing users to relocate, share, and balance infrastructure resources between sites, which can be within a campus or


between data centers, up to 10 ms apart with VPLEX Metro, or farther apart (50 ms RTT) across asynchronous distances with VPLEX Geo.

Figure 1. Application and data mobility example

HA infrastructure — Reduces recovery time objective. An example is shown in Figure 2.

High availability (HA) is a term that several products claim they can deliver. Ultimately, a HA solution is supposed to protect against a failure and keep an application online. Storage administrators plan around HA to provide near-continuous uptime for their critical applications, and automate the restart of an application once a failure has occurred, with as little human intervention as possible. With conventional solutions, customers typically have to choose a recovery point objective (RPO) and a recovery time objective (RTO). But even while some solutions offer small RTOs and RPOs, there can still be downtime, and for most customers, any downtime at all can be costly.

Figure 2. HA infrastructure example

Distributed data collaboration — Increases utilization of passive data recovery (DR) assets and provides simultaneous access to data. An example is shown in Figure 3.

This is when a workforce has multiple users at different sites who need to work on the same data, and maintain consistency in the dataset when changes are made. Use cases include co-development of software where the development happens


across different teams from separate locations, and collaborative workflows such as engineering, graphic arts, videos, educational programs, designs, research reports, and so forth.

When customers have tried to build collaboration across distance with the traditional solutions, they normally have to save the entire file at one location and then send it to another site using FTP. This is slow, can incur heavy bandwidth costs for large files, or even small files that move regularly, and negatively impacts productivity because the other sites can sit idle while they wait to receive the latest data from another site. If teams decide to do their own work independent of each other, then the dataset quickly becomes inconsistent, as multiple people are working on it at the same time and are unaware of each other’s most recent changes. Bringing all of the changes together in the end is time-consuming and costly, and grows more complicated as the dataset gets larger.

Figure 3. Distributed data collaboration example

VPLEX product offerings VPLEX first meets high-availability and data-mobility requirements and then scales up to the I/O throughput required for the front-end applications and back-end storage.

A VPLEX cluster consists of one, two, or four engines (each containing two directors), and a management server. A dual-engine or quad-engine cluster also contains a pair of Fibre Channel switches for communication between directors.

Each engine is protected by a standby power supply (SPS), and each Fibre Channel switch gets its power through an uninterruptible power supply (UPS). (In a dual-engine or quad-engine cluster, the management server also gets power from a UPS.)

The management server has a public Ethernet port, which provides cluster management services when connected to the customer network.

VPLEX Local, VPLEX Metro, VPLEX Geo

EMC offers VPLEX in three configurations to address customer needs for high-availability and data mobility:

VPLEX Local


VPLEX Metro

VPLEX Geo

The following figure provides an example of each.

Figure 4. VPLEX offerings

VPLEX Local

VPLEX Local provides seamless, nondisruptive data mobility and the ability to manage multiple heterogeneous arrays from a single interface within a data center.

VPLEX Local allows increased availability, simplified management, and improved utilization across multiple arrays.

VPLEX Metro with AccessAnywhere

VPLEX Metro with AccessAnywhere enables active-active, block-level access to data between two sites within synchronous distances. The distance is limited as to what synchronous behavior can withstand as well as consideration to host application stability and MAN traffic. It is recommended that depending on the application that consideration for Metro be less than or equal to 5 ms1 RTT.

The combination of virtual storage with VPLEX Metro and virtual servers enables the transparent movement of virtual machines and storage across a distance. This technology provides improved utilization across heterogeneous arrays and multiple sites.

VPLEX Geo with AccessAnywhere

VPLEX Geo with AccessAnywhere enables active-active, block-level access to data between two sites within asynchronous distances. VPLEX Geo enables better cost-effective use of resources and power. Geo provides the same distributed virtual volume flexibility as Metro but extends the distance up to and within 50 ms RTT. As with any asynchronous transport media, bandwidth is also important to consider for optimal behavior as well as application sharing on the link.

1 Refer to VPLEX and vendor-specific white papers for confirmation of latency limitations.


Architecture highlights

VPLEX support is open and heterogeneous, supporting both EMC storage and common arrays from other storage vendors, such as HDS, HP, and IBM. VPLEX conforms to established World Wide Naming guidelines that can be used for zoning.

VPLEX supports operating systems including both physical and virtual server environments with VMware® ESX® and Microsoft Hyper-V. VPLEX supports network fabrics from Brocade and Cisco including legacy McData SANs.

The following table lists an overview of VPLEX features along with benefits.

Table 1. Overview of VPLEX features and benefits

Features Benefits

Mobility Move data and applications without impact on users.

Resiliency Mirror across arrays without host impact, and increase high availability for critical applications.

Distributed cache coherency Automate sharing, balancing, and failover of I/O across the cluster and between clusters.

Advanced data caching Improve I/O performance and reduce storage array contention.

Virtual storage federation Achieve transparent mobility and access in a data center and between data centers.

Scale-out cluster architecture Start small and grow larger with predictable service levels.

For all VPLEX products, the appliance-based VPLEX technology:

Presents SAN volumes from back-end arrays to VPLEX engines

Packages the SAN volumes into sets of VPLEX virtual volumes with user-defined configuration and protection levels

Presents virtual volumes to production hosts in the SAN via the VPLEX front end

The VPLEX Metro and VPLEX Geo products present a global, block-level directory for distributed cache and I/O between VPLEX clusters.

Location and distance determine high-availability and data-mobility requirements. For example, if all storage arrays are in a single data center, a VPLEX Local product federates back-end storage arrays within the data center.


When back-end storage arrays span two data centers, the AccessAnywhere feature in a VPLEX Metro or a VPLEX Geo product federates storage in an active-active configuration between VPLEX clusters. Choosing between VPLEX Metro or VPLEX Geo depends on distance and data synchronicity requirements.

Application and back-end storage I/O throughput determine the number of engines in each VPLEX cluster. High-availability features within the VPLEX cluster allow for nondisruptive software upgrades and expansion as I/O throughput increases

VPLEX Geo EMC VPLEX Geo presents storage in an active-active fashion across asynchronous distances. This is achieved by creating VPLEX distributed virtual volumes, which consist of a RAID 1 mirror with extents located across two VPLEX Geo clusters. Once the distributed virtual volumes have been created, they are then placed into a consistency group for management decisions made by VPLEX Witness.

This is shown in Figure 5.

Distributed DevicesRAID-1 Mirrors Across Sites

SITE-BSITE-A

VPLEX Cluster 2VPLEX Cluster 1

Ethernet WAN(Host Connectivity)

Ethernet WAN(VPLEX Connectivity)

Figure 5. VPLEX distributed virtual volume

Being an active-active presentation, hosts can perform read-write operations on the distributed virtual volume while being simultaneously presented to both clusters at both sites. This is fundamentally different from traditional asynchronous mirroring solutions in arrays where the volume on the secondary clusters remains Write Disabled until a failover procedure is performed.

With VPLEX distributed virtual volumes, no manual failover processes are required. The Global Cache Coherency layer in VPLEX presents a consistent view of data at any point in time.


VPLEX Geo setup To set up a VPLEX Geo environment, first we assume the back-end storage has been created and masked to the VPLEX Geo cluster for encapsulation and presentation to our Hyper-V Failover Cluster Server. Once this storage has been claimed we will create the extents as shown in Figure 6.

Figure 6. Creating extents with the VPLEX Management Console

Now that the extents have been created at Site-1 and Site-2, we will now create the distributed virtual volumes that will be used by Windows Failover Cluster and although it is not completely necessary to use Cluster Shared Volumes, we will use CSVs to place our Hyper-V virtual machines. The distributed virtual volumes are shown in Figure 7.

Figure 7. Creating distributed virtual volumes with the VPLEX Management Console

Let’s now place the distributed virtual volumes into a consistency group so that we may ensure consistent behavior among the volumes in that group. A consistency group's cache mode can be synchronous or asynchronous. In a VPLEX Geo configuration, asynchronous groups are required to maintain consistency during an inter-cluster link outage. The consistency group is shown in Figure 8.


Figure 8. Placing the distributed virtual volumes into a consistency group

Using detach rules for setting the cluster preference

For every VPLEX distributed virtual volume placed into a consistency group, the user can configure a detach rule that determines which cluster will continue to service I/O in case of inter-site link failure. The preference can be selected as follows:

Prefer A: Cluster A services I/O

Prefer B: Cluster B services I/O

No Automatic Winner: No one services I/O

Active Cluster Wins: If active, detaches and services I/O

NOTE: If both clusters were active, or both clusters were passive at the time of the link failure, I/O is suspended on both clusters. This is only happens with the preference set to “Active Cluster Wins”.

VPLEX Witness

The VPLEX Witness is responsible for helping VPLEX clusters distinguish between VPLEX cluster failures and inter-cluster partition failures. The witness observes health-check heartbeats to both clusters over the IP network and notifies clusters about its observations. All distributed virtual volumes are still configured with the static preference. However, in the presence of cluster or connectivity failures, the VPLEX Witness forces the majority rule to take precedence over the preference rule. This means that in order for a given cluster to continue processing I/O it must either be connected to a peer cluster or the VPLEX Witness. The static preference plays a role only in the case of an inter-cluster network partition when both clusters remain connected to the VPLEX Witness.

Hyper-V requirements Setting up Hyper-V servers starts with adding the Hyper-V Role from the Add Roles Wizard from Server Manager as seen in Figure 9.


Figure 9. Adding the Hyper-V Role

Failover Clustering requirements

Failover Clustering requires that you have the following components:

SAN with shared storage

Minimum of (2) Ethernet adapters (preferably 1 GB or greater)

The Failover Cluster feature, which can be added with the Add Feature Wizard in Server Manager (Figure 10)

Figure 10. Adding the Failover Cluster feature

Creating highly available virtual machines

To create highly available virtual machines, first use Hyper-V Manager to access the New Virtual Machine Wizard. From this wizard you will specify a VM name and storage location for your new VM.

NOTE: In Figure 11, we are placing our VMs onto a Cluster Shared Volume created on a distributed virtual volume from the VPLEX Geo cluster.


Figure 11. Setting the VM name and storage location

Once the new VM has been created with Hyper-V Manager, open the Failover Cluster Manager and start the High Availability Wizard to make this new VM highly available as shown in Figure 12. Remember to test your highly available VM using a manual move between nodes, or by using the quick and live migration functions.

Figure 12. Creating a highly available virtual machine

Hyper-V manual VM move With Hyper-V move operations, the cluster prepares to take the virtual machine offline by performing a Save of the virtual machine state information so that the state can be restored when bringing the virtual machine back online on the target node you have specified. The default action is Save, but there are three other settings for consideration:

Shut down performs an orderly shutdown of the operating system.

Shut down (forced) shuts down the operating system on the virtual machine without waiting.

Turn off is like turning off the power for increased risk of data loss.


Hyper-V quick migration Hyper-V quick migration will copy the memory and state information needed by the virtual machine to a disk in storage, allowing that virtual machine to quickly be transitioned to another node by reading the data from disk on the node that is taking over ownership. A quick migration can be used to manage several concurrent migrations at once and may be used for planned maintenance, disaster avoidance, or dynamic load balancing.

Hyper-V live migration Hyper-V live migration will copy the memory and state information needed by the virtual machine directly to the target node, allowing that virtual machine to quickly be transitioned to another node by reading the data from memory on the node that is taking over ownership. This allows running VMs from one Hyper-V physical host to another without any disruption of service or perceived downtime.

Moving running VMs without downtime using Hyper-V live migration:

Provides better agility: Data centers with multiple Hyper-V servers can move running VMs to the best physical computer for performance, scaling, or optimal consolidation without affecting users.

Reduces costs and increase productivity: Data centers with multiple Hyper-V servers can perform maintenance on those systems in a controlled fashion— adding the flexibility of scheduling maintenance during regular business hours or the traditional after-hour windows. Live migration makes it possible to keep VMs online, even during maintenance, increasing productivity for users and server administrators. Data centers may now also take advantage of reduced power consumption by dynamically increasing consolidation ratios and powering off unused physical hosts during lower demand times.

Figure 13. Initiating a live migration

A live migration as shown in Figure 13 follows these steps:


All VM memory pages are transferred from the source Hyper-V server to the designated target Hyper-V server. As this is occurs, any VM modifications to the VMs’ memory pages are tracked.

Any memory pages that are modified are then transferred to the target Hyper-V server.

Hyper-V moves the storage handle for the VMs’ .vhd files to the target Hyper-V server.

The VM is then brought online on the target Hyper-V server.

Cluster Shared Volume

As the name suggests, a Cluster Shared Volume (CSV) allows multiple nodes of a Windows 2008 R2 cluster to access a common shared storage volume. This allows multiple cluster nodes to view the CSV as a single common LUN, and this facilitates Hyper-V live migration between these nodes. CSV functions as a distributed-access file system that is optimized for Hyper-V. Unlike a Clustered File System (CFS), CSV does not use a specialized proprietary file system—it uses the standard NTFS file system, so it requires nothing additional to purchase or support, as shown in Figure 14.

CSV breaks the dependency between application resources (the virtual machines) and disk resources; it does not matter where a disk is mounted because it will appear local to all nodes in the failover cluster. However, the applications on that CSV disk can run on any node at any time. In other words, the application becomes the unit of failover. With CSV, any node in a failover cluster can access the shared storage and any node can host virtual machines, regardless of which node “owns” (or manages NTFS on) the storage.

Hyper-VNode-2

ß Live Migration à

Storage Area Network

Hyper-VNode-1

W2K8_SRVR_4W2K8_SRVR_2W2K8_SRVR_3W2K8_SRVR_1VHD-1VHD-2VHD-3VHD-4

Figure 14. Cluster Shared Volume


Live migration is enhanced by CSV within failover clustering in Windows Server 2008 R2. Live migration and CSV are separate but complementary technologies—they can work independently, but CSV enhances the resilience of live migration and is thus recommended for live migration. The CSV volumes enable multiple nodes in the same failover cluster to concurrently access the same LUN. From the perspective of the VMs, each appears to actually own a LUN; however, the .vhd files for each VM are stored on the same CSV volume.

Deployment configuration The following reference deployment configuration shows how Microsoft Windows 2008 R2 Failover Cluster can be set up to achieve Hyper-V live migration over large distances using EMC VPLEX.

VPLEX Geo Cluster

CX4 VMAX

Site-1

Fabric-A Fabric-B

Sun

Node-1

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

CX4 VMAX

Site-2

Fabric-A Fabric-B

Sun

Node-2

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

2Gb

4Gb

10GB Ethernet WAN Connectivity

Node-5

Node-3

Node-4

Node-6

Figure 15. Deployment configuration for Microsoft Windows 2008 R2 Failover Cluster with Hyper-V and VPLEX Geo

To achieve live migration over distance, the CSV needs to be configured on a VPLEX distributed volume. This enables the ability to extend the CSV across VPLEX clusters, providing read-write capability on both clusters.



SITE-BSITE-A

VPLEX Cluster 2VPLEX Cluster 1

Hyper-VNode-2

WANConnectivity

Hosts

Hyper-VNode-1

W2K8_SRVR_4W2K8_SRVR_2W2K8_SRVR_3W2K8_SRVR_1

VHD-1VHD-2VHD-3VHD-4

WANConnectivity

VPLEX



Engine Cache Coherency Directory

Block Address 1 2 3 4 5 6 7 8 9 10 11 12 13 …

Cache A

Cache C

Cache E

Cache G

Cache Directory B

Cache Directory A

Cache Directory D

Cache Directory C

Figure 16. Configuring CSV on a VPLEX distributed virtual volume using Global Cache Coherency

There are two options available to configure virtual machines on CSVs:

1::1 mapping: This means that a separate CSV is configured for every VM in the cluster. This allows maximum flexibility in terms of migration and allows each virtual machine to fail over independently of other VMs in case of underlying disk resource failure.

Many::1 mapping: This allows multiple VMs to be configured on a single CSV. In this case, if the underlying disk resource fails, the entire set of VMs configured on the CSV will need to fail over (Figure 16).


Resource DLL A resource DLL allows a custom resource to interact with the Microsoft 2008 R2 Failover Cluster and perform common functional tasks, like bringing the resource offline or online. The Resource DLL translates cluster resource state transitions to the cluster application. This allows the application state to be consistent with the underlying cluster resource state.

Figure 17. Configuring dependencies for highly available VMs

Any resource DLL is expected to implement the following entry points, which map common cluster operations to the resource type specific operations.

Close removes a resource instance from the cluster.

IsAlive determines if a resource is actually operational.

LooksAlive determines if a resource appears to be available for use.

Offline performs a graceful shutdown of the resource.

Online starts the resource and makes it available to the cluster.

Open creates a new resource instance.

ResourceControl supports resource control codes (optional).

ResourceTypeControl supports resource type control codes (optional).

Startup receives the LogEvent and SetResourceStatus callbacks and returns a function table.

Terminate performs an immediate shutdown of the resource.

In our case, the CSV (hence the underlying VPLEX distributed virtual volume) is the resource we need to manage and control, and we’ll write our own resource DLL for it. Each Hyper-V virtual machine and its corresponding CSV resource will form a resource group with the VM being dependent on the CSV resource.


.BIN .VSV .XML

.VHD

CSV-1

W2K8_SRVR_1

.BIN .VSV .XML

.VHD

CSV-2

W2K8_SRVR_2

.BIN .VSV .XML

.VHD

CSV-3

W2K8_SRVR_3

.BIN .VSV .XML

.VHD

CSV-4

W2K8_SRVR_4

Figure 18. Virtual machine and CSV dependency with each VM on a separate CSV

In case there are multiple VMs mapped to a single CSV, we can still configure separate resource groups with the appropriate VM-to-CSV dependency as shown below.

.BIN .VSV .XML

.VHD

CSV-1

W2K8_SRVR_1

.BIN .VSV .XML

.VHD

CSV-1

W2K8_SRVR_2

.BIN .VSV .XML

.VHD

CSV-1

W2K8_SRVR_3

.BIN .VSV .XML

.VHD

CSV-1

W2K8_SRVR_4

Figure 19. Virtual machine and CSV dependency with multiple VMs on a single CSV

Making the VM dependent on the CSV means that the cluster service will coordinate the VM behavior depending on the underlying resource state. At the time of VM startup, the cluster service will bring the resource in an online state by sending Online call to the resource DLL. In steady state operation, the cluster service keeps track of the underlying resource health by sending LooksAlive and IsAlive calls on the resource DLL. In this case, the resource DLL will communicate with VPLEX in order to respond to the Online, LooksAlive and IsAlive calls. Failure of any underlying resource in a resource groups prompts the cluster service to fail over the entire resource group to a different cluster node. The resource DLL will communicate with the local VPLEX cluster management server to get the state of the distributed virtual volume.

Live migration scenarios This section discusses the various live migration scenarios, success as well as failure, and provides a high-level view of how the resource DLL performs in these scenarios. For the purpose of this discussion, we’ll consider only one virtual machine configured to use the CSV. The corresponding cluster resource group will have the VM dependent on a CSV, which in turn is a VPLEX distributed virtual volume.

User-initiated live migration

In this case, the user wants to live migrate VM1 from cluster node 1 to cluster node 2. Since VPLEX presents the CSV in active/active mode, both node 1 and node 2 see the same distributed virtual volume with RW access.


Hyper-VNode-2


Storage Area Network

Hyper-VNode-1

W2K8_SRVR_4W2K8_SRVR_2W2K8_SRVR_3W2K8_SRVR_1VHD-1VHD-2VHD-3VHD-4


Figure 20. User-initiated live migration

From the cluster perspective, this is no different from a local CSV configuration. Live migration will proceed normally.

Failure of a VPLEX cluster without preference

At the time of distributed virtual volume creation the cluster preference needs to be specified. This determines the “preferred” or the “nonpreferred” site in case of failures observed by VPLEX. If the nonpreferred site fails and only the preferred site has active I/O, then I/O will continue without disruption at the preferred site.

To take advantage of this single active writer behavior with VPLEX Geo, align virtual machines residing on the same datastore so that they run at the same site. Further, add the virtual volume containing the datastore to a consistency group that has the matching site preference.



SITE-BSITE-A

VPLEX Cluster 2(No Preference)

VPLEX Cluster 1(Preference)

Hyper-VNode-2

WANConnectivity

Hosts

Hyper-VNode-1



WANConnectivity

VPLEX


Resource Group Failover

SITE-C

VPLEX Witness

Figure 21. Failure of a VPLEX cluster with preference

T his can be achieved by declaring the resource not available in the IsAlive and LooksAlive calls on the “nonpreferred” site. The resource DLL queries VPLEX for the distributed virtual volume status every time it receives these messages.

In this case, the resource DLL will determine that the CSV is no longer available from the “nonpreferred” site and will declare the resource dead. This triggers Microsoft cluster service to fail the resource group (VM + CSV) to a new node on the “preferred” site.

Failure of a VPLEX cluster with preference

In case the VPLEX cluster that has the preference for the distributed virtual volume fails, the VPLEX Witness will determine that the VPLEX cluster that does not have the preference is still alive and will recommend that I/O should continue from the surviving cluster. If there were VMs running on the failed VPLEX cluster site, the corresponding resource DLL will declare the CSV dead and all I/O would be stopped until the “resume” command could be issued at the nonpreference site.

NOTE: There are some scenarios where you may have multiple active writers where I/Os may continue at the nonpreferred site automatically.



SITE-BSITE-A



Hyper-VNode-2

WANConnectivity

Hosts

Hyper-VNode-1



WANConnectivity

VPLEX



SITE-C

VPLEX Witness

VPLEX Witness recommends that

VPLEX Cluster 2 will continue servicing I/O

Figure 22. Failure of a VPLEX cluster with preference

VPLEX inter-cluster link failure

In case of VPLEX inter-site link failure, the distributed virtual volume preference decides which VPLEX cluster site continues to service I/O. In Figure 23, VPLEX Cluster 1 will continue to provide service. The resource DLL on Site-B will discover that the distributed virtual volume on the local site is no longer servicing I/O and will force a corresponding resource group failure via the live migration tool.



SITE-BSITE-A



Hyper-VNode-2

WANConnectivity

Hosts

Hyper-VNode-1



WANConnectivity

VPLEX



SITE-C

VPLEX Witness

Figure 23. VPLEX inter-site link failure

VPLEX Witness failure scenarios

The following section addresses VPLEX Witness functionality and expected behavior while dealing with single or multisite failures.


Figure 24. Failure handling semantics

In case of extended VPLEX Witness failure

If for any reason you find that you are experiencing an extended or prolonged VPLEX Witness failure, that prolonged failure exposes the system to potential DU in the presence of additional failures. In this case you will need to temporarily disable the VPLEX Witness while it is down.

NOTE: This follows the assumption that the two clusters are in contact with one another.

To disable, run this from the CLI: “cluster-witness disable –-force –-force-without-server”

Networking considerations Hyper-V supports a variety of network adapters in various configurations. There are synthetic and legacy adapters. A synthetic adapter offers greater performance and optimized processor overhead.

A network adapter may be connected in the following methods:


1. Not Connected – Not plugged in to the network

1. Private Virtual Network – Provides a Virtual Switch for VM-to-VM communication (single Hyper-V)

2. Internal Virtual Network – Provides a Virtual Switch for VM-to-Hyper-V communications

3. External Virtual Network – Provides network access through physical adapters on Hyper-V

Rename the default network interface

When creating your virtual networks for Hyper-V it is important that you rename the default external interface name from something like “Broadcom BCM5708C NetXtreme II GigE” to something a little more descriptive. This could be something like “Public – 10.5.42.0” or “Private – 192.168.42.0.” By using descriptive names it becomes easier to manage as your virtual environment continues to grow. Also, as you deploy new VMs it is important to maintain these standardized names to ensure that live migrate and other functions continue to work as designed.

Dedicate network interfaces by traffic patterns

It is considered a best practice to dedicate at least one physical network adapter to Hyper-V management and backup traffic. Isolating this traffic from the VM production networks will ensure that in times of heavy traffic, it will not affect production.

Also it may be a good idea to also separate different types of traffic from single adapters. For example, you probably want to separate iSCSI from your production networks due to the adverse effects it may have on your network and/or disk performance. Another example is separating your cluster communication traffic to a private network so that there is never a problem with delayed response or other latencies.

Enabling Jumbo Frames

Enabling Jumbo Frames allows Hyper-V to accommodate packet sizes that exceed the default size of 1,500 bytes. Microsoft and EMC VPLEX Geo both support up to 9,000 bytes for Jumbo Frames, but it is important to note that each network component or appliance must also support this size. If set to 9,000 bytes, it must be set on all devices from point-to-point or it will not work.

Network Adapter Teaming

Although supported, when using highly available VMs with Failover Cluster it is not recommended at this time to use Network Adapter Teaming with this setup. If you are planning on deploying this service then be sure to disable “receive-side load balancing” on all teamed adapters. Failure to do so will cause the VMs to lose communication with the Hyper-V servers.


Conclusion To meet today’s demanding business challenges an organization’s data must be highly available—in the right place, at the right time, and at the right cost to the enterprise. Using VPLEX Geo with Microsoft Hyper-V, organizations can manage their virtual storage environments more effectively through:

Transparent integration with existing applications and infrastructure

Its ability to migrate data between remote data centers with no disruption in service

Its ability to migrate datastores across storage arrays nondisruptively for maintenance and technology refresh operations

References The following includes more information on EMC with Microsoft products and can be found on EMC.com and Powerlink:

Long-Distance Application Mobility Enabled by EMC VPLEX Geo—An Architectural Overview

VPLEX with GeoSynchrony 5.0 Product Guide

EMC VPLEX 5.0 Architecture Guide

Implementing and Planning Best Practices for EMC VPLEX

The following can be found on the Microsoft website:

Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2

Windows Server 2008 R2 & Microsoft Hyper-V Server 2008 R2 - Hyper-V Live Migration Overview & Architecture

microsoft hyper-v live migration and emc vplex geo · considerations for supporting microsoft...

Documents