EVA5000 - Host best practices

[Guy Humphreys]

Morning everyone,

I have a planning/best practices sort of question, first a bit of background.

We are moving to a SAN environment for our HP-UX boxes, and have bought an EVA5000, fully redundant, 8 disk shelves, multiple FC switches, multiple paths, 2 HBAs per server host. As ever in a bid to remove that dreaded single point of failure.

What our hardware supplier has suggested is to boot each server off 2 internal mirrored SCSI disks and then just use the SAN for data. We will be using RP3440s as our servers

However the problem with this is at the moment we only have one disk controller and so we have a single point of failure, we can always get to the san if a HBA breaks or a switch or a Fibre link but that is no good if vg00 goes down!

my quesiton is this:

What are people booting from with their SAN hosts presently? Internal disk or straight from the SAN??

If it is from the SAN then we have two HBAs so are in a better position for redundancy than off the internal disks (unless of course we pay more money and get another disk controller)

Or to put it another way should I be worried about a SCSI disk controller failing or are they as reliable as a motherboard say?

Thanks in advance for any help/advice on this

cheers
Guy

[Alex Lavrov.]

You can boot from both, but generally, if you hardware allows it you should boot from the local disks.

Failures in fibres, hba's and SAN occure more often than a failure in the internal disks.

Alex.

[Gavin Clarke]

We boot our rp4440's from mirrored internal disks. It seems like the simplest solution to me.

Booting from the SAN seems clever, yet complicated and hence potentially unreliable in my eyes.

I've got make_tape_recovery tapes if I need them, oh and serviceguard.

Cheers.

[Alex Lavrov.]

I don't agree that it's complicated. When you specify the boot path, instead of the hardware path of you internal disks, you specify the hardware path of the disks in SAN, so it's the same procedure.

But I defentely agree that it less reliable.

Alex.

[Gavin Clarke]

Alex, I like to know where the OS is. Over here somewhere (amongst all these other disks) is a little too vague for my liking.

Although, now you've explained it, the setup is very similar.

Cheers

[Alex Lavrov.]

I did it only once, when I installed VPAR on N class server and I just didn't have enough internal disks to use for system. So I had no choise, but to boot it from HDS box.

So, as I said before if your hardware allows it, use internal disks.

Alex.

[Guy Humphreys]

Thanks for the comments so far guys.

For those of us not blessed with Serviceguard, how risky is it to just use a single disk controller for the internal disks?

We have always used two in the past for our direct attached boxes. I am loathe to move away from this setup, but am I just being too paranoid?

cheers again
Guy

[Stafford Hyacinth]

We started out just the way you did and now have two maxed out EVA 5000. SAN can be so finicky especially if not zoned properly when you start to add different OSs and HBAs vendors.

Do yourself a favor and buy a couple hard drives. It will go a long way and you will have a little piece of mind.

Single drive = if it fails how fast will you be able to get another drive to rebuild?

Good luck

[Alex Lavrov.]

As long as you have the system *** disk mirrored ***, I wouldn't worry about scsi controller, it's not a part that fails a lot. You'll find more failures in hba, SAN, fiber switches.


Alex.

[Cem Tugrul]

Well,i have discussed it before with my HP
for my EVA5k and my hosts connected (SD16000,N-Class,rp5430,etc)but also they mentioned no need to boot it from SAN
for eliminating SPOF because disk controllers
of these hosts are really strong so just mirroring of your VG00 you can decrease the
risk of SPOF and also regular tape recovery
is your insurance.
But on the other hand,the Q is if we have
this technology and it we have this infastructure so why don't we use???
According to me;if i have a "system" and
paid it much $$$ then i want to use it in
limits!!!

Good Luck,

[Cem Tugrul]

MAX LIMITS!!!
:-))

[Alex Lavrov.]

Why not to use technology if you have it? Because every technology servers specific needs, and booting from SAN, which is possible, but not recommended.

It's like saying, if I have wireless router, why don't I use it with my superdome? The question is, do you really want to do it, even if it's possible? Is the wireless connection enough for the production enveronment I have in the same way it's enough for my laptop to check emails?

Alex.

[Steven E. Protter]

There are some valid reasons NOT to use technology just because its there.

If you have a problem with your HP-9000 servers fiber card for example and you use that to boot the server, your server is down.

You lose access to cstm/mstm/xstm which are actually quite hellpful in diagnosing the trouble.

Booting your server off local disk offers tangilbe benefits, such as HAVING an OS to do diagnosis on.

There are tools available from the console, but if actually want HP Hardware to show up and fix something, its useful to be able to run some commands.

I have no problem with storing application data on the SAN. Its a more efficient and cost effective way to provide disk and if configured correctly can provide better performance than local disk.

But boot off it, just because its there? I need a better reason to use technology than just because its there.

SEP

[Hein van den Heuvel]

I have been working with San's for years but still prefer a mirrored local system disks for single systems. It appeals to me as it follows the KISS princple. It allows me to 'do something' in a severely reduced/crippled circumstance, should that need ever arise. There is so much less stuff to go through, and it gets me going so much quicker... not measured in time but in time to understand the system. Everything inside the box, no switched, no zoning, no presenting to host, no grouping, no attributes to set. JBOD.

With a local, mirrored, boot disk should I need a more-signifcant upgrade then ever then I'd take an extra boot-disk clone, physically remove it. Next upgrade/update and rest secured in the knowledge that I can always, easily, plug back in that old disk. Maybe I'm a tree-hugger, but I feel comfortable in this mode of operation.

Now for a clustered setup, or a blade like setup with 'roll out those app servers' attitude, where there is very little 'personal identity' on the boot disk, but where the boot disks define the server and not the other way around that's where my balance tips to san boot drives.

The compromise could/should perhaps be to work on a bootable san 'drive' in addition to the local disk. And when you finally feel confident enough about (managing) the san, then still always have a bootable local this available 'just in case'. Belt and suspenders.

Just a personal opinion,
fwiw,

Hein.

fwiw,
Hein.