pat-cv at wcyv
Nov 24, 2009, 8:40 AM
Post #2 of 2
(268 views)
Permalink
|
|
Re: Off site subscriber for disaster recovery
[In reply to]
|
|
For UC, both database and messages(files) are replicated in real time
and you would probably be asking for trouble if you short it on the
bandwidth. There isn't a way to actively only replicate configuration
info, but what about a cold-standby? Stage a clean install of UC
running the same version at your DR site. Take DRS backups nightly and
copy them over. If/when the time comes, you run the DRS restore. If
you choose not to restore messages, the restore would be pretty quick,
probably under 30 mins.
On Mon, Nov 23, 2009 at 8:06 PM, Chris Parker <cparker [at] cparker> wrote:
> Hello,
>
> I am working on a design for disaster recovery for a Call manager and Unity
> connection cluster. The idea is to have one sub located off site in a remote
> data center for both the Call Manager and Unity clusters.
>
> Neither sub would ever process any calls unless the production site was
> down. I am wondering how much bandwidth I am going to need. Since the Call
> Manager sub isn't processing calls, it should only need to receive data from
> the pub when there is a configuration change in the database? So I'm
> thinking the traffic will be pretty low.
>
> The UC sub may require a lot of bandwidth if messages need to be replicated.
> Is this done in real time or are the messages just copied over using ftp
> etc.? How much bandwidth does the server really need? I suppose I can look
> at how many messages we get in a day and calculate the file sizes add them
> up etc. But I don't know what kind of time frame the messages need to be
> copied for UC to be happy. Since its for DR I mainly care about the
> configuration being correct on the UC sub, and not so much the mailbox
> contents. Is it possible the have a UC sub that only syncs configuration and
> not messages?
>
> I know the SRND's give numbers for both these scenarios, but they seem
> really high. Anyone have experience doing this?
>
> Chris
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip
|
