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. Compatibility 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.
Related: Other SQL Server Storage Options
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.
