EMC – VNX Pool LUN Allocation vs Default Owner

Posted on 2014-08-15 by dan

I had a question about this come up this week and thought I’d already posted something about it. Seems I was lazy and didn’t. If you have access, have a look at Primus article emc311319 on EMC’s support site. If you don’t, here’s the rough guide to what it’s all about.

When a Storage Pool is created, a large number of private LUNs are bound on all the Pool drives and these are divided up between SP A and B. When a Pool LUN is created, it uses the allocation owner to determine which SP private LUNs should be used to store the Pool LUN slices. If the default and current owner are not the same as the allocation owner, the I/O will have to be passed over the CMI bus between SP, to reach the Pool Private FLARE LUNs. This is a bad thing, and can lead to higher response times and general I/O bottlenecks.

OMG, I might have this issue, what should I do? You can change the default owner of a LUN by accessing the LUN properties in Unisphere. You can also change the default owner of a LUN thusly.

naviseccli -h <SP A or B> chglun -l <metalun> -d owner <0|1>

where

-d owner 0 = SP A

-d owner 1 = SP B

But what if you have too many LUNs where the allocation owner sits on one SP? And when did I start writing blog posts in the form of a series of questions? I don’t know the answer to the latter question. But for the first, the simplest remedy is to create a LUN on the alternate SP and use EMC’s LUN migration tool to get the LUN to the other SP. Finally, to match the current owner of a LUN to the default owner, simply trespass the LUN to the default owner SP.

Note that this is a problem from CX4 arrays through to VNX2 arrays. It does not apply to traditional RAID Group FLARE LUNs though, only Pool LUNs.

EMC CLARiiON VNX7500 Configuration guidelines – Part 1

Posted on 2011-09-06 by dan

I’ve been doing some internal design work and referencing the “EMC Unified Storage Best Practices for Performance and Availability Common Platform and Block Storage 31.0 – Applied Best Practices” – rev 23/06/2011 – h8268_VNX_Block_best_practices.pdf fairly heavily. If you’re an EMC customer or partner you can get it from the Powerlink website. I thought it would be a useful thing to put some of the information here, more as a personal reference. The first part of this two-part series will focus on configuration maximums for the VNX7500 – the flagship midrange array from EMC. The sequel will look at Storage Pools, RAID Groups and thin things. There may or may not be a third part on some of the hardware configuration considerations. Note that the information here is based on the revision of the document referenced at the start. Some of these numbers will change with code updates.

Here are some useful numbers to know when considering a VNX7500 deployment:

Maximum RAID Groups – 1000;
Maximum drives per RAID Group – 16;
Minimum drives per RAID Group – R1/0 – 2, R5 – 3, R6 – 4;
Stripe Size R1/0 (4+4) and R5 (4+1) – 256KB, R6 (6+2) – 384KB;
Maximum LUNs (this includes private LUNs) – 8192;
Maximum LUNs per Pool / all pools – 2048;
Maximum LUNs per RAID Group – 256;
Maximum MetaLUNs per System – 2048;
Maximum Pool LUN size (thick or thin) – 16TB;
Maximum traditional LUN size = largest, highest capacity RAID Group;
Maximum components per MetaLUN – 512;
EMC still recommends 1 Global Hot Spare per 30 drives.

When you add drives to a Storage Pool or RAID Group they are zeroed out – this is a background process but can take some time. New drives shipped from EMC are pre-zeroed and won’t be “re-zeroed”. The drives you bought off ebay are not. To pre-zero drives prior to adding to Storage Pool or RAID Group run the following commands with naviseccli:

naviseccli zerodisk -messner <disk-id> <disk-id> <disk-id> start

naviseccli zerodisk -messner <disk-id> <disk-id> <disk-id> status

Trespassing a Pool LUN will adversely affect its performance after the trespass. It is recommended that you avoid doing this, except for NDU or break-fix situations.

The LUN Migration tool provided by EMC has saved my bacon a number of times. If you need to know how long a LUN migration will take, you can use the following formula. LUN Migration duration = (Source LUN (GB) * (1/Migration Rate)) + ((Dest LUN Capacity – Source LUN Capacity) * (1/Initialization Rate)). The Migration rates are – Low = 1.4, Medium = 13, High = 44, ASAP = 85 (in MB/s). Up to 2 ASAP migrations can be performed at the same time per Storage Processor. Keep in mind that this will belt the Storage Processors though, so, you know, be careful.

EMC – naviseccli getlun -capacity

Posted on 2011-06-25 by dan

I needed to run this command recently to get the blocksize of a pool LUN that I wanted to migrate to a traditional FLARE LUN. I’ll going into the reasons for the migration another time, but basically a pool LUN doesn’t show you the number of blocks consumed when viewed through Unisphere.

So I used naviseccli to report the block count accurately so I could create another LUN of exactly the same size.

I:\>naviseccli -address 256.256.256.256 getlun 432 -capacity
LUN Capacity(Megabytes): 1048576
LUN Capacity(Blocks): 2147483648

It’s also important to note that you cannot migrate a LUN using the LUN Migration tool to a LUN that is larger than the source. Test it for yourself if you don’t believe me. If you want to migrate a LUN to a larger destination you need to use SAN Copy. This also became an issue recently when I needed to migrate some Pool LUNs to traditional MetaLUNs and used components that were a block or two too large. Fortunately when you create a MetaLUN you can specify the correct block count / MB / GB / size.