Site Replication Alternatives

[ekisner]

So, I'm one host into my upgrade to ESXi, and I've come across a fairly critical problem.  Was hoping to get the insight from some people who use replication software, and are happy (or also important, those who are unhappy) with their replication.

Currently, we use Quest Software's vReplicator (vRanger 5.3).  After upgrading my first host to ESXi, I went in-depth into setting up a virtual appliance (since they cannot inject an agent into ESXi, according to their tech support) and I was horrified at the VA's scratch disk requirements.  In short, meeting their recommendations means I need about 40TB of disk space for scratch disks... I know in reality it won't need to be that high, but I don't want to use any scratch disks.

So, I'm looking for alternatives.  My environment consists of two clusters, geographically dispersed, and directly connected by fibre.  I'm planning on replicating about 40 VMs, with varying schedules (critical VMs such as Exchange, SQL, and file servers get replicated at 15 minute intervals, LOB app servers that remain static are replicated once per week, for example).  Enterprise storage on both sides.

Existing Solution:

1) Nightly tape backup for application-consistent backups, tapes stored off-site

2) vReplicator replication on custom schedule to DR site  <-- This is what I'm looking to replace

3) VDR 2 backup to an old SAN using default retention, for VM recovery and alternative to tape backup

I've researched SRM 5, and although it would work, it is far a preferred solution (largely due to its limitations, of which there are many).

I've contacted Veeam for more info about their B&R v6 solution, but I was hoping to get a sense from the people in the community who use it, to see if they like it.

- Pretty sure it requires a virtual appliance (which in itself is fine)... does this VA require scratch disks?  Do said scratch disks have high space requirements?

- Replication from ESXi cluster to ESXi cluster - does it work reliably?  What kind of job failure rates do you see?

- Interface - do you find the interface friendly to use?  Is it responsive (or at least, scalable depending on the mem/cpu you give it)?

Double Take

- They're oddly specific about protecting windows servers.  Is it agent based?  If so do they have linux protection?

- Not too sure about this particular one.

Others

- There are a few other smaller ones out there... anyone have any other recommendations that they're happy with?

[ekisner]

Update

I've received my Veeam trial software, and I'm running some replication jobs now, gotta say the sandbox feature looks interesting - I'll definitely try it out... probably a DC, SQL and Exchange servers.. see how that plays out.  So far I'm impressed, they've done what Quest tech support has said cannot be done (replication without using an intermediary to store delta files).

At present the replication job is between my ESX 4.1 and an ESXi 5 host through vsphere.  Application installed on my desktop to be sure I can watch it regularly for surprises.

Additional perks I have noticed thusfar is that the interface is more responsive, the jobs seem to run faster, it provides much more verbose information (for example, the dedup and whitespace that is not being replicated).

One other perk, that isn't really a perk so much as a really good model, is their licensing.  Quest licenses per host, both source and destination... their licenses are less costly.  Veeam, on the other hand, licenses per host, source only.  In turn their licenses cost more per seat - however I'm still saving money on licensing.  This information, however, is based on their present licensing promotion - as I understand it their licenses will go up in price after Feb 1 2012.

I'll keep updating with more info, hopefully this helps someone else down the road.  As before, if anyone has other insight to share, I'm all ears.

[KiranQuest]

ekisner

I work for Quest software. Thanks for your post. Here are some points about our solution. If you would like to have more conversation, please feel free to email me at Kiran.Ranabhor@quest.com.

Quest licensing for vReplicator is based on source-servers only (physical sockets on ESX hosts being protected by vReplicator). Licensing destination (DR side) servers is not needed.

I get your points about the scratch disk. vReplicator uses scratch disks to store the replicated data before applying the changes to the base image. Most of the industry standard replication products I know do this: EMC RecoverPoint, NetApp SnapMirror (array based), EMC SRDF etc. They all create a snapshot on the DR side (or use logs) to hold the changes while the data is being replicated. Once replication transfer is done, changes are applied in one swoop.

In all these situations, scratch space is managed automatically, but its there. vRanger VA requires manual scratch disk management in this release.

This type of scratch disk use is very useful in replication in WAN environments where network can be a little flakey. Helps in avoiding having to re-silver the entire VM if data transfer fails...

Please let me know if you have any questions or would like to chat.

Thanks

kiran.

[KiranQuest]

BTW, the scratch disk space requirements in the doc are conservative (best practices) than absolute requirements. Also note that scratch disks are not used when doing initial sync - so initial size of the VM is not important, only the amount of changes between replication passes.

Thanks

[ekisner]

My apologies for the mis-information regarding your licensing.

I'm in emails with Kiran, as before I'll keep things up to date in the hopes that I can help others with choosing their best fit for DR replication.

[J1mbo]

Veeam is a solid and amazingly cheap solution, compared to the likes of the (very dated) DoubleTake anyway.  DT also places massive load on storage, in my experience.  Latest release of Veeam provides greatly improved replication performance through the use of a proxy compression engine at either end.

NB I have no connection whatsoever with Veeam other than as a customer.

[ekisner]

I thought DT's solution looked... old.  Wasn't sure, they were relatively new when we started virtualizing.

As to the proxy compression engines, I must say I agree - blazing fast when you put a bunch of those out there. Almost positive we're going to switch to Veeam.

[muratpe]

hi ekisner,

did you try veeam-replication with SQL and Exchange? Any Problems with inconsistency?

and using veeam-replication you really don`t need any vm-appliance or scratch-disk?

thanx a lot!

pek