Additional Design Considerations
In addition to expected Exchange-related I/O, several circumstances that may exist in your environment can impact your storage requirements. These circumstances include:
Data replication
Clustering
Geographically dispersed clusters
Backup and restore
The following table lists the considerations for each of these circumstances
Circumstances that affect storage requirements
| Circumstance | Considerations |
|---|---|
Data replication |
Because data is being replicated to a remote location, your storage planning must include the communication links and storage needs at the remote location. To use the replicated data for disaster recovery purposes, you must replicate the transaction log files, checkpoint file, and database volumes, and synchronization must be maintained between all drive sets. For synchronous replication, data is not committed to your hard disks until it is committed at the remote location. As a result, the performance of your communications link and the storage system at the remote location is critical. If synchronization across your link is slow, your server prioritizes synchronization needs over user requests, effectively slowing down user response time. For asynchronous replication, each replica is typically out of sync. As with synchronous replication, when asynchronous replication falls too far behind, priority must be given to replication rather than to application performance, resulting in slow user response time. Important You must use only Microsoft-provided or qualified software drivers and services, along with hardware systems that have been appropriately qualified through Windows Hardware Quality Labs (WHQL) testing and have received the appropriate "Designed for Windows" logo status. In addition, for Exchange, a fully Microsoft-supported platform uses only native Microsoft Exchange services and components. For more information about Microsoft's third-party storage software solutions support policy, see Microsoft Knowledge Base article 841696, "Overview of the Microsoft third-party storage software solutions support policy." |
Clustering |
Only complete cluster solutions that appear on the Microsoft Windows Server Cluster Catalog (formerly the HCL) will be supported by Microsoft. Clusters cannot be arbitrarily constructed from device-level components (even components such as RAID controllers and multi-cluster devices that qualify as cluster components) and connected into a supported configuration. Because active/active clusters have virtual memory limitations and limitations on the number of users per node, it is highly recommended that you do not implement active/active clustering. Your active and passive nodes access Exchange data stored in shared SCSI, Fibre Channel, or iSCSI arrays. As a result, in a two-node active/passive cluster, there are no additional storage considerations when implementing the passive nodes. If you have multiple active nodes, you must configure your storage so that each Exchange Virtual Server can access only its own data. |
Geographically dispersed clusters |
As with any clustering solution, the hardware and software you use must be certified and listed in the Windows Server Catalog. However, be aware that third-party software and drivers may be required for your geographically dispersed cluster to function correctly. Because data in a geographically dispersed cluster is replicated across a WAN link, the same considerations apply here as for data replication (earlier in this table). Additionally, to provide for adequate failover, you must configure at least one storage array in each site. Your cluster nodes must be connected to your storage subsystem in such a way that when there is a failure at one site or a failure in communication between sites, the functioning nodes can still connect to storage at their own site. |
Backup |
The process of backing up data requires that data be read from your database and transaction log file volumes. This additional I/O can impact user response times and should be avoided during business hours. The process of soft recovery requires that Jet play back all the transaction log files. This causes the I/O profile to be a sequential read stream. As a result, the recovery performance improves if the transaction log files are on a disk with fast sequential disk access. Exchange also supports Volume Shadow Copy service for Windows Server 2003. To optimize storage for Volume Shadow Copy service performance, you should:
|