Solved

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

  • 15 June 2023
  • 9 replies
  • 286 views

Badge +2

Hello Metallic Community,

I am currently researching a comprehensive data protection solution for our Azure VMware Solution (AVS) environment. While evaluating different backup solutions, Metallic caught my attention due to its cloud-based nature, potentially offering a seamless integration with our mostly cloud-based components.

However, in the course of my research, I found information suggesting that AVS primarily supports the hotadd transport mode for data protection. Given this, I'm trying to understand if it's mandatory to have a proxy within the AVS environment to perform backups.

To provide some context, I'm considering setting up our backup server (potentially Azure MABS or Metallic Backup Gateway /Metallic MA) within a dedicated VNet. This setup aims to isolate our internet-facing devices in a separate VNet. The plan is to establish connectivity to AVS via ExpressRoute, allowing our backup solution to interact with the AVS vCenter,  take snapshots, transfer the data to a local disk on the Media Agent, and then push another copy to the Azure Blob for additional redundancy and data protection.

Can you provide clarification on the requirement (if any) for a proxy within the AVS environment given the hotadd transport mode? Any insights, suggestions, or experiences that can assist me in designing this backup solution effectively for an AVS cloud workload would be greatly appreciated!

Any best practices recommendation or Generic Validated designs would also help.

Thank you for your time and expertise.

I have a similar post in the Commvault community, but wasnt sure if People here in the Metallic community would monitor these posts, hence created a new one here.

 

 

icon

Best answer by Lukas3D 16 June 2023, 14:29

View original

9 replies

Userlevel 3
Badge +5

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). 

Badge +2

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.

Badge +2


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.


 

 

Userlevel 3
Badge +5

 

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. 

 


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. 

Badge +2

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?

Userlevel 3
Badge +5

It’s one of VMware transport modes Virtual Disk Transport Methods (vmware.com), but usually everything AVS based is referred to be running in HotAdd mode. So, it would be good to confirm with VMware or Metallic/Commvault support, that’s safe in terms of data consistency to use it. 

 

You mean the NBD limitations? The major showstopper is low speed limited by network connection mostly. But if backup scope is low and you are not in hurry, it may work. Just from my experience it’s usually 2-3 times slower. 

 

It’s not due to trail, Metallic is in general simplified version of Commvault, we can call it Commvault for human beings You won’t be able to access or setup some features e.g. network topology on your own, but these features are in place. You can ask support to provide some configuration from the backend and most probably they will agree, but it usually takes time. 

 

In some environments there are e.g. one-way network topologies in place to provide air-gapped communication. In such case only one side can initiate communication. I was using network topologies mostly to tunnel communication in firewalled networks (that’s the origin of this feature). 

Userlevel 3
Badge +8

 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

Badge +2

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!

Userlevel 2
Badge +5

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.

 

 

 

Reply