Veeam vs. vSphere Replication

[Gostev]

Here is my current understanding, based on Ken's explanation above.

Ordered by I/O impact during data transfer periods, from lowest to highest:

1. Veeam replication with storage snapshot integration.
No I/O overhead.

2. vSphere replication
3x I/O overhead for VMDK writes to blocks belonging to the replicated state, and meeting the following criteria:

1) have changed while the replication for that VMDK is taking place,
2) have not already been sent from the current LWD,
3) have been sent but not written and acknowledged by the recovery site.

Write to PSF (for holding), Read from PSF + Write to VMDK (for LWD commit) = 3x I/O (Ken to confirm if 2x and why).

3. Veeam replication with vStorage API
3x I/O overhead for any VMDK write at all.
Write to snapshot (for holding), Read from snapshot + Write to VMDK (for snapshot commit) = 3x I/O

[averylarry]

I don't think so. Ken claims that only the very small subset of changed blocks that are changed again during the replication cycle are CoW . . .

And if I understand, it's only changed blocks that are changed again but haven't been replicated yet, so it's a shrinking subset of blocks that might need to be CoW.

If true, I think that really could be an interesting way to reduce I/O load from 3X guaranteed to 2X guaranteed and up to 3X max.

Of course, synchronous replication could in theory make no I/O impact. I think.

[Gostev]

it's a shrinking subset of blocks that might need to be CoW

That is correct. Still, LWD can produce noticeable extra I/O that should be taken into account for I/O intensive workloads before enabling vSphere replication.

[dellock6]

First things first, thanks Ken for coming here and explaining these things. This discussion is becoming really interesting.

There is no published API at all, to partners or customers, it's using a fundamental call within the kernel itself, so it's hard to expose that gracefully to the outside world. Trust me, we get beat up on APIs about this all the time, but securing the kernel is important. So we have a few calls we can make to it internally (via CLI) to configure the replication and that's about it. Lots of people want API access and lots of people want expanded CLI. We're always looking at how to do that though! Some other vendors in the world are doing... inappropriate things to gain access to things like the vSCSI filters without an API, and the problem there is if we change anything at all on those internal calls the whole house of cards might come down. People don't like it when their replication stops working for DR. So we're looking at potentially writing a published API for this, but since that hasn't been in scope from the start it's something we're going to have to retrofit.

Even without putting out the names many of us know who are you referring about, and is more than one solution. One of them is really "near" to VMware and claims to use the vSCSI filter driver, so you are saying that even in that case it's a totally unsupported solution, from a VMware view point? You can also say "no comment" or nothing, I can understand.

Here is the problem: there is no other "officially supported" way of doing replication other than VM snapshots (or bypassing it completely with storage level replication), so some other solutions choose some "hacks" and by doing this they are totally unsupported; this is not a great thing not only because one simple change in the kernel would break their software, but also since we are talking about data protection so even official support is important.

But, but, there is an exception with your own Replication, that uses an "internal use only" kernel call. I've found this blog post by you (http://blogs.vmware.com/vsphere/2011/10 ... -work.html) and also this KB (http://kb.vmware.com/selfservice/micros ... Id=2005776) and in both places VMware says it's using vSCSI filter driver, the same of the other solutions.

So, can we sum it as "the filter driver itself is totally supported, but only if it's called by a VMware product" ?

Really, exposing those calls to partners would make all this stuff really easier, completely supported, and at the end customers will have better products.
Your role sounds to me like one that could eventually take care of this

Luca.

[Starman]

The only difference that matters to me is that Veeam does not work (or have a plug in for) with VMware SRM so I am forced to use VMware replication on the 20% of machines that aren't on my Equalogics for array based replication. I say so again so that it may happen in the future

I've never been very happy with the extremely limited VMware replication devices.

[PeteWest]

This forum was a great read
We are possibly purchasing Veeam soon. Ive found that a lot of features functionality depends on the business requirements.
I've noticed high I/O and performance impacts when VM's come in and out of snapshots, i would like to use storage level replication to avoid this but Veeam only support HP SANS and the function is at an increased cost.
Obviously an advantage is vSphere replication is free... It also allows us to Replicate production from a Dell Compellent SAN to our older EMC San, which Veeam cannot.
Once Veeam releases a few plug-ins for more SAN vendors will re-asses, but even then may stick with vSphere replication as alwyas have a few little disk consolidation issues and performance impact using snapshot, we will already be using many snapshots with Veeam images, adding many hourly replication snapshots to production machines as well doesn't appeal to us.
Im in no way a replication or backup specialist, this is just based on encountered experiences.
In relation to the question Veeam v vSphere replicaton.. we plan to be using both haha
Cheers

[karlochacon]

hi guys

I would like to know what I have to choose among Veeam and vSphere replication but regarding version 5.5

for what I know vSphere Replication now has multiple recovery points but I was reading only one VM at a time can be recover during a Failover.
I know the RPO for vSphere replication is 15 min what about Veeam?

does any one has any comparison table among these products?

BTW can I failover and failback multiple VMs at a time using Veeam?

thanks a lot

[veremin]

Hi, Carlos,

Your post has been merged into existing discussion regarding similar matter, so, please, take a look at the answers provided above.

I know the RPO for vSphere replication is 15 min what about Veeam?

You can set whatever interval or exact run time you want to. Also, if you're after minimal RPO, you can set replication job to run continuously. This, way new replication cycle will be started immediately after the previous one is finished.

BTW can I failover and failback multiple VMs at a time using Veeam?

Yes, you can select multiple VMs at one time and perform the said operations.

Thanks.

[DaveBristolIT]

From a pure speed point of view, across local network, is vSphere replication quicker? Veeam replication on it's first run is about 7MB/sec in my current environments and blames the "Target" for being the bottleneck, even though the Target is capable of writing at speeds of 200MB/sec plus.

[Vitaliy S.]

What performance rate do you have if you try to write any similar data to the target storage via datastore browser of the vSphere Client?

[Gostev]

Vitaly, I think I can answer this question myself (about 7MB/s or so)
Perhaps the target proxy is simply not hot add capable in this case.

[DaveBristolIT]

Hotadd... well that's an entire different equation that I'm currently struggling with Veeam Support on (00581754)

I can tell you the speed uploading via vSphere client in about 50 hours after my 2TB replication finishes at 5MB/sec I know from previous experience that I've been able to upload the 2012 R2 ISO to the datastore in about 45 seconds (91MB/sec)

[Vitaliy S.]

The upload speed via Datastore Browser and writing data to target host via network mode is the same, since the same uploading method is used in both cases. I wonder what performance rates you will have if you switch your target proxy to network mode.

[albertwt]

Cool, many thanks Anton G. for the explanation.

[cffit]

Can someone update this thread with comparing VEEAM B&R v8 and the current VMware DRaaS offering? I'm currently trying to decide on one or the other and I think that there have been large changes on both sides since this thread was created and debated.

[Gostev]

Can someone update this thread with comparing VEEAM B&R v8 and the current VMware DRaaS offering? I'm currently trying to decide on one or the other and I think that there have been large changes on both sides since this thread was created and debated.

All Veeam changes can be found at the end of the 2nd page of the What's New for v8 document. As you will see, most of these features are unique to Veeam.

[albertwt]

So with the new Veeam Backup & Replication v8.0 patch 2, how does it compare with the VMware Site Recovery Manager combined with SAN based replication technology ?

[lando_uk]

Hi

From reading this thread:
https://m.reddit.com/r/vmware/comments/ ... plication/

The conclusion I've made is this:

Veeam replication, Pros = FREE, we can enable it tomorrow, simple to setup.
Cons= higher RPO, quirks that may require intervention. Performance hit because of snapshots.

Vmware SRM, Pros= lower RPO, seamless, SAN replication (or not), one button failover. Big knowledge base.
Cons = £3.5k per 25 protected VMs, potentially complex to configure. Requires SAN datastore redesign. Maybe consultancy to implement.

Its also my understanding that there is a host licensing consideration - in that with Veeam Replication, we can basically use our existing esxi licenses on the DR hosts so long as they aren't running any live VM's, but with SRM we'd need the DR hosts licensed so they can be part of SRM. Is that correct?

M

[foggy]

Mark, please review the thread above for some considerations regarding both solutions. Also, I'd like to note that starting Veeam B&R v8, you can leverage replication from backup that does not deal with snapshots of original VMs at all.

[lando_uk]

Hi Foggy

I thought my post got deleted, and I found it here merged. Thanks.

I'm more interested in comparing SRM rather than vSphere Replication, but I'll read the thread.

[rreed]

Resurrection, we're looking into this exactly right now. VBR vs. SRM (ABR). Management has been looking forward to SRM for some time here, but I've very recently gotten my feet wet w/ VBR Replication and love it's vast simplicity over SRM w/ ABR greatly. Plus we already own it. I need some good points to convince management that VBR is the way to go over SRM.

What's the latest please?

[cjack03]

in the exact same situation as rreed, hoping for some new announcements tomorrow! finding real world example of VBR replication hard to come across when replicating over a handful of VMs. Anyone have experience they could share of replicating 100s of VMs with relatively low RPOs < 2hours?

thanks

[rreed]

We've since been rolling along w/ VBR, mostly because of its simplicity vs. all the moving parts of SRM - that failed miserably the day I attempted to do a demo for our CIO and director - and all the additional things it can bring to the party over SRM. We're working out the networking side of things, which is not going to be trivial at all for us for two long-existing active/active data centers cross-replicating, but looking forward to when it's all settled and done and we're failing over VM's side to side.

[cjack03]

Thanks for the update rreed. How many VMs/total size will you be replicating and at what frequency, do you have any issues with the frequency of the snapshots?

I'm looking at about 50Vms/20TB and would like to do this every two hours, we can offload the snapshots to the storage but i'm still unsure about the impact on our production environment.

[rreed]

We're just recently getting started, and easing into it. We're also not large; around 50-75 VM's total, probably up to around 10TB idle storage but don't forget to take into consideration how many restore points you're keeping (two for us since we of course run nightly backups) and how much churn each VM makes will affect snapshot and therefore total storage size. Good point though, we're rolling along now and I do need to try to get a handle on how much we're cranking through.

So far we only replicate once at night, but I'd like to bump that up to twice w/ the second one at lunch time. In older versions of VMware (we're at v6 update 1 I think) we would have occasional impact from a snapshot that stunned a VM (usually a SQL server, of course) while the snapshot took a while to take, or just keep track of the deltas really chugged the storage (again, highly transactional VM's) and caused the phone to ring. Allegedly, they have really addressed that in v6. I dunno, I still hear the ghosts of those telephone screams back when I thought it was okay to run a quick backup during business hours as I type this. If you're talking about SAN snapshots, allegedly that is supposed to have more of a "guarantee" that it won't affect upwards to the datastore or especially VM level. Again, I dunno. I don't like my phone to ring because I clicked on something.