In many cases the first choice, a standalone NAS system, makes the most sense. It may be easier to manage two separate storage areas for two separate tasks than to try to integrate the two. That's because, oftentimes, the intended use of file services is very different than the existing use of SAN storage. For example, there may be some call for sequential processing of specific data sets, like in the processing and design industries; in that scenario, many high-end user workstations or even servers need to have access to the same file data in close succession. In such a case, a standalone NAS system would be justified.
Another reason to consider a standalone NAS: The customer may be dissatisfied with their current SAN investment. They may be looking to the NAS system as an easier-to-use alternative. Today's NAS can host databases and virtual servers in addition to normal file-type data. Many customers perceive this as an easier environment to manage and maintain.
The downside to a standalone NAS, though, is that it adds a separate storage area that needs to be implemented, managed and maintained independent of the existing block-based storage. This downside has led many customers to consider a NAS gateway instead.
A NAS gateway is typically a NAS appliance that attaches to an existing SAN. It's essentially a NAS head with no storage; the storage comes from the SAN, and a section of the block storage capacity is assigned to the NAS gateway. The gateway then presents its defined capacity as file-based storage. All future storage management for the NAS is done via the NAS gateway, which may have a different GUI than the SAN. This solution seems to be a logical way to augment an existing SAN with NAS services, even when a customer is looking to move out of SAN technology because they feel that the block-based storage model is too complex.
Despite the seemingly logical path to a NAS, NAS gateways have seen limited success, for several reasons. First, the NAS hardware is relatively expensive compared with additional file servers. While that cost may be acceptable if the customer has a significant need for processing-based file services or wants to move away from block-based storage, for large-scale file sharing, it's often overkill. The second reason is that a NAS gateway doesn't obviate SAN integration chores; the gateway has to be attached to the SAN and have storage provisioned to it, which is especially challenging if the customer is struggling with block-based storage. Finally, once the capacity has been assigned to the NAS, it is in most cases still a different management paradigm for the customer to deal with. As mentioned earlier, the GUI is often entirely different. The net effect is that you have two storage management platforms; they just happen to share the same disk cabinet. Finally, with a NAS gateway, the customer is essentially "turning off" the feature set of the SAN and counting on the NAS gateway feature set for things like snapshot capabilities. That may or may not be an upgrade, depending on which product implements the technology better. In either case, the customer is buying many of the same capabilities twice.
The final option for adding file capabilities to a customer's storage environment is to provide NAS services via a virtual machine in a server virtualization project. While not ideal for a company that has large-scale processing types of operations that need NAS, a virtual NAS may be perfect for companies that need more traditional NAS services but want to stop file server sprawl. There are several NAS products that provide the typical NAS functionality through a virtual appliance. This allows them to leverage the capabilities of the virtual environment for availability and disaster recovery while keeping costs down since no physical appliance is needed.
A virtual NAS is easier to integrate with the existing SAN than a NAS gateway and less complex than setting up a standalone NAS. There is no additional hardware to install and cable, and, assuming that the virtual server infrastructure has already been connected to the SAN, the virtual NAS can leverage that configuration as well as the storage already configured for the virtual host. This means no additional storage management beyond what is already being performed and no additional storage platforms to buy.
The downside is that these systems do use processing, storage capacity and I/O of a physical host, like any other virtual machine. That needs to be accounted for. From a capacity standpoint, a few virtual NAS suppliers can migrate data between tiers of storage and even to a cloud storage service to help manage capacity. But these are extensions of the existing block storage system, not a replacement. Your customer needs to like and want to keep leveraging block storage for databases, email and virtual machines.
Of these three possible options, your recommendation will depend on the needs of your customer. Assuming they like their current SAN and they need file services that are more powerful and less resource-consuming than a general-purpose OS-based server acting as a file server, there is a lot to like about a virtual NAS. On the other hand, if they have a high file processing type of need, like chip simulation or seismic processing, then a dedicated NAS device may be the best solution.
The most interesting project is one where the customer dislikes the current SAN and wants to move to something easier with the assumption that NAS will provide that solution. It is up to you to determine what to do here. Do you try to fix the current system or rip it out and replace it with a new one? We will discuss that in our next article.
About the author
George Crump is president of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. With 25 years of experience designing storage solutions for data centers across the United States, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland, George was chief technology officer at one of the nation's largest storage integrators, where he was in charge of technology testing, integration and product selection. Find Storage Switzerland's disclosure statement here.
This was first published in November 2010