Diskless Blades boot to SAN [pros/cons] - Storage

This is a discussion on Diskless Blades boot to SAN [pros/cons] - Storage ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Diskless Blades boot to SAN [pros/cons]

  1. 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



  2. Re: Diskless Blades boot to SAN [pros/cons]

    In comp.sys.ibm.pc.hardware.storage Jackson Houndmugger wrote:
    > 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?


    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



  3. Re: Diskless Blades boot to SAN [pros/cons]

    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


  4. Re: Diskless Blades boot to SAN [pros/cons]

    On Thu, 17 Mar 2005 11:09:37 -0800, "Jackson Houndmugger"
    wrote:

    >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
    >


    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

  5. Re: Diskless Blades boot to SAN [pros/cons]

    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:
    http://www.qualystem.com/en/lannetpc.html


  6. Re: Diskless Blades boot to SAN [pros/cons]

    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.


+ Reply to Thread