Exchange 2007 SP1 SCR 知识点研究

 

  You can use standalone, single copy cluster (SCC), or CCR Mailbox servers as SCR sources.

 

Storage groups (SGs) for SCR can hold only a single database, which is in line with Microsoft’s current design philosophy to focus on databases as the management object you're building high availability around rather than SGs that can hold multiple databases

 

a single source can have multiple targets: Exchange sends copies of logs to different points in the network, each of which replays the logs to build its own copy of the database. There's no hardcoded limit to the number of targets you can configure for a source, but every target you add increases the load on

§  the source server to replicate logs

§  the network to transport the logs

§  the target servers to replay the logs

Microsoft recommends that you configure no more than four targets for a single source, but even four might be too many. You need to perform tests to verify the best setup for your environment before you proceed to deployment

 

Best practice is therefore to ensure that the display names for SGs and databases are unique, perhaps by including the name of the server in the names that you assign to these objects

 

The same problem exists with the folder paths that you assign to SGs. SCR creates the same folder paths on the target server as are used for the SG on the source.

 

you can't replicate SGs from multiple source servers that use the same paths to a single target server

 

SCR target servers must have the Mailbox server role installed, even if no mailboxes are present. A target can be either a standalone Mailbox server or a passive node in a failover cluster (but not a clustered Mailbox server). If you use a standalone server, you can't run LCR for any SGs on the server because Exchange uses the Replication Service to process incoming logs from the source server. Target servers must be in the same Active Directory (AD) domain as source servers (but can be in different sites), and they must have the same installation paths for Exchange binaries and files as the source server. If the paths don't match, the RecoverCMS option fails when you run the Exchange Setup program to activate the target.

 

The source and target servers must both be running the same version of Windows (e.g., Windows 2003 SP2, Windows Server 2008) as well as Exchange 2007 SP1

 

 

To enable the selected SG for SCR, you use the Enable-StorageGroupCopy cmdlet. For example, entering

Enable-StorageGroupCopy -id 'XYZ-MBX1\Super Critical Mailboxes'
  -StandByMachine 'SCRTargetServer' -ReplayLagTime 0.0:3:0
  -TruncationLagTime 1.0:0:0

 

 The ReplayLagTime parameter specifies the time that the Replication Service on the target server waits before it replays copied logs. The default lag time is 24 hours and the maximum you can set is 7 days. If the default value is used, for example, Exchange waits 24 hours after copying a log to a target server before replaying that log into the database copy.

 

The TruncationLagTime parameter defines how long the Replication Service on the source server waits before it truncates (i.e., removes) log files that the target server has successfully replayed into its database copy. Note that you can't change the value of these parameters (TruncationLagTime and ReplayLagTime) dynamically. If you need to change them, you first have to disable SCR for the SG with the Disable-StorageGroupCopy cmdlet:

Disable-StorageGroupCopy id 'XYZ-MBX1\Super Critical Mailboxes'
  -StandByMachine 'SCRTargetServer'

 

EMC doesn't display status information about SCR for SGs, so you use the Get-StorageGroupCopyStatus cmdlet to monitor the health of SCR and report on the status of the SG, as follows:

Get-StorageGroupCopyStatus -id 'XYZ-MBX1\Super Critical Mailboxes'
  -StandByMachine 'SCRTargetServer'

 

With SCR, you have a copy of the source database on the target server, but no function exists to transform an SCR copy directly into a live database (although this could appear in a future version of Exchange). To make that copy the active database and restore user access to mailbox data, follow these steps:

1.     Create a new SG and mailbox database on the target server. This process gives you stub objects in the Exchange configuration data in AD that you can later use to transfer mailbox configurations.

2.     Delete the mailbox database that you just created.

3.     Use the Move-StorageGroupPath and Move-DatabasePath commands to change paths stored in AD for your stub SG and database to the paths for the SCR logs and database.

4.     Transfer the mailbox configuration data so that Exchange directs users to the SCR copy.

5.     Test whether users can reconnect successfully to their mailboxes.

An outage now occurs, and you can no longer access the source database. You need to instruct Exchange to disable SCR for the source database, and you need to make the target copy mountable by using the Restore-StorageGroupCopy command:

Restore-StorageGroupCopy -id 'Super Critical Mailboxes'
  -StandByMachine 'SCRTargetServer' -Force 

Move-StorageGroupPath -id 'Recovery SG'
  -SystemFolderPath 'L:\SG1\First Storage Group'
  -LogFolderPath 'L:\SG1\First Storage Group'
  -ConfigurationOnly -Confirm $False 
Move-DatabasePath -id 'Recovery MBX'
  -EdbFilePath 'L:\SG1\First Storage Group\Mailbox Database.edb'
  -ConfigurationOnly -Confirm $False 

http://www.windowsitpro.com/article/exchange-information-store/exchange-2007-sp1-s-standby-continuous-replication.aspx