Azure workloads and access nodes requirement

Hi,

why not to go with Commvault Cloud infra instead? It’s shared under a single CommServe (called a “ring” here), however you won’t be charged extra for the VM’s compute. 

With self-hosted it would be like this, but it might be better to go with on-prem/core Commvault instead of Commvault Cloud (SaaS/BaaS offering) if you want to have full control over the environment.

1. You will need proxy in each region, otherwise delay could affect the backup
2. To reduce the Azure egress costs, it would be better to have three smaller MediaAgents, one per region, with it’s own storage. The backups needs to be replicated to follow 3-2-1 or ideally 3-2-1-1-0 rule
3. Here’s the official Azure architecture guide Public-Cloud-Architecture-Guide-Microsoft-Azure.pdf

May I know the approximate workload scope per region? is it gigabytes, terabytes or maybe closer to petabytes? 

• Thanks for your quick response, Lukas.

• Workloads in scope:

  • Azure SQL Database

  • SQL Managed Instance

  • MySQL Flexible Server

  • PostgreSQL Flexible Server

  • Blob & File Storage Accounts

  • Virtual Machines and VM Scale Sets

• Overall baseline:

  • Total data size: < 300 TB

  • spread across three Azure regions (A, B, and C)

• Questions:

  1. When deploying a local media agent in each region:

     • Can the media agent also serve as an access node?

     • Will combining these roles have any performance impact on backups?

  2. Considering that different workloads require access nodes for backup:

     • Do we need to create separate access nodes for each workload, such as:

       • Azure SQL Database – 1

       • SQL Managed Instance – 1

       • MySQL Flexible Server – 1

       • PostgreSQL Flexible Server – 1

       • Blob & File Storage – 1

       • VMs and VM Scale Sets – 1

     • Or is it possible to consolidate access nodes across multiple workloads?

     • If consolidation is possible, which workloads can be combined without impacting performance?

  3. For VM Scale Sets(VMs are dynamically allocated):

     • Do we have an option to select VM Scale Sets directly as content for backups in Azure workloads?

     • What is the best approach to back up VM Scale Sets?

Hi,

Yes, MA can act as an access node — we use these for Cloud VM backups, so there's no need to deploy a single VM/Access Node for each task. Haven't deployed it for Cloud DBs yet, but it should work (see: Add an Access Node for Azure Cosmos DB for MongoDB).

More tasks mean more resources consumed. If the MA consistently hits 100% resource utilization, backups could be affected, but with proper tuning and workload distribution, it should be fine. Everything will be cloud-native, so performance should be decent. If necessary, MA can be running in clusters. 

I don't think there's a dedicated option to select VM Scale Sets directly as backup content in Commvault's Azure workload protection. The typical approaches depend on your use case:

• Stateful VMSS (persistent data on instances): Back up individual VMs from the Scale Set as standard Azure VMs
• Stateless VMSS (ephemeral instances): Back up the golden image (Shared Image Gallery/VHD) + application-level data (databases, files) rather than the VM instances themselves?

But I’m looking for a confirmation on the below—it would be really helpful!

Considering that different workloads require access nodes for backup:

• Do we need to create separate access nodes for each workload, such as:

  • Azure SQL Database – 1

  • SQL Managed Instance – 1

  • MySQL Flexible Server – 1

  • PostgreSQL Flexible Server – 1

  • Blob & File Storage – 1

  • VMs and VM Scale Sets – 1

• Or is it possible to consolidate access nodes across multiple workloads?

• If consolidation is possible, which workloads can be combined without impacting performance?

Answered already, also, I'm running on BaaS version, so can't see every configuration aspect. If you want to deploy self-hosted configuration then Commvault Cloud shouldn't be primary focus, rather standalone Commvault installation. As it comes to deployment I'd ask Custom Success Manager, they have access to technical contacts, so would be able to confirm design idea.

Thanks for the detailed info Lukas,

I have a few questions regarding our Azure VM backup design using Commvault:

1. VSA Deployment Across Subscriptions
   For backing up ~100 VMs distributed across 4 Azure subscriptions, and to leverage fast backup and recovery using IntelliSnap:

   • Do we need to deploy a VSA proxy in each subscription?

   • Or can a single VSA proxy handle VM snapshots across multiple subscriptions?

2. Network Isolation for Backup Traffic
   We plan to isolate production traffic used for backups by deploying a dedicated backup VNet for the VSA and MediaAgent.

   • With IntelliSnap, since snapshots are mounted on the VSA, will the backup data movement (backupcopy operations to MediaAgent/storage) occur over this backup VNet?

   • Please confirm if this understanding is correct.

3. Streaming Backups – Network Configuration
   If we use streaming backups instead of IntelliSnap: will it use the Production network for backup transfer the VSA/MA?

   • What network configurations are recommended to isolate backup traffic from the production network?

Looking forward to your guidance.

Hello Manoj,

Most of these assumptions are valid; however, it's important to remember this isn't an on-premises environment, it's cloud infrastructure with its own networking model. Backup traffic will sometimes travel directly to Azure storage accounts, and with agent-based backups, data flows either to storage accounts or to the MediaAgent, depending on the configuration.

I don't think designing a backup system for a customer via questions posted on the community portal will result in a successful deployment. I'd suggest reaching out to your sales team or Customer Success Manager, they have access to technical resources who can address all your questions in detail and help validate your architecture before implementation.