Cluster - LUN / HOSTID Host Interpretation Error? Please Help

Question

Here's a simplified description of the problem: (this is an example but speaks to the symptom we're experiencing) Long story short from the storage groups all the shared luns have same host id but are coming up different on the host and causing problems with our junction drives ( placeholders to overcome the drive letter limitation ) [KNOWN] A. One the first node in the cluster we 1) assign drive letters, 2) format, and 3) assign volume lable for all the shared (clustered) luns while other cluster nodes offline. This implies the only thing one must do is shut this node down, power up next node and simply assign a drive letter using node 2's Windows Disk Mgr. After closing out of disk mgr and going back in, the drive letter assigned should auto populate the volume lable created on node 1 initally. Host Clariion Host Power Host 1 Host 1 Host 1 Name HLU ID Path Dump Disk Mgr Drive Letter Vol Label Comment ===================================================================================== ============ node1 lun 33 -------> lun 33 disk 1 H EVS1-SG1 n/a node1 lun 38 -------> lun 38 disk 2 I EVS1-SG2 n/a node1 lun 40 -------> lun 40 disk 3 J EVS1-SG3 n/a B. Now, we shut down node 1 and power up node 2 to avoid corrupting shared luns since MS cluster disk driver is not loaded/running yet. Refering to the power path dump from node 1 we determine that the junnction drive letter H maps to disk 1 on node 1 which is lun 33. We run the same dump on node 2 (below) 'powermt display dev=all' and find that lun 33 which has already been formatted and assigned a vol label via node 1 is enumerated as disk 2 on node 2. We assign drive letter H in node 2's disk mgr, exit disk mgr, and open it again and find the volume lable (EVS1-SG1) is already formatted as expect as denoted by the parantheses. This is expected since the lun is shared across Clariion storage groups. [SYMPTOM] However, when assigning the next drive letter (I) to the lun 38 which transaltes to disk 3 on node 2, the volume label automatically populated turns out to be the volume label for lun 40 (EVS1-SG3). This is not expected since the lun to disk mappings on node 2 (below) clearly show lun 38 mapping to disk 3 on node 2. Host Clariion Host Power Host 2 Host 2 Host 2 Name HLU ID Path Dump Disk Mgr Drive Letter Vol Label Description ===================================================================================== ============ node2 lun 33 -------> lun 33 disk 2 H (EVS1-SG1) as expected node2 lun 38 -------> lun 38 disk 3 I (EVS1-SG3) not expected node2 lun 40 -------> lun 40 disk 4 J (no label ?) [ADDITIONAL COMMENTS] We've presented x12 200mb luns to node 1 used as junction drives for mounting volumes to mitigate the drive letter constraint encountered in a 4 node, active/active/active/passive exchange cluster. We assigned drive letters, formatted, and assigned vol labels to these junction drives. We then created 5 vol mount points in each of the junction drives from which we created volume mount points to the striped meta luns we created for the exchange mailbox stores. Note, per the above simplified example, the vol mount points also immediately show up for junction drive H on node 2 implying the meta data written by node 1 initially was picked up and interpretted correctly on node 2. However, again, node 2 fails to read the correct vol label for junction drive I mapping to the correct lun (38) and instead picks up lun 40's vol label when disk 3 is assigned drive letter I. Instead, node 2 picks up lun 40's vol label and vol mount points which contradicts node 2's disk-to-lun mappings!

mpi2 · Answer

Do you share the LUNs through one storage group or do you have several storage groups for every clusternode and added the shared luns in each of them?

mpi2 · Answer

okay, now i see you have three different Storagegroups.
Is there a special need for three storagegroups?/why don't you use one storage group to share the luns with alle clusternodes?
Please check the Host LUN IDs from the Storage groups they should be equal.
If you use one Storagegroup for the shared luns you don't have to care about equal host lun ids because of the Storagegroup itself.

best regards
Manfred

ajw2 · Answer

The problem was someone accidentally powered on another server thereby corrupting the meta data on the disks written by the hosts and the junction drives. We had to used diskpart to to a clean to all disks start from scratch and make sure no two host were up at the same time and everything seems to be working normally now.

As far as being in the same storage group we did not do that because of boot from san and they did not have a separate HBA to boot from SAN as each host only had two HBA's. So if we had a third HBA we could registered that in a different storage group for boot from SAN, but that was not done. Otherwise I don't see any other way to do that without sharing the boot luns, because you can only have one host per storage group, unless something that is something that can be overridden in engineering mode or something.

CLARiiON

Was this post helpful?