We're seeing replication shares that take more than a few days to update and wanted to understand why they take so long and why the size of the replication is so large (2-3 Gb). We run un-throttled at night and throttled during business hours to limit impact on operations. We have a single Kbox at our data center and replicate out to 25 branch offices. There's a single T1 at each branch and a 3 Mbit MPLS connection to the data center. Would it be possible to replicate from the KBOX out to a smaller number of offices and have those offices distribute out to the rest? How do we manage the size of the replication job?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
The only way you could replicate from other sites would be to install a KBOX at each one. As far as replication times go, that all depends on your network traffic, max bandwidth, throttling, and the amount of data your replication shares are updating. We have 80 replication shares with sites all the way down to 256Kbps, and they all work properly.

The size of the replication job is dependent on the amount of updates (if you are using the Security portion of KBOX), the software distributions, scripts, etc. Everything that will be run or installed on clients is replicated down to the replication shares.
Answered 03/04/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
In the details of a replication share you can see the files that have already been replicated, the files that are to be replicated and sizes.

While you cannot replicate using the kbox UI from one share to another you can certainly copy the files from one share to another. The kbox will see the new files -- it doesn't care how they get there as long as they are the correct files name (which include checksums) and checksums and directory structure -- so copying from an existing share will have that taken care of.

There are customers who do this type of thing -- perhaps they respond?
Answered 03/04/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Ah, yes. Hadn't thought of that, Gerald. However, this would require custom scripting to automate - and it would be completely independent of the KBOX / agent.
Answered 03/04/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Yes, it could be separate

Or, if more convenient, you could send a script to the 1st rep share via KBOX -- on windows maybe something like a script with a batch task that runs:

XCOPY c:\repl2\* \\remoteshare\repl2 /s /i
Answered 03/04/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Wouldn't you need to stop the agent first? That's why I think it would have to be totally separate from KBOX. You won't be able to copy a file into the proper directory if the KBOX Agent is in the process of replicating that file from the KBOX.
Answered 03/04/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
You won't be able to copy the file that the kbox is currently replicating to the remote B server, but if you are doing this technique you probably have the replication schedule for the remote B server turned off.

KBOX -> Remote A via replication
Remote A -> Remote B via replication

Shares for A and B are both defined in kbox (note: using the same patching files)

Remote A has a schedule
Remote B optionally does not have a schedule as your script takes care of it.
Answered 03/04/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Thanks for the suggestion about replicating to fewer sites then copying from those sites out to the other branch offices. You'd want to do some kind of filtering of the copy by file/folder age, wouldn't you, so that you're not copying out the entire replication share every time?
Answered 03/04/2011 by: kawelea
Orange Belt

Please log in to comment
0
Since the file names have checksums in them you would want to copy any file that doesn't already exist.
Answered 03/04/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
We currently replicate from our KBOX (DS3) to 4 remote sites (T1). I run wide open at night and off during the day and after patches are downloaded to the KBOX it can take a few days to get them out. So far, I've found that anything under 1GB in a single file will make it, but larger files (autoCAD) will crash the SMMP agent on the replication machine. What I have done in a pinch either for large files, or if I need a file on a share asap, is to replicate from the KBOX to my local PC (LAN) then manually copy the file to the replication shares.

I also replicate our backups to the same shares using Microsoft's free powertoy SyncToy. It doesn't allow me throttle the bandwidth, but it will send only the changed files.

Casey
Answered 03/04/2011 by: cmccracken
Orange Senior Belt

Please log in to comment
0
I have noticed that replication is extremely slow as well, and I am not sure if it is due to the methodology that Kace uses in transferring the files, or if there is a capped bandwidth somewhere in my box I haven't found yet. It seems like it is almost replicating in a round-robin fashion (send file A to repA then send file A to repB, etc.) instead of having concurrent connections to each repshare and just maxing out the transfer capability. I could be completely off base on that, but I do know that I can set a computer up on the same subnet as our KBOX and have it copy files of the same total size to 10 remote machines faster than the kbox will transfer the same amount of data.
Answered 04/13/2011 by: dyehardfan
Second Degree Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity