A Storage Area Network is a high-speed special-purpose network or subnetwork that connects various data storage devices with associated data servers on behalf of a larger network of users. Typically, a SAN is but part of an overall network of computing resources for an enterprise. A SAN is usually located in relative proximity to other computing resources, such as databases and file servers, but might also extend to remote locations for backup and archival storage. These remote locations are traditionally connected via wide area network carrier technologies such as asynchronous transfer mode (ATM) or Synchronous Optical Networks (SONET).

It is very important to understand that the SAN is more than just the chassis that contains the disks. It includes the RAID controllers for the disks, the Fiber Channel switching fabric, and the Host Bus Adapters that reside in the data servers. SANs are traditionally connected to hosts via Fiber Channel. Although it can be fairly easy to support dual arbitrated fiber loops in a corporate environment, keep in mind that one of the primary benefits of SAN is the ability to do block-level mirroring to another SAN. If this SAN is located remotely, up to 1,000km away with current Fiber technology, a company needs to have fiber between the two locations. A fiber connection across those kinds of distances can be quite expensive.

SAN technologies excel in the area of disk performance. Fiber channel networks regularly push 2GB/sec of throughput. Although SCSI technologies can move data at up to 320MB/sec, they are limited to less than 25 feet of distance. SAN, not unlike SCSI, is seen by the host system as RAW disk. This is also referred to as a block-level technology. In the past, database applications required block-level access to the disk as well as the “near 0 latency” offered by SAN.

Network attached storage (NAS) is a hard disk storage technology that uses its own network address rather than being attached directly to the host computer that is serving applications or data to a network’s users. By removing storage access and its management from the host server, both application programming and files can be served faster because they are not competing for the same processor time. The network-attached storage device is attached to a local area network via Ethernet and given an IP address. File requests are mapped by the host server to the NAS device.

Network-attached storage consists of hard disk storage, including multidisk RAID systems, and software for configuring and mapping file locations to the network-attached device. NAS software can usually handle a number of network protocols, including Microsoft’s Internetwork Packet Exchange, Common Internet File System and NetBEUI, Novell Netware Internetwork Packet Exchange, and Sun Microsystems Network File System. Configuration, including the setting of user access priorities, is usually possible using a Web browser though many NAS offerings require command line configuration. Most NAS manufacturers include specialized software for allowing specific applications such as SQL or Exchange to take advantage of special functions provided by the NAS. These functions include things like mirroring, failover, automated recovery, and snapshotting.

NAS has the advantage of using existing Ethernet technologies that are much less expensive than Fiber technologies. With the availability of 10GB Ethernet, NAS is able to compete with Fiber Channel–based technologies even with the added overhead of Ethernet over Fiber Channel.

Direct Attached Storage (DAS) is the traditional “local disk” that most administrators are accustomed to. Technologies like IDE and SCSI are used to connect drives or RAIDs to the host computer. Direct Attached Storage has many advantages in the area of performance and cost. With SCSI technologies like Ultra 320, which can transfer 320MB/sec of data across the bus and controllers with large amounts of cache memory, DAS is well situated to provide fast and stable disk performance. The disadvantage of DAS is that the management load of each of these DAS subsystems increased linearly with the number of servers. This can eventually become unwieldy as there is a lack of centralized management.

With the advent of Serial ATA and Serial ATA RAID controllers, IDE devices are becoming more and more viable for systems that need fast access to large amounts of data that won’t see huge numbers of transactions. Systemlike backup servers that will cache to disk before spooling to tape can benefit from the speed and low cost of Serial ATA devices. IDE drives almost always lead SCSI drives in the area of size and are always less expensive. IDE RAID controllers offer excellent performance at much lower costs than their SCSI equivalents. IDE-based RAID controllers don’t handle large numbers of requests as well as SCSI-based RAID controllers. IDE-based RAIDs are still limited to four devices. This isn’t always an issue as SATA drives of 250GB or more are commonly available. A 1 Terabyte SATA RAID can be built for well under $1,500. With throughput of over 180MB/sec, Serial ATA RAID can be a very tempting DAS technology.

The first phase of any good project is an in-depth analysis of the environment and its needs. In the case of Storage Systems it is critical to identify any systems with special requirements. This would include systems that require multiple layers of redundancy, systems that are under extremely tight Service Level Agreements, and systems that cannot tolerate a loss of data.

Another key area to understand is the capacity requirements of the enterprise. If an investment is going to be made in storage it is a good idea to plan for several years of growth. Look at the number of servers in the environment. If additional servers have been added simply because that is the way things were always done, it is time to look at shifting the philosophy to doing things because they are the right way to do them.

Storage technologies can be very confusing. In most situations, valid arguments can be made for using any of the available technologies. This is a situation in which it makes a lot of sense to get your vendors involved. Contact your potential vendors and let them know what your storage requirements are. Often times they have worked with other companies with similar needs and can provide valuable insight into what worked and what didn’t. Given the costs of a large storage system, you can’t afford to do it wrong.

After you have an idea of what you’d like to implement, find out if there are reference accounts that you can contact to determine if they were happy with the solution they implemented. Some companies will try to get you to commit to the latest greatest versions of their software and firmware. Large storage environments are a big investment and business processes will depend heavily on it. Ensure that you are implementing a stable and well-tested solution.

After you have determined the needs, explored the options, and come up with a plan, the real fun can begin. Any solution that will become part of the critical path of business must be developed and tested in a controlled lab environment. This is the part of the project where policies and procedures start to take form. Practice runs of mirroring, failing over of resources, and recovery of systems will ensure that the solution will be able to support the needs of the company.

This development phase will identify several requirements that are not usually thought of during the planning phase. Most specifically these requirements are in the area of facilities. Most SAN devices are fairly large. An EMC Symetrix and Connectix, for example, will take up a full rack each. With heat generation more than 3,000BTUs, HVAC resources will need to be considered. Also keep in mind that most SAN and NAS solutions require 220V to run them. Ensure that planned data center locations have appropriate space, cooling, and power. Power should include not only the standard AC feed, but battery backup as well. Be aware of any special requirements of the SAN or NAS. Some SAN devices on the market will void their warranty if they are placed within five feet of any solid objects.

After the solution has been well tested in the lab, it’s time to break it in limited production. Even extensive testing in a lab cannot always fully test all possible scenarios that a storage system will see in production. The best way to try to break the solution is to let users have access to it. Rolling the storage solution into a limited Pilot program will enable you to gather feedback about the performance of the system as well as feedback on the policies and procedures that will support the system. It’s also a great time to get support staff trained on a system that they will likely end up supporting in full production.

After the system has gone through a final feedback loop from the pilot phase it is time to put the system into production. After following these steps you should have a well thought out solution that meets the current and future needs on the company. The solution will have been well tested and will encompass tweaks and improvements that came from the various testing phases. Performance metrics will be known and monitoring points determined. Now the company can begin to enjoy the benefits of the new storage solution.

All the high-speed disks in the world won’t amount to much if you can’t get the data to and from the servers quickly. In a NAS environment, the network itself is the biggest concern for performance. Most NAS devices on the market use very fast heads that are literally dedicated computers with high performance processors and loads of memory. With SCSI RAID controllers on board, they can easily saturate multiple 100MB Ethernet connections. Attaching such a device to a low-end switch would result in the NAS running in an extremely restricted manner. Strongly consider using a switch that will enable you to use a gigabit connection.

Consider creating a separate network for the NAS environment. Say, for example, that the NAS is going to support a number of Exchange servers. By multi-homing the Exchange servers, they would have one Ethernet connection that faced the users and provided connectivity to the mail clients, whereas the other interface would be dedicated to NAS traffic. This would allow each interface to run unfettered by the traffic associated with the other network. This also enables you to upgrade only a subset of the network to improve performance and save money. The traffic of the database transaction back to the NAS device by Exchange would be much greater than the traffic associated with users viewing their mail because the traffic that would normally go to the local disk would now be traveling across the Ethernet via the Virtual Disk driver that connects the NAS to the Exchange server.

When selecting network gear for a NAS out-of-band network, focus on packets per second. Whenever possible, build this NAS network with multiple switches that are cross-connected. Connect each server to both switches with the NICs in a teamed mode. This will not only add bandwidth but also will create redundancy for the network layer. Odds are if the application warranted the use of a NAS device, it deserves redundancy at the network level as well.

Simple physics tells you that you’ll get improvements in performance as you add more disks to an array. Because each drive’s read/write head can operate simultaneously you get a fairly linear improvement as drives are added. NAS and SAN offer the advantage of dynamically increasing the size of a volume without taking the volume offline. This allows for the addition of even more spindles.

Although it’s possible to later resize a volume from a NAS or SAN, you must be careful not to over subscribe the device. Devices that support snapshots of the data reserve twice the volume size that they claim for capacity. So in order to make 100GB available to a server, the NAS would reserve 200GB on itself. This ensures that it is able to complete all transactions. This function can be disabled on most devices but it is not recommended. This removes the protection from oversubscription of the disks.

Distributed File System has come a long way with Windows Server 2003. The ability to pre-stage data, the ability to mirror the DFS root, and improvements in control of replication topologies have all helped companies to adopt and take advantage of Distributed File System. Although things have gotten better, many administrators still find that there are too many limitations to the functionality of File Replication Services. FRS can’t deal properly with roaming profiles and it often replicates data unnecessarily. For example, most antivirus products flag files that they have recently scanned. FRS will misinterpret this as a modification to the file and will queue it up for replication to all of its partners.

Many administrators are finding that the native replication functions of NAS and SAN devices are a much better way to maintain replication for DFS replicas. By having Windows Server 2003 servers mount those replicas and present them as nodes in the DFS tree, they are able to achieve enhanced usability in their DFS structures. This adds an additional layer of redundancy because NAS or SAN mirrored replicas are automatically presented to users if a local copy were to fail.

Most administrators are very familiar with the Logical Disk Manager that comes built into Windows. This is the interface that is regularly used to mount new disks, create partitions, and format drives. Administrators who are a bit more advanced have no doubt learned the benefits of being able to mount disks to folders rather than drive letters. Very large powerful servers that serve multiple tasks no longer have to worry about running out of drive letters.

Most SAN and NAS devices on the market offer management plug-ins that enable them to be managed through the existing Logical Disk Manager. Through hardware abstraction the remote disk is made to look like a local disk. This enables you to perform much of the management of the remote resources through an interface that they already know. This reduces the requirements to retrain administrative staff on a new technology.

Remote Storage, the Windows version of Hierarchical Storage Management (HSM), enables you to increase disk space on a server without physically adding more hard disks. Remote Storage automatically moves data back and forth between high-cost, faster disk drives and low-cost, high-capacity storage media. This traditionally meant moving data from Direct Attached Storage to either a lower performance server or a very low cost but high capacity storage media such as a tape library or rewritable DVD or DC media. Remote Storage monitors the amount of space available on local NTFS volumes, and when the amount of free space dips below the low water line, it transfers eligible files from the primary storage to the secondary storage. Users can still see and access archived files but they are actually seeing links to the files stored on the lower cost media. This frees up storage on the file server without requiring the purchase and installation of additional hard disks. The Remote Storage service also works with the Removable Storage service to access any removable media used for remote storage.

In an environment that uses NAS or SAN for storage, this concept can be moved up one tier. In most cases, the NAS or SAN device will replace a number of servers. These are servers that would normally be retired. Rather than scrap all the servers, you can take a subset of the servers and salvage the disks from all the systems and distribute them across the remaining servers. Those servers would be relegated to storing low demand data only. This would enable you to still lower the overall number of servers in the enterprise that require management.

Optionally these “lower tier” servers could be low-end servers with IDE RAID devices attached to them. Given the current prices and sizes of IDE drives, a 1-TB server could be built for well less than $5,000. Because it wouldn’t be holding “primary” data, it would be acceptable to take the hit in performance and reliability that comes with IDE drives. This could allow for an environment where high demand and highly important data could live on redundant and high performance SAN/NAS devices. Data that hadn’t been accessed in some time could be moved to the IDE RAID systems where the data would still be retrieved quickly. Data that hadn’t been accessed in long periods of time would be moved to tape or rewritable media for long-term storage.

Many administrators have faced the challenge of dealing with narrow windows of opportunity for performing backups. Given a choice, every department would request that their systems only be backed up between 2 a.m. and 3 a.m. so that they wouldn’t suffer a performance hit while users might be accessing them. This is especially difficult in environments where systems are used globally. The challenge with narrow backup windows is that data cannot be spooled to tape fast enough to meet the time commitments. One of the easiest ways to improve this performance is to perform the remote backups to disk.

By using a NAS or SAN device to buffer the backups, you create an environment where the NAS or SAN becomes the backup device. Backups are written directly to the NAS/SAN at impressive speeds. Outside the backup windows, the data is backed up from the NAS/SAN to tape for long term storage. The added benefit of this model is that 90% of restore requests are for data from the previous evening. By having that data on disk on the SAN/NAS, the restore process is also much faster than it would have been from tape. SAN devices often support what is known as serverless backups. This means that the SAN itself controls the tape device and writes the data to it without the need for a traditional backup server.

Disk quotas were introduced as a long overdue feature in Windows. For a long time, you had to worry about users storing inordinate amounts of data in their user directory and filling up the entire volume. Any other users whose home directories were on the same volume would suffer through no fault of their own. In an environment that makes user directory space available on a NAS or SAN will appreciate the safety that comes with being able to enforce quotas through Windows Server 2003. Imaging having to explain to your management that your brand new 4-TB SAN is already full because your users have filled it with “personal” data.

One of the greatest concepts ever put into use is the OSI Model. In a nutshell, the concept is that if you have a series of layers that work together than anything that can be abstracted to look like one of those layers will automatically work with the rest of the layers. In the case of SAN or NAS, a driver is used to make the remote storage look just like regular attached storage. After that is done, the rest of the system will treat the abstracted drive like another locally attached drive. This means that technologies like EFS will automatically work with the remote disk. Users can continue to encrypt data on the SAN or NAS and administrators can continue to manage EFS keys and agents the way that they always have.

When implementing a NAS or SAN solution in a Microsoft Exchange environment, there are many different interpretations on the best way to implement the solution. Some of the recommended best practices are as follows:

A Microsoft SQL environment can leverage NAS and SAN technologies to improve storage management and storage solution implementation. Some of the recommended best practices for implementing a NAS or SAN device in a SQL Server environment are

When implementing a NAS solution, some of the technological solutions that can improve operational performance need to be taken into account. As an example, the following fictitious organization with the following requirements for a SQL Server can be modeled for a NAS configuration:

Based on the statistical information for this organization, the resulting analysis and projections can be as follows:

File servers are based typically on small individual files as opposed to large blocks of structured information as in a SQL or Exchange environment. Best practices found in creating a NAS or SAN environment for file servers are as follows:

When configuring NAS or SAN devices as part of a backup, fault tolerance, disaster recovery, or business continuity structure, the configurations and optimization are much different than for file servers or database servers because the information is primarily stored for redundancy purposes. Some of the best practices for building a backup system NAS or SAN environment are as follows:

Building a NAS or SAN environment in a Windows environment can leverage Active Directory and be integrated into the Directory for authentication, security, and management purposes. Some of the best practices for integrating Active Directory for NAS and SAN devices are as follows:

Although a service that runs on Windows 2003, Windows Terminal Services operates similar to multiple workstations as opposed to a limited number of database servers. Some of the best practices in optimizing Windows Terminal Services in a NAS or SAN environment are as follows:

Some network solutions require certain network functions to load upon server boot-up whereas other applications are independent of server boot functions. When configuring a NAS or SAN device for system boot-up, some of the best practices for configuration are as follows:

Exchange servers were traditionally sized based not only on performance potential but also on the time needed to recover a system. Administrators knew that if they had a four-hour Service Level Agreement for system recovery they could count on using half that time to recover data from tape and half that time to perform the recovery tasks. This meant that they could only have as much local storage as they could recover in two hours. So if a backup/restore system could restore 16GB of data in two hours and each user was allowed 100MB of storage, the maximum number of users on the system would be 160. For a company of 1,600 users, this would mean 10 Exchange servers would be required to support the four-hour SLA.

By placing the mailbox stores onto a NAS or SAN device that can be mirrored and snapshotted, the recoverability time for a 16GB database would drop to mere minutes. Now the bottleneck would become the performance of the server itself and possibly the IO rate of the NAS or SAN. Odds are that the systems that had been purchased for the ability to support 160 users would be dual processor systems with a Gig or two of memory. By reducing the server count to two and fully populating those two systems with memory taken from the retired systems, the two systems with NAS- or SAN-based mailboxes could easily support the 800 users each and still meet the four-hour recovery time required by the SLA.

This would result in the reduction of eight Exchange servers which would free up OS licenses and hardware as well as reduce the effort required to manage the data center.

Most companies grow their file server environment in an organic manner. This is to say that as different groups in the company come up with needs for data storage, additional file servers are brought up. This can be an expensive process in that each of these file servers requires not only hardware but also an operating system, antivirus software, management software, space in the data center, facilities like cooling and electricity, and many other expenses. Users take storage for granted because drive prices are relatively inexpensive and they believe that disks can just be added and added forever so that they can fill it.

This results in a difficult to manage environment for the IT professional. When system patches become available it can be quite an event to ensure that potentially hundreds of file servers are up to date. Companies that enforce a life cycle for their servers find themselves replacing more and more servers each year.

NAS and SAN devices offer a solution to this problem. By consolidating the storage of data and presenting this data to the user community through a smaller number of high-performance file server clusters, you can ensure that users have reliable access to the files they need. At the same time, you can greatly reduce the management overhead of the vast number of servers and reduce costs across the board.

In environments where file servers are brought up simply to provide better access for local users, you can leverage technologies like DFS and mirroring to make data available to each location. Through DFS and site locality, users can ensure that they are reaching the closest copy of a file without any sort of user interaction. By leveraging a SAN or NAS at each major location administrators can still reduce the number of file servers at each location and maintain the same if not better level of support.