Why boot from san

More robust storage. In most enterprise environments that use SAN-based shared storage, the storage infrastructure is intentionally built to be rock solid since it holds, in many cases, everything.

This means that the SAN probably has more disks, more capacity, faster storage processors, and other redundancies that might not be found on a local server.

Further, if we start to get low on disk space on one of the connected servers, we just provision more. Additional availability opportunities. Although individual servers can also be replicated, doing so requires additional software that may not be a standard operating method in an environment, thereby creating a process exception that can be difficult to support.

New upgrade options. When the time comes to move to a new operating system across the entire organization, you can more easily stage the upgrade by creating all of the OS images on the SAN and then connecting individual servers to new boot images.

Cons Need for more advanced storage adapter. Boot from SAN requires some method by which a server can be connected to a storage device before the operating system has had an opportunity to load drivers. In an environment that is already using shared storage, it's likely that the servers would already be provisioned with these storage adapters, so storage adapters may not be an additional cost that is borne to just boot from SAN. Potential for boot storms. If there are many servers booting from shared storage, it's possible that all servers could attempt to boot at once.

This situation can overload the storage since boot time is an intensive process from a storage perspective. As such, planning is key to make sure that all SAN-based services remain within performance parameters supported by the SAN. Additional complexity. Local storage is now so much faster than SAN storage even with a 40Gbps connection. On a single drive. For not that much money.

In the future once PCI-e 4. Sorry, but I see SAN as a dead medium in the modern world. With AlwaysOn High Availability you can get highly available SQL servers with no shared storage although the storage layout on all the servers does need to look identical on each node.

They are all going to perform poorly versus local storage. However, I realise that's not the question you're actually asking and I'm just hoping that you haven't bought a new SAN in and you still have the opportunity to reevaluate. There are many systems running like this right now everywhere, in particular things like non-virtualised database servers work this way, it's fine and very useful if you need the lowest latencies and to gain access to every last drop of performance - CGI render-farms usually work like this too.

I've done this once or twice over the years, usually it's a little more 'fragile' than I'd like, yes it works but can take a lot more work to do than the local-disk option, and really all you're doing is saving a little bit extra on your servers by not buying a boot pair and disk controller - personally I can't see me using this in the future.

You mention vSAN here, which product are you talking about, if you're talking about VMware's vSAN product then that changes things as you can then run disks locally, have protection from failure and have the ability to migrate from host to host - maybe come back to clear that up? In corporate environments this is probably the most frequently used and trusted method right now though that might change as distributed file systems such as vSAN really take off.

If you use 1Gbps ethernet against a slow disk array then it'll definitely be slower than using local disks, the array manufacturer I prefer, combined with 40Gbps FCoE is way quicker than anything I can connect directly to my server bar NVMe drives.

So it really does depend on what that centralised storage is. I'm not sure how 'rare' this practice is, I've seen it a lot but I'd guess it depends on the environment. Since the typical blade server has only two slots for disks, this could be pretty limiting for something like a database server where multiple terabytes of space might be required. Additionally, it's fast and easy to replace a failing blade by simply replacing the blade and not having to worry about the guy doing that to move the disks and not get them in the correct slots.

This still requires the HBA in the new blade to be configured a discussed below. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Asked 2 years, 2 months ago. Active 2 years, 2 months ago. You can slap a new host into the environment and it will boot up and appear as the old vSphere host.

The installation and configuration requires a lot of time and effort. Boot from SAN is something that should be evaluated from all angles, and is not by default a huge benefit to the typical vSphere environment.

It adds a decent bit of complexity and time investment while having narrowly defined returns. Additionally, modern server technology can easily have a pair of SD cards or SSD drives that are mirrored to protect the data, reducing a reliance on spinning disk.