Many clustered technologies require the use of some kind of shared storage. You can go with an enterprise class SAN, or build something out by hand with technology like DRBD, but you need to have multiple hosts able to access the same data at once.

This particular discussion was about moving virtual machine images to shared storage. In particular, my colleague reacted like it was some crazy idea I had cooked up, rather than standard practice in enterprise environments. Sure, it is simple and easy to keep all the images stored on the local hosts, but you lose benefits like live migration which are pretty useful. The irony is that you usually leverage a SAN to avoid having a SPOF for whatever service is using your storage, and if you’re worried about the SAN you’re ignoring that fact. It is judgmental to call the SAN device a SPOF without learning about the long list of redundant devices in it, including power supplies, controllers and ethernet interfaces.

Which emphasizes my earlier point, you need to know why something works, not just that it does or does not for you at the moment.

I am for example a huge fan of running ZFS on local SATA disks. This technology stack is dead simple: ZFS combines the block layer & fs layer in one, and standard SATA chips these day all implement the same well-known AHCI hw interface. That’s it. It works great. I use that tech stack at home, at work, etc. Now read the ZFS mailing list, there are many stories of sysadmins trying to deploy storage technologies in their companies. The *vast* majority of people having any sort of problems are those that employ the most complex technologies involving SANs, iSCSI, FC switches, etc; there are people experiencing bugs in SAN devices ignoring SCSI commands to flush caches, etc. It is painfully obvious to me that the bigger your tech stack is, the bigger the amount of money you will waste on debugging and deploying it is.

You can probably tell by now that I am strongly anti-SAN That said, I would be interested to hear some of your viewpoints.