Storage Requirements for Cluster Continuous Replication
CCR is designed to eliminate the need for shared storage in a Windows cluster. Shared storage was a requirement of previous versions of Exchange. The only storage requirements for CCR are sufficient performance and capacity from Windows-supported storage.
CCR does not place additional I/O considerations on the storage used by storage groups and databases. When you design your CCR storage solution, we recommend that you follow these best practices:
-
The location of the storage groups and databases must be identical on all cluster nodes.
-
Store the database files and transaction log files on different logical unit numbers (LUNs).
-
Use NTFS file system volume mount points to surface the volumes to the operating system.
-
Use recognizable names that can be directly and obviously tied to the hosted storage group or database. If different volumes are used for logs and databases, the paths should identify the type of data. This approach can help prevent human errors as the number of databases and storage groups increases. If the default installation is performed, the storage group and databases are created under the install location of Exchange 2007.
.gif) Note: |
|---|
|
Exchange 2007 does not support placing transaction logs or database files in the root of a volume.
|
A CCR environment requires storage that provides adequate performance and capacity. Equivalent storage for performance and capacity of the system should be configured on both nodes using the same location (drive letter and paths) for each storage group and database.
Database Size and Cluster Continuous Replication
The first line of defense for catastrophic storage failure or physical database corruption with CCR is to revert to the passive copy of the data and not restore from backup. This makes it much less important to have short recovery time objectives (RTOs) based on restoring from archive or tape. Instead of restoring from tape, you activate the passive copy of a database and the data is available to clients in minutes as opposed to hours. In this sense, CCR can be considered a fast recovery mechanism, putting it in the same category as hardware-based snapshots and clones created using the Volume Shadow Copy Service (VSS) in Exchange Server 2003.
It is not uncommon for an administrator to have to perform offline database operations, such as repairs, because of bad backups (for example, a tape is bad or a restore fails). With CCR, this scenario is avoided and there is much less chance of having to run a repair against a database. Although the percentage of situations in which repair is necessary should decrease dramatically, there will still be times when it will be necessary. Be sure to consider your tolerance for worst case downtime when deciding on database size.
CCR enables you to have longer online maintenance windows. Because CCR allows you to make a backup from the passive copy of a storage group, you can extend your online maintenance window on the active cluster node. In many cases, you can double the online maintenance window, which in turn allows you to have larger mailboxes and databases.
Another feature of Exchange 2007, called lost log resilience (LLR), drastically reduces the occurrence of database inconsistency due to lost logs. Generally, the most common reason an administrator repairs a database is to bring it into a consistent state when required logs have been lost or corrupted, thereby preventing the database from mounting. LLR provides resiliency for many of these lost and corrupted log scenarios, enabling a database to be mounted without having to run repair. For more information about LLR, see Lost Log Resilience and Transaction Log Activity in Exchange 2007.
At this point, it might appear as though continuous replication enables you to grow your databases as large as you like without risk. However, that is not the case. Online maintenance that completes in a reasonable amount of time per database is still a limiting factor on database size. But with CCR, the possibility of needing to reseed databases is also a limiting factor. CCR provides database redundancy so that if the active copy of a database is lost or corrupted, recovery can be accomplished quickly by activating the passive copy of the database. CCR provides automatic activation through the process known as failover.
After failover occurs, there remains only one copy of the database—the new active copy. Because the passive copy no longer exists, database resiliency may be compromised. However, you should still have your backup. To enable resiliency again, the lost or corrupted database needs to be removed, and a new passive copy of the database needs to be created and reseeded from the active copy. Depending upon the size of your database, this could take a long time. The worst case scenario is the loss or corruption of all active copies, where all passive copies have to be reseeded. This scenario is one of the reasons why we recommend Gigabit Ethernet for CCR environments.
In a CCR environment, you should expect to see the following rates over Gigabit Ethernet where there are no disk or processor bottlenecks:
-
Single database reseed: approximately 25 megabytes (MB) per second
-
Multiple database reseed (in Parallel): approximately 100 MB per second (limited by network bandwidth)
A larger maximum database size is possible when continuous replication is used. We recommend the following maximum database sizes for Exchange 2007:
-
Databases hosted on a Mailbox server without continuous replication: 100 gigabytes (GB)
-
Databases hosted on a Mailbox server with continuous replication and Gigabit Ethernet: 200 GB
| Note: |
|---|
|
Large databases may also require newer storage technology for increased bandwidth to accommodate repair scenarios.
|
| Important: |
|---|
|
The true maximum size for your databases should be dictated by the service level agreement (SLA) in place at your organization. Determining the largest size database that can be backed up and restored within the period specified in your organization's SLA is how you determine the maximum size for your databases.
|