Help with replicating vm's from all around the world

[AndyK]

We currently have 13 remote sites throughtout europe and one major london hub site along with a single DR site which provides DR for all sites including the hub.

Each remote site has two ESX hosts in (either ESX 3.5 or a on older sites 3.0.3) with HP Lefthand VSA iSCSI storage. From each remote site we replicate a single file server to the central DR site in London. The links between the remote sites and central DR are between 5-10 Mbps. This currently uses the standard legacy network replication.

The veeam backup and replication server is a virtual machine which resides at the DR site which pulls all the replication data from each remote site to the DR vSphere ESX hosts and onto shared iSCSI storage.

Does anybody know of a better way to do this? The remote sites will be upgraded to vSphere but due to the number of hosts and the travel required it's not going to be a quick upgrade for the entire enterprise.

We are currentl ynot using Veeam to do any backups, purely replication.

Thanks

Andy

[Gostev]

Hello Andy, you have everything designed exactly how I would recommend in your situation (with ESX 3.x). As you are upgrading you remote sites to vSphere, you can consider switching the corresponding jobs to vStorage API "Network" mode for faster incremental replication runs. Thanks!

[tsightler]

Hi Andy,

We only have 5 sites, and mostly in the US, with only a single site in Europe, and we use Equallogic rather than Lefthand, but our overall design is basically the same and we find it generally works well. We are on vShphere 4 however. We currently use vStorage API network mode and pull the replicas, but this is not the most bandwidth friendly. We're wanting to switch to using a Veeam server at each site to "push" the replicas, but this has the negative side effect that a replica that was "in progress" when a disaster strikes might be in an unrecoverable state unless you active replicate your Veeam SQL database to the DR site. It was just too much complication for our setup so we stuck with the "pull" scenario and let our WAN accelerators handle the bandwidth saving (which they do quite well at).

While this is not really related to your question, I have a question of my own. Why does upgrading to vSphere 4 require you to visit each site? I performed our vSphere upgrade remotely on all of our servers, including our servers in Europe. Are you planning to upgrade hardware as well or is there some other reason that the upgrade requires a site visit? Have you experienced trouble with remote upgrades previously?

[Bunce]

Tom, how did you handle the initial seeding (e.g.to portable hd) given you're pulling? or did you do an initial full replication across the wire?

[tsightler]

We pulled the initial sync across the wire. In some cases this took days but we generally believe that being able to pull the full replica across the wire is important because otherwise, what happens if you have any type of failure that causes corruption at the DR site? You have to worry about seeding all over again. Also, we're still not 100% comfortable with forever incremental replication since there's no method to verify integrity of the remote copy. It would be nice if Veeam would provide some type of "Verify replica" functionality that would compare the two sides block for block. Because of our distrust of this we occasionally pull full replica's over the wire anyway.

[Bunce]

Similar thoughts here, it was only the initial sync holding us back from switching to Pull rather than Push with SQL replication of VBR.

We've got Riverbeds setup, so now that the cache is populated I might give a full sync a try and see how long it actually takes.