Ask the Expert: Avamar Server, Capacity and Replication

Hello,

great to have this discussion open.

Regrading AV/DD installations. Is it best practice to use link aggregation (i.e. lacp) on the DD or DDBoost interface groups on single physical network ports?

Is there any best practice how to setup replication in a AV/DD environment?
I made the experience that the replication traffic is routed over the management network . Or in other words the network port(s) to which the Hostname of the DD is pinned and not the interface group network cards.

Although when I make static routes it don´t work at a customer.

Avamar replicates backups on DataDomain via MFR (Managed File Replication). If you are trying to setup interface groups for MFR, please reference the document below:

https://support.emc.com/docu61798_Data-Domain-Boost-for-Partner-Integration-3.2.1-Administration-Guide.pdf?language=en_U…

It helps if the performance bottle neck is network bandwidth. It really depends.

Hi Leo,

In Avamar architecture, metadata are an important part of the capacity. And sometimes we have to format the grid or ASN (to add DD for exemple) because there is too much metadata.

For customer this operation is disruptive and could lost old backups because he have not enough space.

Could you tell us if in the future we can clean metadata or expand its space?

regards.

Pascal

Hello Pascal,

In most cases, it is not the metadata container which occupies most space but the data container.

Within the GSAN, there are two primary types of containers for storing data: metadata containers and data containers.

◆ Metadata containers store the metadata for backups.

◆ Data containers store the actual backup data.

Both types of containers are created as required, based on the data that is being backed up.

Metadata can only be written to metadata containers. In addition, after the Avamar server creates containers, you cannot remove them. To illustrate how this process affects metadata capacity, consider the following scenario:

A customer uses an Avamar server as the target for backups. The customer is close to reaching full capacity on the Avamar server, and thus purchases a Data Domain system to provide additional capacity for backups. The customer then decides to transition existing backup workloads to the Data Domain system. Doing so results in a decrease in the amount of GSAN capacity used on the Avamar server. The customer then begins adding new backup workloads that require significant metadata capacity to the Data Domain system. The space freed in the data containers cannot store new metadata for the additional backup workloads. New metadata containers must be created for new workloads that require substantial metadata storage (for example, file system backups with lots of files).

The Avamar server must have sufficient disk space available to create new metadata containers. If the server has already allocated data containers, the disk space might be insufficient for creating new metadata containers.

For more information, please reference the following document:

https://support.emc.com/docu49793_Avamar-Metadata-Server-Capacity-Technical-Note.pdf?language=en_US

Hello All,

What kind of impact can a WAN optimization device like RiverBed have on Replication between Avamar--Data Domain pair?.

Regards

Raghav

Thank you Leo

Hello Raghav,

Since Avamar/DD replication Dedups, it only transmits network packets that are unique, and therefore only transmitted once. If you put in a Riverbed/Steelhead solution between the replication source and the replication target, since every network package is unique the Riverbed appliance will record it in its local cache and transmit the full packet. Since that packet is never transmitted again the data just takes up cache space on the Riverbed that could be used for real repeating network transmissions.

It is kind of like Zipping up a Zip file, you don’t get any more compression out of it, but the result is a slightly larger zip file, and you used extra resources to do the second zip and unzip to do it, resulting in negative benefits.

But if you can configure the Riverbed to ignore certain specific IP port packet traffic, that is used by Avamar/DD replication communications, you can still use Riverbed to speed up your normal over WAN traffic without negatively impacting the performance of the Avamar/DD replication traffic, or the regular network traffic over the Riverbed solution.

This Ask the Expert event has officially ended, but don't let that retract you from asking more questions. At this point our SMEs, after addressing all questions previously posted, are still welcomed to answer and continue the discussion though not required. Here is where we ask our community members to chime in and assist other users if they're able to come up with accurate information. Additionally, you're welcome to post other questions unrelated to the topic of this ATE on the Avamar community.

Many thanks to our SMEs who selflessly made themselves available to answer questions. We also appreciate our community members for taking part of the discussion and ask so many interesting questions.

ATE events are made for your benefit as members of ECN. If you’re interested in pitching a topic or Subject Matter Experts we would be interested in hearing it. To learn more on what it takes to start an event please visit our Ask the Expert Program Space on ECN.