Wednesday, December 2, 2009

The traditional NAS architecture is a single system, often called a NAS head, with one or two storage controllers. The only way to scale the performance of these architectures is to replace the existing NAS head with faster controllers or to add separately managed NAS heads. Since many of these systems are based on off-the-shelf Intel hardware, they’ve been able to maintain acceptable performance by ‘riding the Intel performance wave’, as CPUs have gotten more powerful. While some of these systems can be clustered together, clustering NAS heads is most often done to provide high availability, not enhanced performance. The second NAS head can stand in for the primary but it can seldom share the workload requirements.

These architectures were fine for the traditional NAS application, such as when a file server is accessed by many users via desktops and laptops to read and write files. Although there may have been thousands of users, there was one relatively predictable I/O stream from each and the data being accessed was usually small in size. Also, each user didn’t typically make continuous requests from the NAS device. They accessed a file, worked on that file and then saved that file back; it wasn’t a continuous interaction with the NAS. During the lag time between file access and re-save, the NAS was free to service other requests. In fact, most NAS systems in the file server use case spent a majority of their time waiting for something to happen.

As NAS applications evolve into server virtualization, the use changes significantly. There are two major obstacles to using traditional NAS systems in the virtual server environment. The first is the randomness of I/O requests and the second is the size of data objects being accessed. Instead of 1,000s of infrequent accesses by users, potentially hundreds of virtual machines now access the NAS continuously, with much larger files than typical users requested. Then, as the applications running on these virtual machines hit a peak, load times and storage I/O bandwidth are stretched to the limit, especially in the traditional, dual-controller NAS architecture.

This potential performance shortfall has lead to two typical workarounds, as stated earlier. One is to upgrade the NAS head with faster processors or to add more NAS heads. The first solution, additional processing power, works as long as the maximum available processing level will still scale to meet the eventual I/O demands of the virtual server environment.

The first problem with this approach is that it’s a waste in capital and the storage manager is forced to go through the upgrade process by switching out NAS heads. While most NAS vendors today do an admirable job of being able to plug the old storage into the new NAS head in a non-destructive fashion, there is still often downtime required for the upgrade. There’s also the problem that the trade-in value on the old system is seldom what was paid for it. There’s almost always an extra cost to move to the new level of performance and to discard the old NAS head.

The other workaround to avoid this problem is overbuying performance upfront. This is also a waste of capital. Spending money, today, for tomorrow’s performance is far more costly than waiting until that performance is actually needed. Processing power will only get less expensive with time.

The second alternative is to keep using the current NAS head but to buy another head. This avoids the disposal costs associated with the upgrade and avoids much of the downtime-related issues. There is, however a migration issue, or the time to copy some of the data to the new system. Remember, that NAS heads are IP based, and the migration from one to another is a copy across an IP network which will affect migration time and possibly overall network performance. Further, once the additional systems are in place, there is the issue of managing a new entity on the network. Moves, adds and changes to users, applications, backup and disaster recovery processes must all be made, and these new systems must be managed separately.

Global File Systems, or File Virtualization, are viable options to fix this issue as they allow the data path to be abstracted from the individual systems. This abstraction layer, however, creates metadata overhead as file systems are tracked and translated for the users and applications. Additionally, individual performance, even with a global file system, is still limited to the I/O capabilities of the NAS head. Performance does not scale linearly with additional heads. Finally, data management tasks like provisioning, setting backup policies, DR policies etc. must all be done individually for each NAS head.

All of these stumbling blocks become particularly challenging as NAS is considered to store virtualized server images. These environments tend to grow rapidly and unexpectedly. The cost and time involved in adding and managing additional NAS heads can be of great concern.

An alternative would be to implement a scale-out NAS solution where performance can be increased as the virtual server environment grows. A solution like that offered by Isilon Systems allows for an exacting growth path so that no over-purchase of NAS resources is required. The NAS nodes are added only when they are needed so they’re purchased at the best possible price point for the technology. Each time a node is added, capacity, NAS processing power and NAS bandwidth all increase in a linear fashion. There is no migration or rebalancing that needs to occur.

The other advantage of a scaled out NAS implementation is that it provides a single entity to manage, and if desired, a single, large file system. This means that all data management tasks are now isolated down to one NAS system with one file system, greatly improving the ratio of administrator to storage capacity.

In our next article we will take a deeper dive into scale-out NAS and its use as a storage platform for virtual server images.

George Crump, Senior Analyst