Unsolved
This post is more than 5 years old
2 Intern
•
132 Posts
0
2658
June 6th, 2017 12:00
Backup and restore performance guidelines for integrated Avamar and Data Domain configurations?
So, it looks like there are a few discussions relative to performance "guidelines" for Avamar only configurations - do we have any similar values for integrated Avamar and Data Domain configurations?
I do understand that the most likely "culprit" for poor performance is the client "environment (that is, either the physical client hardware itself or the hardware associated with the VMware environment in the case of VM images) - but it would be helpful to have similar information consolidated in one location for what we might expect from each part of the overall environment like a couple of the Avamar only discussions have.
That is:
1) Bottleneck threshold (approx.) for the Avamar/DD components for backup and restore
2) Bottleneck threshold (approx.)for the network environment (including 10GB networks, if applicable)
3) Bottleneck threshold (approx.) for physical clients
4) Bottleneck threshold (approx.) for VM environment components
As well, I'll likely post a separate sidebar for it, but are there any guidelines as to a "plateau" in terms of overall VMware environment size with respect to determining whether an Avamar solution would suffice for DR, and/or at which point it makes more sense to consider something like Recoverpoint? (ties in to the Avamar performance numbers, of course - just wondering if anyone had a "hard and fast" number)
All comments/feedback appreciated - thanks.
Avamar Exorcist
462 Posts
0
June 9th, 2017 03:00
Given that avtar's job is to reduce as far as possible the amount of data that we send to the back end device, in real world terms, day to day (L1) backups are almost going to bottle-necked at the network or client whether the backup was written to the Avamar GSAN or to DataDomain.
The Avamar server is carefully tuned to permit a certain number of simultaneous client sessions depending on version, hardware type, number of node and whether maintenance tasks are in progress at the time - reference KB 335770
The DataDomain forum would be a good place to check for figures on DD read/write performance but, as with GSAN backups, avtar is going to be filtering out a very large proportion of the backup data leaving relatively little for DD to process.
L0 backups are naturally much more demanding but they are exceptional and generally accepted as a one off 'cost'.
Restores are a very different story since the backup server will need to read and transmit all the backup chunks over the network to the client.
Single node Avamar systems sending backups from the GSAN via a high speed LAN to a client with a high data ingestion capability could potentially see bottle-necking at the Avamar server side. Multi-node Avamar servers in a similar scenario (using the --allnodes flag) would be expected to cause a bottleneck at the client.
My understanding is that DataDomain makes careful use of file locality to enhance restore performance but again, the DD forum would probably be a better place to discuss that particular point and the theoretical or practical throughputs achievable.
Backups being much more common than restores there is more opportunity to investigate performance behaviour. I'd suggest if performing any kind of backup testing to review the avtar informational messages and the comstats statistics to understand what is happening from the client perspective.
The following two articles should be helpful
And since client bottlenecks are often at the storage device hosting the data, the following article may be of interest
VMware image backup performance is highly dependent on change rate of the virtual disks as well as the back end storage performance and contention with other users of that storage.
I'd like to suggest checking out the following article if you'd like to read around it.
KB 487711 - Avamar VMware image backup performance is slow (RESOLUTION PATH)
It's a big topic but I hope that was of some help to you..