Multipathing. How did we get here?

I saw statistics from one of the computer marketing groups (Gartner, I think) showing that 90% of mid-range servers go into data-centers that use networked storage. Although not mentioned in the report, I bet the vast majority of those servers have high-availability requirements that demand that all storage components be redundant including array controllers, switches, cabling, and host adapters, and that failover happens automatically.

Given this fact, selling a server and OS without multipathing in the storage stack seems like selling cars without drive shafts. Administrators have been buying new servers, THEN they have to buy the missing multipath part from a third party, install it themselves, and since these drivers weren't originally designed as part of the operating system's I/O framework, they don't integrate as well with the OS as they should.

The industry got here because of the way the technology evolved. It was the array vendors who originally invented dual controllers with failover. Some early redundant controllers used ID aliasing for failover. Say controller 1 appeared on SCSI target ID 1, controller 2 at ID 2. If controller 1 died, controller 2 detected that its alternate was no longer there, and began responding to requests for both SCSI IDs 1 and 2. The problem with this approach was that the interconnect and the HBA were still single points of failure so they started developing add-on drivers for each OS they supported. So, administrators got used to buying and installing these drivers and that's the way the industry worked for several years.

Since then, the OS vendors and the standards bodies have finally caught up. The ANSI T10 SCSI committee now has a standard for asymmetric controller failover. Solaris 10 has the concept of virtualized paths built natively into the device tree and it knows how to do path virtualization, as well as controller failover for most common storage arrays. This is available as a patch for S8 and 9 as well.

On the storage side at Sun, we are moving to use the native multipathing in every OS as well. Most Sun arrays work with the native 'md' driver in Linux. See a paper on how to configure it HERE

Windows is adding a native multipathing framework called MPIO and we are working with Microsoft to support Sun storage. (in the meantime, we have a traditional add-on multipath driver available – yes, we know how to write Windows drivers). HP is now bundling the Veritas VM with DMP into HP-UX as their multipath solution so we are negotiating with Veritas to make sure that 'native' solution supports our arrays.

So, stop buying third-party drive shafts and use an OS that has everything needed to start working with your storage.

Comments:

One thing that I've been wanting to ask about for a while with this is active/active versus active passive arrays -- all the mpxio documentation I've found seems to indicate it's either one or the other for ALL attached devices -- so it suggests that if you say had a 9900 (A/A) and an EMC clariion array (A/P) on your san that you wanted to use on a box, you'd end up having to go A/P for both, unlike VxDMP (which appears to be able to track A/A vs. A/P on a per device/array basis). Is this wrong, or if not, are there any plans to correct that?

Posted by Jason on April 11, 2005 at 11:04 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

kgibson

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today