Reserved LUN Pool with EMC MirrorView/Asynchronous

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.