Protecting VM workloads in Azure


Commvault’s ability to protect workloads in public cloud is nothing new, however with the increased popularity of hybrid cloud architectures it makes sense to protect both on & off-premises workloads through a single management platform.

Block-level protection of Azure virtual machines has been available since v11 SP4, further enhanced by SP5 with the introduction of CBT (Changed Block Tracking) and by SP10 with the support for managed disks. At present CBT is available for unmanaged disks only but is roadmapped to support managed disks soon.




The following items should be in place prior to implementing this solution:

  • Commvault infrastructure/test lab installation. V11 SP14 or above.
  • Azure Subscription (keep in mind you have a limit of 4 vcores on a trial)
    • User credentials with Service Administrator capabilities, for logging in to your Azure account.
  • Resource Group created with:
    • Virtual Network Created
      • Azure Virtual Network configured with a Service Endpoint for Storage on the default subnet (or subnet used for the VSA VM)
    • Network Security Group allowing remote access and Commvault firewall ports access to Azure VSA. Typically this would be ports 3389 (RDP) and 8400-8403 (Commvault).
  • Azure Virtual machine with MediaAgent and Virtual Server Agent (VSA) software installed & connected to on-premises CommServe.
    • Connectivity verified with “Check Readiness” function.
    • Best Practice for this AzureVM can be found here.
    • Ensure a Premium SSD disk is allocated for the GDDB. This should be formatted and have a drive letter assigned.
    • Ensure your VSA can resolve If you are using your own internal DNS this may not be the case. More detail here.

It is also advisable to read the cloud architecture guide located here to ensure you have the latest best practice information.


Configure VSA

To configure the Azure VM to function as a VSA:

  1. Configure a Application and Tenant for Azure Resource Manager
    1. Note down your Azure account subscription ID
    2. Submit a new Application Registration
      You can choose the name and Sign-In URL, keep it simple. This will be used in a later step to reference this app registration.
    3. Adjust the required permissions
      1. Select the new application and select the settings blade.
        From the Required Permissions tab select Add:
      2. Click Select an API
        find “Windows Azure Service Management API” and select.
      3. Select “Access Azure Service Management as organization users (preview)” and click Select.
    4. Create a new Key by selecting the Keys blade.
      1. Give the Key a name and expiry and choose save. Take note of the generated key value (Its the only chance you’ll get).
    5. Enter the subscriptions tab.
      1. Select Access Control (IAM) and then Add a role assignment.
        Select contributor & the webapp you created earlier and click save.
        NOTE: You can add a custom JSON role here, see the official documentation for details.
    6. To configure the VSA pseudoclient within Commvault (Next Step) you will need:
      1. Your subscription ID
      2. The Key you assigned to the application.
      3. Your Tenant ID. This can be found under Azure Active Directory –> Properties –> Directory ID
  2. From the CommCell Console, Create a new Azure Virtualization client NewAzure.PNG
    1. Enter the credentials as follows:
      Subscription ID: From Subscription Properties
      Tenant ID: From Azure Active Directory
      Application: For App Registrations
      App Password: Key Created during App Registration.

Configure Disk Library

We are using Azure BLOB (Binary Large OBject) storage to store the protected VSA data.

  1. From the Azure Portal, Select Storage Accounts.
  2. Create a New Storage Account

    1. The name should be unique (and will be used when creating the cloud disk library later on).
    2. Account Kind should be Blob Storage.
    3. Replication can be chosen based on requirments, for a lab LRS is fine.
    4. Hot is best for primary backup targets.
    5. Click Review + Create. (You can add Tags & encryption options etc via advanced options if desired)
    6. Click Create
  3. Goto the newly create blob storage and select Keys.
  4. Select one of the access keys and copy for use later.
  5. Create a New container within the blob storage:
    New COntainer.PNG
    Configure as follows (choose your own name)
  6. From the CommCell Console, create a new Cloud Disk library, configure as follows:

    1. MediaAgent: Your Azure VSA/MediaAgent
    2. Service Host: leave default (in most cases)
    3. Access Key ID: The Key you copied earlier
    4. Account Name: The unique name you created earlier.
    5. Click Detect. Select the container you created earlier.
    6. Click OK.

Configure Global Deduplication Database (GDDB)

To make the most efficient use of your newly created Blob library, you’re gonna want it deduplicated. To configure the GDDB you’ll use the standard process as follows:

  1. From Storage Resources, RIght Click Deduplication Engines and select New Global Deduplication Policy
  2. Give it a name and choose next
  3. Select the previously created BLOB library and click next.
  4. Select the Azure VSA MediaAgetnt and choose next.
  5. CHoose whether you woud like to encrypt your data, keep in mind that Azure blob storage is encrypted by default anyway.
  6. Click Next until the Specify location page appears. Specify the location of the Premium SSD allocated for the GDDB.
  7. Click next until the process is completed. As this is a cloud library it will automatically specify the deduplication block size to 512Kb.

Configure Storage Policies

You are now free to create a storage policy using the new Global Dedupe policy as it primary. You can also (from SP14) add this GDDB as an additional copy in existing 128Kb based policies. See Change in Default Block Size on this link. I wont go into the details of creating a storage policy here, if you need a guide, check out Commvaults Books Online.

Create subclients and kick off your first backup!

You created your Azure pseudoclient earlier on, now its time to create a subclient to protect your selected VMs. The default subclient will automatically pick up anything it has the permssion to see so its usually best to create separate subclients to create granular control of retention & scheduling.

Azure subclients can select their content by:

  • Name (Wildcard if needed)
  • Resource Group
  • Region
  • Storage Account
  • Tag
  • Power State
  • A combination of the above 🙂

How you organise things depends on your environment. Tags can work well as once set up, any backup requirements can be set when creating the Azure VMs.

Associate your subclient with your Azure Storage Policy and kick it off. If you want higher throughput try increasing the instance size or adding additional proxies.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s