Solved

Standby Continuous Replication throttling question

Posted on 2008-10-16
18
731 Views
Last Modified: 2008-10-22
We are setting up SCR in our environment and replicating over a WAN. There are a lot of Storage Groups to replicate and we are concerned about the amount of traffic with log shipping and all. I have two questions. One, does anyone know if the log shipping process is file level or bit level? Two, is there any way at all to throttle the log file shipping so we can reduce the traffic during the day when WAN utilization is the highest. Just curious as to what others are doing in a situation like this.
0
Comment
Question by:osiexchange
  • 9
  • 9
18 Comments
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
Hi,
Q1: Log Shipping is File Level, log files are 1MB each.
Q2: Well if you want to delay it then the entire objective would be lost
Here are few good articles to refer to:
Hope this helps
Thanks
Nitin
0
 

Author Comment

by:osiexchange
Comment Utility
Thanks. I wil check these out.
0
 

Author Comment

by:osiexchange
Comment Utility
I have seen these articles before. They only confuse me more than I am. They don't mention anything about throttling. What I am looking for is a way to more or less schedule replication to the SCR target. Once it starts, or you Enable-StorageGroup Copy, log files start shipping and we are afraid it will take up too much bandwidth. I know I can suspend the copy and resume it later but that is too much work with a lot of Storage Groups. The replay lag time doesn't slow down or delay the copy from what I have read. It simply delays the committing to the database after the log has been copied. Is this correct?

Also, I don't understand this paragraph. Is it saysing the SCR allows for log file truncation at the SOURCE
or it does log file truncation at the source. I don't think I would want my production server log files to be truncated automatically. Maybe I am reading it wrong.

In the RTM version of Exchange 2007, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait till all logs have been replayed into all SCR targets because SCR target copies can configured with large log replay lag times.
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
Hi,
Let me clarify some points here....
RelayLagTime (sth like that) is the one that just delays the replay of Log Files once they have been successfully replicated to Target Server
TruncateLagTime (sth like that) is the one that defines the time for which Exchange on target server will wait after sucessful Log Replay and then will delete the Log Files. Logs are truncated at Target Server !!
And on the Scheduling of Replicaiton, No that cannot be done.
Hope this helps
Thanks
Nitin
0
 

Author Comment

by:osiexchange
Comment Utility
OK, so if that is true, there is no need to  run backups on your production server just to flush log files because this does it for you.Of course you have to back up databases. Is there a way to disable the truncate on the source so you just let you backups flush the logs. I don't see a benefit to this but maybe I am missing something. Thanks for this info. It is really helpful.
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
100%, true...but backups will be required to backup !
Well, see once the Logs are replayed into the Database, then the DB is uptodate, and Logs as such are not required. Thats the reason MS has brought in this setting.
By default Truncate setting is set to 0 seconds. Well, you can increase this if oyu want. but I would say not required
Thanks
Nitin
0
 

Author Comment

by:osiexchange
Comment Utility
I understand, but, what happens if the logs truncate on your production server and then your database crashes and all you have left is a backup of your database from yesterday and whatever log files you have to play back. Then what! If they are truncated, you are out of luck.
I suppose you can say, well, at that point you can failover to your SCR server but I would prefer not to do that because failing back means down time for all users on that server. With a CCR environment, you need to remove the Cluster software before you can fail back which means everyone is disrupted. So,
to avoid this, if a single database fails, you have to fail over the entire server to avoid disruption when failing back. Really not a good option. You see what I mean. If there is no way to disable truncation, can you delay it until after your backups have been run?
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
Hi,
I understand your concern....See you can set the TruncationLagTime anything between 0 Sec to 7 days....so that can take care of your concern. Though I am not sure what is the reason then that you want to continue with SCR, I assume it is a part of larger Site DR (BCP), right?
Also, CCR you do not have to remove Cluster Software, that is the benefit, if the Active fails the passive takes over, thats where CCR is better than LCR, whereby in LCR you got to manually initiate the failover. Are we in sync?
Nitin
0
 

Author Comment

by:osiexchange
Comment Utility
What I was talking about is failing back from the SCR server to your CCR. Not node failover from active to passive. In order to replicate data back to your CCR from the SCR, in other words, reverse the process to fail back to production from your DR Site,  you need to run Exchange setup.com with the /removeCMS switch on your CCR. Then enable Storage group copy back to your CCR server, then reinstall CMS. Its a major pain. Thats why you are forced to fail over all your Storage Groups even if one fails because failing back will take everyone down. Having said this, I prefer not to use the SCR unless we do indeed have a total Site failure, and not just a single database failure. Its just too much trouble failing back, seeding the database etc.....over a WAN.

However, if I set log truncation to seven days, our backup software will be able to capture all the logs during the week. I just wish there was a way to turn it off. I don't like anything messing with the logs.
0
Free book by J.Peter Bruzzese, Microsoft MVP

Are you using Office 365? Trying to set up email signatures but you’re struggling with transport rules and connectors? Let renowned Microsoft MVP J.Peter Bruzzese show you how in this exclusive e-book on Office 365 email signatures. Better yet, it’s free!

 
LVL 32

Expert Comment

by:gupnit
Comment Utility
Ok, so your Source is a CCR and Target is a single SCR or you have your SCR at multiple locations....!! See to overcome your concerns....I would suggest...
  • ReplayLagTime....well here you better keep a delay of around 24 hrs (assuming your backups are daily)
  • TruncationLagTime....keep it to another 24 hrs so that you have 2 days in hand....else inccrease this to 7 (I doubt you would want to)
Considering you are being very clear on your deployment, I assume that there will be pretty active monitoring, so 48 hrs is a pretty good time so take control of things...
Hope you are getting what I am trying to say here....and well you have to live with /RecoverCMS....if at all you need to....no way out :-) !!
 
Unlike CCR where there is no delay allowed, you can then go with 2 options.....1
0
 

Author Comment

by:osiexchange
Comment Utility
Thanks for all your help. I really appreciate it. OK, so if I keep the replaylagtime to 24 hours, what flushes the logs on the target. The daily backups or do the logs truncate on the target automatically after they are committed to the database.
I suppose even if the logs did truncate on the source, if I needed them to replay into the database after a crash, I could always manually copy them from the target SCR server back into the source log folder. No?
Also, if I increase the truncate time to 7 days, what would be the harm seeing the backups are flushing the logs every day anyway?
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
See what happens is that when a successful Backup is taken on the Source SG the DB header Target will be updated and the log files will be truncated. Now in your case (CCR Source) the DB header on Target will be updated and Log files will be truncated the moment a successful Backup is taken on either Active or Passive Nodes of SCR source SG ie CCR.
As such no harm, you might get some warnings on the truncation (not tried though).
Read this...http://technet.microsoft.com/en-us/library/cc164368(EXCHG.80).aspx
0
 

Author Comment

by:osiexchange
Comment Utility
If logs are truncated on the source, then why does this blog state that they are truncated on the target.

Here is the section I am referring to and below a link to the blog:

SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed.

Possible Causes

The SCR log file truncation time is set to a value over 24 hours.

Resolution

Set TruncationLagTime to 0.0:00:00 minutes and then restart the Microsoft Exchange Information Store and Microsoft Exchange Replication services.  Next, take a backup of the Storage Group on the SCR Source server and then confirm that SCR Target log files get truncated after successful backup.  After SCR target files truncate properly, you may change the TruncationLagTime to your desired values.

http://msexchangeteam.com/archive/2008/05/28/448929.aspx

Its all very confusing.
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
Log are truncated on Source and Target both....Read this from Technet as I explained earlier...
"
In Exchange 2007 RTM, rules are enforced so that in a continuous replication environment, a log file is not deleted unless it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target computers. Log truncation on the SCR source does not wait until all logs have been replayed into all SCR targets because SCR target copies can be configured with large log replay delays. However, log truncation on an SCR source will not occur if one or more SCR targets for a storage group are down. In order for logs to be truncated on an SCR source, the SCR target computer(s) must be online and accessible by the source.
On an SCR target, a background thread runs every three minutes to determine if any log files need to be truncated. If the following three criteria are met, a log file will be truncated on an SCR target: The log file has been truncated on the SCR source.
The log file generation sequence is below the log file checkpoint for the storage group.
The log file is older than ReplayLagTime + TruncationLagTime. (For a description of these parameters, see "Cmdlet Updates for SCR" in the topic, Standby Continuous Replication)


In an LCR or CCR environment that is extended with SCR, if the following three criteria are met, a log file will be truncated on the active and passive copies in the LCR or CCR environment: The log file has been backed up.
The log file generation sequence is below the log file checkpoint for the storage group.
All SCR targets have inspected the log file"
Let me know
0
 

Author Comment

by:osiexchange
Comment Utility
Thanks. I read that about 5 times. I posted on a Microsoft forum and got an explanation I hope is correct and final. The truncationlagtime value is the amount of time the SCR target waits before truncating log files after they have been truncated on the source. For example, if I set truncationlagtime to 1 hour and my backup runs at 11:00 PM at night and flushes the logs on the source, the SCR target will waiting 1 hour and then flush the logs on the target server. I like this explanation better because I was concerned that the logs on the source would be flushed without running a backup. I am hoping this is correct. I am not sure why you would want to do this which is maybe why Microsoft set the default to zero.
0
 
LVL 32

Accepted Solution

by:
gupnit earned 500 total points
Comment Utility
100%....if you see one of my previous comment....after successful backup on Source, the Target is updated with informaiton
Here is what I wrote "See what happens is that when a successful Backup is taken on the Source SG the DB header Target will be updated and the log files will be truncated. Now in your case (CCR Source) the DB header on Target will be updated and Log files will be truncated the moment a successful Backup is taken on either Active or Passive Nodes of SCR source SG ie CCR."
This would be since by default it is 0.
Now you wanted to be sure of keeping logs for sometime, hence I said make it 24 hrs....as per one of my suggestions
Hope this clarifies
Thanks
Nitin
0
 

Author Comment

by:osiexchange
Comment Utility
Thanks for all your help. Its clear now.
0
 
LVL 32

Expert Comment

by:gupnit
Comment Utility
My pleasure....It helps me also revise hahaha..!!
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Easy CSR creation in Exchange 2007,2010 and 2013
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
how to add IIS SMTP to handle application/Scanner relays into office 365.

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now