Direct-attached storage (DAS) is a common scenario in smaller Exchange deployments. Most of the best practices that apply to DAS are common to other scenarios and are therefore covered in Best Practices Common to Multiple Architectures. For DAS, the only additional best practice is to implement redundancy for all storage components and the power supply—this is to prevent the possibility of a single point of failure.

Storage Area Networks (SANs) are excellent storage architectures for Exchange. Even so, to optimize for reliability and performance, there are numerous best practices that you should implement.

To optimize a SAN for reliability, you should:

• Configure redundant controllers, SAN switch, and spindles.
  

To optimize a SAN for performance, you should:

• Dedicate physical spindles within your SAN to Exchange databases. Ideally, you should dedicate an entire SAN to large Exchange deployments.
  
• Ignore any redundant components for planning purposes. You should plan for performance even in a failover situation.
  
• Plan so that expected peak utilization does not exceed 80 percent saturation of the system.
  
• Configure storage so that the channel on the storage unit supports your expected IOPS value that you calculated earlier in this guide. The IOPS supported on the channel is bandwidth/block size. If you have multiple channels and plan on one being redundant, do not count the redundant channel in this calculation.
  
• Verify that your SAN switch can support your IOPS requirements, even in a failover situation. The SAN switch has to process the incoming I/O request and forward it out the appropriate port and therefore limits the amount of I/O that can be handled..
  
• Verify that the Host Bus Adapter (HBA) installed in the server can support your IOPS requirements, even in a failover situation. To avoid throttling, ensure that the queue depth is set according to your storage vendor’s recommendation.
  

Network-attached storage was recently added as a supported storage architecture for Exchange 2003. However, for Exchange 2003 organizations, it is recommended that you implement a Storage Area Network (SAN) solution over a network-attached storage solution. If you decide to implement network-attached storage, be sure to familiarize yourself first with the general best practices presented in Best Practices Common to Multiple Architectures. Then, to optimize your network-attached storage solution for performance, you can implement specific best practices presented in this section.

Note:

If you use Exchange 2003 incorrectly with a network-attached storage product, you may experience data loss, including a total loss of the Exchange database files. It is critical that the NAS solution you implement with Exchange is on the Windows Server Catalog. It also critical that, before you deploy any storage solution for Exchange 2003 databases, you obtain your storage vendor's assurance that the end-to-end solution is designed for use with Exchange 2003. Because many vendors have "best practices" guides for Exchange 2003, you should plan to follow your vendor's best practices. For more information about Microsoft's support policy on the use of network-attached storage devices with Exchange Server 2003, see Microsoft Knowledge Base article 839687, "Microsoft support policy on the use of network-attached storage devices with Exchange Server 2003."

To optimize network-attached storage for performance, you should:

• Use a gigabit network connection for connecting to your network-attached storage system.
  
• Verify that I/O bandwidth, I/O latency, and CPU cost to perform a single I/O operation enable you to realize the IOPS requirements that you calculated earlier in this guide.
  
• Verify that the available network bandwidth supports the IOPS requirements of your users. Be aware that you may experience greater latency and increased processing demands on the CPU than you experience when you use locally-attached storage.
  

Logical and Physical Disk performance counters are not useful for measuring disk performance on Exchange 2003 servers configured to use supported Network Attached Storage (NAS) solutions. Drive letters used for the storage of Exchange 2003 database and transaction log files are not presented as physical or logical disks, but as drive letters associated with a network file share. Additional performance counters were added to Exchange 2003 Service Pack 1 to facilitate measuring performance of database/log reads and writes. These counters only measure ESE database I/O (*.edb and *.log). ExIFS I/O (*.stm) is not measured. These counters are only exposed by enabling additional Extensible Storage Engine (ESE) counters. Setting "Show Advanced Counters" in the registry will enable the following extended Exchange 2003 Service Pack 1 performance counters:

• Database(Information Store)\I/O Database Reads Abnormal Latency/sec
  
• Database(Information Store)\I/O Database Reads Async Pending
  
• Database(Information Store)\I/O Database Reads Average Bytes
  
• Database(Information Store)\I/O Database Reads Average Latency
  
• Database(Information Store)\I/O Database Reads In Heap
  
• Database(Information Store)\I/O Database Reads/sec
  
• Database(Information Store)\I/O Database Writes Abnormal Latency/sec
  
• Database(Information Store)\I/O Database Writes Async Pending
  
• Database(Information Store)\I/O Database Writes Average Bytes
  
• Database(Information Store)\I/O Database Writes Average Latency
  
• Database(Information Store)\I/O Database Writes In Heap
  
• Database(Information Store)\I/O Database Writes/sec
  
• Database(Information Store)\I/O Log Reads Abnormal Latency/sec
  
• Database(Information Store)\I/O Log Reads Async Pending
  
• Database(Information Store)\I/O Log Reads Average Bytes
  
• Database(Information Store)\I/O Log Reads Average Latency
  
• Database(Information Store)\I/O Log Reads In Heap
  
• Database(Information Store)\I/O Log Reads/sec
  
• Database(Information Store)\I/O Log Writes Abnormal Latency/sec
  
• Database(Information Store)\I/O Log Writes Async Pending
  
• Database(Information Store)\I/O Log Writes Average Bytes
  
• Database(Information Store)\I/O Log Writes Average Latency
  
• Database(Information Store)\I/O Log Writes In Heap
  
• Database(Information Store)\I/O Log Writes/sec
  

To ensure performance of your network-attached storage system, you should enable the above additional performance counters. For detailed steps on how to enable these additional counters, see How to Enable Extended ESE Performance Counters. Explanations for each of these counters can be found by using the Explain feature in System Monitor (Performance Monitor).

Internet SCSI (iSCSI)is a relatively new technology that enables you to store data remotely in a manner that is seamless to the operating system. The following are best practices for optimizing reliability and performance in an iSCSI storage solution.

To optimize iSCSI for reliability, you should:

• Configure redundant controllers, SAN switch, storage units, and spindles.
  
• Use a separate, dedicated gigabit network for iSCSI traffic.
  

To optimize iSCSI for performance, you should:

• Contact your SAN storage vendor for any special performance and configuration recommendations.
  
• Test to verify that the iSCSI traffic latency observed when your server is fully loaded (per your IOPS requirements) meets your needs.
  
• Use Gigabit Ethernet. iSCSI performance can be improved by using Gigabit Ethernet cabling and switches, and iSCSI chips or HBAs on which to offload TCP/IP processing overhead.
  
• Use the iSCSI command line interface (ISCSICLI) command to configure a persistent login target or the iSCSI Initiator Control Panel tool to make your volumes persistent.
  
• Use the ISCSICLI command to bind persistent volumes or the iSCSI Initiator Control Panel tool to permit the iSCSI service to configure the list of persistent volumes.