MPIO & Disk Signatures

[Michael Schwab_1]

Does anyone know if HP MPIO Full Featured Failover v1.00.01 (or any version for that matter) changes disk signatures?

If I had the resources I know it could easily be verified via the dumpcfg output (before and after MPIO installation); however, I do not have access to these resources at this time.

Any help would be greatly appreciated.

Mike

[Uwe Zessin · Accepted solution]

No, I don't think so. It is a filter that sits on top of the Fibre Channel driver and below the file system. It's job is to present a single device to the file system, but not change the contents of the disk.

[Steven Clementi]

Your questions begs me to ask...

Why would you care about signatures before you install MPIO? MPIO should be installed before you attach the server to your storage.

Now, I can see if you started out with a single path to your storage where you would not need MPIO and then upgraded to multipath and needed to install MPIO.

Just wondering.


As Uwe states, the signature is physically on the disk. MPIO shouldn't re-write it, it only manages the different paths to the disk.


Steven

[Michael Schwab_1]

Ok, I can be long winded so I'll apologize upfront for the long reply, but since you asked.....

I'm running a large EVA SAN implementation/data migration for the Army National Guard (55 site locations). They have existing EMC storage presented to their Windows & Unix servers (separate fabrics than we are working with for the new EVA6000 array). We are installing a new array and new redundant fabrics, etc.. When I was doing the design/implementation docs I was told there were no Windows clusters. Well of course there are which is why I didnâ t research any of this prior to the deployments.

What we are doing is since most servers have EMC's multipath software installed (PowerPath), I came up with the approach of not loading our multipath software until we migrate data, validate and bring the new EVA presented volumes into production. This compatibility (PowerPath & MPIO on the same box) has not been tested and I did not have the resources to test this prior to our deployments. Obviously I cannot take "any" risk of harming production data. So based on that we are only zoning out one host port from the EVA6000 for the duration of the data migration with the TDMF utility (host based block level replication software). Upon completion we are removing the EMC HBA cards, uninstalling the EMC multipath utility, installing MPIO (or Secure Path 3.0F for HP-UX - actually autopath gets installed in this case w/active-active controllers) and finally opening up the zoning to allow the host to see all host ports on the EVA6000.

Of course when you are dealing with Windows clusters, the disk signature becomes critical. So far on the two Windows clusters we have migrated up to this point, the site did not have the EMC PowerPath utility loaded. So we installed MPIO from the start. I have not yet had the resources to test what will happen if we have to load MPIO after the migration. I did see a Windows article (293778) that talks about the possibility of some multipathing software (if configured incorrectly) can cause problems. Now this article is specific to W2K and we are working primarily with W2K3 cluster nodes, but I'm just trying to ensure we are prepared for any potential problems.

Now I do have a work around in place in the event that we do have to load MPIO after the migration if PowerPath is present from the start. Of course that work-around is a precautionary measure in case the signatures change (involves the use of the dumpcfg utility). I was just trying to see if anyone new for sure if the signature would be changed.

Thanks for the input.

Mike

[Uwe Zessin]

OK, clustering is another reason that a multipath software MUST NOT alter signatures:

imagine what happens when a disk fails over to another cluster member and the signature gets changed?!


I guess the problem of 'incorrectly configured mp software' you are mentioning is that the filter driver simply does not work so that Windows configures a different device for each path. In that case Windows is known to act strange and rewrite signatures. I beleive Steven can tell a few stories ... ;-) or better: :-(

[Michael Schwab_1]

Yea, that would be ugly. Dumpcfg would be the savior there... I guess the key there is knowing what the original signature was. I would assume a good backup of the system state would be your next best friend. Pull the original disk signature from a backup copy of the cluster configuration registry key.

Regarding the multipath software, I don't see much room for configuration problems with the standard installation of the MPIO software. We should be ok there.

Well, thanks again for the input.

Mike

[Steven Clementi]

Windows? act strange? are you kidding me? That could never happen!!!!!


Mike:

There is a nifty utility called the Cluster Recovery Utility that effectively does the came thing as dumpcfg except that it gives you a gui to do it in. It allows you to tell the cluster that you have "recovered" some disks and that they should take on the properties of the old disks.

I may be in a situation where I can test the MPIO install AFTER the fact come tomorrow. I will let you know if so.



Steven

[Michael Schwab_1]

Steven,

Actually we are using the "clusterrecovery.exe" utility to bring the new resources into production.

Basically we are performing the following steps:

1. Failing all resources to one node (making a few config changes to keep them from failing back to the other node)
2. loading the block level copy utility on that node (outside of the cluster software)
3. presenting the target EVA disk(s) and leaving it out of the cluster at this time
4. migrating data (source EMC disk to target EVA disk)
5. upon source and target being synced, bring applications down (if applicable) and bring resource offline
6. run validation scripts to compare source to target
7. add the new target disk to the cluster as a resource
8. run clusterrecovery to point to the new target resource
9. swap drive letters

That's pretty much it... That works fine even though the drive letter swap can be a pain as it doesn't always stick the first time.

If you could test to ensure that MPIO doesn't change the signature that would be great!!! I would imagine you would want to zone out one host port from the array, present a disk, run dumpcfg and capture output, load MPIO, shut down the server, make appropriate zone changes so the host will see all paths, power up the server and run dumpcfg again to see if the signature changed.

My thought is that it won't change, but it would be great to know for sure.

Thanks,

Mike

[Steven Clementi]

Quick test results attached...


Looks like the signature stays the same...




Steven

[Michael Schwab_1]

Steven,

Great, thanks!!!

I really appreciate you taking the time to run that test for me and attaching the resulting output!

It's always beneficial to know for "sure" what's going on under the hood.

Take care,

Mike