Boot From SAN? I Don’t Think So…Anymore.

Several years back, when I was a munchkin – okay not really, there was new trend called Boot from SAN.  This trend continues today.  I hopped on that bandwagon quickly when UCS released and the ability to use Service Profiles with Boot from SAN was a brilliant way of being able to recover server environments in a hurry, and even automatically, when a server failed. This was High Availability at its finest.

Then, I started thinking about it.  In doing so, I realized that the base reasoning for Boot from SAN, in most environments these days, is not necessary anymore.  The ability abstract the server OS install from the underlying hardware for HA purposes, in my opinion, is the primary reason for Boot from SAN.  Now, if you know me, you will understand that I have stated for a while now that unless you are doing something weird – like using a dongle in your environment – there  are very cases where you cannot virtualize all your systems.  If you can virtualize (the right way), then you have high availability built in – so why do you need that twice?  You don’t.

This leads to my biggest pain point with Boot from SAN, migrations from SAN to SAN.  It is just plain painful and time consuming.  Imagine pulling your toenails out of one foot, and having them moved to the other foot.  It just does not work.  This is the same as moving a Boot LUN from SAN to SAN unless you own expensive migration tools, and are willing to go through the extra effort and hassle.  Without the tools, you need to:

  1. Build the new SAN
  2. Create new Boot LUNs
  3. Install the OS
  4. Migrate the VMs

Whereas, if you are local disk boot, you just attach the new SAN and VMotion the virtual machines.  Quick, fast, easy-ish.

Now, I will admit that there are a few cases where Boot from SAN may be useful – where you are not running a hypervisor or a good one anyway –but if that is the case, perhaps you should rethink that as well.  If you don’t believe me that you you can virtualize almost any, if not all, servers in your environment – reach out.  I would be happy to be proven wrong – but I won’t be.


2 thoughts on “Boot From SAN? I Don’t Think So…Anymore.

  1. I disagree, a good use case is the UCS, where I am not swapping out a SAN but swapping out blades.

    Replacement becomes very simple with this approach, and I am not managing several independent spinning disks with separate raid etc. The OS follows along, now I know that we could potentially have to deal with driver issues, etc.

    Since you are not a fan of Hyper-V a VMware installation is fast, and really Windows isn’t terrible (assuming you have a patch management system in place).

    If the biggest issue you have on a SAN migration is installing new hypervisors, you are doing great.

  2. Anon E. Mouse,

    When using UCS, it still has to tie into the SAN. Yes, you can swap out blades all day long — just like I can take two SD cards and/or drives and swap them between blades. You are still in the same boat when you need to replace your SAN. Yes, it is not a huge deal to rebuild an ESXi server (assuming you do it right – Enterprise licenses, host profiles, vDistributed Switches, proper vMotion networking, etc.) and the same goes for Windows (though this does take more effort – or cost if you use VMM). However, what happens when you walk into a larger environment that has 16 ESXi servers and 16 Window Bare Metal (why do people still do this?) blades/servers. Standard licensing — not Enterprise. Now, you are rebuilding 32 nodes (or some form of mirror/replication setup) to replace your SAN. This adds up quickly – very quickly in terms of cost and/or time – which is again, cost.

    P.S: If you are going to do something, do it right. If not, call me. I will do it right for you. 😉

    P.P.S: Hyper-V has its place – it is called Dev/Test/UAT/QA – and it works well in that place. Hell, you can even make it work in production — have at it. You can even call me when it breaks. I know how to fix it. 😉 …and when you are ready to replace it with VMware, you can call me too.

    On a side note, I do allow anonymous comments, but really — we are all friends here, so feel free to share. 😀

Leave a Reply

Your email address will not be published. Required fields are marked *