Network Attached Storage, or NAS, is a compelling technology for network administrators
faced with the need to supply ever-increasing amounts of available storage to
their users.NAS isn’t, however, a universal panacea for all network storage
needs, and SQL Server users in particular must be careful about how they choose
to implement NAS technology.
SQL Server Considerations
SQL Server 2005 fully supports the use of NAS devices. Many NAS vendors claim
SQL Server support but make a point of stating that running databases directly
from their storage devices isn’t a good idea.These vendors are making
an honest evaluation of how their NAS devices will perform.Com- patibility is
rarely a problem—many NAS vendors in the Windows Server market segment
offer devices based on Windows Storage Server 2003 R2, which guarantees that
existing Windows Server administrators will be familiar with those NAS devices’use
and management.
On the surface, it appears that mid-to high-end NAS devices are perfect candidates
for providing storage for SQL Server. These devices are typically based on high-performance
computing hardware, can have a huge amount of local caching and memory capabilities,have
the hardware horsepower to run fault-tolerant systems such as the more complex
RAID variants, and often offer completely hardware-redundant fault tolerance
as well—all elements that administrators look for in their quest for
six sigma uptime and high-performance data delivery to users. The problem is
that I/O is the slowest and many times the most crucial part of database server
performance. It’s hard to think of a worse way to improve the I/O performance
of your SQL Server databases than by stretching the connections between application
server and storage over your LAN. Although the storage system might be capable
of delivering the performance necessary to avoid latency problems for SQL Server,other
factors—such as network congestion—can lead to undesirable results.The
network path between application server and storage can easily become the bottleneck
that slows down SQL Server.
Because NAS systems are usually available to all users on the network, it’s
important to correctly configure access and availability and determine whether
you’re dedicating the storage to a particular application or group. Many
NAS vendors suggest that SQL Server be configured only with little-used archival
data stored on their NAS devices. Situations in which data isn’t likely
to be accessed often or in which data-access performance isn’t an issue
are most suitable for the use of NAS storage (rather than DAS or SAN storage).
This is not to say that a high-performance NAS device running on dedicated Gigabit
Ethernet (GbE) links wouldn’t work well with SQL Server; it does mean
that you’ll pay for the performance and capability, and that NAS might
not be the best solution for your needs.
Make the Right Choice
Many NAS vendors are positioning their NAS devices in the SQL Server market
to play to the strengths of the devices; these are easily accessible, large-capacity
online devices that come with software that makes backing up and restoring SQL
Server much simpler. As the cost of storage continues to decline, the practicality
of online backups that are disk-based, rather than nearline tape-based, makes
more economic sense, as do configurations where tape backups are made of the
disk-based copies, allowing complete data protection without affecting the real-time
performance of the SQL Server database.
Using NAS storage to provide high-performance backup or intermediate storage
as part of your data protection design is a practical solution. What you choose
to do with NAS devices in your environment is determined by the amount of money
you have available, the design of your SQL Server environment, and your goals
in providing storage capabilities to your SQL databases.The following considerations
will help you determine how well NAS will work for you as primary storage for
your SQL Server database.
Is your application I/O-bound? If the answer is yes, NAS storage
might add to the problem because of additional latency the network connection
can add.
Can your network infrastructure handle the additional traffic? Even
if your application can run successfully from a NAS device, will the network
support the additional demands that running from the device will place on it?
GbE and a good switch is the baseline network environment for running directly
from a NAS device.
Will your application be better served by
a DAS device? With costs that are roughly
comparable, is there a specific reason why
NAS will work better for you? If not, DAS
is fundamentally simpler to deploy.
What about a SAN? SAN implementation requires rearchitecting
a network and application infrastructure. Using SAN is a significantly more
expensive proposition than implementing NAS.
View Buyers Guide
End of Article
