For way more years than I want to accept, most operating systems were clueless about Fibre Channel networks. Totally clueless.
Of course I am kinda talking ancient history… plus my expectations of now distant operating systems like Windows NT were not that high. But I was still shocked the first time I presented a SAN LUN that had 4 paths…. and Windows NT declared it had found four disks rather than one (and then tried to write a signature on all of them!). Sadly AIX was not much better (this was around the time of AIX 4.2/4.3). These Operating Systems insisted on seeing each path as a different LUN…. which was a bit clueless. It became rapidly apparent that two things were going on:
- Whatever SCSI standards existed to ensure uniform behaviour between hardware and software vendors, were not being embraced.
- Vendor unique multi-pathing solutions to manage these paths became routine practice.
For IBM this meant creating a piece of software called Data Path Optimiser or DPO. IBM toyed with the idea of charging for it, but rapidly realised that doing so made no sense, so they renamed it Subsystem Device Driver (SDD) and made it available free of charge. Other vendors came out with their own versions for their own hardware (think EMC PowerPath or Hitachi HDLM) while Veritas brought out a multi-vendor capable package called DMP (which made much more sense, but cost money and so did not have the success it deserved).
So the real requirement for the market was two fold:
- Operating system vendors needed to embrace multi-pathing as a native feature of the their products.
- Hardware vendors needed to embrace SCSI standard compliant ways of indicating how multiple paths should be presented and used by those operating systems.
Fortunately in both cases, some common sense began to emerge from the fog. Operating system vendors added native MPIO capability. Microsoft started getting serious in Windows 2003 (with MPIO) and much more so in Windows 2008. IBM started with a fix level in AIX 5.2 (which added MPIO), SUN kicked in with MPxIO. Linux added DMP, which was a great step as it saved IBM from having to recompile it’s closed-source SDD package every time a new Linux kernel came out.
From the hardware side SCSI3 standards came up with ALUA (Asynchronous Logical Unit Access). In simple terms ALUA allows a strorage device to indicate to an operating system which paths are preferred, on both a port by port basis and a volume by volume basis. This is really important for storage products that are active/passive, either for a whole controller or on a volume by volume basis (e.g. indicating that Volume 1 should ideally only be accessed using ports on Controller A while Volume 2 should ideally only be accessed using ports on Controller B).
So the story gets better as time goes on. Hardware vendors for the most part have got on board with ALUA but there are some hold-outs. This is why I was really pleased to see that the DS3500 and DCS3700 from IBM will now support ALUA (after a firmware update to version 07.83 or later, which should be available June 15, 2012). The announcement letter is here. This is a great step forward. In case you’re wondering, IBMs DS8000, XIV, Storwize V7000 and SVC all support ALUA.
But sadly while this improvement is a good positive step forward for IBM, there are still some simple problems in the industry that need to be fixed. First and foremost: Vendors need to stop producing their own multi-pathing software and either stick to just plugins to Operating System software (such as DSMs for Windows or PCMs for AIX, maybe with some handy utilities to list path status) or preferably work with native MPIO “out of the box”. This means for instance switching from SDD to SDDDSM (Windows) or SDD to SDDPCM (AIX). Ideally even these plugins should become redundant.
If a vendors hardware is dependant on heavy host path software being installed, then they should change their hardware (which is not so simple with legacy designs). Having to install non-plugin Vendor supplied MPIO software creates potential interoperability issues that can prevent clients from making purchases from multiple vendors. It blocks efficiency, it makes migrations harder and it creates uncertainty. Insisting that you will only support a client if they install your multi-pathing software, but then refusing to support the installation of another vendors software, is equally unhelpful.
If I give a gold star out to any operating system vendor, it’s VMware. Their ability to attach to storage from multiple vendors is simply fantastic. Migration with VMotion is a breeze and I have happily moved clients between all sorts of storage platforms all attached to the same ESXi Server. Nice! Though I remain confused that EMC describe PowerPath/VE as superior to the native capabilities of VMware. If this is more than just because EMC kit needs special handling, then VMware customers everywhere should be up in arms that the parent company is withholding technology from their hypervisor (unless of course they expect VMware customers to be only using EMC kit!).
So supporting ALUA is a critical step towards a more open world where multipathing just works ‘out-of-the-box’.
Want to read more about ALUA and MPIO? Check out these very useful articles: