Backup Proxy NIC Bottleneck

[jbarrow.viracoribt]

Hi there.

I'm new to replicating with this product. I have a production vCenter environment and a backup environment in another building. Both environments have identical Cisco UCS blades running ESXi 5.1, and identical SAN's.

Since my production and backup networks are on the same fibre network. I decided to go with only one physical proxy server. This proxy has direct access to both my production and backup SAN's. I did try the two proxy method and backups were slower. I think that was because the proxy at the production site was sending data over Ethernet to the proxy at the DR site which was slowing things down.

So, replication jobs are running, but I seem to be limited by the Ethernet speeds in my proxy server. While a replication job is running I see traffic on the NIC (I only have one connected right now) shoot to 100% for the length of the replication job. When I use TCPView to see what's going on I see that the VeeamAgent.exe process is receiving tons of data from the originating ESXi host.

So my question what should I do here? Can the ESXi hosts and the proxy servers communicate over fibre channel? I really want to get all of my data transfers for replication off my Ethernet network if at all possible.

Thanks in advance.

[tsightler]

Direct SAN can be used to read data, but cannot be used to write data on the target. You can see what mode is being used by looking at the job stats screen. Highlight the VM and the first few lines of the log will look something like this:

Code: Select all

2/15/2013 12:01:23 AM :: Using source proxy <name_of_proxy> [san]
2/15/2013 12:01:23 AM :: Using target proxy <name_of_proxy> [nbd]

In the example above the data is being read from the source via the SAN, but written to the ESXi host via network mode. The only way to do completely "LAN free" replication is to use a virtual proxy and hotadd. The ESXi that the proxy is running on must have the datastores from both the source and target systems presented and mounted.

[dellock6]

Jonathan, Veeam DirectSAN is available only when reading but not for writing to SAN, so your single proxy is getting data from source san, but is writing it via ethernet. Are you sure the two-proxies setup was slower than a single proxy? Sounds strange to me... Proxy is at source site or destination?

Since Veeam proxies are connected each other via tcp, there is no way to avoid network connection. What you can do (and many customers do) is to create a BAN (backup area network) via dedicated nics or VLANs for your proxies, so this traffic does not flow into the VM network.

Luca.

[jbarrow.viracoribt]

Jonathan, Veeam DirectSAN is available only when reading but not for writing to SAN, so your single proxy is getting data from source san, but is writing it via ethernet. Are you sure the two-proxies setup was slower than a single proxy? Sounds strange to me... Proxy is at source site or destination?

Since Veeam proxies are connected each other via tcp, there is no way to avoid network connection. What you can do (and many customers do) is to create a BAN (backup area network) via dedicated nics or VLANs for your proxies, so this traffic does not flow into the VM network.

Luca.

Backing up using two proxies took twice as long. A 60GB VM took about 20 minutes with two proxies. With a single proxy the VM took about 12. Keep in mind, both of my "sites" are on the same fibre channel network.

[dellock6]

Hotadd as a lot of actvities to prepare the VM before effectively starting the copy, you can clearly see them in the log. How much of that time is consumed by for example copy the same VMDK disk of a given VM, do you have a comparison between the two jobs?

Keep in mind you are NOT comparing HotAdd-1proxy with HotAdd-2proxy, the other job is DirectSAN with network mode at destination. It's not the same stuff, and sometimes right because all of the preparation activities of hotadd, it happens on small VMs (60 gb is small!) network mode is faster because it skips all those pre-activities...

Luca.

[jbarrow.viracoribt]

Hotadd as a lot of actvities to prepare the VM before effectively starting the copy, you can clearly see them in the log. How much of that time is consumed by for example copy the same VMDK disk of a given VM, do you have a comparison between the two jobs?

Keep in mind you are NOT comparing HotAdd-1proxy with HotAdd-2proxy, the other job is DirectSAN with network mode at destination. It's not the same stuff, and sometimes right because all of the preparation activities of hotadd, it happens on small VMs (60 gb is small!) network mode is faster because it skips all those pre-activities...

Luca.

The first job I had the two proxies specified. Then I changed them both to the same proxy for the second job. The first job was ran, took 20 minutes and some change. I then deleted the replica files, changed the proxies to the same one, and my time was about 12. Just FYI.

What is HotAdd?

[Vitaliy S.]

What is HotAdd?

HotAdd is the second best choice for reading and writing VM data from/to the target storage. Please take a look at our sticky F.A.Q. for further information.