Today, SAN and NAS platforms routinely exist side by side and can often be interconnected with each other in order to share their respective benefits. A NAS gateway can bring NAS functionality to the SAN, allowing the gateway to serve files. In other cases, you may find converged storage platforms providing both a SAN and NAS interface and allowing the storage platform to operate in either environment. However, NAS integration is not always appropriate and storage administrators must use care when connecting SAN and NAS.
Best Practice No. 1: Examine the extent of, and need for, convergence
The choice to integrate (and how much to integrate) should be driven by your particular storage needs and convergence goals. A SAN-centric environment with relatively light NAS needs would benefit from a file server connected to the SAN through a NAS gateway. Conversely, a NAS-heavy environment with a limited SAN deployment may benefit from eliminating the SAN entirely. Experts note that applications, like Exchange or an Oracle database management system, can potentially run fine from NAS. When the mix of NAS and SAN is closer to 50/50, don't be afraid to maintain separate infrastructures or limit the level of integration between the two infrastructures.
Practice No. 2: Consider the availability of multiprotocol storage systems
The storage industry is moving toward a single system that can support both file and block access. This type of system, which is often called multiprotocol or unified storage, allows applications to use file systems for storing data and perform block-based I/O. NAS gateways are likely to be the preferred choice to merge separate NAS and SAN systems that are already deployed in the infrastructure. However, unified storage platforms may be preferable when integrating NAS and SAN in new deployments, colocation facilities or regular technology refreshes.
Practice No. 3: Ensure that storage management tools can handle a mixed environment
Any NAS/SAN integration should include an examination of management tools to handle administrative tasks within a mixed storage infrastructure, such as resource allocation and data migration. The objective is to simplify management tasks by reducing the number of tools, but it's important to test any tools in advance. "We're seeing more multiprotocol storage," says Greg Schulz, founder and senior analyst at the Storage IO Group. "But if you're coming through a NAS device for block-based storage, you might be paying a performance penalty in exchange for all those management features."
Practice No. 4: Opt for systems that minimize disruption
Emerging storage systems are more tolerant of changes and additions, but disruptions can still occur. When merging NAS into a SAN, it's important to gauge the impact of storage changes on performance or availability. Ideally, adding or redeploying storage should result in minimal (if any) disruption, but it will ultimately depend on your storage infrastructure and application demands. Once the effect of change is understood, you can modify internal practices to streamline the change process.
Practice No. 5: Ensure that necessary features are added or maintained
Bringing two disparate storage platforms together does not guarantee that similar features will work together or that a feature available in one platform will be available in the other. For example, a SAN storage infrastructure may support storage tiering, but NAS might not support tiering. Verify that necessary features are available and continue to operate together.
Practice No. 6: Seek out newer NAS gateways that offer high availability and scalability
Older NAS gateways cannot provide high availability or significant capacity scaling because they were tightly coupled to the data being processed. This prevented multiple gateways from accessing the same files within a given pool of storage. Clustering and metadata server schemes could work around these issues and allow simultaneous file access, but this usually added complexity and cost to the NAS gateway. Use NAS gateways that can access the same files simultaneously. This supports load balancing for better performance and failover capabilities for high availability, two valuable enterprise features when using multiple NAS heads. Also opt for NAS heads that can support expanded file services on the SAN, often by integrating the NAS file system with the SAN volume manager. Otherwise, the NAS remains a logical "island" even though it may be physically interconnected with the SAN.
Practice No. 7: Be concerned with data protection capabilities
Older NAS gateways cannot generally perform advanced data protection tasks, such as looking into a SAN fabric to execute snapshots or replicating file volumes across the SAN. Look for NAS heads that provide native data protection features that can interoperate with the SAN. These features are already available through software tools. For example, EMC Corp. NAS gateways, such as the Celerra NS family support standard backup software, such as EMC NetWorker, Symantec Corp. NetBackup, CommVault System Inc. Galaxy, Hewlett-Packard Co. (HP) OpenView, Atempo Inc. Time Navigator or IBM Tivoli Storage Manager (TSM). The Celerra gateways also include data protection software tools ,such as Celerra FileMover for archiving and Celerra Replicator for file replication.
Practice No. 8: Look for advanced file services in the NAS gateway
Intelligent policy features, such as those seen in storage resource management (SRM) tools, are emerging in NAS gateways -- using policies based on file metadata, such as date, location, business group and access frequency.These criteria allow file data to be moved to its appropriate location on the SAN, then be migrated, replicated, or staged for backup. Experts suggest that such features should ultimately be integrated with SRM tools for infrastructure-wide provisioning, capacity planning and data protection capabilities. For example, a converged NAS/SAN system might migrate infrequently used files to nearline disk but perform the migration as a background, rather than a manual task.
This was first published in November 2007