Diskless Blades boot to SAN [pros/cons]

Hi,

Could someone briefly talk about the pros/cons of having all blade
servers boot to a SAN as opposed to containing their own hard drives?

I imagine the scenario would look something like this: A SAN contains 14
drives. One huge RAID 5 partition is created. Somehow, logical drives are
created in the partition, one logical drive per blade. Each blade boots to
its own logical drive. Do I have the right idea conceptually?

This seems somewhat dangerous to me since if the SAN controller fails,
ALL of your blades go down.... On the other hand, people much smarter than I
are using this technique so there must be some advantages. What do you
think?

Jackson

In comp.sys.ibm.pc.hardware.storage Jackson Houndmugger <lameboy@booooon.com> wrote:[color=blue]
> Hi,[/color]
[color=blue]
> Could someone briefly talk about the pros/cons of having all blade
> servers boot to a SAN as opposed to containing their own hard drives?[/color]
[color=blue]
> I imagine the scenario would look something like this: A SAN contains 14
> drives. One huge RAID 5 partition is created. Somehow, logical drives are
> created in the partition, one logical drive per blade. Each blade boots to
> its own logical drive. Do I have the right idea conceptually?[/color]
[color=blue]
> This seems somewhat dangerous to me since if the SAN controller fails,
> ALL of your blades go down.... On the other hand, people much smarter than I
> are using this technique so there must be some advantages. What do you
> think?[/color]

I have something roughly similar (22 Standard PCs in a rack with
one boot server).

Pro: You can configure boot-parameters centrally without hassle.
You have only one storage device to monitor (and repair).
You need to do only one backup.

Con: Your blades are useless if the SAN fails.
You have a _major_ bottleneck for disk-intensive applications.
Your backup is huge.


In the end I decided to have both, local disks for the OS and data as
well as Kernels deliverd from fileserver and more data partitions
there. Backup is only from the fileserver and the installation on the
individual PCs can be reconstucted in minutes with FAI (Fully
Automatic Installation), which makes recovery from a disk-replacement
easy. Also users are told thet there is no backup of node-local
disks. (There is no backup of data on the fileservers either, but
that is because a 3TB backup would just take far too long and be
too expensive. We have all raw data on tape anyways.)

I think the bottleneck argument is the most important. Personally
I found that as little as 3 PCs can saturate a RAID5 array on
64 Bit PCI. A SAN may be able to take more (I use Linux software
RAID), but not that many more. And local storage scales linearly.

Arno

There are good reasons either way based on the business needs of the
application. Your concerns are well founded, but the addtional risk
associated with booting off the SAN can be mitigated with the correct
architecture-- using multiple HBAs across multiple fabrics (or
direct-attached) to multiple ports on your disk array.

I'm not sure of the specification of your bladecenter, but the blades
that I've seen, only suppported a single IDE laptop-style drive.

This produces a couple of disadvantages:
1. The speed of ATA drives, especially for typical random workloads is
very poor in comparison to SCSI/FC drives on most SAN-attached disk
arrays.

2. In order to provide redundancy, you would need to mirror between
the SAN and the internal disk. This would deliver the poor performance
of your IDE disk, and you would be unable to use parity RAID (instead
of mirroring) to reduce disk usage.

Some advantages of having your OS on the SAN include:
1. The ability to move disk between blades easily. Keep in mind, that
since your blades are going to have nearly identical hardware, the
installed OS would be very portable.

2. With some disk arrays, disk space can be added on the fly.

3. As a blade server becomes higher profile, additional features like
point-in-time copies, remote-mirroring, and remote replication are
available.

HTH
Aaron

On Thu, 17 Mar 2005 11:09:37 -0800, "Jackson Houndmugger"
<lameboy@booooon.com> wrote:
[color=blue]
>Hi,
>
> Could someone briefly talk about the pros/cons of having all blade
>servers boot to a SAN as opposed to containing their own hard drives?
>
> I imagine the scenario would look something like this: A SAN contains 14
>drives. One huge RAID 5 partition is created. Somehow, logical drives are
>created in the partition, one logical drive per blade. Each blade boots to
>its own logical drive. Do I have the right idea conceptually?
>
> This seems somewhat dangerous to me since if the SAN controller fails,
>ALL of your blades go down.... On the other hand, people much smarter than I
>are using this technique so there must be some advantages. What do you
>think?
>
>Jackson
>[/color]

Other people have mentioned pros and cons allready, although the
performance side of it I take some issue with.

One serious benefit of SAN booting is upgrades. You can clone the
production LUN, upgrade it or test changes with a test blade, then
point the production servers at it if all goes well. In this way it's
easy to upgrade a rack at a time.

This assumes some unix based OS, no clue how it would work with
windows.

~F

If you can use PXE Boot with your blades, and want to boot Windows OS
on your baldes, you may consider an alternative to SAN-Boot:
Qualystem LAN-PC 3 product.
It makes it possible to boot Windows 2K/XP/2K3 on diskless nodes
(including blades). The virtual HD is stored on a Linux/Windows/FreeBSD
server and can be shared by several nodes AT THE SAME TIME. Upgrades
and deployment are then just a matter of modifying ONE and ONLY ONE HD
(virtual HD in fact).
The server module (that can run on Linux/Windows or FreeBSD OS) can
also be run on a Blade. This Server can use directly attached storage,
or SAN attached disks.

More details about Qualystem LAN-PC:
[url]http://www.qualystem.com/en/lannetpc.html[/url]

Regarding the SAN availability, any SAN worth it's salt will have N+1
redundancy, so it will be more robust than anything your servers offer,
with redundant SCSI controllers.

Typically it should have redundant paths to the SAN anyway across two
independent fabrics. Besides, even if you can boot the servers with a
down SAN, who cares? There's no data. Point being you aren't really
introducing another point of failure.

Advantages)

Windows 2000 (win2003) cluster server DR
if you want DR available clusters, this is the best way to go if you
are doing firmware level mirroring. Windows clusters have a big
problem trying to bring up another servers disks and split brain
partition (they really can't do it). Booting from SAN alleviates this
problem

LAB environments
You can quickly change configurations, test, change, test, etc and have
seperate partitions for your different versions. Therefore you could
have one server with Win2k, 2003, LINUX, Solaris, Oracle DB servers,
Exchange Servers etc LUNs available and be able to quickly change from
one to another.

Makes the server a FRP.
Field replaceable part, wonderful option, but with caveats

Disadvantages:

It will work on identical hardware only. If you replace parts, you
must replace them on all boxes. This is a biggie.

My own preference when all is said and done would be to take a big
servers with duplexed internal drives and have it keep all of it's data
on the SAN, then use CITRIX to carve that larger box into as many
virtual servers as you wish. DR is also simple with this as you can
move virtual servers from one location to another. In this way you
have server commoditized and can quickly replace them, you have a very
standard configuration, and are extremely flexible.