Integrating Metallic into an Azure VMware Solution (AVS) Backup Strategy: Need Clarification

Hi,

As for the proxy itself I don’t have experience with AVS, but for Azure cloud or on-prem hypervisors the proxy role is quite simple, it mounts the data during the backup and read the content. When Changed Block Traffic is in use incremental backups are pretty fast. So usually, it can be even powered off for most of the time. 

I don’t know what amount of VMs we are considering, but single proxy can usually handle dozens and in some cases hundreds of VMs If the workload is staggered and the servers are not very large.

In some cases more pressure is put to MediaAgent where deduplication database is hosted and their data blocks are compered. 

Using Azure MABS will force you to go with the Recovery Vaults? If so then backups might be ~2-3 more expensive than with Metallic/Commvault, where decent deduplication is in place. 

Please keep in mind that Metallic is running on shared environment, so with your own MediaAgent or Commvault average throughput can be higher.

If you want to stay with Metallic infra, storage etc. and your Virtual Server Agent (VSA) 1-2 should be enough, but it’s hard to guess what amount of data, VMs, databases etc. we are talking about.

If you want to go with your MediaAgent within Metallic, with your storage etc. then MA can have VSA role as well, but needs to be properly sized, there must be SSD disk for DDB drive, and enough storage provided for primary/secondary copies. I assume that running with your MA will allow you to get better results. 

Here are basic requirements for such System Requirements and Hardware Specifications for an On-Premises Deployment of the Metallic Backup Gateway

Commvault documentation covers more detailed specification per amount of data protected, but this part of documentation is closed Hardware Specifications for Deduplication Mode (commvault.com). If you are having conversation with Metallic sales already you can ask them to provide you the details, maybe help with initial design (about that I’m not entierly sure). 

greatly appreciate your response, lukas3d. It's filled with useful information. Thank you.

Regarding Metallic, it's my understanding that the Metallic Gateway Server (MGS) serves dual roles as both a proxy and a data mover. We plan to locate it in a separate Vnet to segregate the devices that have internet exposure. In this arrangement, I'm pondering if an extra proxy preceding the MGS in the AVS environment is required. Is such a configuration supported, or is there a need for separate MGSs, even within the AVS framework?

Please forgive me if my question comes across as simplistic. I am still familiarizing myself with Metallic.

It can have multiple roles installed, usually MediaAgent  is data mover + hosts deduplication engine + access to storage Metallic Gateway is actually the same. You can install virtual server proxy on it to allow it to use VMDK libraries (or AVS equivalent) and provide VMware backups. Ideally proxy should be within the environment to allow it to use HotAdd transport mode. 

nicky wrote:

In a recent test, deployed the Metallic Gateway server as an Azure Native instance within its dedicated vNet. Using the NBD transport mode, the VM image backup process performed smoothly and efficiently. This result contradicts Commvaults existing documentation, which stipulates HotAdd as the exclusive method for executing AVS backups with Metallic.

If Commvault can verify that the NBD method is indeed certified method, it would alleviate the need for us to establish internet access for the proxies to connect to Metallic, thus avoiding the difficulties associated with setting up proxies and HotAdd. Currently, we dont have an active Metallic subscription so are not able to raise a support ticket for further investigation. We've reached out to the sales team, but this route might take some time.

Open to suggestions and welcome any feedback that could help us here.

 

 

NBD should work as long as proxy can reach VMware via network, but this backup/transport mode is slow due to working only at network layer. HotAdd will allow you to provide backups (and restores) few times faster, due to mounting VM disks to proxy directly and reading the content from the proxy. 

Maybe documentation isn’t up to date or there are some additional limitations. 

I appreciate your response, @Lukas3D. You have been incredibly helpful. Just to confirm, NBD is indeed a certified transport mode that works with AVS, correct?

If you don't mind, could you please provide more details about the limitations you mentioned? Apologies for asking numerous questions. 
 

In addition, do you recommend any specific network requirements that we should follow, such as a network topology or a persistent tunnel between CS->Proxy->client? I've noticed that there are a few sections missing on the Metallic Command Center. Could this be due to the trial version we are currently using?

Good day @nicky 

Based on what I can see here https://docs.metallic.io/metallic/143833_azure_vmware_solution.html - only Hotadd mode is supported for AVS.

nly HotAdd transport mode is supported. SAN and NBD transport modes do not work with VMware Cloud on Microsoft Azure.

In reference to your second question, all traffic for Metallic leverages port 443 and the network routes are not required to be defined.

Thanks

Mike

Thanks so much @Lukas3D and @Michael Mancino , you guys have been a great help! We ended up setting up internet access for the proxies to link up with Metallic, and we used hotadd for backup. It seemed to work pretty well, but we've also asked Commvault to let us know if NBD is their preferred method. We're really focused on using methods that have the Commvault stamp of approval. Thanks again for all the assistance, you've been fantastic!

Hi @nicky 

We do not support SAN and NBD for Azure VMware Solution as suggested in https://docs.metallic.io/metallic/143833_azure_vmware_solution.html.  Since Metallic is built on Commvault software, it inherits all commvault certified features and method.