Tag Archives: WIL

EMC – CX4 Configuration – a few things I’d forgotten

Posted on by

I’ve been commissioning some new CX4-960s recently (it’s a long story), and came across a few things that I’d forgotten about for some reason. If you’re running older disks, and they get replaced by EMC, there’s a good chance they’ll be a higher capacity. In our case I was creating a storage pool with 45 300GB FC disks and kept getting the following error.

This error was driving me nuts for a while, until I realised that one of the 300GB disks had, at some point, been replaced with a 450GB drive. Hence the error.

The other thing I came across was the restriction that Private LUNs (Write Intent Log, Reserved LUN Pool, MetaLUN Components) have to reside on traditional RAID Groups and can’t live in storage pools. Not a big issue, but I hadn’t really planned to use RAID Groups on these arrays. If you search for emc254739 you’ll find a handy KB article on WIL performance considerations, including this nugget “Virtual Provisioning LUNs are not supported for the WIL; RAID group-based LUNs or metaLUNs should be used”. Which clarifies why I was unable to allocate the 2 WIL LUNs I’d configured in the pool.

*Edit* I re-read the KB article and realised it doesn’t address the problem I saw. I had created thick LUNs on a storage pool, but these weren’t able to be allocated as WIL LUNs. Even though the article states “[The WIL LUNs] can either be RAID-group based LUNs, metaLUNs or Thick Pool LUNs”. So I don’t really know. Maybe it’s a VNX vs CX4 thing. Maybe not.

EMC – Manipulating the Write Intent Log LUNs with naviseccli

Posted on by

Last week Mat was wanting to migrate some WIL LUNs on one of our CX4s to a different RAID Group. Unfortunately, one does not simply migrate WIL LUNs. Firstly, once they’re allocated, they’re treated as Private LUNs by FLARE, so you can’t use Virtual LUN technology to migrate them. Secondly, if you have active MirrorView mirrors in place, you’ll get the following error when trying to de-allocate the WIL LUNs via Unisphere: “Unable to deallocate WIL since in use (0x71058199)[0x71058199]“. Note that fracturing the mirrors is not sufficient to avoid this error.

So there’s a few things you need to do to resolve this. Firstly, confirm the WIL LUNs in use on the array (there’s only 2).

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -listlog
Storage Processor: SP A
Lun Number: 10000
Storage Processor: SP B
Lun Number: 10001

Now list all the mirrors that are using the WIL. Note that it lists the primary and secondary mirrors, so you’ll need to extraxt the primary mirrors from the list.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -list -usewriteintentlog
MirrorView Name: DC1_FC_R5_DATA_0002_SRM
Write Intent Log Used: YES
[snip]

Now the simplest thing to do is create a script that runs the command below for each of the mirrors in your list of primaries. This command disable the use of the WIL, and -o won’t prompt for confirmation.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -change -name DC1_FC_R5_DATA_0002_SRM -usewriteintentlog no -o

Now that you’ve done that, you can allocate the new WIL LUNs.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -allocatelog -spA lun_ID1 -spB lun_ID2

Now run your script again, changing -usewriteintentlog from no to yes.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -change -name DC1_FC_R5_DATA_0002_SRM -usewriteintentlog yes -o

And now you can get rid of those old WIL LUNs. Huzzah!