Boot disks in SAN

[Fabio Ettore]

Hello guys,

my question wishes some replies from your great experience on HP-UX systems.

What are issues to have boot disks (boot disk + mirror) in SAN (Storage Area Network)?

I think about a slow boot (slower than boot disks inside the machine) and performance issues on network.
It also could be another point of failure for Disk Array.

Other hints according to your experience?

Thanks and best regards,
Ettore

[Mark Grant]

I haven't done this and I understand it is quite a new facility. However, in my opinion, I would much much prefer to have a local disk to boot off. If your machine isn't attached to the SAN, you can't boot it. I admit if all your data is on the SAN annd the SAN isn't available there isn't much point in booting it but I just like being able to boot.

[G. Vrijhoeven]

Ettore,

Same here, no experience. It can be usefull if you have more than one identical server in case of desaster recovery.
I would prefer local disks for swap.

HTH,

Gideon

[Roberto Polli]

Using fiber there should be less network speed issues.
Maybe the whole network could be a point of failure (eg: cables, NIC)
You may want to implement a redundant boot nic.
eg.

MirroredDiskArray
| |
| |
Controller1-Controller2
| \ / |
| \/ |
| /\ |
| / \ |
SANswitch1 SANswitch2
| |
| |
NIC1 NIC2
| |
Server


Any comments are welcome.


Peace, R>

[Roberto Polli]

these f*ing html blew up spaces from my diag but it should be readable.

Swap space issues are meaningful but you may use local swap.

Maybe you can have problems upgrading NIC firmware or nic driver. Don't know how is singel-user booting tru san-storage but the server should see the fiber like a scsi device (but I'm not sure about it!!!)
Peace ,r

[Uwe Zessin]

For some systems (like Windows) one puts the system disk onto the SAN so that it can be replicated by the storage array to a desaster recovery site where an identical spare server is located.

Running the system disks on the SAN is a hot topic for OpenVMS and Tru64 Unix systems, because both can use a common system disk within a cluster. It is less of a problem, because the AlphaServer console has good boot support and diagnostic tools.

It limits the system management a little bit, because patches are rolled out only once. The downside, of course is, that you are now depended on one copy of the system disk, but we all know that breakfast is not free ;-)

You could use value-added services on the storage array like snapshots or clones to protect your data or make it available for tests. Not every operating system has a powerful volume manager.

A local disk with a pre-installed operating system and up-to-date drivers is still a nice thing. It adds additional diagnostics for some systems and you don't have to pull your system up from CD-ROM - I have seen cases where the drivers on the CD-ROM were too old and I could no longer access a storage array with recent firmware.


Roberto,
if you attach your drawing as a .TXT file there is less reason to curse ;-)

[harry d brown jr]

We have over 200 "systems" booting from the SAN, basically because we have over 200 virtual partitions across 50 N-class servers. Some older equip (like K's) didn't work, so we scrapped them from booting off the SAN.

You need to check with your SAN switch, SAN disk, and server providers to determine the interoperibility issues.

live free or die
harry

[Zinky]

Ettore,

I am currently prototyping SecurePath 3.0D - which has support for boot,swap and dump on SAN devices(including EVA). Despite it being withdrawn twice already, I am finding it remarkably robust and fast too. We will be rolling it to production very soon once we get an Okay from HP on SecurePath 3.0D being once more on G.A.

Harry,

What SAN environment are you booting off your servers? DO you use SecurePath/AutoPath or simply PV links?


Thanks!

[harry d brown jr]

Nelson,

emc/McData switches with EMC symm's and clariions.

live free or die
harry

[Zinky]

Harry,

And HP "supports" this environment?

I suppose you use PVLINKS for Path protection?