Tag Archives: FAST Cache

EMC – naviseccli – Using chglun to modify LUN cache settings

Posted on by

Friday morning I had cause to “fiddle” with the LUN cache settings on 312 component LUNs across 2 arrays and needed to turn on read and write cache on each component LUN. Via Unisphere I would have to find the MetaLUN, right-click, select Show Components, expand the Component 0, right-click on the component, select Properties, select the Cache tab, tick the radio boxes for SP Read Cache and SP Write Cache, click OK, then re-expand the Component 0, rinse and repeat. On a few components this is tolerable, but for 312 not so much.

So I thought that maybe I could do something with naviseccli. You can change the cache properties of a LUN, amongst other things, using the chglun command.

chglun -l <LUN-ID> -c none | caching read | write | rw – where you can select no cache, read cache, write cache or read-write cache. So the command I used to enable rw cache on the LUN was

naviseccli -h 256.256.256.256 chglun -l 24047 -c rw

Note that if you have FAST Cache installed you can also use this command to set FAST Cache for a LUN using the -fastcache 0 | 1 switch.

My next issue was that, even though these components had normal LUN IDs like 3, 8 and so forth, their actual LUN ID when they were used as MetaLUN Components was changed to something else by Unisphere. So I ran a report for each array to list the configured MetaLUNs. I then opened the .xml file in Excel and copied the Component LUN IDs into a different column. Put some commands before and after the column and then saved it as a txt file that I could then run as a script. It took a little time to run, but a lot less time than it would have taken to change these settings by hand. If you are checking the resultas in Unisphere you should make sure that you’ve refreshed your screen, because it least in our environment it can take a while to show up.

One other thing to note is that, as the manual says, “The chglun command does not support thin LUNs”. Fair enough, so I can do chglun operations on Pool LUNs? Well, mostly. Here’s one we tried earlier:

c:\>naviseccli -h 256.256.256.256 chglun -l 130 -c rw
Error: chglun command failed
Switch not supported: -c
One or more of the specified switches is not supported for the input Pool lun.

c:\>

New Article – Configuring FAST Cache on the CLARiiON

Posted on by

I’ve added a brief article full of pretty screenshots regarding FAST Cache on the CX4. Nothing groundbreaking – because that’s not really my style. I hope to have some more posts shortly on our real world experiences with FAST and FAST Cache. Check out some other articles here.

EMC – FAST and FAST Cache on the CX4-960

Posted on by

Apologies for the lack of posts over the last few months – I have been nuts deep in work and holidays. I’m working on some literature around Storage Pools and FAST in general, but in the meantime I thought I’d share this nugget with you. We finally got approval to install the FAST and FAST Cache enablers on our production CX4-960s a few nights ago. We couldn’t install them on one of the arrays because we had a dead disk that prevented the NDU from going ahead. Fair enough. Two awesome things happened when we installed it on the other array. Both of which could have been avoided if I’d had my shit together. Firstly, when I got into the office the next morning at 8 am, we noticed that the Read Cache on the array was disabled. For those of you playing at home, we had the cache on the 960 set at 1000MB read and 9760MB for write. I think I read this in a whitepaper some where. But after FAST went on, we still had 9760MB allocated to Write, and 0MB available for Read. Awesome not so much. Seems that we lost 1000MB, presumably because we added another layered application. Funnily enough we didn’t observe this behaviour on our lab CX4-120s, although you could argue that they really have sweet FA of cache in the first place. So now we have 8760MB for Write, and 1000MB for Read. And I’m about to configure a few hundred GB of FAST Cache on the EFDs in any case. We’ll see how that goes.

The other slightly boneheaded thing we did was forget to trespass the LUN ownership of LUNs on SP A back from SP B. In other words, an NDU applies code to SP B first, reboots the SP, checks it, and then loads code on the other SP. As part of this, LUN ownership is temporarily trespassed to the surviving SP (this is the whole non-disruptive thing). Once the NDU is complete, you should go and check for trespassed LUNs and move them back to their owners. Or not, and have everything run on one SP for a while. And wait for about 9000 Exchange users to complain when one of the Exchange clusters goes off-line. Happy days.

EMC FAST and FAST Cache

Posted on by

I don’t have a lot to say on FAST or FAST Cache just yet – because the PO hasn’t quite made its way to EMC. But when I was researching the topic I found Matt Taylor’s post on this topic to be an excellent summary – particularly the point about configuration options. Particularly if you’re rolling with multiple CX4-960s – as we are. I think it’s going to scream :)