Proxy Deployment has been intentionally designed to ensure broad compatibility with most customer environments. This necessitated making certain design assumptions about typical customer environments and reasonable proxy capabilities in those environments. Understanding these design assumptions can help you to better understand Proxy Deployment recommendations in order to potentially further optimize proxy deployment at your site. Some of the best practices are also discussed below:
Data change rate
The data change rate is the percentage of a client file system that actually changes between backups. Data change rates directly impact the number of proxies required to successfully back up all required virtual machines in the time allotted by the backup window. More data to be backed up requires more time, more proxies, or both.
Even though empirical field data routinely reports client data change rates of 3-4% per day, by default Proxy Deployment assumes a client data change rate of 12% per day. The intentionally conservative use of 12% as a design assumption provides a buffer.
If client data change rates at your site are routinely lower or higher than these assumed values, you can add or delete proxies as needed. You can also shorten or lengthen the backup window.
Proxy data ingestion rate
Proxy data ingestion rate is another parameter that directly impacts the number of proxies required to successfully back up all required virtual machines in the time allotted by the backup window. By default, Proxy Deployment assumes that each proxy can run 8 concurrent backup jobs and process 500 GB of data per hour.
While an assumed proxy data ingestion rate of 500 GB per hour is a very conservative estimate, a number of factors at each customer site directly affect the actual proxy data ingestion rate. Some of these factors are the:
Avamar server architecture (physical Avamar server using a Data Domain system for back end storage versus a virtual Avamar server hosted in vCenter)
Type of storage media used for proxy storage
Network infrastructure and connectivity speed
SAN infrastructure and connectivity speed
If proxy data ingestion rates at your site are routinely lower or higher than 500 GB per hour, you can add or delete proxies as needed. You can also shorten or lengthen the backup window.
If your site consistently experiences substantially different proxy data ingestion rates (that is, either substantially lower or higher than 500 GB per hour), you can permanently change the default proxy data ingestion rate setting, which will affect all future proxy deployment recommendations. To do this:
Open a command shell and log in to the Avamar server as user
admin.
Switch user to root by typing
su -
.
Open
/etc/vcs/dm.properties in a UNIX text editor.
Change the
proxy_ingest_rate_gb_per_hour setting.
Save your changes and close
/etc/vcs/dm.properties.
Protecting against proxy over commit
By default, each Avamar proxy is configured to allow 8 concurrent backup jobs. This setting is known to work well for most customer sites.
We recommend against increasing the number of concurrent jobs to more than 8 because it can lead to a condition in which too many backup jobs are queued for a given proxy (proxy over commit). This causes uneven distribution of backup jobs among proxies, and can also cause a bottleneck in which backup jobs to take longer to complete than they otherwise might.
Some sites might benefit from configuring some proxies to allow fewer concurrent backup jobs. This generally requires deploying additional proxies, but can result in more even distribution of backup jobs among proxies, as opposed to concentrating or clustering backups in a certain area of the virtual infrastructure.
Optimization for level-1 incremental change block backups
When Proxy Deployment generates a proxy deploy recommendation, it does so by calculating how many proxies are required to sustain normal backup operations. One of the assumptions about normal backup operation is that backups will be level-1 incremental or changed block backups, not level-0 full backups.
Level-0 backups inherently take longer and use more proxy resources. Therefore, large new virtual machine deployments can adversely affect the ability to complete all required backups in the time allotted by the backup window.
For this reason, whenever possible phase-in large new virtual machine deployments in order to give the system an opportunity to ingest the necessary level-0 backups.
If a phased-in deployment is not possible, another approach is to tolerate the failed backups that will occur due to proxy over commit. Once the system begins to settle, proxy resources will be under committed, and those virtual machines will eventually be backed up. Administrators should monitor the situation closely to ensure that the system does settle and that the virtual machines eventually do successfully back up.
NOTE:Avamar will attempt to deploy proxies where needed, but it is impossible to know all details about the environment so it is important you verify the proxy deployment does not over allocate proxies beyond the maximum supported.
Proxy PDM support for thin provision
To enable Proxy deployed from PDM to use thin provision disk by default, perform the following step:
Edit
/etc/vcs/dm.properties on utility or AVE node to update the value of parameter
proxy_disk_provisioning_policy as following:
proxy_disk_provisioning_policy=thin
If you do not see this parameter or the value of this parameter is empty or is set to a value other than thin, PDM treats this as Thick Provision Lazy Zeroed.
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\