Replication SAN to SAN

[chrmol]

Hi.
We are pretty new to Veeam backup and replication and is now running i trial on our system that contains 5 ESX hosts (with service console) in a HA / DRS cluster. All of our VMs are running on a single SAN system with 4x2TB datastore.

We would like all (except for a few) VMs to be replicated to another SAN system once every night so we are able to power on our machines on that SAN in case of a disaster on the primary SAN.

Our secondary SAN contains one big lun (9,5TB) created by extends.

The Veeam server is a physical server with 10gb Ethernet and 4gb HBA.

What would be the best way to accomplish this?


At the moment (doing our test with the product) we have configured 5 replications jobs – one per ESX host – each using that ESX host as a container – each using another host in the same cluster as destination.
Our reason for designing it like that is that with this setup we are sure that one job uses on specific host as source and another specific host as destination. At this moment we are using network backup with CBT.
But I fear if one machine gets moved by DRS, that the replication would fail because the VM then will be contained in another job (haven’t tested this yet). How would Veeam handle this?
And back to the first question – is there any better way for doing this kind of replication?

[Gostev]

Hi, you are right - your job setup is not ideal, because due to DRS and using host as container, job content will be changing all the time, which will likely result in some bad mess. So instead, I would recommend using datastores or VM folders to define your replication jobs. This way, each replication jobs' content will always stay the same. Thanks!

[chrmol]

Hi.
I just tried to do a "failover to replica" test - it seems like the "replica" machine has lost the original network configuration. Is that normal behavior?
If so, then i need to configure network settins for all of my machine in the case of disaster on the primary storage system?

[Gostev]

Hi, this is possible if you use DVS (distributed virtual switch), we have this documented in the Known Issues section of the Release Notes document. Otherwise, it is not normal and needs to be investigated. Thanks!

[chrmol]

Okay - ill have a look at the Release Notes document

Another question: Is there any problem related to having one or more VMs in different backup / replica jobs? My concern is if CBT jounal is capable of tracking changes in multiply jobs?

[Gostev]

Arguably most asked question of 2010... and of course answered in my uber FAQ topic.

[chrmol]

Thanks

[nickf]

Sounds like we have a similar requirement to you, the way I've configured things is individual jobs for each replicated VM and they all target the same ESX host at the remote site (if there was an issue with that host I'd just change the jobs). Seems to be working well for us (we've recently done two internal and one full, involving the client, DR test and all were successful). Three main issues we've encountered are:
1). Windows VMs change a lot more than I was expecting (we're currently replicating about 20 (largely static) VMs twice a day over a 10Mbps link (no WAN optimiser) and it's a struggle (this obviously isn't a Veeam issue but just be careful when estimating bandwidth requirements...)
2). We've had a few replication failures leading to us having to delete all the replicated files and re-seed the job again (which can take a couple of days depending on the VM size), we've not raised these with Veeam support yet so entirely possible there's an easier fix (or a way to prevent them happening in the first place...)
3). We're currently configured to push the replicas (i.e. Veeam server is in the production site) however it gives us two issues; we can't use the in-built Veeam replica recovery features (as in DR the Veeam server doesn't exist) and if the DR event occurs mid-replication then the replica is corrupted (at least the way we've configured things).

We're about to start investigating number 3 above more, for example build a Veeam server in DR and see if that can deal with mid-replication DR corruption, by being able to use an older version etc. or just switching to pull replication (I'm sure I read this can adversely effect performance though but might be wrong).

[chrmol]

Hi Nick. Thanks for your inputs
I have also been thinking a lot on #3 - what to do if disaster strikes while running replication? - what do you mean by "pull replication"

[Vitaliy S.]

Christian, this topic should answer your questions, please review in case you didn't see it: What happens if a DR event occurs mid-replication?

[chrmol]

So push and pull is just term of placement of the veeam server right?

[Gostev]

Yep. If you place Veeam in target site, you are pulling the replicated data from another site. If you place Veeam in source site, you are pushing the replicated data to another site.

[chrmol]

Is my understanding right:
If for some reasons my primary SAN storage system goes down WHILE doing replication to secondary SAN system, then the affected VMs (the ones that were actually being replicated in the moment of disaster) would still be usable?
Please note that I’m not doing datacenter to datacenter replication – but only SAN to SAN replication (on the same site)
My Veeam server is a physical server that doesn’t rely on any SAN system (DB and Veeam are on local disks)

[Gostev]

If for some reasons my primary SAN storage system goes down WHILE doing replication to secondary SAN system, then the affected VMs (the ones that were actually being replicated in the moment of disaster) would still be usable?

This is not different from "WAN link or source site" dying in case of DC to DC replication, so what is written in the topic referenced above fully applies here as well. Thanks!

[chrmol]

I just wanted to make sure that I understand it correctly