Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.”
What is 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.
SAN Misconceptions
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.
The second misconception is that SAN means “big” and NAS means “small.” There is no such association. Both SANs and NASs can be of nearly any scale or quality. They both run the gamut and there isn’t the slightest suggestion from the technology chosen whether a device is large or not.
In fact, a SAN actually can technically come “smaller” than a NAS solution. However, although there are SAN products on the market that are in this category, it is very rare to find them in use.
The third misconception is that SAN and NAS are dramatically different inside the chassis. This is certainly not the case as the majority of SAN and NAS devices today offer “unified storage,” meaning a storage appliance that acts simultaneously as both SAN and NAS.
The key difference between the two is not in backend technology or hardware or size or reliability. Instead, the defining difference is the protocols used to transfer storage. SANs are block storage exposing raw block devices onto the network using protocols like fibre channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) or Fibre Channel over Ethernet (FCoE). NAS, on the other hand, uses a network file system and exposes files onto the network using application layer protocols like NFS, SMB, AFP, HTTP and FTP which then ride over TCP/IP.
The fourth misconception is that SANs are inherently a file-sharing technology. This is NAS. SAN simply takes your block storage (hard disk subsystem) and making it remotely available over a network. The nature of networks suggests that we can attach that storage to multiple devices at once and indeed, physically, we can. But SAN is not intended for file-sharing. There are mechanisms available in special clustered filesystems and their drivers to allow for this, but this requires special knowledge and understanding. Many people acquiring SANs are unaware that they need these tools for what they often believe is the very purpose of the SAN — a disaster so common that I probably speak to someone who has done just this almost weekly.
The fifth misconception is that SANs are fast. SANs can be fast; they can also be horrifically slow. There is no intrinsic speed boost from the use of SAN technology on its own.
It is actually fairly difficult for SANs to overcome the inherent bottlenecks introduced by the network on which they sit. Some other storage options, such as DAS use all the same technologies as SAN, but lack the bottleneck and latency of the actual network an equivalent. As a result, DAS will be just a little faster than its SAN counterpart. SANs are generally a little faster than a hardware-identical NAS equivalent, but even this is not guaranteed. SAN and NAS behave differently, and in different use cases either may perform better than the other. SAN would rarely be chosen as a solution based on performance needs.
The sixth misconception is that a SAN eliminates the inherent problems associated with storage choices. A good example is the use of RAID 5. This would be considered bad practice in a server, but when working with a SAN (which in theory is far more critical than a standalone server) often careful storage subsystem planning is eschewed based on a belief that SAN technology has somehow fixed those issues or that they do not apply.
It is true that some high-end SANs do have some amount of risk mitigation features unlikely to be found elsewhere, but these are rare and exclusively relegated to very high-end units where fragile designs would already be uncommon. It is a dangerous, but very common practice, to take great care and consideration when planning storage for a physical server but skip that planning and oversight when using a SAN. You cannot assume that the SAN handles all of that internally or that it is simply no longer needed.
SAN Benefits
Now that we’ve shot down many misconceptions about SAN, you may be wondering if SANs are ever appropriate. They are, of course, quite important and incredibly valuable when used correctly. The strongest points of SANs come from consolidation and special types of shared storage.
Historically, customers sought out SAN solutions for consolidation. A SAN allows us to combine many filesystems into a single disk array, allowing far more efficient use of storage resources. Because SAN is block level, it is able to do this anytime that a traditional, local disk subsystem could be employed.
In many servers, and even many desktops, storage space is wasted due to the necessities of growth, planning and disk capacity granularity. If we have twenty servers each with 300GB drive arrays but each only using 80GB of that capacity, we have large waste. With a SAN would could consolidate to just 1.6TB, plus a small amount necessary for overhead, and spend far less on physical disks than if each server was maintaining its own storage.
Once we begin consolidating storage, we begin to look for advanced consolidation opportunities. Having consolidated many server filesytems onto a single SAN, we have the chance, if our SAN implementation supports it, to deduplicate and compress that data which, in many cases, can result in significant utilization reduction. So the 1.6TB in our example above might actually end up being only 800GB or less. Suddenly, our consolidation numbers are getting better and better.
To efficiently leverage consolidation, it is necessary to have scale. And this is where SANs really shine — when the number of attaching nodes becomes very large. SANs are best suited to large scale storage consolidation. This is their sweet spot and what makes them nearly ubiquitous in large enterprises and very rare in small ones.
SANs are also very important for certain types of clustering and shared storage that requires single shared filesystem access. This is actually a pretty rare need outside of one special circumstance — databases. Most applications are happy to utilize any type of storage provided to them, but databases often require low-level block access to be able to properly manipulate their data most effectively. Because of this, they can rarely be used, or used effectively, on NAS or file servers. Providing high availability storage environments for database clusters has long been a key use case of SAN storage.
Outside of these two primary use cases, which justify the vast majority of SAN installations, SAN also provides for high levels of storage flexibility. Potentially, SANs can make it very simple to move, grow and modify storage in a large environment without needing to deal with physical moves or complicated procurement and provisioning. Again, like consolidation, this is an artifact of large scale.
In very large environments, SAN can also provide a point a demarcation between storage and system engineering teams, allowing there to be a handoff at the network layer, generally of fibre channel or iSCSI. This clear separation of duties can be critical in allowing for teams to be highly segregated in companies that want highly discrete storage, network and systems teams. This allows the storage team to do nothing but focus on storage, and the systems team to do nothing but focus on the systems without any need for knowledge of the other team’s implementations.
For a long time, SANs also presented themselves as a convenient means to improve storage performance. This is not an intrinsic component of SAN, but an outgrowth of their common use for consolidation. Similar to virtualization when used as consolidation, shared SANs will have a natural advantage of having better utilization of available spindles, centralized caches and bigger hardware than the equivalent storage spread out among many individual servers. Like shared CPU resources, when the SAN is not receiving requests from multiple clients, it has the ability to dedicate all of its capacity to serving the requests of a single client. That provides an average performance potentially far higher than what an individual server would be able to affordably achieve on its own.
Using SANs for performance is rapidly fading from favor, however, because of the advent of SSD storage. SSDs with incredibly low latency and high IOPS performance are dropping in price to the point where they are being added to stand alone servers as local cache or potentially even being used as mainline storage. As a result, the bottleneck of the SAN’s networking becomes a larger and larger factor, making it increasingly difficult for the consolidation benefits of a SAN to offset the performance benefits of local SSDs. SSDs are potentially very disruptive for the shared storage market as they bring the performance advantage back towards local storage — just the latest in the ebb and flow of storage architecture design.
Do You Need a SAN?
The most important aspect of SAN usage to remember is that SAN should not be a default starting point in storage planning. It is one of many technology choices and one that often does not fit the bill as intended — or does so but at an unnecessarily high price point either in monetary or complexity terms.
Instead, start by defining your business goals and needs. Select SAN when it solves those needs most effectively, but keep an open mind and consider the overall storage needs of the environment.
