replication and ESXi

[bproteau]

[merged]

I am evaluating this product for a large VMware migration. I think this is preferred for our virtual environment but, I'm not seeing great performance numbers. This test is going between 2 ESXi environments with all systems in the same network.

(1) I read where ESXi is slower than ESX. Is this true?
(2) Are there any methods to increase performance with ESXi?
(3) I had considered utilizing Hyper IP for the actual migration but, I'm not clear it would help if the bottleneck is ESXi? We will have a 10Gb connection between the 2 datacenters.

[Gostev]

Replication is dramatically enhanced in v6 (Q4 this year). Particularly, there will be no performance differences between ESX and ESXi.

[bproteau]

Thank you but depending on the actual release date we may be using the current version. we have a pretty aggressive migration timeline. Could you respond to the posted questions with the current version?

[bc07]

Did you read the findings in the previous posts in this forum thread?

[bproteau]

I see how it was merged. I'll look it over thanks.

[caustic386]

If I create a Veeam VM on my target side, can I continue to use the replica that already exists. That is, I replicated 5-6x from source side, now per Veeam's suggestion I will replicate from target side ("pull" the VM instead of "push"). Will I need to reseed/perform full replica?

[Gostev]

You would need to perform full replica, as with v5 seeding is impossible with backup server located at destination site. Thanks!

[Vitaliy S.]

Just wanted to add that, if you transfer Veeam SQL configuration database to the offsite location too, then you should be able to continue using replication existing replication jobs.

[caustic386]

Moving the Veeam box to the target site has certainly increased responsiveness.

Is it possible to preseed backup jobs by redirecting backup location with the Veeam box on the target side?

[Vitaliy S.]

No, this is not possible, since backup traffic goes through the backup server before hitting destination target.

[caustic386]

In that case, is it best to have backups running on the source side?

[Vitaliy S.]

Yes, it is always better to place backup server on the source side to be able to use direct SAN/Virtual Appliance modes for better performance rates.

With version 6 there will be no difference where to install backup server even for replication jobs targeted to ESXi hosts.

[caustic386]

I'm not sure I understand why SAN/VA mode would have a significant impact? Maybe for some shops, but my WAN link is only 10Mb.

[Vitaliy S.]

I was talking about our general recommendation, but in your case it looks like it doesn't matter what mode to use.

[caustic386]

Not to complicate things, but this has brought a few more questions to mind. When a VM is replicated, is an agent copied to the target host to process rollbacks? Or is the VM processed locally? If it's processed locally, does it actively use existing data on the target host or does it process the VM locally and send the results to the target host?

It's probably moot with v6 on the horizon, but I can't get my head around the reasoning for processing WAN backups at the source and WAN replicas at the destination.

[Gostev]

Unlike with backups to agent-enabled repository (Linux server), there is no place on ESXi to install the agent to. Everything is done locally on the server, and results are sent to the target host (good analogy is a file share).

[caustic386]

What is the method used in v6 to get around the agent installation that will make the source/target issue irrelevant?

[tsightler]

In simple terms, V6 will use a VM on the target side as a proxy to receive the replication data as well as some additional modifications which minimizes the amount of I/O that must be performed on the target. This proxy can also leverage hot add to keep the replication traffic completely within the storage stack rather than forcing I/O through the management network.

[tsightler]

Just to clarify, when I said "keep the replication traffic in the storage stack" I'm referring to the I/O portion of the traffic, obviously the actual replication traffic would still need to pass through the VM network. The point is, no traffic has to pass the ESXi managment network stack when using a proxy with hot add capability.

[caustic386]

Will those VM be deployed automatically via automated procedure? One major reason we're switching away from vRanger is their VA requires significant configuration on each host to use HotAdd, plus a "scratch disk" that can grow as large as 100% of the size of all VMDKs being replicated.

[Gostev]

We do not deploy any additional VMs, instead we install a light-weight data mover service to any existing Windows VM you select. Deployment is automated (just a few click in a short wizard). The upgrade is also automated (something that is often overlooked with virtual appliances).

There are no storage requirements on proxies with Veeam.

Also, to use hotadd there is no need to have 1 proxy per host, 1 per cluster is enough. Although frankly speaking, for WAN replication scenario hot add is less important to have (as your primary bottleneck will be your WAN link speed anyway).

Thanks.

[tsightler]

Although frankly speaking, for WAN replication scenario hot add is less important to have (as your primary bottleneck will be your WAN link speed anyway).

Certainly true for the classic WAN, but it's becoming more and more common for WAN speeds to be 100's of megabit or much more, so there are places where hot add is going to be an important improvement even for WAN replication.

[caustic386]

Curently we do not have a cluster, because we don't have shared storage. Will we need to create one for hotadd to function properly? I'm thinking of our LAN/HA replications.

[Gostev]

No, cluster is not required for hotadd.

[hagepat]

[merged]

Hi there,

We have a problem with one site. 2 ESXi 4.1 servers are replicating to eachother. ESXi 4.1 servers both have local storage. There is no SAN involved. Veeam B&R server is installed on ESXi 4.1 (1). We use push replication to Synology iSCSI NAS. Replication is so slow it only peaks at 3MB/s. Veeam Server is virtual, so we use virtual appliance mode. The servers on ESXi 4.1 (2) cannot be replicated with Virtual appliance mode because they are on an other datastore. So network mode is used, but still with 1GB/s network it should be faster then 3MB/s. Replicating the servers of ESXi 4.1 (1) to ESXi 4.1 (2) with datastore on iSCSI SAN is slow, and they are using Virtual Appliance mode.
Does someone known what could be wrong?

Thanks in advanced.

[bproteau]

[merged]

I undersand there was a performance hit related to ESXi so, I wanted to design to maximize performance. All my testing has been done with source side Veeam servers. A Veeam engineer suggested that a pull configuration may provide better performance.

(1) First can someone clarify or confirm that a pull configuration merely means using destination side Veeam Servers instead of source side?
(2) Can anyone offer details on why a pull configuration might provide increased performance?

- Source ESXi 4.1 U1 Hosts and vCenter 4.1 U1
- Destination ESXi 4.1 U1 Hosts and vCenter 4.1 U1
- 10GbE connection between sites (35-40ms latency)

[Andreas Neufert]

Client error: File does not exist or locked. VMFS path: [[cx3_1] ****.vmx].
Please, try to download specified file using connection to the ESX server where the VM registered.

Had the same issue at a customer yesterday with and ESX 5 host. The root cause was a wrong Subnet Mask at VMKernel Interface.