Scalable network storage architectures

Computer Technology Review, August, 2004 by Geoff Barrall

The network storage world has long been polarized into two distinct camps--Network Attached Storage (NAS) and Storage Area Networks (SAN)--with historical limitations of NAS restricting these solutions to specific markets. Customers with performance-sensitive applications or high-growth storage environments have predominantly turned to SAN solutions, finding traditional NAS offerings incapable of meeting business requirements. One of the primary reasons why SAN solutions are deployed for high-performance or high-scalability applications is that SAN solutions utilize hardware-based RAID controllers for data movement, while traditional NAS solutions utilize software running on a general-purpose CPU-based computer which, while more flexible and feature rich, proved far less able to cope during periods of heavy load.

The general-purpose computer within a traditional NAS solution provides a high degree of manageability and value-added features, including snapshots, multi-protocol support, file sharing, etc.--all of which have made NAS the preferred solution for any network storage environment that does not rely upon high-performance or high-scalability, yet traditional NAS implementations fail to scale because they are bound by the CPU cycles their host system can produce. This affects system throughput and as system load and capacity increases, software overhead similarly increases--causing performance degradation and increased latency. As business environments continue to see exponential growth in terms of storage capacity requirements, NAS solutions are failing to keep pace with this growth. As a result, the customer is left with the difficult choice to either add an increasing number of NAS systems, or move to a SAN-based solution.

BlueArc has recognized these scalability and performance limitations of traditional CPU-based NAS offerings, and architected a solution that delivers the ease of management commonly associated with NAS with unparalleled performance and scalability. BlueArc's third-generation SiliconServer, Titan, is the first NAS system to have its file system completely implemented in hardware, designed to eliminate the inherent limitations of CPU-bound NAS, providing an alternative to deploying SAN solutions.

[FIGURE 1 OMITTED]

A Close Look at CPU Architecture

With the exception of BlueArc, every NAS device available to consumers today is implemented using a CPU-based architecture. There is little difference between these and the PCs on your desks. This traditional approach to data delivery is failing to scale, as the software controlling the file system is nearing its algorithmic maximum efficiency and future performance improvements will be incremental in nature, as computer systems tend to scale at around 15%-30% in terms of real end-user performance each year. In fact, these speed enhancements are decreasing over time. In the 2003-2004 period, CPU manufacturers saw performance improvements significantly below that forecast by Moore's Law, as the move from 130nm to 90nm proved more difficult than anticipated.

[FIGURE 2 OMITTED]

In order to create a software appliance that extracts as much capability out of the underlying hardware as possible, one must begin with the operating system itself. General-purpose operating systems are built to be extremely flexible and contain many elements in support of many applications and hardware devices. However, when used as a NAS server, this flexibility amounts to overhead unrelated to the core efficiencies of the server, alongside marginal performance. A superior approach is to instead implement a microkernel, or lightweight operating system, designed for the specific purpose of serving data. Additionally, some software-based data vendors have taken the step of designing a specialized file system, coupled with RAID management, to provide data protection services. These three elements characterize the overall approach to the fastest software-based appliances.

As shown in Figure 1, when a client machine makes a request to the software appliance, every attempt is made to fulfill that request as far through the compute process as possible. The steps include the device driver of the network card initially receiving the request through error checking and translation of the request into the file system interface. However, this is a best effort strategy. In fact, it can only be a best effort strategy, because the CPU at the heart of software appliances is limited to performing only one task at a time. Looking at the simplified diagram, you can see that there are several things competing for time on the CPU:

* Each request from a client competes with every other request

* The file system semantic layer must decode the request

* Error processing may be required for bad requests

* Writes into NVRAM are competing for time

* Writes into the RAM buffer are competing for time

* The block allocation layer must formulate a storage request

* The RAID manager must execute the storage request