Continuous replication causing problems with fax server

[tholyoak]

I'm doing a trial of Veeam 6.1. I have a Win2008R2 server running on ESXi 4.1 that hosts an Exchange 2010 SP1 server as well as a GFI Faxmaker server with virtual Brooktrout SR140 devices.

I started doing crash-consistent continuous replication on the this VM this morning. This afternoon, I'm told that users are getting failed fax messages or only partial faxes coming through, and that it's been going on all day. I disabled the replication, and everything seems to have gone back to normal.

So apparently the replication is interfering in some way with the fax server. (And to think I was worried about problems with Exchange...)

[dellock6]

How much does it takes for a replica to complete? How much for the snapshot commit? My suspect is during snapshot commit the short freeze of the VM is enough to disconnect the phone line and then to give you failed fax operations.
You can try and replicate the error by manually snapshotting the VM every TOT minutes and then committing the snapshot...

Luca.

[tsightler]

I agree with Luca on the likely cause. Any details on how your fax software is terminated? Is it using a SIP trunk or H.323 gateway that supports T.38 or perhaps instead using G.711 passthrough? G.711 is especially sensitive to even slight interruptions (even the increased jitter due to higher costop when running from snapshots can impact voice codecs like G.711), but honestly all voice and fax protocols are very sensitive to interruptions. This is the same reason why most VoIP systems specifically state that running on VMware snapshots is not supported (many have even more restrictions when running virtually).

[dellock6]

Exactly. We run several fax servers and even PBX on virtual, but we do backups or replicas for our customers during non-working hours right because of these issues, sometimes even vmotion is critical for this kind of workloads.

[tholyoak]

Thanks, that does make sense. I guess we'll either have to separate the mail and fax servers or just do all the backup/replication jobs at night. That's too bad, the continuous replication appeared to be working really well otherwise (other than the occasional "Another task is already in progress" error).

[tholyoak]

We ended up getting a new host server and moving Exchange to it, so it is separated from the fax server. Continuous replication of the Exchange VM seems to be working just fine now. However, I am now wondering if there is any reason we wouldn't want to do it this often? It doesn't seem to be causing any problems as far as resources go. But the replication cycle only takes about 3 minutes and that seems like an awful lot of snapshotting going on.

[dellock6]

On a near-CDP activity, for sure you could end up seeing Veeam loosing most of the time for snapshots activity more than the data copy.
It's not a technical problem but a design decision: which kind of RPO do you need on that server? If you can afford to loose let's say an hour of activity, you can slow down the replica to a hourly schedule for example.
You know your environment and your own requirements more than everyone else

[tholyoak]

Well, looking at the performance graphs, I can see that it's actually affecting CPU, RAM, and disk usage of all the VMs on the host. It doesn't cause any noticeable performance issues, but we decided to limit it to an hourly replication schedule.

Thanks for all the input on this thread. It's been very helpful.