VMware HA and vMotion with stretched IBM System Storage SAN Volume Controller Cluster
search cancel

VMware HA and vMotion with stretched IBM System Storage SAN Volume Controller Cluster

book

Article ID: 343148

calendar_today

Updated On:

Products

VMware vCenter Server VMware vSphere ESXi

Issue/Introduction

This article provides information about Partner Supported Products for using Stretched IBM System Storage SAN Volume Controller Cluster (SVC Cluster) with VMware HA and vMotion.

Disclaimer: The partner products referenced in this article are hardware devices that are developed and supported by stated partners. Use of these products are also governed by the end user license agreements of the partners. You must obtain the application, support, and licensing for using these products from the partners. For more information, see Support Information.


Environment

VMware vCenter Server 4.1.x
VMware ESXi 4.1.x Embedded
VMware ESXi 4.1.x Installable
VMware ESX 4.1.x

Resolution

Description of Stretched SAN Volume Controller cluster:

A stretched IBM SAN Volume Controller configuration in conjunction with VMware vSphere enables transparent VMware vMotion migration and automatic VMware HA failover of virtualized workloads between physical data centers.
The IBM System Storage SAN Volume Controller is an enterprise class storage virtualization system that enables a single point of control for aggregated storage systems (both IBM and non-IBM branded), while enabling common copy functions, non-disruptive data movement, and improving performance and availability.
IBM SAN Volume Controller combines hardware and software into an integrated, modular solution that forms a highly scalable cluster. An IBM SAN Volume Controller cluster is commonly installed to provide service in a single data center.
An IBM SAN Volume Controller cluster can provide service to two data centers at a maximum distance of 10 kilometers. In a stretched configuration, IBM SAN Volume Controller enables a highly available stretched volume to be concurrently accessed at both data center locations.

Supported use cases

This list describes the supported use cases of a stretched SAN Volume Controller cluster and VMware vSphere.
  1. A stretched SAN Volume Controller cluster presenting an accessible VMware VMFS volume to vSphere hosts at two separate data center locations separated by a distance of up to 10 kilometers.
  2. Single stretched vSphere cluster leveraging VMware HA and DRS functions with hosts at two separate data center locations separated by a distance of up to 10 kilometers.
  3. vMotion between vSphere hosts at two separate data center locations separated by a distance of up to 10 kilometres (as per IBM recommendations for SVC clusters with longwave SFPs)
  4. Automatic HA fail over of virtual machines between data centers due to server, storage, or site failure.

Tested Scenarios

This table outlines the tested and supported failure scenarios when using a stretched SAN Volume Controller cluster and VMware vSphere.

Failure Scenario

SAN Volume Controller Behavior

VMware HA Impact

Path Failure – SAN Volume Controller Back End Port

  • Single path failure between SAN Volume Controller node and storage subsystems
  • No impact to volume mirroring
  • No impact

Path Failure – SAN Volume Controller Front End Port

  • Single path failure between SAN Volume Controller node and host
  • No impact to host access
  • Loss of path
  • No downtime impact.

Active SAN Volume Controller Quorum Disk Failure

  • Secondary quorum disk assigned upon failure of active quorum
  • No impact

Loss of storage subsystem

  • Loss of volume mirror copy at site with affected storage subsystem
  • No impact to volume access
  • No impact

SAN Volume Controller Node Failure

  • Loss of volume mirror
  • Paths to impacted SAN Volume Controller node lost
  • Volume accessible on secondary node
  • No HA impact

vSphere Host Failure

  • No Impact
  • HA event triggered
  • Virtual machines restarted on other hosts in cluster

vSphere Host Isolation

  • No Impact
  • HA event dependent upon isolation response rules
  • Virtual machines can be left on, or rules can dictate for virtual machines to shut down and restart on other hosts in cluster

vSphere Cluster Failure

  • No Impact
  • VMware HA powers on virtual machines after hosts are available

Complete Site Failure

  • Volume still accessible at secondary site
  • VMware HA triggered to restart virtual machines on available hosts.

Configuration Requirements

These requirements must be fulfilled to support VMware HA, DRS, and vMotion functions between data centers with a stretched SVC cluster.
  1. VMware vCenter server must be able to connect to vSphere hosts at both locations.
  2. An IP network with a minimum bandwidth of 622 Mbps for vSphere hosts participating in vMotion.
  3. Maximum latency of 5 milliseconds (ms) between hosts participating in vMotion.
  4. Source and destination vSphere hosts must have a network interface on the same IP subnet and broadcast domain.
  5. The same IP network on which the virtual machines reside must be accessible to vSphere hosts at both data center locations.
  6. Datastores on which the virtual machine boot drives must be accessible to vSphere hosts at both data center locations.
  7. The maximum number of vSphere hosts in a HA-enabled cluster must not exceed eight (8), with four (4) hosts residing at each site.
  8. IBM SAN Volume Controller cluster running software code 5.1 or later, and configured in a supported hardware configuration as outlined in the IBM System Storage SAN Volume Controller V6.1.0 Software Installation and Configuration Guide.

Supportability

If you encounter an issue in this environment and the environment meets all configuration requirements outlined above, file a Support Request with VMware or IBM. Whether you choose VMware or IBM depends on which will best serve your needs based on the issue you have encountered.

How the process works

If you open the Support Request directly with VMware Support Services, the support team will troubleshoot the issue and can engage VMware engineering if required. If, during the troubleshooting process, it is determined that the cause of the issue is related to the IBM Stretch Cluster, VMware will request that you either:
  1. Provide VMware with all of your entitlement details with IBM (so that VMware can engage IBM via Technical Support Alliances; or
  2. File a Support Request with IBM directly and provide VMware with all relevant details, including the Support Request number and the appropriate contact information for IBM's support personnel.
Adhering to this process ensures both vendors will collaborate directly on the issue you have encountered.
Note: The process described here works in the same way if the Support Request is initially opened with IBM.
The following caveats will be applied:
  • If an issue is encountered on a Failed Scenario that is not mentioned in this article under the Tested Scenarios section, both VMware and IBM will apply their best efforts to help the customer. However, a supported resolution cannot be guaranteed by either VMware or IBM.

Examples of a failed scenario include, but are not limited to:

  • When two or more of the aforementioned scenarios occur at the same time.
  • When a network interface goes down or causes latency to be higher than five milliseconds during a vMotion operation.
If the issue cannot be reproduced in a non-SVC stretched configuration, IBM needs to reproduce the problem in an IBM lab environment.

Caution: This article only applies to the vSphere 4.1 release. Consult the VMware vSphere 5 vMSC program for future configuration offerings and support.

Additional Information

Support Information

For more information, see IBM product and support pages.