Crossed replication - proxy configuration between 2 VCENTER

[DaFresh]

Hello,

I have 2 sites A and B, with on each side :

- 1 VCENTER running with 1 Veeam instance (let say for convenience vcA and vcB). VCENTER (2 nodes each) are running in standalone (separated) mode, and has there own license, as Veeam.
- 1 dedicated Veeam proxy (pxA and pxB)
- 1 NFS datastore, dedicated to store the replicas of the opposite side (nfsA and nfsB). Datastore nfsA is only 'used/mounted' by vcB to store replicas from site B, vice versa.

[vcA - pxA - nfsA] <=> 100Mbits <=> [vcB - pxB - nfsB]

When I configure the replication job (virtual appliance mode) on vcA to use pxA for both src and dst, everything works fine, the links is used at almost its full bandwidth capacity.
But when I configure the vcA job to use pxA as src and pxB as dst, the data flow do some strange "go and back" on the like, something like that : pxA => pxB => vcA => nfsB.

I there a way I can use efficiently both Veeam proxy to do my replications jobs ?
I mean, the ideal data flow would be : pxA => pxB => nfsB. How pxB could send data directly to nfsB, is it even possible ?

Any advices will be appreciated !

Thx

[foggy]

Cedric, pxB proxy should have access to the nfsB datastore to be able to write directly to it.

[DaFresh]

Thx for replying Foggy, you mean 'NFS access' ? Veeam Proxy are able to use the Windows NFS client to access the storage and mount the replicate vhd ?

[veremin]

Honestly, there is nothing special to setup with Hot Add backup mode – just make sure that the ESX(i) host running backup proxy server VM (pxB) has datastore in question (nfsB) connected to it.

I’m wondering in which mode the target proxy (pxB) is specified. Also, when the traffic went back and forth between proxy servers, what did job statistics show regarding target proxy method (was it hot add, nbd,etc)? Thanks.

[DaFresh]

Ok I allow pxB to access nfsB (pure NFS rights) and run a quick test by lauching the replication job on site A (which send replication on nfsB), here are the flows I can see thought the gateway of the site A when the job is running :

pxA => pxB (good)
pxB => vcA (why ?)
vcA => nfsB (and why ??)

Why data are coming back from pxB to vcA then forwarded to nfsB ? Is it because the src and dst proxy are not running on the same vSphere instance ?

[DaFresh]

Honestly, there is nothing special to setup with Hot Add backup mode – just make sure that the ESX(i) host running backup proxy server VM (pxB) has datastore in question (nfsB) connected to it.

I’m wondering in which mode the target proxy (pxB) is specified. Also, when the traffic went back and forth between proxy servers, what did job statistics show regarding target proxy method (was it hot add, nbd,etc)? Thanks.

Job's statistics show that the src proxy pxA use hot add and dst proxy pxB use nbd. Both VCENTER vcA and vcB has RW access to the NFS share, and both proxy pxA and pxB too. I remember you that these 2 VCENTER vcA and vcB and Veeam instances on each are running completely separately with their own licence, there are no common ESXi between them.

[veremin]

Is it because the src and dst proxy are not running on the same vSphere instance ?

Nope, it shouldn’t be the case. As long as you properly specify pxA as a source proxy and prB as a target one, the traffic shouldn’t go back and forth between them.

and dst proxy pxB use nbd

Have you also tried to specify target proxy mode in Hot Add mode and see whether it solves the issue or not?

Anyway, the best way to address any technical issue is to open a ticket with our support team and let them investigate it directly. Thanks.

[foggy]

It's not about NFS rights. You need to connect the nfsB datastore to the host where pxB proxy resides. Am I understanding your setup right?



In this case it's completely expected that data go from prB to the nfsB datastore through vcA network stack.

[DaFresh]

It's not about NFS rights. You need to connect the nfsB datastore to the host where pxB proxy resides. Am I understanding your setup right?

Yes you get it right, nice picture anyway !

nfsB is connected to all VCENTER (thus all ESXi).

Site A and B are on different location, linked with dedicated link. I need to cross the replication in order to have a disaster recovery solution (Site A replicated on site B and vice versa).

In this case it's completely expected that data go from prB to the nfsB datastore through vcA network stack.

So if I understand, I cannot use the proxy of the opposite site for the replication, and use the local proxy for both source et destination ?

[foggy]

nfsB is connected to all VCENTER (thus all ESXi).

So, just to clear it up, is nfsB connected to vcB? Cause in your OP you've stated that it is not:

Datastore nfsA is only 'used/mounted' by vcB to store replicas from site B, vice versa.

If it is, then prB should be able to use hotadd to write to this datastore directly.

[DaFresh]

So, just to clear it up, is nfsB connected to vcB? Cause in your OP you've stated that it is not:

It was not, but now it is, every ESXi and Veeam Proxy has RW access to nfsB, but the data flow is not good, still going back.
Are you sure that the dst Veeam Proxy prB located on a remote VCENTER vcB (not the same as the one where the Veam job is running (vcA), and where the src proxy is (prA), and where the VM "_replica" are registered) is able to locate and use the NFS datastore ? If yes, how the dst Veeam Proxy prB can locate and mount the vhd ? because vcA and vcB are running on there own and only manage VM registered on them, even if they have both access to nfsB, how vcA can 'ask' vcB (where the replica are not registered) to mount the vhd on prB ? vcA can only manage prB via the Veeam layer, not the vSphere one, I think this is the key here.

I think this could work only if both prA and prB are managed on the same VCENTER (thus has access to the same VM and can be managed by Veeam via the vSphere API).

If it is, then prB should be able to use hotadd to write to this datastore directly.

How ? prB is registered on the remote VCENTER vcB .

In the hope the schema is a bit clear ... please correct me if I am wrong.

[foggy]

...the dst Veeam Proxy prB located on a remote VCENTER vcB (not the same as the one where the Veam job is running (vcA), and where the src proxy is (prA), and where the VM "_replica" are registered...)

They should be registered on the vcB for the prB to be able to hotadd them. What is the reason behind such configuration (where the datastore is registered on the remote host)?

[DaFresh]

But vcA and vcB are not linked ! they are ***separate*** VCENTER and Veeam instance (and licences). Veeam running on vcA side register the replicated VM on vcA side (but they are physically on nfsB, on the other side), and cannot access neither ESXi hosts and vm on vcB, but only communicate with the Veeam Proxy Agent on prB.

[foggy]

Cedric, I understand your setup (though not quite realize the reasoning behind), but, as I already mentioned, in this case prB cannot write directly to nfsB datastore, as the host it is running on does not have that datastore connected to it. If you could register replica VMs on the remote vCenter/host, as it is typically done (or just connect the datastore to the remote vCenter), you would be able to hotadd their disks to prB.

[DaFresh]

Cedric, I understand your setup (though not quite realize the reasoning behind)

I think that the point you miss here, since the beginning, is the vSphere/Veeam licensing model :

- Veeam on site A is only connected to VCENTER on site A.VCENTER on the site A can only managed ESXi hosts and VM on the same site, A. Veeam on site A send replica on the NFS nas on site B.
- Veeam on site B is only connected to VCENTER on site B.VCENTER on the site B can only managed ESXi hosts and VM on the same site, B. Veeam on site B send replica on the NFS nas on site A.
- site A and B are on different physical city, different subnet, connected via a dedicated fiber link (100Mbits)
- both NAS are connected on both VCENTER.

Is that difficult to understand that I need to cross the replication between site over the fiber link to keep data safe in case of disaster (fire, storm, meteorite .... what ever you want) ?

For the exemple, let take the job on site A : send replica on the NFS nas located on site B (of course the replicated VM are registers on site A *because there are no other solution* because of the licensing model).
This way, could you explain me *how* the Veeam on site A, which can only manage VM located on site A, can ask the proxy on site B to do something at the vSphere layer (which is needed for hot add mode)?

, but, as I already mentioned, in this case prB cannot write directly to nfsB datastore, as the host it is running on does not have that datastore connected to it. If you could register replica VMs on the remote vCenter/host, as it is typically done (or just connect the datastore to the remote vCenter), you would be able to hotadd their disks to prB.

No, because of the licensing model I cannot (except manually, every day after each replication ...) ask Veeam A to register the replicated VM on VCENTER B.

[Vitaliy S.]

Hi Cedric,

Let me chime in to your discussion.

Your scenario does make sense, but I do not see any issues with Veeam licensing if you decide to add target vCenter Server to the Veeam console.

For the exemple, let take the job on site A : send replica on the NFS nas located on site B (of course the replicated VM are registers on site A *because there are no other solution* because of the licensing model)

Veeam requires license keys only for source hosts, so if you add your target vCenter Server to the backup console and start replicating VMs from site A to site B, there will no issues in terms of licensing. Moreover, this is one of the most commonly used scenarios among our existing customers.

This way, could you explain me *how* the Veeam on site A, which can only manage VM located on site A, can ask the proxy on site B to do something at the vSphere layer (which is needed for hot add mode)?

In your current scenario it is not possible, but if you choose ESXi host from site B as a target for your replication jobs, it will work with no issues, and traffic will not go back and forth over the WAN link.

No, because of the licensing model I cannot (except manually, every day after each replication ...) ask Veeam A to register the replicated VM on VCENTER B.

Veeam does not require license keys for target hosts, so you can add it to the console and use vCenter Server on site B as replication target for your production VMs.

Hope this makes sense.

[DaFresh]

Ok ... Didn't know that Veeam does not require licence key for destination hosts, and now I understand how Veeam can manage remote proxy, it's working perfectly as expected now.

Many thanks to both of you for the time you spend to understand my issue

Veeam is really a very nice piece of software, keep going that way !

[foggy]

Glad that it's working as expected now and thanks for your kind words. Feel free to ask any additional questions you may have.