A while back, I commented on how CCI was a pain in the proverbial **** because specifying the replicated LUNs required them to be presented onto a port/HSD. Snig kindly pointed out that although the LDEV needs to be presented, you can now just use the LDEV number rather than the complicated TID/LUN representation previously required.
I've been checking this out today as I've been doing some replication work and want to put together a central replication server which can build disk groups for all possible hosts on an array. Any hoo, I found that you can now specify the LUN number of the device on a port in the HORCM file, if you specify the port and the HSD number - like CL1-C-6 or similar, where 6 is the HSD number. Unfortunately you still need to specify the TID which has to be obtained from RAIDSCAN.
I gleaned this information from "Command Control Interface User and Reference Guide" version MK90RD011-18 (June 2006). In here I still can't see a reference to using LDEVs rather than LUN numbers, which to me, still makes the CCI specification a pile of unmentionables. In fact, I republish here this remarkable paragraph from section 4.20.1 of the said manual:
"The way what CCI has addition of argument for the host group to the raidscan command and
the configuration file will not be able to maintain the compatibility with conventional CLI.
Therefore, CCI adopts a way that supports in the form which specifies a host group in the
port strings as follows."
Now this has me confused - in fact those clever Japanese have already pre-empted me because the previous paragraph tells me how I was about to be confused:
"The USP/NSC and 9900V have the defined host group in the port and are able to allocate
Host LU every this host group. CCI does not use this host LU, and specifies by using absolute
LUN in the port. Therefore, a user can become confused because LUN of the CCI notation
does not correspond to LUN on the host view and Remote Console. Thus, CCI supports a way
of specifying a host group and LUN on the host view."
It would be useful if someone from HDS could confirm if I've read the manual correctly (or if there's a later release) as I still don't think replication based on LDEV is possible. The sooner it is brought in the better; the current method is just way too risky for my liking.
Tuesday 12 June 2007
CCI Update
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
Hi Chris,
If you change the name of the HORCM_DEV section to HORCM_LDEV you can specify LUNs as follows -
group device serial_of_array LDEV_number MU
E.g.
group1 device1 12345 01:33 0
No more need for TIDs etc
You can also now specify a command device as follows -
\\.\CMD-12345-510
Where 12345 is the array serial number and 510 is the decimal representation of the hex LDEV number. Interestingly you dont even have to specify the LDEV number, just the array serial number is sufficient (havent looked into that yet). Great for Windows shops and I would never think of using one of the old ways.
I understand that this functionality requires a certain array MC and version of CCI but most recent versions should be fine.
Nigel
Nigel, just tried this and - result - it works - thanks for providing an example. I also found the details in the manual, which I doubt I would have found without you specifying the HORCM_LDEV prefix. This is a great step forward and *so* much simpler to visualise (and create). Hopefully replication without needing to present the LUN won't be too far away; then we're really sorted!
Chris,
How do EMC do it? Do they have an attribute or something on the volume to indicate that it is being used for SRDF etc? Obviously there needs to be a clear way to determine that although the volume is not presented on a port, it is NOT free to be allocated to a host.
Cheers
EMC LUNs/LDEVs all have a personality - so they are local (simplex) or R1 (PVOL) or R2 (SVOL). The relationship between the R1/R2 in a pair is based on the LUN/LDEV number and exists irrespective of the use of the LUN. At installation time it would be normal to pre-assign R1/R2 pairs and sync them up. That way, they can be allocated out as needed. Otherwise, symconfigure can be used to change the status of devices after initial installation (a binfile change can also be used). There are lots of controls in symconfigure to cater for making illogical changes - for example, you can't break an R1/R2 pair that is in use on a port. Although at the time these are annoying, they can save your bacon if you haven't thought through the implication of a change. What worries me about CCI is the ability to mistype an entry in horcmx.conf, for instance selecting the wrong HSD and inadvertently pair against LDEVs that are in use. Fortunately, with EMC symconfigure, the target SVOL has to be write disabled before this can be done.
Post a Comment