Veeam v EMC MirrorView

[icebun]

Here's a quick note of our environment:-

Primary Site:-
4 x 3.5 ESX Hosts
16 TB FC SAN - EMC Clariion CX-320

DR Site
2 x 3.5 ESX Hosts
16 TB iSCSI SAN - EMC Clariion CX-320

I have been having performance problems with using EMC MirrorView which replicates at the SAN level and was thinking of using the Veeam product instead.

My main worry is that it seems the way it works relies heavily on the use of VMware snapshots, which in itself can be problematic.

Can anyone advise if there are any pitfulls I should be considering?

By the way some of our VMDK files are quite large 1.3 TB in some cases.

[Gostev]

Actually, what is really problematic is the fact that SAN level replication does NOT use snapshot and instead produces crash-consistent replicas. This is actually the main reason why most customers prefer our replication to SAN-level replication. Crash-consistent replicas are similar to pushing reset on working server, and so are pretty useless for many application: in the best case, you will have lost transactions - and in the worst case, replica will not be able to start. Veeam replication uses VSS to quiesce all application inside VM to ensure there are no lost transactions, additional Veeam configures apps to perform VSS-aware restore, which is required for Domain Controllers or Exchange servers for example to ensure successful failover to replica.

But for large VMs of 1TB and more, I strongly suggest that you first upgrade to ESX4, otherwise incremental replication cycles will be taking way too long time.

[tsightler]

To be fair, EMC has host agents that can be used with MirrorView to create consistent replica's. We used to use EMC MirrorView/A with a FCoIP gateway to replicate our critical data, and of course that has the advantage of being able to replicate data from physical servers as well.

We're now using Veeam because we dumped our EMC storage, and Veeam is far more bandwidth friendly than the replication in our current storage solution, especially when combined with our WAN acceleration boxes. Also, Veeam works with any VM no matter the storage vendor so that's pretty nice. I guess all options have their advantages and disadvantages.

That being said, I'd say Veeam is pretty much unworkable for replicating 1TB VM's with ESX 3.5 since Veeam will constantly have to scan the entire VMDK file to find the changed blocks it will put too much stress on the source storage, and probably be too slow, unless you were only going to replicate a few times a day. Upgrading to ESX 4 with block change tracking would likely bring this into setup that would probably work. We haven't really had any issues with snapshot removal because in general with ESX4 the replication cycle is very short and thus the snapshot is small and takes very little time to commit.

[icebun]

Hi Tom,

Thanks for the response.

The real problem I am having at the moment is that the RLP luns are based on SATA drives and maxing out I/O wise. We also use McData routers to handle FCoIP as well. And to be fair, it's fast, apart from the performance hit.

What I really need is some EMC FC disks instead but they are mega expensive so that is why I am looking into Veeam as a more cost effective solution and dump MirrorView /A. But means I need to get to ESX 4.0 first (next month or so).

It's either that or stick with EMC MV and cough up for the disks.

By the way, how did you configure your Veeam server, is it a VM running in Appliance mode?

[tsightler]

Our Veeam server is currently an old, and severely underpowered Dell 2650, but it actually seems to work fine for replication. It's only Optimal (and of course Best) compression backups that truly work the server. We've tested running Veeam in a VM, but using iSCSI seems to be somewhat unstable, and using Virtual Appliance mode has quirks that we've been waiting to get worked out (see threads on Virtual Appliance mode and snapshot removal).

[icebun]

Sorry Tom,

Did you say that the PE 2650 is SAN attached or are you using Network mode?

[tsightler]

iSCSI SAN attached and using vStorage API (Qlogic iSCSI HBA with EQL load balancing agent). I don't think you can get block change tracking with Network mode.