Unsolved
This post is more than 5 years old
42 Posts
3
6696
February 9th, 2015 09:00
Is ‘HLU Conflict’ Corrective Action Needed?
I am working with an assigned EMC Support team member to prepare for a VNX7500 EO code upgrade. From a complete environment analysis by EMC, I am being told that the array has multiple HLU conflicts, and while they will have no impact on the success of the code upgrade, he is pretty insistent that these conflicts should be corrected ASAP. I was referred to KB Article to correct the problem: http://support.emc.com/kb/41822.
Below are a two examples of the sixteen reported HLU conflicts. Three of the conflicts are of three LUNs in four storage groups which supports the same clustered environment HyperV_cl(1-4). The other thirteen HLU conflicts are of individual LUNs in individual storage groups for hosts, as well as all of those same LUNs in another single storage group for RecoverPoint replication. (Sorry if that was not completely clear)
ALU HLU Storage Group
----- ----- -----------------
197 2 HyperV_cl1
197 3 HyperV_cl2
197 2 HyperV_cl3
197 2 HyperV_cl4
128 6 SQL_Server_A
128 21 RecoverPoint_0
I had to do some research to figure out what this problem actually is. As I understand it, the HLU ID is supposed to be the same in each host that has access to the same shared LUN. So for example, that one “3” HLU ID in the UCSHVCLUS0(1-4) cluster for ALU 197 should actually be a “2”, as are the others. And for ALU 128, the HLU ID of RecoverPoint_0 should match the HLU ID of SQL_Server_A.
I am questioning this insistence that I need to correct these HLU conflicts for the following reasons:
- As the new Storage Administrator, I inherited this array and its configuration as it has been for the last three years. The system administrators of these hosted environments have reported no storage related issues in that time, and the RecoverPoint replications appear to be configured and working as expected.
- The provided KB article refers to VMware VMs clustered with physical servers. As a complete Windows shop, we use MS HyperV virtual hosting, and have no VM/physical mixed cluster environments.
While I suspect this HLU Conflict is not the critical issue that is implied for my environments, I would like a second opinion please.
If this is of no concern, I will take no further actions. However, if corrective action is required, please explain the impact of this problem.
In addition, this particular VNX array is scheduled for replacement in late summer (expecting a VNX2 series). If this HLU conflict is a problem that should be addressed, can I put it off until the migration to the new array?
Thank you,
Bryan
bryan_washburn
42 Posts
0
February 17th, 2015 20:00
Wow, no takers on this?
Is the issue not clear, or have I really stumped the community?
Let me know if more info is needed.
Bryan
kelleg
6 Operator
•
4.5K Posts
2
February 18th, 2015 08:00
When you setup a Cluster - say two nodes. You have two methods to configure this on the array. You can put both hosts into the same Storage Group or you can put each Host into a separate Storage Group and assign the same LUNs to each Storage Group.
When a host in a Storage Group is assigned the first LUN, say array LUN number 10, the Storage Group assigns that LUN 10 as Host LUN number 0 (you can manually change this is you want). The host then sees that HLU 0 as the first device from the array and will assign it a harddisk number from the operating system - say device 004. You then take that new device and in Windows initialize it and assign it a device - say E:. When your host reboots it scans the PCI bus for devices and finds the HBA and then scans that HBA for devices and finds that first HLU 0 device and the OS knows that's the E: drive.
Now you add more disks to the Storage Group and each gets assigned the next HLU number in ascending order and you assign those on the OS as specific devices F:, G:, etc. When you reboot the host, the scan on the HBA finds the array devices, but not always in the same order - it might find the first LUN, then the third LUN, then the second LUN. But the HLU 0 is the same so the OS knows that each device is linked to a specific OS device, i.e., E:, G:, F:, so there is no confusion as to which HLU is assigned to which OS device.
When you add the second host to that Storage Group, it should see the same array LUNs and since the HLUs are already assigned, it should assign the same HLU's to the second host the same as the first host. This the way that EMC recommends that you configure the HLU's - each host that shares the same array LUN should have the same HLU as the other hosts.
In the past, we have seen issues on some operating systems (ESX) where different hosts share access to the same LUNs, but the HLU's were different and that caused issues. Generally we saw issues when all the hosts were in the same Storage Group but some hosts had different HLU's for the same array LUN. For some reason, when the HLU's did not match, there were connection issues between the hosts. This is why we recommend that hosts assigned the same array LUN also use the same HLU number. This is what we consider best practice.
I understand that your configuration has been the way it is now for some time and you've not seen issues, but that does not mean that you will never experience issues and that is why we recommend that the HLU's should be the same - to eliminate that as a possible cause of host connection issues, if you ever have problems with hosts disconnecting or losing paths.
glen
bryan_washburn
42 Posts
0
February 19th, 2015 09:00
Thank you very much for this information, Glen.
Very helpful.
Bryan
StorageAdmins1
2 Posts
0
May 19th, 2015 11:00
We have the same issue with VMAX array never had the HLU conflict before
let me try remove the LUN and add it back
kelleg
6 Operator
•
4.5K Posts
0
May 27th, 2015 14:00
May experience has been that a single storage group (all hosts and LUNs in the same SG) is where you see the most problems. But I have heard from others that this also affects configurations with multiple storage groups sharing the same LUNs.
glen
kelleg
6 Operator
•
4.5K Posts
0
May 28th, 2015 14:00
I've seen random host disconnects, hosts not coming up after a reboot - general host connection issues. But there are a lot of other things that can cause the same symptoms so it may not always be clear what the real issue is.
glen
Alty-CG
2 Posts
0
October 3rd, 2015 11:00
I have a similar situation where I need to make HLU unique for few of the LUNs shared between two storage groups where second SG happened to be for RecoverPoint replication. I believe the safer option is to change HLU for the LUN assigned to RP Storage group. Can somebody please tell me the impact of doing this ?
brettesinclair
2 Intern
•
715 Posts
0
October 3rd, 2015 17:00
The simplest way is to disable the affected Consistency Group, make your changes, Verify the CG and if ok, re-enable it.
I would then expect a full-sweep to occur.
Alty-CG
2 Posts
0
October 4th, 2015 05:00
Thanks Brett...that was useful. I just had a look at my storage group for RecoverPoint and realized that I'll have to remove all the LUNs (including journal) as HLU's assigned to LUNs in other SG are already in use here. what i want to know here is, having these LUNs assigned to a 2nd SG for RP replication will have the same risk of host disconnects which we'll probably have in a situation a LUN is assigned to multiple SG for a cluster ??
The reason for me asking this question is to understand whether it is really required to correct LUNs HLU's for our configuration.
kelleg
6 Operator
•
4.5K Posts
0
October 8th, 2015 13:00
Generally speaking, when the devices are for RP or other backup applications, you can ignore the HLU/ALU matching that you should do for hosts.
glen