Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Implementing vSphere Metro Storage Cluster (vMSC) using HPE Nimble Storage Peer Persistence (77185)

Last Updated: 2/10/2020Categories: InformationalTotal Views: 21488Language:
Chinese (Simplified)JapaneseEnglish

36 like this article

Subscribe to get an email
newsletter with new updates

36 people found this helpful Please provide article feedback:

Details

This article provides information about deploying a vSphere Metro Storage Cluster (vMSC) across two data centers or sites using HPE Nimble Storage.

Solution

What is vMSC?

vSphere Metro Storage Cluster (vMSC) is a tested and supported configuration for stretched storage cluster architectures. A vMSC configuration is designed to maintain data availability beyond a single physical or logical site. All supported storage devices are listed on either the VMware Storage Compatibility Guide or the Partner Verified and Supported Products (PVSP) listings.

What is HPE Nimble Storage Peer Persistence?

Built from a resilient architecture, HPE Peer Persistence is available on HPE Nimble Storage. Paired arrays located at metropolitan distances, present a continuous storage system to hosts connected to them.
This capability allows you to configure a high-availability solution between two sites where storage failover and failback remains completely transparent to the hosts and applications running on those hosts.
This results in elimination of recovery times because unlike traditional failover models, your applications don’t have to be restarted after a failover.

HPE Nimble Storage Quorum Witness

The HPE Nimble Storage Quorum Witness is a component provisioned as a virtual machine that is recommended to be deployed at a third site. The HPE Nimble Storage Quorum Witness, along with the two  Nimble Storage systems, forms a three part quorum system. This quorum system monitors  the status of both the HPE Nimble Storage systems and the storage site inter-links. A number of site and inter-link failure scenarios are recognized by this three part quorum system, and appropriate failover actions are implemented. In the event of a disaster that brings down one of the storage  sites, a failover to the surviving HPE Nimble Storage site is automatically initiated. During this failover operation, replicated volumes on the remaining storage system are made active. The host paths to those volumes are also made active, thereby ensuring that hosts can continue to access their volumes without any disruption or outage. Communication between the three sites for quorum is via the Quorum Witness IP and the service management IP’s of the two HPE Nimble Storage systems. HPE Nimble Storage Quorum Witness does not actively participate in data storage and a failure or removal of the HPE Nimble Storage Quorum Witness from an otherwise functioning environment will have no impact on data storage. However it will impact the automatic switch over from one site to another incase of a disaster. Thus the HPE Nimble Storage Quorum Witness only comes into play when one site or the Inter-Site Link (ISL) has failed.

Configuration Requirements

These requirements must be satisfied to support a vMSC configuration with HPE Nimble Storage.

VMware ESXi 6.0 or higher, Metro Storage Cluster configured for uniform host access per VMware requirements and best practices.

In the first release, HPE-Nimble Peer Persistence can only be configured between arrays of the same model. Meaning an AF40 can replicate to another AF40 but not to a HF40, as one is All Flash, the other is Hybrid. Capacity and interface cards may differ on both systems, but the type and model of the arrays must to be the same. This is to ensure the best ISL performance.

Peer Persistence is supported on the current 'Gen5' and previous generation of HPE Nimble Storage hardware, including:

AFx0 arrays, HFx0 arrays
AFx000 arrays, CSx000 arrays.
The HF20H and CS1000H are not supported for synchronous replication - even if fully populated with both halves of drives.

In order to provide maximum protection, redundant links for Replication and Client Access are required. A minimum of 2 x 1Gb Ethernet links are required per controller for Replication traffic.

Both FC and iSCSI attached hosts are supported with Peer Persistence, however the ISL is available over IP.

Nimble Peer Persistence supports both upstream and downstream volume replication. The volumes are grouped into Volume Collections (VolCol). A VolCol may either be upstream or downstream. Additionally an individual VolCol will only serve data on the host side either on FC or IP, not  both i.e. mixed protocols in a VolCol are not supported.

Latency should remain <5ms round-trip response time between arrays in the group on all synchronous replication links. The replication traffic will be classified as “Group traffic” within the scale-out group.

If using Automatic Switch Over (ASO) for application transparent failover, it is highly recommended that the Witness client be located at a third site for failure domain redundancy.

NimbleOS 5.1 comes with updated host-side Nimble Toolkits, and these should be installed and correctly working for VMware, Windows and/or Linux hosts.

Solution Overview

A test qualified VMware Metro Storage Cluster using HPE Nimble Storage is supported in accordance with the VMware description of a uniform access vMSC configuration. Particular to the uniform access configuration, host data path connections at each site are cross-connected to the peer Data Center site storage array. ESXi hosts access volumes in the Data Center local array via active paths. Connectivity to standby peer volumes on the distance array is maintained in standby mode until such time as a failover or switchover. In concert with HPE Nimble Storage, HPE Nimble Quorum Witness and with Automated Fail Over (AFO) enabled, a minimally disruptive switchover or failover of volume access across sites can be achieved.
A vital component is the HPE Nimble Storage witness server which arbitrates in a split-brain scenario.

AFO is triggered in following scenarios

Array is not reachable to its peer array and witness for certain amount of time i.e. the array is out of quorum

if Group Leader not reachable(no heartbeats to quorum), Backup Group Leader will become Group Leader and sync replication handover happens so that new group leader can start serving the IO.

if Backup Group Leader not reachable(not heart beating to quorum),  Group Leader (GL) will handover sync rep volumes served from Backup Group Leader (BGL). So that GL can start serve the IO for those volumes.

When Backup Group Leader (BGL) cannot reach Group Leader (even if BGL can reach witness), Then Group leader will perform AFO and start serving IO from group leader. This is due to NimOS dependency on group leader to be reachable to server IO

This diagram depicts a high level overview of the solution.

Failure Scenarios

It is important to understand how the system will react under various failure conditions. In some situations, the hosts may also be experiencing failures. HPE Nimble Storage Peer Persistence is designed to protect the integrity of the data while allowing ASO. Under certain failure conditions, ASO may not occur.

Scenario

HPE Nimble Storage System Behaviour

Witness Failure or disconnect

All volumes will remain online and serving data on their current array. Once the Witness is repaired, ASO capability will recover.

Volumes out of sync

When a downstream synchronously-replicated volume is unavailable, then the upstream volume collection goes out of sync, but host I/O is accepted. Note that I/O resynchronization is continuously attempted by the upstream volume in this state. When the volume recovers resynchronization brings the upstream and downstream volume collections into sync.

Local Controller failure

During a local controller failover operation, no ASO will occur. Controller operations will resume locally on the partner controller. Volume collections may go out of sync briefly and automatic resynchronization may be required

Array failure

If an entire array fails, an ASO will be triggered. Group functions and access to data will be provided by the surviving array. Resynchronization will occur after the array is recovered and brought back online. A manual handover will be required after recovery and resynchronization. Volumes not protected by Peer Persistence will be unavailable.

Replication Link failure

Volume collections will resynchronize after replication links are recovered.

Related Information

https://infosight.hpe.com/InfoSight/media/cms/active/public/HPE_Nimble_Storage_Peer_Persistence_Deployment_Considerations.pdf

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
仮想マシンの作成中に、Debian 9 ゲスト OS オプションを使用することができない (76911)

KB
•
Intel® Optane™ DC 永続メモリ モジュールをサポートする Intel® Server System S2600WF ファミリ (70884)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-4 of 4

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

Related Versions:

Take Our Survey

Support Assistant