1826779
Members
1475
Online
109702
Solutions
SOLVED
David,
And where exactly did you read that the Clariion CX700 is actually supported with 11iv3?
Personally that would have been the first thing I wanted to check prior to using a brand new OS like 11iv3...
For your information, HP don't and never will offer support for Clariion disk arrays - thats EMC's problem - you'd get the same response from IBM, Sun or any other OS/Server vendor on that. What HP do carry out (or allow a third party to carry out) is 'independent interoperability validation', which means they work with EMC to 'qualify' their storage with HPUX and HP9000/Integrity. You can see the support matrix for that here:
http://www.hp.com/products1/serverconnectivity/mass_storage_devices.html#EMC
Note that 11iv3 is not mentioned.
Now EMC also carry out their own Interoperability tests and publish these on their customer support website (powerlink.emc.com) - I can't post a link to these here (you need a login), but I can tell you that this also doesn't mention support for 11iv3 with Clariion (it does for Symmetrix/DMX though).
So if neither the OS vendor nor the Array vendor list this as supported its not really a surprise that there are problems.
Now on to *why* there are problems:
The EMC Clariion is one of the few arrays on the market that still operates in an 'active passive' configuration - that is for any given LUN, IOs are only accepted on one controller (the EVA used to work like that as well about 3 years ago). What happens when an IO is sent to the non-owning controller (this event is called a trespass) depends on how a certain parameter is set on the Clariion (IIRC its called 'failover mode').
Now I expect that you have your failover mode set such that every time a trespass occurs, the owning controller for a LUN is changed - this operation is *slow* and if you are doing load balancing (which 11iv3 will do by default) almost every IO is going to cause a trespass.
Now you *might* be able to reolve this somewhat by playing with the load balancing options in the new storage stack (if you set load balancing to preferred path and then set the preferred path to the owning controller using the scsimgr command then at least *most* of the IOs would go to the owning controller, but anything that probes the other path is still going to cause a path failover and slow things down) - or I think theres an option to disable the new load balancing algorithms on the legacy DSFs (thats the cXtYdZ DSFs) - you could do that and then just use LVM PVLinks which were ceratinly supported in 11iv1/11iv2 - but that doesn't alter the fact that you are running an unsupported configuration...
I expect EMC are working on a plug-in or a version of PowerPath for 11iv3 which will resolve this, so maybe you can persuade them to give you a beta, otherwise I guess you need to go back to 11iv2 or use another storage array.
HTH
Duncan
I am an HPE Employee
And where exactly did you read that the Clariion CX700 is actually supported with 11iv3?
Personally that would have been the first thing I wanted to check prior to using a brand new OS like 11iv3...
For your information, HP don't and never will offer support for Clariion disk arrays - thats EMC's problem - you'd get the same response from IBM, Sun or any other OS/Server vendor on that. What HP do carry out (or allow a third party to carry out) is 'independent interoperability validation', which means they work with EMC to 'qualify' their storage with HPUX and HP9000/Integrity. You can see the support matrix for that here:
http://www.hp.com/products1/serverconnectivity/mass_storage_devices.html#EMC
Note that 11iv3 is not mentioned.
Now EMC also carry out their own Interoperability tests and publish these on their customer support website (powerlink.emc.com) - I can't post a link to these here (you need a login), but I can tell you that this also doesn't mention support for 11iv3 with Clariion (it does for Symmetrix/DMX though).
So if neither the OS vendor nor the Array vendor list this as supported its not really a surprise that there are problems.
Now on to *why* there are problems:
The EMC Clariion is one of the few arrays on the market that still operates in an 'active passive' configuration - that is for any given LUN, IOs are only accepted on one controller (the EVA used to work like that as well about 3 years ago). What happens when an IO is sent to the non-owning controller (this event is called a trespass) depends on how a certain parameter is set on the Clariion (IIRC its called 'failover mode').
Now I expect that you have your failover mode set such that every time a trespass occurs, the owning controller for a LUN is changed - this operation is *slow* and if you are doing load balancing (which 11iv3 will do by default) almost every IO is going to cause a trespass.
Now you *might* be able to reolve this somewhat by playing with the load balancing options in the new storage stack (if you set load balancing to preferred path and then set the preferred path to the owning controller using the scsimgr command then at least *most* of the IOs would go to the owning controller, but anything that probes the other path is still going to cause a path failover and slow things down) - or I think theres an option to disable the new load balancing algorithms on the legacy DSFs (thats the cXtYdZ DSFs) - you could do that and then just use LVM PVLinks which were ceratinly supported in 11iv1/11iv2 - but that doesn't alter the fact that you are running an unsupported configuration...
I expect EMC are working on a plug-in or a version of PowerPath for 11iv3 which will resolve this, so maybe you can persuade them to give you a beta, otherwise I guess you need to go back to 11iv2 or use another storage array.
HTH
Duncan
I am an HPE Employee
Nelson,
>> The only pain now is to go through each of the hundreds or so Hitachi 9500V LUN on my 11.31 Server
Ahh now you'll get a chance to see the real "beauty" of the new IO stack to make at least part of this simpler for you
What you need to do is setup a new attribute scope with scsimgr which identifies only LUNs on the HDS9500V:
Identify a suitable DDR name using scsimgr ddr_name against one of the HDS LUNs (any will do) You'll have to decide whether you do this down to just the actual array level, or down to the array and firmware level (I'd suggest just to the array level myself), but anyway compare what you get from
scsimgr ddr_name -D /dev/rdisk/diskNN vid
and
scsimgr ddr_name -D /dev/rdisk/diskNN rev
You should get something like "/escsi/esdisk/0x0/HITACHI /DF600-V /0123"
or something like that (I don't have a HDS box to test against)
Then use one of those to define the scope:
scsimgr ddr_add -N "/escsi/esdisk/0x0/HITACHI /DF600-V /0123"
Now you have a scope which will effect all objects of that type (including new ones when they're added), and you can set attributes across that scope as in:
scsimgr save_attr -N "/escsi/esdisk/0x0/HITACHI /DF600-V /0123" -a load_bal_policy="preferred_path"
However as for setting the preferred path - well do you have an easy way of detrmining programatically which lunpath should be the preferred path (is it something really simple on the HDS array like each odd lun is on one controller an each even lun is on the other???) But all I can think here is that you're going to have to script it in some way (surely doing it by hand isn't an option??)
HTH
Duncan
I am an HPE Employee
>> The only pain now is to go through each of the hundreds or so Hitachi 9500V LUN on my 11.31 Server
Ahh now you'll get a chance to see the real "beauty" of the new IO stack to make at least part of this simpler for you
What you need to do is setup a new attribute scope with scsimgr which identifies only LUNs on the HDS9500V:
Identify a suitable DDR name using scsimgr ddr_name against one of the HDS LUNs (any will do) You'll have to decide whether you do this down to just the actual array level, or down to the array and firmware level (I'd suggest just to the array level myself), but anyway compare what you get from
scsimgr ddr_name -D /dev/rdisk/diskNN vid
and
scsimgr ddr_name -D /dev/rdisk/diskNN rev
You should get something like "/escsi/esdisk/0x0/HITACHI /DF600-V /0123"
or something like that (I don't have a HDS box to test against)
Then use one of those to define the scope:
scsimgr ddr_add -N "/escsi/esdisk/0x0/HITACHI /DF600-V /0123"
Now you have a scope which will effect all objects of that type (including new ones when they're added), and you can set attributes across that scope as in:
scsimgr save_attr -N "/escsi/esdisk/0x0/HITACHI /DF600-V /0123" -a load_bal_policy="preferred_path"
However as for setting the preferred path - well do you have an easy way of detrmining programatically which lunpath should be the preferred path (is it something really simple on the HDS array like each odd lun is on one controller an each even lun is on the other???) But all I can think here is that you're going to have to script it in some way (surely doing it by hand isn't an option??)
HTH
Duncan
I am an HPE Employee
>> Thanks for your input man but our 11.31 server hosts 4 9500V arrays. And I did ddr_name vid and rev on a disk from each HDS array but there does not seem to be a distinguishing differentiator to identify which is HDS1 2 3 or 4.
Why would you want to differentiate between the 4 arrays with respect to scsimgr commands? Are you saying they're at different firmware revs and the ddr_name command isn't picking that up?
Interestingly note that the 9500s aren't listed as supported with 11iv3 on HP's interoperability matrix:
http://www.hp.com/products1/serverconnectivity/mass_storage_devices.html#Hitachi_ds
Do HDS qualify them as supported
HTH
Duncan
PS Why the name change??
I am an HPE Employee
Why would you want to differentiate between the 4 arrays with respect to scsimgr commands? Are you saying they're at different firmware revs and the ddr_name command isn't picking that up?
Interestingly note that the 9500s aren't listed as supported with 11iv3 on HP's interoperability matrix:
http://www.hp.com/products1/serverconnectivity/mass_storage_devices.html#Hitachi_ds
Do HDS qualify them as supported
HTH
Duncan
PS Why the name change??
I am an HPE Employee