Using MCServiceguard in IBM ESS (shark)

[Mike Patterson]

I know that IBM supports this configuration, while HP technically does not. However, HP support admitted to me that if LVM is stable, then the packages that live on the VGs should be happy regardless of where the PVs are located. I also understand that one should build the packages on VGs using PV links instead of using the vpaths created by the IBM SDD software.

Questions:
1. Does this mean SDD should not be installed, or install it and ignore the vpaths?
2. Does anyone have a success story to share regarding MCServiceguard and ESS storage?

We don't have the budget to have both an IBM and HP enterpise SAN so I've got a real incentive to make this work.
Thanks in advance.

[Sridhar Bhaskarla]

Hi Mike,

I believe HP support rather than one or two HP support engineers. As long as you can be able to satisfy the requirements (availability, shareability etc.,) for ServiceGuard, you should be able to configure it. However, when you get into any issues, HP's ability will only be limited to it's components and HP will not be able to determine the issues with the storage. I haven't seen any document out there that says HP supports only certain types of storage systems.

I haven't worked with SDD software. But I do have powerpath which I believe is similar to SDD. I configure all the PV links in /etc/lvmtab irrespective of Powerpath. I have created serviceguard clusters on even junk storage and had them running successfully for many years.

As long as your LVM configuration is good, you are good as serviceguard only looks at it. It doesn't matter on which disks the PVs were created.

-Sri

[Steven E. Protter]

HP doesn't officially "support" our current Xiotech disk array. Yet it can be configured for multiple World Wide Names to have "ownership" of LUN's and should present no problems with ServiceGuard.

If there is a problem that appers to be coming from the disk array, HP's ability to help will be limited. Most SG problems come from bad SG configuration or incorrect LVM configuration though.

If LVM can recognize the disk, add it to a volume group and set up filesystems, then using SG should not present a challenge.

SEP

[Mike Patterson]

Steven and Sri - thanks for the encouragement.
However, I'm hoping to find someone who has direct experience with MCServiceguard in the ESS and whether or not to install the SDD software.
- Mike

[John Poff · Accepted solution]

Hi Mike,

We have an IBM Shark and we have used it successfully in an MC/SG cluster. Your SDD software will not work with MC/SG. We tried it. It will work fine using the vpaths with a standalone system, but the LVM part of MC/SG does not like the vpaths and will not work with it.

Other than that, the Shark worked fine in our cluster. IBM will support their end and HP will support their end, but if you have a problem you could get caught in the middle. We never ran into a serious problem and so the support was never an issue for us, but it is something to keep in mind. For what it is worth, we are running on an XP1024 now.

Good luck!

JP

[Mike Patterson]

John -

Yes, we also have an HP9000 running standalone attached to the ESS using SDD and vpaths just fine, as you confirmed.

Re: SG on ESS, I also agree with the previous posts that most SG problems will likely manifest above the hardware disk level. I know that I can't use the SDD vpaths with SG, as you confirm. So, I'm interpreting your post to mean "don't even bother installing SDD."

I certainly understand that finger-pointing can occur between vendors anytime we employ a "mixed" vendor solution. SAN is the poster-child for this syndrome. In our case, we run an ESS800 with dual Cisco MDS9509 switches, and clients ranging from WinNT, XP, Novell, HP-UX, AIX, etc.

Thanks. - Mike

[Gord Moore]

We have an IBM Shark and run MC/ServiceGuard using PVLinks on on rp8400s. The SDD software did not play nice with ServiceGuard. I believe the latest version of SDD may have corrected the problem. That being said we aren't jumping on it right away.

Gord

[Mike Patterson]

Thanks for the help.