SUMMARY: Pros and Cons of Booting Solaris From a SAN ( Specifically and EMC)

From: Tom Zurita <>
Date: Tue May 29 2001 - 11:46:09 EDT
Here is my summary of responses that I recieved for my question regarding
booting from a SAN.  I would like to thank all who responded.  I would
like to see a resonse from someone that has actually built an environment
where the Solaris boxes boot from the EMC's.  What interests me is the
pitfalls of such an environment and whether or not they would do it again.

EMC's stance is "it works GREAT....", yet it sounds more like a sales ploy
to get a company to depend on the SAN for all things.

My issues are the following:

1. I understand that in order to be able to boot from the SAN you need to
have EMC's proprietary PROM installed.  I prefer to leave the SUN PROM

2. Isolating a problem may also be a problem because it may be hard to
differentiate the problem from being host specific or SAN.

My preference is to use SDS for the internal root disks and Veritas for
the external disks.  At any rate, below are the responses I recieved.

Original Question:

I am trying to get the pros and cons of booting a solaris box from an EMC
vs. mirrored local disks.  If anyone has any experience with the
Solaris-EMC-Boot config and it's benefits and drawbacks.

Kevin Buterbaugh:
"I personally prefer booting from mirrored local disks.  The reason is
that any other configuration (EMC, A1000, etc.) all have some sort of "If
such and such occurs, I can't boot my box."  For example, while you can
boot a Sun from an A1000, what if there's a problem with the RAID manager

On the other hand, if I've got my root disk mirrored across controllers,
almost all of that is eliminated.  Hope this helps..."

Don Harris:
"I don't have experience booting from an EMC disk, but I don't boot any of
my production servers from the disk boards.  (They all have mirrored boot
disks in a D1000).
There are a couple reasons for doing this.
1. Disk boards take up another slot that I could be using for CPU/Memory
or I/O boards.
2. If the server dies, I don't have many options for getting it back up
and running, other than fixing the problem.  All my production servers are
config'd the same way, so I could just grab my boot disk tray (a D1000)
and plug it in to another (staging/devel) server and let it boot the disk
tray, and it would automagically become the first server that died (as it
is booting the other set of disks now).  Granted you could move disk
boards around, achieving the same end effect, but this saves you from
having to move the disk broards around.
3. Any mirroring you do on a disk board is done through software (either
Disk Suite / Veritas).  This takes cycles.  If you use EMC you might be
able to do something within EMC to mirror them outside of the o/s.  (If
you  used something like an A1000 you use hardware based mirroring, so, it
wouldn't put any more overhead on the o/s itself).

The main advantage to doing this is that you can save 1 slot by not using
disk boards.

Seth Rothenberg:
"There is EMC at our site, serving the mainframe, but we have not yet
accepted the IBM team's offer to hook us up.

Here's one thought that came to may be extreme, but something
to think about....

One reason we bought Sun disk instead of connecting to the EMC was that
EMC admitted that major firmware upgrades require the Storage to be down.
I realized that this could still be 99.999 or higher, but the fact is,
shutting down the system for regular maintenance should not be needed.
What it means for you is, when that maintenance occurs, your host must be down.  Not
just your application.

With the Sun A3500, we needed to replace a controller board (OK, that
is a story of its own), and we did it online.

I would have been very nervous upgrading the A3500 if we had booted from
it (I don't even know if they allow it :-)
We boot off local disks.  My particular preference is, I am asking for two
Multipacks on each system, each with multiple disks.  The first disk on
each multipack is root (root mirror on the second multipack); the other
disk(s) are used for other admin activities....actually, we have done
tests where we have used vxvm to sync local disk with the A3500, and then
idled the A3500, all the while, running our live system.  We then
resynchronized A3500, and detached the local disk."

Paul Timmins:
"Well, I have some opinions here:
-  Con: Booting from the SAN is relatively new... I've seen problems in
boot timing. I'd use it for several months in development before moving to
production. Every environment has it's problems...
-  Pro: You can use EMC's timefinder (snapshots, or BCV's) to manage boot
-  Note: Make sure you use volume logix for lun masking... also, make sure
you have a system with local bootdisk, so you can boot it and run the
volume logix software.
-  Con: May have some performance improvement by having your OS run off a
different controller than the SAN...

    From experience, most people use local disks for boot. Booting from
the SAN is often a pain... however if you have a very standardized
environment, it may be reasonable to play with it in the lab and work out
the kinks. The advantages to eliminating all local disks is very

Brooke King:
You get another place from which to boot that is isolated from
failures that can plague local disks.

You use up precious LUNs, which do have a rather low limit, in my
opinion and compared to competitors, in your EMC Symmetrix.

What we do:
Conserve LUNs by only booting from locally mirrored disks under
Veritas Volume Management. I automated the Sun Blueprint regarding best
practices for managing boot disks with VxVM, well, at least the parts
about mirroring, de-encapsulating, and re-initializing root. This has served us well when we JumpStarted many such systems and
had to go back and add VxVM to others."


Tom Zurita
Sr. Site Engineer                               24x7 ICCC: 888-898-7667
SiteSmith, Inc.                                      Main: 703-467-5780
485 Spring Park Place, #1500                          Fax: 703-467-5799
Herndon, VA, 20170                                 Direct: 703-796-3016
Received on Tue May 29 16:46:09 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:55 EDT