Boot from SAN

[UxBoD]

Hi,

On behalf of a client I am looking at migrating their internal HP-UX 11.23 O/S disks to SAN disks on a EVA4000. I have tested cloning the root disks using DRD (Dynamic Root Disk) from internal to SAN, and that worked a treat. The cloned disks booted just fine.

Now my question is according to the HP Boot from SAN documentation this should only be performed on a disk group that is not high in application activity. Though was does this mean, as there is no criteria for measuring against. On the disk group at the moment is some applications, and Progress databases but most of these are pinned in memory through a caching mechanism.

Any ideas on this ? before I go back to the client and tell them they will need to purchase eight more disks.

TIA

[Steven E. Protter]

Shalom,

Tell the client its a bad idea.

Data on the SAN no problem.

Booting on the SAN, big problem. Because you can't boot the system when there is a SAN issue there is one less tool to diagnose the problem with. Actually many less tools.

One little mistake by the SAN admin and all eight systems are down.

Not all HP-UX systems support SAN boot and as for best practices, it is best to not.

SEP

[UxBoD]

Interesting though that the white paper (http://search.hp.com/redirect.html?type=REG&qt=HP-UX+boot+from+SAN&url=http%3A//docs.hp.com/en/7408/HPUXSANBootWP_final_v2_update.pdf%3Fjumpid%3Dreg_R1002_USEN&pos=3) only really lists the positives.

[Vladimir Fabecic]

I also had idea to boot HP-UX 11.23 from SAN.
I come from TRU64 and VMS background where boot from SAN is normal and sometimes you MUST boot from SAN (TRU Cluster).
Then I read post from SEP who said "Do NOT do it" and did some experiments.
As one from world where boot from SAN is preferred way to boot, I strongly agree with SEP!!!
Do NOT do it 11.23 or do it with 11.31.

[UxBoD]

Got a linky for SEP's post please ?

[Duncan Edmonstone]

SEP has very fixed ideas about boot from SAN (I expect born out of a bad experience). I would say it certainly has its place, but you need to have a reason for doing it. If you don't have a good justification, then don't bother. I think saying its not 'best practise' is too strong though, unless SEP can point to a HP document that clearly states that.

For the the real question is 'do I have control over/trust the SAN?'. If the answer is yes then I don't see SAN boot as anything particularly risky. However if my SAN is under the control of some loose cannon who is always making changes without telling me, I'd think very differently about it. In a a well managed/controlled environment boot from SAN is not an issue.

With respect to your original question, I'm not sure how we could arrive at any hard and fast rules - if you don't think the current load on the disk group in the EVA is particularly high then just create the boot vdisks out of that group, if you think you are already bottlenecked on IO, then consider adding more disks/another disk group for boot LUNs.

HTH

Duncan

[UxBoD]

Yes I have complete control over the SAN :) We shall still have the internal disks so periodically will clone the SAN boot image back using DRD. The reason why this is being looked at is they wish to upgrade a production server from 11.00 to 11.23. Has to be 11.23 as on PA-RISC. We have a loan machine where I have built up a copy of production, from scratch, on 11.23 and if I clone to SAN when the client wishes to perform the cutover I just need to down the upgrade server, present the LUN(s) to the production server and tell it to boot from them. The internal disks in the production server are very old aswell, and so is the whole N class. Having the O/S on SAN would certainly mean fast recovery to a DR server.

I do appreciate all comments that have been made, but it does feel to me, and from reading other threads that most issues have arisen due to poor SAN or HP-UX configuration; this includes firmware patching etc.

[Duncan Edmonstone]

>>when the client wishes to perform the cutover I just need to down the upgrade server, present the LUN(s) to the production server and tell it to boot from them.

Be careful...

This will only work without a hitch if your upgrade server is *completely identical* to your production server (i.e. same model, same disks in same slots, same cards in same slots).

If it's not then the chances are at the very least you will be paying a visit to LVM maintenance mode to export/import the root VG and other VGs, as well as having to figure out new instance numbering for your LAN cards. At worst you could find you can't boot due to missing drivers.

HTH

Duncan

[UxBoD]

the plan would be to mirror the configuration, but your warnings are understood :)

[Eric SAUBIGNAC]

Hi,

Several of my clients have their HP-UX boxes configured to boot on SAN. And there is no known issue due to boot on SAN.

Why do they boot on SAN ? Mainly for faster recovery.

For example some of them have 2 RX8640 and 2 EVA 4000, one of each in a separate room. vPar are configured inside the nPars : for one vPar "production" in an RX, you will find the same vPar "devlopment/integration" on the other RX, with the same IO slots. Each vDisk on one EVA is mirrored through LVM with the other EVA. So, have one room totally crashed, and you will be able to start production vPars in the other room, in place of corresponding integration vPar.

With HP Integrity VM, it's then more flexible if you boot the Guest's OS from the SAN : you can easly move VM from one HP VM Host to another, for availablity purpose or simply to have better load balance between VM Hosts.

Really, in my experience, there is NO problem with this kind of architecture, even less if you are the boss of the SAN, even less if you have redundant fabrics, even less if you do intelligent design ...

Just one fact : i do suggest you use SecurePath even if PV Links are supported with EVA 4000, mainly for performance reasons. Anyway, if you use securepath don't forget to add PV links in vg00 : at time where the system comes up remember that if the path used to build vg00 is down, securepath is not active. So you will not be able to boot.

Be fair with my english ;-)

Hope this will help

Eric