If you would like to be notified when Anderson Patricio releases the next part of this article series please sign up to the MSExchange.org Real time article update newsletter.
In Exchange Server 2007 RTM and Windows Server 2003 we had two options to provide high availability: SCC (Single Copy Cluster) and CCR (Cluster Continuous Replication) (Figure 01), however we could not have site resilience and high availability in the same scenario.
Figure 01: High availability solutions available with Exchange Server 2007 RTM
Windows 2008 with failover cluster has a new feature that allows installing a CCR or SCC on different IP subnets which would not have been possible using Windows Server 2003. Using Windows 2008 we can use two datacenters, each with a CMS (Clustered Mailbox Server) CCR node. However, in this scenario we will not have a local high availability solution.
Note:
To use site resilience with Windows Server 2003 Cluster we must have both nodes in the same subnet even if they are in different locations. The only way to accomplish that is using Virtual LAN to stretch the network among the nodes.
Using Exchange Server 2007 RTM, we can choose: high availability scenario or site resilience but not both. However the Service Pack 1 release brought the SCR feature where we are able to achieve both requirements (high availability and site resilience) using only Exchange Server 2007. For example, we can have a main site with a mailbox server that can be in either in a single mailbox server, CCR or SCC and a replica of the storage groups in a standby site; in case of main site failure we can use the replicated data in the secondary site to quickly recover the users’ message data.
SCR adds more options to the current High availability solutions found in the RTM version and extends it, enabling an environment to have a copy of the primary site database in a second site to provide an extra layer of security in a disaster recovery scenario.
The SCR feature uses the concept of Source and Target. The SCR sources can be any Exchange Server 2007 Mailbox deployment such as: a mailbox server, a Single Copy Cluster (SCC), or a Cluster Continuous Replication (CCR). On other hand the SCR target can be a single mailbox server or a CMS passive node where there is not any CMS cluster configured just a passive node.
SCR uses the same Replication technology used by CCR and LCR but in a different way. Using SCR we have the concept of Source (Active copy) and Target (Passive Copy) and they have some requirements, as follows:
- The Operating System used by target and source must be the same.
- Exchange Server 2007 SP1 must be installed in both: Source and Target.
- They must be in the same Active Directory domain.
- The target can handle 50 Storage Groups in the Enterprise Edition and 5 Storage Groups in the Standard Edition.
- The target must have at least the Mailbox Server role installed.
- In the target server there is no indication of the replication using Exchange Management Console.
- The database and storage group paths must be the same in the source and target; this means that the paths must be defined cautiously. Example: two sources cannot use the same path for database and storage groups with a single target.
- The Replication service will maintain the database, log files and path in the target SCR, it is not necessary to create a folder or anything else before enabling it.
- One source can have multiple targets; one target can have multiple sources.
- Microsoft recommends no more than 4 (four) targets per source.
One last thing to mote before starting to play with SCR, we cannot back up a SCR target only the SCR source.
Enabling SCR
In this article series we are going to use two servers with three roles: Client Access Server, Mailbox Server and Hub Transport and they will be running on top of Windows Server 2008 RTM. The scenario that will be used during this article can be seen in Figure 02.
Figure 02
The server located in the main site (srv-ex01) has a Storage Group called UsersSG and a mailbox database called UsersSG and all the log files and databases will be kept in the path c:\UsersSG, as shown in Figure 03.
Note:
In this article our emphasis is on demonstrating how SCR works. Keeping the database and log files on the same disks and on the same disk as the OS is not a best practice and it should not be followed in a production environment.
Figure 03
Let’s open the Exchange Management Shell on srv-ex01 and list all the existent Storage Groups through Get-StorageGroup –Server <server name> cmdlet. Our initial objective is to configure SCR on the UsersSG storage group. We will accomplish this task using a cmdlet to enable an existent storage group to use a SCR target. The Enable-StorageGroupCopy cmdlet in SP1 has new options to allow this:
Enable-StorageGroupCopy –Identity <Storage Group Name> -StandbyMachine <Target SCR server> -ReplayLagTime <using the format day.hours:minutes:seconds 0.0:0:0> -TruncationLagTime <period of time using the same format of the previous parameter>
This cmdlet above is responsible for enabling a SCR target in an existent Storage Group. Using this cmdlet we have important parameters to be used with SCR:
-
–Standbymachine: name of the SCR target where a passive copy of the current storage group will be kept
-
–ReplayLagTime: the files will be copied to the SCR target and the Replication Service will wait the amount of time specified in this parameter to replay the copied log files into the passive database copy. Even though specifying 0 there is a hard coded limit of 50 log files, this means that the SCR Target will be at least 50 log files behind the production environment. The default value is 24 hours.
-
–TruncationLagTime : we can specify the amount of time that the replayed log files into the passive database will be purged from the SCR Target.
Note:
The ReplayLagTime and TruncationLagTime cannot be changed, only disabling and enabling the replication will change their values.
Note:
There is a default and unchangeable value of 50 log files lag time to avoid reseeding in case of a lossy failover. Even though the lossy failover only can occur with a LCR/CCR implementation the 50 log files is default in SCR independently of the SCR source.
The steps to list the storage groups and create a replica of the UsersSG are shown in Figure 04.
Figure 04
After a few minutes we will see a new entry in the Event Viewer of the SCR target. This new entry has EventID 2114 and source MSExchangeRepl – basically the information will be an instance that the storage group has started, as shown in Figure 05.
Figure 05
We can also use the Get-StorageGroupCopyStatus cmdlet to see the current information of our SCR, in order to get only the SCR information we can use the parameter –StandbyMachine and the SCR Target server name, as shown in Figure 06.
Figure 06
We can validate log file replication (Figure 07) in the SCR target (srv-ex02), as we saw previously the path used by the source must be the same in the target. The only thing that we cannot see yet is a database in the SCR Target. This is normal behavior because the database will be created in the SCR target only after 50 logs are created in the SCR source and after the replaylagtime parameter is reached as well.
Figure 07
Finally, let us take a look at the srv-ex02 (Figure 08) and we will not see any changes in the number of mailbox stores and storage groups. The only way to manage the SCR is by using the Exchange Management Shell. Keep in mind that srv-ex02 will receive all the log files in the path c:\UsersSG but any information about that will be displayed in the Exchange Management Console.
Figure 08
Conclusion
In this article we demonstrated how to enable the SCR feature and the definition of source and target. We also validated the changes in the source and target servers after enabling the SCR feature. In the next article we are going to test possible scenarios where SCR can add more options to a disaster recovery plan and we also will see how to recover using SCR.
If you would like to be notified when Anderson Patricio releases the next part of this article series please sign up to the MSExchange.org Real time article update newsletter.
