Several Virtual Veeam Servers on same subnet

[lars@norstat.no]

I have several Veeam Virtual Proxies and the Veeam server itself is also a virtual server. I'm using the servers effectively as a data mover / replicator between two SAN's .... like this:

Source SAN -> Veeam -> Target SAN

All servers are in the same subnet, but something is wrong because this is the ways it works:

Source SAN -> Random Veeam Server -> LAN -> Random Veeam Server -> Target SAN

As i was told in this tread:

http://forums.veeam.com/viewtopic.php?f=2&t=12196

Veeam chooses the most efficient way to do it, and the most efficient way to do it is to have the same machine Hotadd read and Hotadd write. Transferring data on the LAN between machines using bandwidth and CPU on both machines it very inefficient.

Now, i read in the other tread that there is no way to specify to use the same server as source and target without choosing it manually ... I thought this was only if i used a mix of physical and virtual.

But if this is the way it works no matter what, then i'm stunned. It's called Veeam Backup and Replication after all, and you claim it can do Near Continuous Replication .... That would only be possible if the source and target is at the same site or connected with a line that makes it as close as does not matter.

Then if there is now way to handle this local replication and backup function is now useful because deduplication is pr job, then effectively the software is only useful for site to site replication. Maybe this was the point the whole time, but then i have been seriously mislead by your sales people.

Luckily i haven't bought any licenses yet, and will not buy any before the product is usable for me ....

[Vitaliy S.]

Hi Lars,

Now, i read in the other tread that there is no way to specify to use the same server as source and target without choosing it manually ... I thought this was only if i used a mix of physical and virtual.

What version of Veeam B&R are you running? It doesn't look like you're using our latest version (#6.1), as I have just reproduced your scenario and it works exactly how you've described below:

Veeam chooses the most efficient way to do it, and the most efficient way to do it is to have the same machine Hotadd read and Hotadd write.

Thanks!

[lars@norstat.no]

I am running 6.1 acctually ... Can you give me some details on your setup ?

Then there is the fact that Veeam says that it does not work, if i understand them correctly .....

[Vitaliy S.]

In our labs there are two ESX(i) hosts with local and shared storages. Each host has its own proxy VM that is hosted on the local storage of ESX(i) server, so technically I have two proxy servers which are able to use HotAdd and NBD modes on read and write operations.

In order to reproduce your scenario, I have configured a replication job that was replicating a VM to the same ESX(i) server that it was located on. Replication job was set to automatic proxy selection. When I started the replication job, my first proxy was chosen to retrieve VM data through HotAdd and the very same proxy was chosen to write data via HotAdd mode. As you see that the data flow was exactly the same as what you've described: Source Storage -> Veeam -> Target Storage.

Hope this helps!

[lars@norstat.no]

Maybe, but understand that i not after replicating the server to the same ESXi although you write that you also are able to use the same Proxy aswell .....

At my end it uses one for read and one for write although some times it uses the same server for both, so it seems random ... Did you test just one time ?

I have setup like this:

Source side:
IBM Storwize 7000 SAN

Replication Servers (All Virtual):
VBR1 (Veeam Main server)
VP1
VP2
VP3
VP4

Target side:
IBM DS4700 SAN


All of this is connected through the same LOCAL network and SAN Fabric.

I have about 60 jobs running, some all the time and some every 15 minutes. Until i add more proxies about 20 jobs are running at the same time ...

Sometimes VBR1 will pickup the data and transfer the data to VP1 who will write the data. Sometimes VP2 will read and write and so on .....

In other words it's completely random and ineffective ....

Are you then saying that it should not be like this ? That this is a support case ?

P.s i have read somewhere that ip addresses could have an impact .... VBR1, the VP servers and the Virtual Center machine is on the SAME subnet, BUT the management interface of the ESXi servers are on a DIFFERENT subnet ....

Thnx for helping

[Vitaliy S.]

At my end it uses one for read and one for write although some times it uses the same server for both, so it seems random ... Did you test just one time ?

We have run this test in two similar environments, and the result was the same in both cases. And it's not random as you might think Here is the detailed description of how it works: Proxy issues with v6.1

Btw, how many concurrent tasks have you allowed to run on your proxy servers? And how many replication jobs have scheduled to run at the same time?

[lars@norstat.no]

It is random here. There is no pattern to what server it chooses. I can see in the link that you provide that:

"2. ESX Servers added to the vCenter on same subnet."

Does this mean that the ESX Servers have to be on the same subnet as the Vcenter server for this to work correctly ?

14 jobs can run at the same time on all the servers put together, how many jobs that are trying to run at the same time depends on what jobs are running at the time, some are running all the time and some are running every 15 minutes so some times they run at the same time and some time not.

But i'm going to add alot more Proxy servers so that i can run more jobs at the same time. At the moment i have 28 cores running jobs, but i'm hoping that i can acctually run more than 1 job pr 2 x CPU's at the same time as long as there is no compression or deduplication and i only run replication jobs ....

[Vitaliy S.]

Does this mean that the ESX Servers have to be on the same subnet as the Vcenter server for this to work correctly ?

Not really, it is the proxy server that should be in the same subnet as the management interface of the ESX(i) host.

[foggy]

I guess the reason is in the fact that several jobs are running concurrently reaching the max concurrent tasks number for the proxy. I believe that in those cases when the same proxy has available slots for the new task, it is selected for writing data on target, but when the tasks limit is reached and there is another hotadd proxy available, the job will not wait for the same proxy to write data but will be rather assigned to the available one.

[lars@norstat.no]

Thanks for both replies. I do NOT have the proxy servers on the same subnet as the ESXi host. And the post from Foggy is also revealing ....

I have some work to do this weekend, i will come back with results .....