Boot disks in SAN

[Uwe Zessin]

Nelson,
the update of Secure Path V3.0D is back:
http://h18000.www1.hp.com/products/sanworks/softwaredrivers/securepath/sphpuxv30d.html

[Zinky]

Uwe.. thanks for the update.

'Been awaiting this announcement since it was withdrawn several times in the past...

[harry d brown jr]

Nelson,

Yes, HP and EMC support this. We are running about 200 virtual partitions across ~50 n-class servers, that use the SAN for booting and other VG's.

EMC doesn't currently support booting across ISL's, but we expect them to bless it sometime in the future, especially since their lab does it without issues. We do keep boot ports/paths separate from data vg's.

live free or die
harry

[Uwe Zessin]

Good point, Harry.
In MicroSoft Cluster configuration it used to be mandatory to have a different adapter for the boot LUN than for the cluster shared LUNs. I thought that has changed, but the current boot guide from February 2004 still lists this requirement.

On AlphaServers there never was such a restriction.

[Zinky]

So Harry, each of your N-Class' vPar would have 4 FC-HBA's? Why the need for separate boot paths (FC channels) for your SAN based boot disks?

[harry d brown jr]

Nelson,

actually each vPar has TWO (2) FC's, but the path to the Symmetrix of boot vs data is different. Plus we use powerpath.

live free or die
harry

[Zinky]

Thanks for the clarification Harry.

I am architecting a large system that will be flexible enough. It will be HDS(XP)/EVA based using SecurePath and will be a mix of nPars and vPars. To increase vPar density - we plan to use A9784A's (PCI-X Combo 2Gbps FC/GigEthernet) - so our test/non-prod vPar can now actually require only a single PCI slot while production vPars can now subsist on just 2 PCI slots. With Boot Support to EVA's now fully supported under SecurePath 3.0D and a single vendor... we're expecting lesser bumps ahead...

[Fabio Ettore]

ok