Start a Conversation

Unsolved

This post is more than 5 years old

2942

October 14th, 2012 21:00

VNX LUN best practise to form vmware datastore

We are having 2TB thin luns for our VNX, and they are concatenated to form datastore on VMware level

My question is for example if we are using 4 2TB LUNs to form a 8TB datastore, should all the LUNs having a same default SP owner, or it should be evenly distributed on two SPs. My understanding is it will be good to evenly distribute the load between SPs. But I have seen this article 'EMC primus emc287223', and worry if this will cause extra path trespasses.

We are using ALUA mode with vmware native multupathing

___________________________________________________

emc287223

Root Cause: With VAAI feature, it enables the ESX host to offload specific VM and storage management operations to the array. In cases where the operation involves two LUNs of different Storage Processors, redirection of I/O occurs. When the number of redirections hits a certain threshold, the redirector will perform an internal trespass to optimize the I/O load. In the event where there are both high application I/O and VAAI XCOPY I/Os, it is possible that the LUNs will trespass back and forth.

During implicit trespass such as these, PowerPath will receive a unit attention informing it of what happened. Because Power Path has no way to tell if the load has changed, PowerPath will not restore the previous LUN ownership

Fix: This behavior is working as designed. As a best practice, it is highly recommended to use LUNs of the same owning Storage Processor for such VMware operations.

November 25th, 2012 21:00

A "new" primus published emc305253 Unexplain trespass with with ESX using NMP and Unified OE Block ALUA.

January 16th, 2013 12:00

Why not just make a larger LUN for this?  My personal best practice is one LUN per Datastore.

If you are afraid of 2TB+ LUNS or using VNXe - go NFS.

Ian

February 24th, 2013 06:00

According to:

https://community.emc.com/thread/132762

https://community.emc.com/message/704402

https://community.emc.com/people/GearoidG/blog/2013/02/08/extended-copy-xcopy-vaai-primitive-not-behaving-as-expected-with-vnx-oe-release-32--emc313487

And NOW R32 MR1 is out!!! Please kindly help to verify if issues we mentioned are supposed to be fix by R32 MR1:

  

emc287223 "Unexplained trespass with PowerPath/VE 5.4 SP2 and CLARiiON ALUA."

emc305253 "Unexplained trespass with ESX using NMP and Unified OE Block ALUA"  

http://virtualgeek.typepad.com/virtual_geek/2013/02/vnx-vaai-fixes-smb-30-inyo-mr1-now-released.html

February 22, 2013

VNX VAAI fixes + SMB 3.0 + ODX – Inyo MR1 now released

In EMC-land, we have maintainance/service releases for major products – and often these don’t get the glory of the big launches, but contain a TON of important stuff.

Inyo is the code name for the currently shipping VNX Operating Environment that covers NAS and Block functionality (VNX OE 32/7), and Maintenance Release 1 (MR1) shipped to manufacturing on the 19th and is available for general download today (feb 22nd).

This contains a ton (read the release notes here – you can find all sorts of stuff on the VNX page on support.emc.com which is here), but there are 3 things I want to call out:

  1. Critical VAAI block XCopy fixes (Primus emc313487 – go to http://support.emc.com and just search for the Primus case)

9 Posts

February 25th, 2013 19:00

Thanks Baif for the information!

No Events found!

Top