Everyone seems to want to jump into purchasing a SAN; sometimes they are quite passionate about the technology. SANs are, admittedly, pretty cool. They are one of the more fun and exciting large-scale hardware items that most IT professionals get a chance to have in their own shops. Often the desire to have a SAN of one's own is a matter of "keeping up with the Joneses." Using a SAN has become a bit of a status symbol — one of those last bastions of big business IT that you only see in a dedicated server closet and never in someone's home (well, almost never).
Vendors advertise SANs as amazing boxes with internal redundancy that makes them infallible, speed that defies logic and features that you never knew that you needed. When speaking to IT pros designing new systems, one of the most common design aspects that I hear is "well we don't know much about our final design, but we know that we need a SAN."
SAN is a soft term used to mean multiple things at different times and can become quite confusing. In the context of this article, I use SAN in its most common context, that is to mean a "block storage device" and not to refer to the entire storage network.
SAN provides back-end storage. The need for it would be, in all cases, determined by other aspects of your architecture. If you have not yet decided upon many other pieces of your infrastructure, you simply cannot know that a SAN is going to be necessary, or even useful, in the final design.
It is clear that the drive to implement a SAN is so strong that often entire projects are devised with little purpose except, it would seem, to justify the purchase of the SAN. As with any project, the first question that one must ask is "What is the business need that we are attempting to fill?" Not "We want to buy a SAN, where can we use it?"
SANs are complex, and with complexity comes fragility. Very often SANs carry high cost.
But the scariest aspect of a SAN is the widespread lack of deep industry knowledge concerning them. SANs pose huge technical and business risk that must be overcome to justify their use. SANs are, without a doubt, very exciting and quite useful, but that is seldom good enough to warrant the desire for one.
We refer to SANs as "the storage of last resort." What this means is, when picking types of storage, you hope that you can use any of the other alternatives such as local drives, DAS (Direct Attached Storage) or NAS (Network Attached Storage) rather than SAN. Most times, other options work wonderfully. But there are times when the business needs demand requirements that can only reasonably be met with a SAN. When those come up, we have no choice and must use a SAN. But generally it can be avoided in favor of simpler and normally less costly or risky options.
I find that most people looking to implement a SAN are doing so under a number of misconceptions.
The first is that SANs, by their very nature, are highly reliable. While there are certainly many SAN vendors and specific SAN products that are amazingly reliable, the same could be said about any IT product.
High-end servers in the price range of high-end SANs are every bit as reliable as SANs. Since SANs are made from the same hardware components as normal servers, there is no magic to making them more reliable. Anything that can be used to make a SAN reliable is a trickle down of server RAS (Reliability, Availability and Serviceability) technologies.
Just like SAN, NAS and DAS, as well as local disks, can be made incredibly reliable. SAN only refers to the device being used to serve block storage rather than perform some other task. A SAN is just a very simple server. SANs encompass the entire range of reliability with mainframe-like reliability at the top end to devices that are nothing more than external hard drives — the most unreliable network devices on your network &mdash: on the bottom end.
SANs have gained a reputation for reliability because businesses put often extreme budgets into their SANs that they do not put into their servers. So they are often comparing is a relatively high end SAN to a budget server.