"Source" Bottleneck clarification

[digitlman]

I'm now on v7, and all of my backups list the bottleneck as the "Source"

A load breakdown of all my jobs usually is 99% source, 30-40% proxy, network 0-5%, and target 0.

Veeam is installed on my only physical server, and is connected to my ESX hosts over GigE. All of the ESX hosts and SANs are connected via 8G fiber channel.

Would I see any real improvement in backup speed by moving the backup server to FC as well? A few years ago, when I was on v5 of Veeam and few had fewer hosts, I was able to hook it all up over FC, but I don't recall the performance. We have maxed out the ports on our FC switches, and it would cost a lot of money to activate the ports required to again hook the backup server to everything else over FC.

Would it be worth it? My gut says that the biggest bottleneck is getting the data off the SANs, to the hosts over FC, then over the GigE from the hosts to the backup server, and that I would really see no improvement at all.

[tsightler]

Based on this it's sounds like you're running network mode with GigE from the physical machine. That means your backups are limited to the performance of this GigE link, about 120MB/s or so even if you can fully utilize this link. Network mode is also known to not be very fast in general because the data has to pass through the ESXi management stack. That's probably why the bottleneck is source, because that's shows that there's plenty of room in the rest of the pipeline if Veeam could retrieve data faster.

If you had Direct SAN it would likely be faster, assuming your storage is able to deliver speeds faster than 1GigE as the physical server would retrieve the data directly over the FC links, cutting out the GigE completely.

However, another option since you have some concern about cost of additional FC ports, might be to deploy a virtual proxy, and continue to use the physical box as the Veeam server and repository. The advantage here is that the virtual proxy would retrieve the data using the ESXi storage stack, thus via the FC links, but then they would compress the data BEFORE sending it to the physical server over the 1GigE. Since typical compression is at least 2x, it's effectively like getting 2x the bandwidth without doing anything else.

[digitlman]

OK, I created a proxy on a vm and it does seem to work better in that it transfers less data and speeds up the backups.

However, when running more than one job, it pegs the CPU to 100%, causing an alarm. The proxy is set up as a Win2008 R2 vm with 4 vCPUs.

I had to disable all alarm actions for the moment. As an aside, does anybody know a better way to vm-level disable select alarms that is easier than this: http://kb.vmware.com/selfservice/micros ... Id=2007767 ?

[digitlman]

Two more things: I *could* bump the vm to 8 vCPUS....overkill? That would solve the alarm issue. Or better to change the max concurrent in the proxy from 4 to 2?

Also, I did not change the automatic proxy selection on the backup jobs....will it automatically pick the new vm-based one?

[tsightler]

What compression are you using? After you upgraded to V7 did you change the jobs to the new optimal compression? This should lower the CPU on the proxies significantly but you'll have to run a new full backup for this to take effect.

[digitlman]

No. I will check them all now.