The Top 10 SANs vs. NAS Decision Factorsby W. Curtis Preston, author of Using SANs and NAS
Many administrators find themselves answering a new question: Should I use Storage Area Networks (SANs) or Network Attached Storage (NAS) to store my data?
NAS filers (dedicated machines serving files via NFS, CIFS, or NCP) were once perceived as "NFS in a box," and no one would think about using them to hold large databases. In contrast, SAN disk arrays were perceived as too expensive for the average user. The decrease in the price of a SAN array, and the increase in functionality and speed of NAS filers have changed all that.
Which is right for you? Should you buy a large Fibre Channel-based array, put it on a SAN, then use disk virtualization, a volume manager, and filesystem software to allocate the disks to multiple hosts? Or should you buy a NAS filer with its native volume manager and use NFS to share its volumes to multiple hosts? This article gives you 10 reasons that people cite when they make this decision.
Many of the comments made in the following paragraphs are summaries of information from the book Using SANs and NAS. For the details behind these summary statements, please see Chapters 2 and 5 of this book.
Many would argue that SANs are simply more powerful than NAS. Some would argue that NFS and CIFS running on top of TCP/IP creates more overhead on the client than SCSI-3 running on top of Fibre Channel. This means, they would say, that a single host can sustain more throughput to a SAN-based disk than a NAS-based disk. While this may be true on very high-end servers, most real-world applications require much less throughput than the maximum available throughput of a filer.
There are applications where SANs will be faster. If your application requires sustained throughput greater than what is available from the fastest filer, your only alternative is a SAN.
One of the downsides of SANs is that, while they do offer multi-host access to devices, they don't offer multi-host access to files, which most applications want. If you want the systems connected to a SAN to be able to read and write to the same file, you'll need a SAN or cluster-based filesystem. Such filesystems are starting to become available, but they are usually expensive and are relatively new technologies. Filers, on the other hand, are able to offer multi-host access to files using technology that has existed since 1984.
Some people are concerned because they do not understand Fibre Channel, and therefore will have difficulty understanding fabric-based SANs. To these people, SANs represents a significant learning curve, where NAS does not. All they need to do to implement a filer is to read the manual provided by their NAS vendor, which is usually rather brief.
In comparison, to implement a SAN they would first need to read about and understand Fibre Channel, then read the HBA manual, the switch manual, and the manuals that come with any SAN management software they purchased. The concepts of Fibre Channel, arbitrated loop, fabric login, and device virtualization are not always easy to grasp. The concepts of NFS and CIFS seem much simpler in comparison.
No one who has managed both a SAN and NAS should argue with this statement. SANs are composed of pieces of hardware from many vendors, including the HBA, the switch or hub, and the disk arrays. Each of these vendors will be new to an environment that has not previously used a SAN. In comparison, filers allow the use of your existing network infrastructure. The only new vendor you'll need to communicate with is the manufacturer of the filer itself. SANs have a larger number of components that can fail, fewer tools to troubleshoot these failures, and more possibilities of finger pointing. The result is that a NAS-based network will be much easier to maintain.
Again, since filers let you leverage your existing network infrastructure, they are usually much cheaper to implement than a SAN. A SAN requires the purchase of a Fibre Channel HBA to support each host that will be connected to the SAN, a port on a hub or switch to support each host, one or more disk arrays, and the appropriate cables to connect all this together. Even if you choose to install a completely separate LAN for your NAS traffic, the required components will still be much cheaper than their SAN counterparts.
Although SANs are getting less expensive every day, a Fibre Channel HBA still costs much more than a standard Ethernet NIC. It's simply a matter of economies of scale. More people need Ethernet than need Fibre Channel.
Many people have criticized SANs for being more hype than reality. Too many vendors’ systems are incompatible, and too many software pieces are just now being released. Vendors are still fighting over the Fibre Channel standard. While there are many successfully implemented SANs today, there are many that were not successful. If you connect equipment from the wrong vendors, things just won't work. In comparison, filers are completely interoperable, and the standards they are based on have been around for years.
Perhaps in a few years, the vendors will have agreed upon an appropriate standard, and SAN management software will do everything that we want it to do, with SAN equipment that is completely interoperable. I sure hope this happens.
NAS filers can be difficult to backup to tape. Although the snapshot and off-site replication software sold by some NAS vendors offers some wonderful recovery possibilities that are rather difficult to achieve with a SAN, filers must still be backed up to tape at some point, and that can be a challenge. One of the reasons is that performing a full backup to tape will typically task an I/O system much more than any other application. This means that backing up a really large filer to tape will create quite a load on the system. Although many filers have significantly improved their backup and recovery speeds, SANs are still faster when it comes to raw throughput to tape.
The throughput possible with a SAN makes large-scale backup and recovery much easier. In fact, large NAS environments take advantage of SAN technology in order to share a tape library and perform LAN-less backups.
So far all of the backup and recovery options for filers are file-based. This means that the backup and recovery software is traversing the filesystem just as you do. There are a few applications that create millions of small files. Restoring millions of small files is perhaps the most difficult task that a backup and recovery system will perform. More time is spent creating the inode than actually restoring the data. This is why most major backup and recovery software vendors have created software that is able to backup filesystems via the raw device -- while maintaining file-level recoverability. Unfortunately, today's filers do not have a solution for this problem.
Although it is arguable that most applications will never task a NAS filer beyond its ability to transfer data, it is important to mention that theoretically a SAN should be capable of transferring more data than a NAS. If your application requires incredible amounts of throughput, you should certainly benchmark both. For some environments, NAS offers a faster, cheaper alternative to SANs. However, for other environments, SANs may be the only option. Just make sure you test your potential system before buying it.
Neither NFS nor CIFS can serve raw devices via the network. They can only serve files. If your application requires access to a raw device, then NAS is simply not an option.
The bottom line is that which storage architecture is appropriate for you depends heavily on your environment. What is more important to you: cost, complexity, flexibility, or raw throughput? Communicate your storage requirements to both NAS and SANs vendors and see what numbers they come up with for cost. If the cost and complexity of a SAN is not completely out of the question, than you should benchmark both.
W. Curtis Preston has specialized in designing backup and recovery systems for over eight years, and has designed such systems for many environments, both large and small.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.