Tag Archives: reserved lun pool

EMC – Configure the Reserved LUN Pool with naviseccli

Posted on by

I’ve been rebuilding our lab CLARiiONs recently, and wanted to configure the Reserved LUN Pool (RLP) for use with SnapView and MirrorView/Asynchronous. Since I spent approximately 8 days per week in Unisphere recently performing storage provisioning, I’ve since made it a goal of mine to never, ever have to log in to Unisphere to do anything again. While this may be unattainable, you can get an awful lot done with a combination of Microsoft Excel, Notepad and naviseccli.

So I needed to configure a Reserved LUN Pool for use with MV/A, SnapView Incremental SAN Copy, and so forth. I won’t go into the reasons for what I’ve created, but let’s just say I needed to create about 50 LUNs and give them each a label. Here’s what I did:

Firstly, I created a RAID Group with an ID of 1 using disks 5 – 9 in the first enclosure.

C:\>naviseccli -h 256.256.256.256 createrg 1 0_0_5 0_0_6 0_0_7 0_0_8 0_0_9

It was then necessary to bind a series of 20GB LUNs to use, 25 for each SP. If you’re smart with Excel you can set the following command to do this for you with little fuss.

C:\>naviseccli -h 256.256.256.256  bind r5 50 -rg 1 -aa 0 -cap 20 -sp a -sq gb  

Here I’ve specified the raid-type (r5), the lun id (50), the RAID Group (1),  -aa 0 (disabling auto-assign), -cap (the capacity), -sp (a or b), and the -sq (size qualifier, which can be mb|gb|tb|sc|bc). Note that if you don’t specify the LUN ID, it will automatically use the next available ID.

So now I’ve bound the LUNs, I can use another command to give them a label that corresponds with our naming standard (using our old friend chglun):

C:\>naviseccli -h 256.256.256.256 chglun -l 50 -name TESTLAB1_RLP01_0050

Once you’ve created the LUNs you require, you can then add them to the Reserved LUN Pool with the reserved command.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -addlun 99

To check that everything’s in order, use the -list switch to get an output of the current RLP configuration.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -list
Name of the SP:  GLOBAL
Total Number of LUNs in Pool:  50
Number of Unallocated LUNs in Pool:  50
Unallocated LUNs:  53, 63, 98, 78, 71, 56, 88, 69, 92, 54, 99, 79, 72, 58, 81, 5
7, 85, 93, 61, 96, 67, 76, 86, 64, 50, 66, 52, 62, 68, 77, 89, 70, 55, 65, 91, 8
0, 73, 59, 82, 90, 94, 84, 97, 74, 60, 83, 95, 75, 87, 51
Total size in GB:  999.975586
Unallocated size in GB:  999.975586
Used LUN Pool in GB:  0
% Used of LUN Pool:  0
Chunk size in disk blocks:  128
No LUN in LUN Pool associated with target LUN.
C:\>

If, for some reason, you want to remove a LUN from the RLP, and it isn’t currently in use by one of the layered applications, you can use the -rmlun switch.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -rmlun 99 -o

If you omit the override [-o] option, the CLI prompts for confirmation before removing the LUN from reserved LUN pool. It’s possible to argue that, with the ability to create multiple LUNs from Unisphere, it might be simpler to not worry about naviseccli, but I think that it’s a very efficient way to get things done quickly, particularly if you’re working in a Unisphere domain with a large number of CLARiiONs, or on a workstation that has some internet browser “issues”.

New Article – Adding capacity to the Reserved LUN Pool

Posted on by

Another simple one that I thought was worth documenting for the cosmetic changes in Unisphere. You can find it here. Check out the rest of my equally exciting guides here.

Reserved LUN Pool with EMC MirrorView/Asynchronous

Posted on by

I’ve spoken briefly before about some of the requirements for MirrorView/Asynchronous, the big “gotcha” being that you need to configure a Reserve LUN Pool on both ends of the solution. There are a variety of formulas used by people to come up with the number and size of the LUNs to use in this scenario. As a rule of thumb, you can count on approximately 20% of the total storage you want to replicate being used for RLP. I’ve seen literature that then suggests you take the number of LUNs you want to mirror, times it be two and divide your RLP storage by that number. Sound a little flaky? Well, some of that is in the re-telling, and some of it is a little flaky. EMC, bless their cotton socks, have a knowledge base article on powerlink (emc107717) entitled “Best practices for setting up Reserved LUN Pool (RLP)”. Now that sounds like something you should be reading. In a nutshell, there are two ways (among many) that you can approach the RLP-sizing question.

“Since reserved LUNs are automatically assigned, users are encouraged to select a uniform size for reserved LUNs, so that all reserved LUNs are suitable for use with any source LUNs”. So we need to create a number of LUNs in the RLP, and we can’t select which RLP LUNs are used with which Remote Mirrors. So we might have a 1TB LUN to mirror and 4 100GB LUNs to mirror. Oh what we do now? One option is to use “Small Reserved LUNs to Conserve Space”. I prefer this option, as invariably the customers I’m deploying MV/A for haven’t considered how much RLP they will need, so we need to squeeze the RLP into whatever space they haven’t allocated to data in their hastily-prepared LUN design. Sometimes, my customers like to pur the RLP on the FLARE disks as well, just to add a little, er, excitement, to the experience. Assume 20% of your source is a good size for the Reserved LUN. So, in our example, we have a 1TB LUN and 4 100GB LUNs to mirror. 20% of 100GB is, like, 20GB. So if we use 20GB as a basis for the RLP LUN size, we’ll need 4 20GB LUNs for the 4 100GB LUNs, and 10 20GB LUNs for the 1TB LUN. This calculation, of course, is based on the assumption that you’ll only have a maximum of 20% block changes between synchronisation activities. If you have some insane application that changes 50% of your blocks in a short amount of time, you’re going to need to bump up that number.

Another option available is to use large Reserved LUN sizes to minimize the number of LUNs in the RLP. This can become an issue if you have a large number of mirror activities in play, and need to have a large number of RLP LUNs to cope with this. On the CX5-4-300, you were limited to 50 Reserved LUNs, and on the CX7-600, you were limited to 100 Reserved LUNs. With the CX3 and CX4, however, these limitations have changed. Note that I am too lazy to look them up for you. So, in our current example, to minimize the number of Reserved LUNs, you could configure 4 100GB LUNs as the RLP for the 4 100GB LUNs, and 2 100GB LUNs to cover the 1TB source LUN.

So, here you have two scenarios, both of which can work for you, but ultimately, as EMC states in the article “Users must decide whether they are constrained by the total number of reserved LUNs or the total amount of space that they have available for use”. Of course, if you don’t do something along these lines, you’ll end up with emc121295, which is this gem “Adding async mirror image failed. You must add LUNs with adequate capacity to the Reserved LUN Pool before you can use this feature. (0x71008031)”. When you don’t have the RLP sorted, you may be able to add a few mirrors, but then you’ll find yourself unable to add any more. And you’ll feel sad if this is the case. So be good and set up your RLP properly. If nothing else, do it for the children.