Analyzing scalable NAS architectures

There are many ways to manage NAS capacity growth while meeting performance requirements.

By Jerome Wendt

What does your NAS environment look like? If “disparate NAS islands with no centralized architecture, management, or upgrade path” is your response, you’re not alone.

With more organizations looking beyond traditional NAS to consolidate, centrally manage, and optimize their NAS infrastructures, users should consider more than just supported protocols and total storage capacity when consolidating NAS.

There are a variety of methods for scaling NAS architectures, and users need to understand which one best suits their environment and positions them for the future.

Comparing NAS scalabillity options
Click here to enlarge image

Users can scale their NAS infrastructures using one or more of the following methods:

Using traditional NAS, NAS heads (nodes) are deployed in active-active or active-passive configurations and support internal storage. Capacity is added by installing internal disks or deploying new heads with internal storage;

NAS gateways combine multiple physical NAS heads using either a clustered or parallel file system to form and present one logical NAS head to servers. Configurations typically range from two to eight nodes, and capacity is added by connecting and configuring more nodes and external storage;

Parallel file systems introduce symmetric processing that spreads data across multiple storage devices and allows multiple servers running parallel applications to access data at the same time while avoiding performance bottlenecks; and

Clustered nodes are servers or nodes that contain internal CPUs and storage and use a clustered file system to present one logical NAS head to servers. Users grow this architecture by adding more nodes to the cluster.

Across this spectrum of architectures, vendors may employ one or more approaches in their implementation with each carrying its own sets of benefits and risks. Approaches based on traditional NAS architectures are easier to understand, implement, and configure, but have limitations on storage capacity, and it may be difficult to upgrade and manage data and capacity across multiple filers.

NAS gateways better address back-end capacity growth and NAS head upgrade paths, but may involve tradeoffs between performance and management.

Clustered nodes take advantage of economical networking, server, and storage components, but do not permit users to re-use existing storage systems.

Parallel file systems allow any node to access data on any back-end storage device, but may require the deployment of agents on client servers. In addition, parallel file systems may have management overhead.

Traditional NAS

Most organizations are best acquainted with traditional NAS architectures. Deployed as self-contained units that house NAS heads with Ethernet interfaces on the front-end and internal storage on the back-end, they are often selected for their ease of setup, implementation, and interoperability with both Unix and Windows servers.

However, the limitations of traditional NAS architectures may become apparent as users are added, file systems and storage requirements grow, departments share resources, and organizations merge. To address these concerns, vendors offer a number of options.

Some vendors support a mix of different types of disk drives within the same storage array to address different applications’ performance, capacity, and cost requirements. For example, Network Appliance’s FAS6000 and Pillar Data Systems’ Axiom systems allow users to mix-and-match high-performance, high-cost Fibre Channel disk drives and high-capacity, low-cost Serial ATA (SATA) drives within the same physical frame.

Another step vendors take to accommodate growth is to support thin provisioning. This technology only allocates back-end storage as it is used, even though the file system believes it has more capacity available. For instance, Network Appliance’s WAFL file system may be assigned 1TB of storage, but if it only needs 200GB, then only 200GB of back-end storage is used, freeing up the other capacity for use by other file systems on that NAS head.

However, these steps may still fall short of meeting some users’ requirements. For instance, total capacity numbers are usually based on the use of slower, higher-capacity SATA drives, so if users need both high performance and high capacity, then a second NAS filer may be required.

Using techniques like thin provisioning may solve an immediate problem but may introduce other headaches longer term. While managers gripe about unused disk capacity, that situation is often easier to manage and understand than the more abstract concept of thin provisioning. Implementing thin provisioning also requires users to manage the software, be adept at forecasting future capacity requirements, and have the freedom to purchase and allocate more storage when it is needed.

Traditional NAS approaches also may fail to address other issues that surface as organizations consolidate or merge their NAS infrastructure. For example, IT organizations may want to use storage capacity that resides on existing storage arrays, which is not possible with most of the traditional NAS approaches. Different applications will have different file access patterns that traditional NAS filers may not be designed to handle. And with the growth of unstructured data occurring at annual rates of 30% or more, upgrading or replacing NAS filers is not always a viable option. To address these challenges, some users may need to look at other NAS architectures to grow their infrastructure.

NAS gateways

NAS gateways overcome some of the restrictions associated with traditional NAS architectures. Gateways may offer features such as

Use of the same or similar file systems used on traditional NAS systems;

64-bit file systems that can manage larger amounts of external storage;

Virtual servers;

Snapshots and replication; and

Support for multiple types, and tiers, of external storage.

The file system included with the NAS gateway is an important initial consideration, and administrators should prioritize features differently according to their specific environments and applications. The key features for users to evaluate often hinge on whether the NAS implementation is primarily a consolidation effort or a new install, as well as the types of applications that it will host.

In consolidation efforts, priority features might include the ability to interact with traditional NAS heads; how the file system handles user authentication and global namespaces; whether the file system supports an anti-virus feature and 64-bit code; and what types and tiers of external storage it supports. For stand-alone installs, these factors may still apply, but a larger percentage of the decision will hinge on the type of applications the gateway supports than on how it fits into the existing infrastructure.

For organizations looking to consolidate multiple existing NAS filers, an often-overlooked task is to verify that new NAS gateways can replace existing NAS filers, not just supplement them. With individual departments and business units often sensitive about the nature of the data they support and who can access it, choosing NAS gateways with the same operating system may be a factor. For instance, Network Appliance’s GF980c and newer V6000 series gateways allow administrators to interact with NetApp’s traditional NAS200 and NAS3000 series filers to perform similar types of replication and management features.

Another feature that users should prioritize when they are consolidating file servers is how well the gateways integrate with existing authentication approaches. With more organizations standardizing on Microsoft’s Active Directory, the ability for NAS gateways to integrate natively with Active Directory using Kerberos may be important to permit existing file permissions and security schemes to migrate smoothly onto the new NAS gateway.

Two other NAS gateway features to consider are anti-virus support and a 64-bit file system. The need for anti-virus support will hinge upon the deployment environment. For users planning to introduce a gateway into a general-purpose, multi-user file server environment, anti-virus support may be a requirement.

The need for a NAS gateway to support a 64-bit file system is less intuitive. A 64-bit file system increases the total number of storage devices or volumes that a file system can reference, compared to a 32-bit file system. Users should weight this feature according to how much external storage they expect the NAS gateway to manage. For users who expect a single logical gateway to manage more than 20TB, a 64-bit file system may be critical.

Other major software features to consider in the selection of NAS gateways include support for snapshots and replication. While most gateways offer these capabilities, they are sometimes options that have to be licensed separately from the file system that comes with the gateway.

The ability to support different types and tiers of back-end storage is another factor that users should consider in the evaluation of NAS gateways.

EMC’s Celerra NSX is only certified with EMC’s disk arrays, while products such as Hewett-Packard’s EFS Clustered Gateway are certified with virtually any vendor’s disk subsystems, and products such as BlueArc’s Titan 2000, NetApp’s V6000, and ONStor’s Bobcat series work with most Fibre Channel storage arrays.

Scalable NAS file systems

Beyond the features and functions that the different scalable NAS file systems offer, users should also understand the underlying clustered or parallel file system that provides these features and the benefits and drawbacks of each implementation. As users add, grow, and consolidate applications, the underlying file system impacts how large a NAS architecture can grow.

Clustered file systems typically follow one of three designs. The dual-headed architecture offered by Network Appliance’s V6000 or FAS980c, for example, is an active-active configuration that allows either one of the nodes to access data on the back-end storage. While this configuration eliminates some of the management overhead associated with NAS gateway models that support more than two nodes, it can also introduce a performance barrier.

To circumvent this potential bottleneck, many NAS gateway vendors extend their clustered file system to support multiple nodes. Since all nodes are part of the cluster, they all have access to the same data on the back-end, which can provide the following benefits:

It allows administrators to dedicate certain nodes to specific tasks, such as backups or a performance-intensive database application, without impacting performance across the entire cluster;

It alleviates some of the management concerns often associated with consolidation since specific nodes can be assigned to and managed by specific administrators with their own security permissions and access; and

Performance concerns can be addressed by either adding more nodes to the cluster or upgrading existing nodes by removing them and introducing new ones that support faster processors, network speeds, or cache.

Within the different NAS gateway offerings, there are configuration differences that users should be aware of. For example, EMC’s Celerra NSX supports an active-passive non-symmetric architecture, which does not allow all nodes access to all data concurrently. Similarly, ONStor’s Bobcat series supports an active-active configuration among the NAS heads, but also only uses a non-symmetric approach to allow nodes to communicate with the back-end storage.

However, this second clustered file system model may be best-suited for the random access environment typical of most businesses. Limitations introduced by this approach are exposed in environments that use multiple servers to read and write data to the same file through different nodes in the cluster. This exposes a potential drawback to this approach, namely, the requirement to maintain cache coherency across all of the nodes in the cluster and to keep their metadata consistent. Under these circumstances, performance could be negatively impacted.

Users with these types of environments should then consider a third type of clustered file system. PolyServe’s File Serving Utility and Hewlett-Packard’s EFS Clustered Gateway (which is based on PolyServe’s Matrix Server software) address these types of limitations in two ways across the nodes in a cluster. First, this approach uses a distributed lock manager (DLM) that runs on each node in the cluster and ensures all nodes have consistent information about the state of the locks. Second, this approach also includes a lock-caching layer.

Yet not every NAS gateway vendor chooses to use a clustered file system and add more nodes as a way to overcome the limitations of a dual-headed architecture. BlueArc’s Titan 2000, for example, uses both a parallel file system and field-programmable gate arrays (FPGAs) to address performance requirements. The parallel file system on the two nodes maintains the data consistency on the back-end storage, while FPGAs increase performance and can be optimized for specific applications.

Another way that parallel file systems are implemented is in a clustered node configuration. Unlike other architectures that separate NAS heads from the physical storage, this configuration scales by adding nodes that include both CPUs and storage capacity. This process introduces additional processing power into the NAS configuration as the NAS head grows. Examples of vendors taking this approach include Ibrix, Isilon, and Panasas.

Scalable NAS architectures are introducing new ways for users to manage files. While traditional NAS may not be able to address a large IT organization’s requirements, new architectures are emerging to meet those challenges. And while users should not dismiss the risks that accompany implementations of newer architectures, neither should they summarily dismiss them in favor of more-traditional architectures.

Jerome Wendt is a freelance writer and independent storage analyst. He can be contacted at jerome.wendt@att.net. Keith Kinser, systems engineer, also contributed to this article.

This article was originally published on August 01, 2006