Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 763
  • Last Modified:

Standby Continuous Replication throttling question

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
osiexchange
Asked:
osiexchange
  • 9
  • 9
1 Solution
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
Thanks. I wil check these out.
0
 
osiexchangeAuthor Commented:
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
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
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
 
gupnitCommented:
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
 
osiexchangeAuthor Commented:
Thanks for all your help. Its clear now.
0
 
gupnitCommented:
My pleasure....It helps me also revise hahaha..!!
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 9
  • 9
Tackle projects and never again get stuck behind a technical roadblock.
Join Now