Slow week….
by Jesse on Nov.04, 2007, under Symmetrix
Last month my timesheet showed a whopping 245 hours….. I’m tired.
But the insanity continues. We completed the first stage of migrations last week, a swimming success. (it’s funny, because I got the impression from the end-customer that they didn’t expect it to go as smoothly.)
SRDF is the easiest way to move data – granted these were….shall we say OLDER systems, running Solaris 2.7/2.8 and Solstice DiskSuite (not something I would *EVER* recomend, as any logical volume manager that runs based on the CxTxDx number of the device is inherently risky, if the CxTxDx number changes, there goes your entire volume group configuration) and this created a number of ridiculous requirements that we had to jump through hoops at the last minute to meet, like making sure the lun numbers didn’t change.
Another requirement was that we had to stick to an out-of-date code rev on the new DMX-3. Normally I’m not the biggest fan of running the “latest and greatest” revision of software, mostly because I don’t like being the one to do the post-beta – beta-testing. I prefer to let it crash someone else’s system first.
But EMC’s Enginuity code is pretty unique in that the benefits of a major code rev update usually outweighs the draw-backs.
As an example. 5772 is the latest major rev of DMX code. We’re running 5771 on the DMX3′s we’re migrating too. 5771 is very stable, does a lot, performs well, etc.
But it does not however allow for dynamic lun numbering. On a Clariion you have two lun numbers. The ALU (Array Logical Unit) and HLU (Host Logical Unit) The ALU is the identifier and what is assigned to the lun by the array, the HLU is what the host sees, and is usually determined by what order the devices are added to the storage group.
On a Symmetrix, the ALU is the only lun. You configure a device to have lun 0EF, and that is exactly what the host sees. So on a Sun system you’d translate that to decimal and configure lun # 239 in your sd.conf as the lun.
Now enter 72 code and dynamc lun numbering. You can now, through the symmask command, dynamically assign a “host-facing” lun # to a device, which means that even if the array-based lun skips all over, your host-based lun numbers will end up nice and sequential. This can come in very handy when you run across operating systems that don’t like to have holes in the lun numbering.
An interesting tidbit.Â
November 7th, 2007 on 12:38 pm
I haven’t done it because it looked way too “involved” for the paypack (none of our OS’s are that picky about requiring sequential numbering), and the strong possiblity of completely confusing other admins. But on 71 code (and 70 if not older) you should be able to change the HLU using the symmask command as well. Using the lunoffset option will allow you to set the lun # for the specific wwn, calculated from a base number. Because of the number of hypers we were presenting to hosts on our old sym 8k’s we started to encroach on 255 luns on a FA, so I had to do some investigation. Luckily new versions of solutions enabler came out, allowing me to create meta’s without involving our SE and I no longer worry so much about it.
November 8th, 2007 on 5:42 am
Lun_offset is (with 71 code) the best way to go about it – much in the same way that Scotch is the best way to numb pain when oxycodone isn’t an option.
But you have to remember that you only have one “hole”. So if your lun numbers (sym-side) go 0-5, 8-12, 17-20, you can close the 5-8 hole but not the 12-17 hole.
The best way I’ve found to do this is, especially in a Solaris environment where lun #’s can’t go above 255, to group the hosts as follows:
00-FF – Host-A
100-1FF – Host-B
200-2FF – Host-C
300-3FF – Host-D
Then drop the first digit of the lun number using the following commands:
symmask -sid 1234 set lunoffset on 100 000 -awwn HostA/HBA0 -dir 8a -p 0
symmask -sid 1234 set lunoffset on 200 000 -awwn HostB/HBA0 -dir 8a -p 0
symmask -sid 1234 set lunoffset on 300 000 -awwn HostC/HBA0 -dir 8a -p 0
etc.
The only difference is, if you need to have the VCMDB device visible, you have to change the lun-offset to “100 001″ instead of “100 000″ to make sure that lun000 is exposed to the host. The down side is that if you use “set lunoffset on 100 001″ then lun # 100 (actual) is useless, because ALU 100 becomes “hidden” behind ALU 000.
Then when presenting new luns to a host, you simply determine which range the lun is in and put it in that range, so if you were adding 0AC to Host-B, you’d actually map it to the front-end ports as 2AC and when you mask the device the offset would automatically compensate.
it’s handy, but like i said before, it doesn’t enable you to take a disbursed range of lun numbers and present them as a sequential list, that requires 5772 code.
/jg