Hello
Readers,
Which solution meets your network's storage needs the best -
SANs or NAS? The specs of both systems have gone through major
changes recently, so if you haven't checked lately, it’s more
than likely time to take another look. While both have increased
in capabilities, there is no doubt that they serve different
functions. So, how do you decide which is right for you? For
starters, check out W. Curtis Preston’s article for the top
10 deciding factors that will help you select either a SANs
or NAS solution for your network storage needs.
Happy reading!
The Top 10 SANs vs. NAS
Decision Factors
The Top 10 SANs vs. NAS Decision Factors
by 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.
1. NAS filers are fast enough for many applications.
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.
2. NAS filers offer multi-host filesystem access.
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.
3. NAS is easier to understand than SAN.
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.
4. NAS filers are easier to maintain than SANs.
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.
5. NAS filers are much cheaper than SANs.
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.
6. NAS filers are here and now.
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.
7. SANs are easier to backup than NAS.
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.
8. You cannot do image-level backup of NAS.
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.
9. The upper limit of a NAS is lower than a SAN.
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.
10. SANs can serve raw devices.
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.
Originally published at http://www.onlamp.com/pub/a/onlamp/2002/03/14/sansnas.html.
| Storage Area Networks (SANs) and Network Attached Storage
(NAS) allow organizations to manage and back up huge file
systems quickly. W. Curtis Preston's insightful book takes
you through the ins and outs of building and managing
large data centers using SANs and NAS. Whether you're
a seasoned storage administrator or a network administrator
charged with taking on this role, you'll find all the
information you need to make informed architecture and
data management decisions. |
 |
|
|