[Linux-PowerEdge] MD3000 preferred path not working

Jens_Heinz at Dell.com Jens_Heinz at Dell.com
Thu Jul 18 06:17:29 CDT 2013


That is one of the changes. DM multipath with rdac handler is officially supported for those systems. 
Another thing is access to the virtual disks. Latest major firmware introduces ALUA. Which enables the MD array to access a virtual disk over the non-preferred path w/o changing ownership. The IO will be forwarded internally. 

Jens

-----Original Message-----
From: G.Bakalarski at icm.edu.pl [mailto:G.Bakalarski at icm.edu.pl] 
Sent: 18 July 2013 13:11
To: Heinz, Jens
Cc: nick.lunt at patech-solutions.com; steve.wilkes at patech-solutions.com; linux-poweredge-Lists
Subject: RE: [Linux-PowerEdge] MD3000 preferred path not working

> I just realized the link points to my own article,

;-) :-O

> that's why I wanted to add
> one thing.
> Everything in the article is still true & valid in regards of MD3000, 
> but for our MD32xx or MD36xx systems situation changed dramatically.
>
I didn't know that. I use MD3620F and multipathing with rdac works fine ...
Especially with newer multipath-tools (0.4.9 + )

GB

> -----Original Message-----
> From: linux-poweredge-bounces-Lists On Behalf Of 
> G.Bakalarski at icm.edu.pl
> Sent: 18 July 2013 12:47
> To: Nick Lunt
> Cc: Steve Wilkes; linux-poweredge-Lists
> Subject: Re: [Linux-PowerEdge] MD3000 preferred path not working
>
> Hi
>
> BTW. what is your server setup? Windows/Linux/Xenserver/VMWare???
>
> This may also mean that your server uses wrong path ...
>
> Have you read this thread:
>
> http://permalink.gmane.org/gmane.linux.hardware.dell.poweredge/40180
>
> ?
>
> Maybe sas cabling is not as expected ? Or SAS HBAs not working ?
>
> G
>>
>> No, not 1000000% sure the array hardware is OK, but MDSM (and Dell) 
>> say it is.
>>
>> 2 x SAS 5/E dual port cards.
>>
>> Md3000 + 3 MD1000's attached.
>>
>> Both SAS cards have firmware 00.10.51.00.06.12.05.00
>>
>> The whole lot has been bounced many times over the past week.
>>
>> I can't imagine how a disk replacement can lead to all this either, 
>> it's a complete mess.
>>
>> Nick .
>>
>>
>> [image: Nick Lunt | Applications DBA Patech Solutions Limited Tame 
>> House, Wellington Crescent, Fradley Park, Lichfield, WS13 8RZ T::
>> +44(0)1543 444
>> 707 | M:: +44(0)7554 003 634 E:: Nick.Lunt at Patech-Solutions.com W::
>> http://www.patech-solutions.com]
>>
>>
>> On 18 July 2013 10:59, <G.Bakalarski at icm.edu.pl> wrote:
>>
>>> Hi
>>>
>>> Are you 10000000% sure all diskarray hardware is OK ???
>>>
>>> And what SAS cards - server HBA or diskarray controllers ???
>>>
>>> Is it single box diskarray or you have expansion enclosures???
>>>
>>> Single/dual controller ???? (if there are expansions: single/dual 
>>> pathed
>>> expansions????)
>>>
>>> If dual controller (in case you replaced any) : are controllers'
>>> firmwares identical?
>>>
>>> Did you power off/on all componets ?
>>>
>>> I can't imagine how regular disk exchange can make such disaster 
>>> nowadays :(
>>>
>>> G.
>>>
>>> >
>>> > we had a disk fail in an MD3000 last week which was replaced under 
>>> > warranty. However, during the replacement of the disk something 
>>> > happened and we ended up getting 2 new SAS cards, MD3000 
>>> > controllers and a new backplane for the MD3000. This took a week 
>>> > to fix
>>> costing us thousands.
>>> >
>>> > Now were just about back online, but we are getting these errors 
>>> > from the
>>> > MD3000:
>>> >
>>> > Summary
>>> > Node ID: WFSC_NON_PROD_SAS
>>> > Host IP Address: 10.69.0.21
>>> > Host ID: fintestdb.wales.nhs.uk
>>> > Event Error Code: 4011
>>> > Event occurred: Jul 18, 2013 9:51:43 AM Event Message: Virtual 
>>> > Disk not on preferred path due to AVT/RDAC
>>> failover
>>> > Component type: RAID Controller Module Component location: RAID 
>>> > Controller Module in slot 0 Priority:Critical
>>> >
>>> > The only way we seem to be able to stop getting these error 
>>> > messages is
>>> to
>>> > set the preferred path to path 0 for all luns.
>>> >
>>> > Now, we have the exact same setup on another server, but using the
>>> correct
>>> > preferred paths and we are having none of these issues. Both these
>>> servers
>>> > have the same OS and MD3000 setup.
>>> >
>>> > Could anyone please shed some light on why the server that's just 
>>> > been 'fixed' is generating these errors unless we assign all luns 
>>> > to path
>>> 0?
>>> >
>>> > Thanks
>>> > Nick .
>>> > _______________________________________________
>>> > Linux-PowerEdge mailing list
>>> > Linux-PowerEdge at dell.com
>>> > https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>> >
>>>
>>>
>>>
>>
>
>
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>




More information about the Linux-PowerEdge mailing list