When does database-on-NAS make sense?

Posted on November 01, 2003

RssImageAltText

By Lisa Coleman

If you're running DB2, Oracle, or SQL Server on network-attached storage (NAS), you're not alone. Increasingly, more IT administrators are hosting database applications on NAS to leverage its ease of use and relatively low cost.

Database and NAS vendors are working together to build products that allow users to quickly deploy databases on NAS filers. For example, Oracle has certified some NAS filers to work with its databases, including products from EMC, Hewlett-Packard, Network Appliance, Procom Technology, and Veritas. BlueArc is currently working on certification.

Traditionally, IT runs databases on direct-attached storage or storage area networks (SANs) because databases process data at the block level, and in most cases, need high performance for transaction-intensive applications. But over the past few years, IT administrators have begun using NAS for database hosting, and the trend is continuing as NAS devices mature and offer SAN connectivity, higher capacities, better performance, and high-availability features.

"The main benefit of running a database on NAS is simplicity. Letting the NAS box do the data management is easier than having the database deal with it directly," says Steve Duplessie, senior analyst at the Enterprise Storage Group consulting firm. "However, it's a religious conversation, and don't expect people to dump their SANs anytime soon."

Analysts say that NAS is a cost-effective alternative for databases, especially if no SAN infrastructure is already installed.

"Compared with the complexity and costs of establishing even a simple Fibre Channel SAN for a two-node Oracle database environment, the ease of deploying a NAS appliance for the same task is compelling," says Brad O'Neill, senior analyst with The Taneja Group consulting firm.

As with any application, using NAS instead of a SAN means sacrificing some of the tool sets common to SAN environments, says O'Neill. But in smaller database deployments the SAN functionality will not be missed, he says.

"The pressure on IT budgets has been a boon for NAS in lightweight and departmental database deployments," says O'Neill.

However, running a database on NAS is not without challenges, and analysts caution users to carefully review all options. Analysts recommend using SANs for large-scale transaction-intensive applications, but they are split on when it is appropriate to use NAS.

In a recent report, the META Group research firm advises IT organizations to thoroughly consider which database application characteristics are appropriate for NAS.

"We believe the critical question for IT organizations is not whether certain database applications can be deployed on NAS systems but whether they should be," writes META Group analyst Rob Schafer in Database on Network-Attached Storage: Choose Wisely. The report was sponsored by EMC.

META's research indicates that early deployments of NAS-hosted database applications have identified the following parameters for meeting reasonable service levels:

  • Most NAS-based database deployments are less than 400GB. Less than 10% exceed 500GB. The typical database size ranges from 50GB to 250GB.
  • Most have 250 to 350 concurrent users. Less than 5% are in the range of 500 concurrent users.
  • I/O rates (assuming a 1Gbps transport) are less than 100MBps.
  • Response-time service levels (host to storage) are usually more than 15 milliseconds.

The report also recommends database application candidates for NAS hosting. These include recursive database testing; content serving/caching; centralizing data for backup/recovery purposes; and database applications using binary large objects.

Overall, the optimum database-on-NAS deployment would have a relatively small database size and relatively low I/O performance requirements, reports META.

But not all analysts and vendors agree with META's conclusions.

For example, Duplessie cites Network Appliance customers' deployments of large databases on NAS. Also, he believes that far more database applications can run on NAS than META suggests.

"For large-scale, high transaction rate database applications, we still recommend block-based SAN storage, but for 90% of database applications NAS is more than adequate," argues Duplessie.

Network Appliance also takes issue with META's findings. "NAS is not limited by the architecture from a performance or scalability standpoint," says Puneet Pandit, director of marketing for Network Appliance.

Network Appliance claims that 35% of its total revenue is associated with databases running on its NAS filers. Pandit says that NetApp customers have been running databases on NAS for six years, and the company has been partnering with Oracle and IBM for database certification for the same amount of time.

"We have many customers that have multi-terabyte, single-instance huge databases on NAS architectures," says Pandit. For example, Pandit says that Southwest Airlines is running its mission-critical online reservation system on Oracle databases and Network Appliance's NAS systems. In fact, Southwest runs a 1 petabyte Oracle database on NAS.

In addition to relatively low cost, there are other advantages to using NAS for databases, according to Pandit. The simplicity of NAS architectures can allow for easier and faster backup and recovery, and snapshots provide high availability. For example, users can create high-availability environments using Oracle's real application clustering (RAC) architecture and Network Appliance's snapshot technology.

EMC is also pursuing database-on-NAS opportunities. An EMC-Oracle partnership, which started in 1995, recently included the two companies' first database-on-NAS service—the first time that EMC offered database-on-NAS capabilities for the midrange market.

EMC launched the "Oracle Database with EMC: Accelerator for NAS" service, which allows customers to rapidly deploy Oracle databases on EMC's Celerra NS600 NAS systems.

"In the past, EMC was not a proponent of deploying databases on NAS," says Tom Joyce, EMC's senior director of NAS product marketing. "We spent most of our efforts dealing with the high-end, and high-end database applications in the past were primarily a better fit on SANs than on NAS," he says.

However, EMC saw different needs in the midrange, where fast deployment often takes priority over high performance. In addition, the midrange market often cannot afford the connectivity costs of Fibre Channel SAN ports and host bus adapters (HBAs). But EMC still touts SANs for databases that need the highest availability and performance.

"However, if you've got departmental or smaller, or less-critical, database applications where there's a benefit to faster implementation, that's where it might be appropriate to put it on NAS," says Joyce.

EMC stands behind META's report, but believes the database-on-NAS parameters are flexible.

"It's possible to do huge data-bases on NAS, but in that space customers tend to look at consolidating onto larger servers and a SAN becomes a natural option," says Joyce.

The average Oracle database is only between 50GB and 80GB. And, small database applications make up a much larger portion of the market than high-end databases.

A number of other NAS vendors offer certification of their filers with databases. For example, BlueArc is currently certifying its NAS systems with Oracle databases. According to company officials, 8% to 10% of BlueArc's customers use Oracle or SQL Server as the main application on the company's SiliconServer NAS systems.

Like Network Appliance, BlueArc officials do not agree with some of META's parameters for running databases on NAS, claiming that their NAS systems are actually faster than SANs. "We could offer I/O rates in the range of 200MBps, which is double what META lists," claims Geoff Barrall, CTO and executive vice president at BlueArc.

Barrall suggests that running databases on NAS brings several advantages, especially snapshot technology, which, among other benefits, allows for much faster recovery of data. "Databases are designed such that the database server itself holds a lot of the data in memory. If you do synchronous replication just on the storage alone then chances are when you have a crash you'll lose some data; with snapshots you can be absolutely certain the database is safe," he says.

Procom Technology's NetFORCE NAS systems are certified with Oracle 8i and 9i RAC. Most of the demand for database-on-NAS products comes from Oracle customers, says John Hamrick, Procom's director of marketing.

Procom's high-end systems use a NAS gateway accessing a back-end SAN, where a chunk of block storage is dedicated to Oracle, SQL Server, or Exchange. Hamrick says that the combination of a NAS gateway and a SAN is becoming increasingly popular among the company's users.

While the options for deploying a database on NAS are expanding, there are still several issues to consider, such as which NAS device to use, database requirements, performance, and scalability, says Randy Kerns, a senior analyst with the Evaluator Group consulting firm.

"Not all NAS devices are created equal," says Kerns. "Some have larger file systems, global file systems, better scalability, different lock mechanisms, etc. Performance is of concern especially as the database gets larger with a greater number of accesses. You need to understand the requirements and then see what systems make the grade."

It would be very difficult to set exact parameters such as the number of users or database size because there are many variables that change the performance characteristics of the different NAS systems available, adds Kerns.

In some cases, TCP/IP acceleration via offloading can make a big difference in performance.

"Simple answers won't work here. It requires homework: Understand the requirements and evaluate the competitive alternatives," recommends Kerns.

Next month: Microsoft weighs in on the database-on-NAS controversy.


Comment and Contribute
(Maximum characters: 1200). You have
characters left.