In-Depth
Top 10 Myths of SAN Storage
Expensive, proprietary, beneficial only to enterprises -- just a few of the myths that should no longer be associated with SAN storage.
SAN storage is saddled with the reputation for being many things: expensive, unwieldy, only beneficial when implemented in enterprise environments, proprietary ... those are among the common ones.
With the help of readers and contributors, MCPmag.com has come up with a list of myths based on those perceptions that continue to stick to SAN storage. We've invited Pete Caviness, solutions marketing manager for LeftHand Networks, to look into each of them.
MCPmag.com: Before we get started, one question: SAN as opposed to iSCSI SAN -- what's the difference?
Pete Caviness: Storage area networks, the general concept, is more about treating storage like a utility and actually having storage that can be provisioned on demand and decreased -- really, a liquid type of storage that's in a pool. So SANs, in general, if you're talking to a purist, is more about the concept of storage turning into utility for the servers. An iSCSI SAN really dictates the way it connects. We try to differentiate iSCSI SANs from Fibre Channel SANs. So, when you say iSCSI SAN, it really focuses on using TCP/IP for the SAN connectivity.
With that out of the way, let's look at Myth No. 1: It's too expensive for mid-sized companies.
SAN storage really earned this reputation. Through the 1990s and early 2000s, SAN storage was expensive and complex. Those two things about SAN storage were universal as people started to look at it. It was really symptoms of where it was in the technical adoption curve. SAN storage, early in its lifespan, focused on the early adopters and technical innovators.
Today, SAN storage is much more mainstream. Two of the major things that contributed to it moving to the mainstream is, first, the adoption of the iSCSI standard in 2003. The iSCSI standard is really the ability to take SCSI communications and encapsulate them in TCP/IP and send them over a standard TCP/IP network. This standard has really pushed SAN storage into the mainstream, and in the meantime, has really decreased the cost for SAN storage and hardware. You'll find that as you're out there looking today, it's not hard to find a solution priced from $5,000 to $500,000.
Unfortunately, most customers are primarily focusing on price and performance, which is really where they don't need to focus their time. The real focus should be put on product features, and how is this storage purchase going to save their company time and money.
No. 2: SAN storage is foreign to me and requires extensive training.
iSCSI has also made this more of a myth when it comes to implementing SANs. It's pretty common when I'm talking to groups about iSCSI and I often ask them, "Raise your hand if you've configured an iSCSI SAN." Very few people raise their hands. Then I'll ask, "Raise your hand if you've configured an IP subnet," and just about everyone in the room raises their hand. There really isn't that much of a difference. Configuring an iSCSI SAN and configuring an IP subnet are identical. You have to worry about the same concerns: IP addresses, network redundancy, network convergence and quality of service. Really, any network administrator that's been working with Ethernet and TCP/IP networking for a while is well on their way to being an expert on iSCSI SANs.
No. 3: SAN storage requires my company to hire a full time storage administration staff.
That really did come out of the 1990s, when SANs were first being evolved. SANs originally were fairly complex to manage and administer and iSCSI has really brought this down to a domain of knowledge that most administrators have, foucusing on standard servers and TCP/IP, not really having to introduce too many new infrastructures into the IT environment.
You have to remember, there are product features inside the storage operating systems that are focused on reducing operating expense and customers need to look at these features as they're looking for these devices. Some of these features are things like thin provisioning, which is a way to automate the storage provisioning task, so the administrator's in control, but they're not micromanaging the storage over time. Other things you want to be concerned about is that, you're not having to micromanage the data protection space. So, if you're setting up snapshots or replication for data, you're not micromanaging that.
Really, at the end of the day, there are features within a storage subsystem that are going to reduce the amount of time you spend managing and adminstrating and reduce the number of people you have to have managing and administrating that storage area network.
How small a staff can you have to manage something like that? Do you need several administrators or could you get by with one administrator and somebody helping at the other sites?
Most of the customers that we work with actually have mixed roles. Most of them don't have a dedicated storage administrator. They usually can be split into two existing roles. So your server administrator starts to take on some of this functionality, because, really, when you're talking about connecting to the storage via iSCSI, it becomes a feature of the operating system, and when you connect or log into an iSCSI device, new drives just appear on the server. The server administrator then takes on some of that role.
And then the network administrator, to understanding how to best optimize and utilize the network to solve some of the storage problems that companies have, is something that's really in the network administrator's domain of expertise. Those two really begin to split the responsibilities.
No. 4: SAN Storage requires new HBAs on all my servers.
It's interesting when you start talking about SAN storage and HBAs or the incremental hardware required inside the server. A lot of administrators get concerned because first, you're talking about additional cost. Each HBA is going to run somewhere between $500 to $1,000 and then it's going to require some down time to get those implemented.
It's interesting when you look at iSCSI. Really, the piece that goes in the server, you can actually get for free an iSCSI software initiator from operating system vendors. Microsoft offers a free iSCSI software initiator that you can download from their Web site. Initially, when iSCSI came out, a lot of people assumed that the overhead of encapsulating all these SCSI commands in TCP/IP would be too much for the CPU to handle, and so customers would need an HBA or some TCP offload engine for that process.
But what we found in reality is that, for most applications it is not a big burden. We have the majority of our customers actually using Microsoft's iSCSI initiator, and with applications like Exchange and SQL Server they're really not seeing any impact on their CPU cycles. Also, the nice thing about this is that you know that that piece of software has been tested and developed by Microsoft, it's included in any of their service pack or OS upgrade testing.
No. 5: Enterprise-size companies are the only ones that can benefit from SAN storage.
That myth is absolutely wrong. The features inside SAN storage are really something that every company can benefit from. And in today's environment, it becomes more important.
A decade ago, when an average Windows administrator was managing maybe a hundred gigabytes of data, their traditional storage practices of having direct-attached disks and direct-attached tape and just streaming this off to tape for offsite data protection worked. In today's environment, data's just growing out of control, so companies that were administering a couple hundred gigs are now administering a couple of terabytes. As this data grows, it's obvious that the direct-attached storage architecture of the past just cannot satisfy the need.
Most of our customers are the mid-sized companies. It's strange to me that other storage vendors think the smaller the budget means the less demand for enterprise-level features. We see overwheling interest for our advanced features such as synchronous and asynchronous replication. Even smaller companies need to ensure that a certain recovery time and recovery point objective for their critical corporate data is there. And as the mid-size companies research SAN storage, they often find several compelling features that are going to positively impact their time and budget.
Have you had small-sized companies request information to implement SAN storage?
Small is kind of a relative word. The majority of our customers are what I would consider the mid-market. Usually, they have between 10 and 30 servers that they're managing and administrating and they can really benefit from getting some server consolidation and storage consolidation, and that's what usually drives their initial interest. Then, when they can see the advanced data protection feature set inside the storage, it really gets them excited about it because they can really solve multiple problems that they're dealing with in their IT environment.
No. 6: Microsoft discourages the use of SAN storage.
We don't hear this one as much today. Early on, there was some disconnect on Microsoft's position on SAN storage and what exactly that meant. In my opinion, Microsoft is the first and largest operating system vendors to embrace iSCSI storage. We work very closely with their storage team and they're constantly educating the industry on the cost savings and the simplicity of iSCSI storage. Microsoft even instituted what they call a Simple SAN Program. This qualification really does identify storage area networks that are simple to implement, simple to use and can save companies time and money. I would consider Microsoft the largest proponent of SAN storage today.
No. 7: SAN storage locks you into one vendor's proprietary hardware.
This one is changing rapidly and, I would say, it's being led really by LeftHand Networks, in terms of this myth going away. This myth hasn't gone away yet in the industry. When you bought a storage subsystem in the past, really what you were looking at was a monolithic box and that box was from one vendor and most of the software was from one vendor. And you're really getting locked into that vendor and their innovation and their product roadmap.
Lefthand Networks really took a different perspective on this. We're not a hardware company, we're a software company and we really focus on implementing full-featured iSCSI storage on industry-standard servers. We offer a wide range of choices when it comes to picking hardware from industry-leading vendors. I would say that this trend that LeftHand is leading is identical to what happened in the server industry over the last couple of decades. Companies used to buy one big monolithic server, where everything within that server came from one vendor. And now that that gets aggregated and the hardware commoditized, you really find some low-cost, full-featured solutions, where you'll buy your hardware from a choice of vendors and your software from a choice of vendors and really be able to put that solution together at a price point with a good amount of features.
No. 8: You must decide between NAS and SAN.
This argument has been going on for quite a few years and it's heated up some when iSCSI has been standardized as a protocol, because now you have two methods that can run over TCP/IP for accessing and storing your data. After all this fanfare, the answer really boils down to that, they're both good alternatives that can be used together. It's common for our customers to use a low-disk or disk-free NAS solution running a really good NAS solution like Microsoft Storage Server in front of our SAN storage, and this really gives you the benefit of NAS and SAN, the best of both worlds. So, I get rich, client-side activities like SIF, NFS, single-instance storage and distributed file systems, and I also get a really rich SAN feature set like easy scalability, data availability and data protection. Combining these two technolies together works really well and it is something that most of our customers are doing today.
I don't think the question is going to be, "NAS vs. SAN?" from this point forward, it's really going to be, "How do we architect these solutions together to solve my current needs?"
No. 9: SAN storage is not secure.
You know the same security practices that your network administrator uses for your IP SANs can also be used on your iSCSI SANs. So you should really be looking at technologies to secure that and isolate that network for security purposes. On top of that, you can also implement various technologies, like CHAP and mutual CHAP inside the storage subsystems and this helps secure the data resources. You know, this challenge-response layer requires a password before any access is granted to data that is stored on the SANs. SAN is definitely secure in its own right and the tools that you have for TCP/IP and standard LANs make it even more secure.
No. 10: SAN storage improves data protection and availability.
Many people really think, "Once I've purchased a shared storage device, I have solved all my data protection and availability and scalability problems." The truth is, simply switching to a SCSI-attached drive to an iSCSI-attached drive does very little to improve your recovery objectives, to improve your data protection and data availability. The customer really needs to keep an eye on what are the advanced data protection and data availability features they get out of the storage subsystem.
Some features that you should really be looking for when you're shopping: You really need to have a really robust snapshot engine; the ability to protect your data from logical corruption, whether it be a virus attack or an accidental user deletion; the snapshots will create good, consistent point-in-times that you can recover from.
On top of that, it's good to have some kind of asynchronous replication or the ability to copy data over longer distances over lower bandwidth links. Asynchronous replication is a strong feature that you should expect in a strong storage subsystem.
And finally, having some kind of synchronous data replication. In an example where there are multiple sites, you might have multiple rooms in a building or multiple floors in a building or multiple buildings in a campus, and if you have gigabit network connectivity between those locations, really utilizing that network connectivity to create synchronous copies of your data and distribute it to protect your company from common events like fire or water damage or power outages.
Having snapshots, asynchronous replication and synchronous replication are three features that work well together and really provide enterprise-class data protection and availability.