| SAN and NAS manufacturers have provided a number of technologies that make it easier to integrate their products with specific software products. Because these products having been available for a number of years , best practices around these implementations have come about and can help you avoid common pitfalls with SAN and NAS usage. Exchange with NAS/SAN 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 : -
Run multiple Host Bus Adapters in each Exchange server with each HBA connected to a different Fiber Channel switch. This will allow for failover if one of the Fiber Channel switches should fail. -
Backups should be performed at the storage group level rather than the mailbox level. Mailbox-level backups are very processor- intensive for the Exchange server. -
Separate logs files from databases onto different drive sets. This will improve overall throughput as well as improve recoverability in the case of a NAS/SAN failure. -
Replicate databases hourly to another device for disaster recovery. Logs should be replicated every few minutes. This will limit potential mail loss to one log replication interval. -
Always use integrated tools if they are available, such as Network Appliance's SnapManager for Exchange 2000. They will greatly simplify management and recoverability of the product for which they were designed. -
Always plan for space reservation on a volume. If the database will grow to 80GB and will have snapshots taken for recoverability, reserve 160GB of space on the device. -
Avoid placing multiple Virtual Logical Disks or LUNs on the same volume. This could result in databases and log files being on the same volume. This would complicate system recovers if the volume were to fail. SQL with NAS/SAN 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 -
Separate database from each other by placing them on separate VLDs or LUNs on different volumes to maximize read/write performance. -
Place databases and log files in separate VLDs or LUNs on different volumes to not only improve read/write performance but to enhance recoverability. -
Run multiple Host Bus Adapters in each SQL Server with each HBA connected to a different Fiber Channel switch. This will allow for failover if one of the Fiber Channel switches should fail. -
Depending on the access pattern, a single hard disk can support roughly 150 I/O operations per second (IOPS). It is important to understand the I/O rate during peak load to estimate the number of disk drives needed to support the I/O load. For example, a RAID group size of eight disks (seven data and one parity) can at most support 7 * 150 IOPS = 1,050 IOPS -
Always take into account database growth to avoid having to constantly expand the volume. When possible, operate with extra free volume space. Maintaining extra free volume space will decrease a possible volume fragmentation rate and will also prevent sudden "out of space" events. When a volume's free space is very limited I/O performance could suffer. 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: -
Initial database size of 80GB -
Database growth rate is estimated to be 15% per month -
Change rate of the current database is estimated to be 15% per month -
Snapshot requirement is four Snapshots per day with a total of 12 Snapshots (three days) -
Default RAID group size is 72GB * 8 devices -
The administrator wants to expand the volume at most every six months -
The growth and change rates are estimates, so extra volume space has been requested , and the customer realizes that a volume always has to operate with some free space to decrease the possible fragmentation rate, or I/O performance could suffer; therefore, an extra 20% free space per disk drive will be allocated as a free-space buffer -
The average I/O rate is about 1.5MB per second and the peak rate is about 3MB per second Based on the statistical information for this organization, the resulting analysis and projections can be as follows: -
The database size after six months will be about 144GB. -
About 1.6GB of the database will change every month after six months, which is equal to 0.12GB per four hours. -
The minimum space requirement after six months will be (144GB * 2) + (0.12GB * 12) = 290GB. -
A 72GB disk drive has 68GB usable file space, and because 20% is allocated as extra free space, only 55GB is usable per disk drive. Hence, six disk drives are needed for data and one disk drive for parity, for a total of seven disk drives. However, it is important for performance reasons to always configure complete RAID groups; therefore, the volume will be created with eight disk drives. If the rate of growth is consistent over time the volume will have to be expanded with another RAID group after six or seven months. -
The estimated peak load was 3MB per second, which is equal to about 770 IOPS. Because seven data disk drives can support 1,050 IOPS, a RAID group size of eight will be sufficient to support both space requirements and I/O load requirements. File Servers with NAS/SAN 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: -
Allocate only the space needed for a particular server. If users have access to infinite space, they'll find a way to fill it. -
Use third-party file comparison tools to determine when duplicate information is being stored on a separate file server. -
Snapshot the data regularly to enable users to recover their own files across multiple versions of the file. -
Consolidate file servers to a location where they can have very high-speed access to the NAS device. If possible, plug in the servers to the same blade on the network device to avoid sending traffic across the backplane. -
Enforce quotas on user data areas to prevent users from consuming all available space. -
Critical data should be mirrored to another location to ensure rapid recoverability. -
Data should be backed up to long- term storage media such as tape to maintain sufficient data history -
Run multiple Host Bus Adapters in each file server with each HBA connected to a different Fiber Channel switch. This will allow for failover if one of the Fiber Channel switches should fail. -
Users should be trained on any tools that will be available to them for tasks such as recovering deleted data or recovering an older version of an existing folder. Backup Systems 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: -
Use configurations that maximize data throughput. Because data will only stay on the NAS or SAN for short periods of time and will be immediately spooled to tape, there is not a large need for redundancy at the SAN or NAS. RAID 0 is a good choice for this. -
The backup system should be connected to the high demand hosts via a dedicated network. This allows the backup to occur without interference from user- facing traffic. -
If using a SAN for the backups, consider using a SAN-attached tape device to spool the data for long term storage. -
For databases that cannot be acquiesced for purposes of backup, use a triple mirror configuration. This allows the third mirror to be broken and brought to a static state. This mirror can then be backed up to tape. After the backup occurs, the third mirror is reattached and synchronized with the system. During the backup process, the system is still protected by the second mirror. -
Run multiple Host Bus Adapters in each file server with each HBA connected to a different Fiber Channel switch. This will allow for failover if one of the Fiber Channel switches should fail. Active Directory Integration 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: -
NAS devices authenticate against the domain by which they are accessed. To ensure that this still works when a domain is upgraded to Active Directory, be sure to point the NAS at a DNS that holds the appropriate service records (SRV). -
Windows Server 2003 domains default to using only NTLM v2 or Kerberos and require the digital signing of communications. Ensure that any NAS devices present in the enterprise can support these requirements. -
NAS devices ACL resources based on SIDs. If a domain upgrade will involve migrating objects from another domain, be sure to either maintain the SID history or re-ACL the NAS device. Terminal Servers 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: -
Store user profiles on a NAS or SAN device to ensure fast access to the profile from any Terminal Server in the farm. -
Store applications on the NAS or SAN device. This allows the new Terminal Servers to be pointed to the existing applications for rapid deployment. -
Store user data on a NAS or SAN device. Due to the high IO requirements of multiple terminal servers potentially needing to reach a given user's data, only a NAS or SAN device spanning a large number of drives will be capable of providing adequate performance. -
Build VLDs or LUNs based not only upon space requirements but on IO requirements as well. Depending on the access pattern, a single hard disk can support roughly 150 I/O operations per second (IOPS). It is important to understand the I/O rate during peak load to estimate the number of disk drives needed to support the I/O load. For example, a RAID group size of eight disks (seven data and one parity) can at most support 7 * 150 IOPS = 1,050 IOPS. -
Store user data and applications on separate VLDs or LUNs. This enables you to easily lock down application files across the entire disk without affecting user-by-user access to their unique data or profiles. Booting from NAS/SAN 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: -
If the Host Bus Adapter supports it, booting a server directly from the SAN without any local hard drives is an easy way to replace failed servers. -
Terminal access type computers can be built by booting via BOOTP and receiving their operating system image from a NAS device. This greatly simplifies management of specialized stations . Using a NAS device for this will greatly improve scalability due to its ability to support higher IO rates. -
Replicate live systems to a test lab SAN by mirroring the data from servers that boot via the SAN. This allows isolated testing with data that is identical to the live system.  |
