System Requirements for Virtual Server Agent with Microsoft Azure

Azure Version

For virtual machines deployed in Azure Classic, data recovery to Premium storage accounts is not supported. This restriction applies for replication, VM conversion, and VM restore jobs.

Virtual Server Agent Proxy Requirements

A physical machine or an Azure virtual machine with the Virtual Server Agent (VSA) installed can act as a VSA proxy to perform backups and restores.

A VSA proxy must meet the following requirements:

• The VSA proxy machine must run one of the following operating systems:

  • Windows:

    Configure one of the following versions with the required software:

    • Windows Server 2019

    • Windows Server 2016

    • Windows Server 2012 R2

  • Linux:

    Use one of the following methods:

    • Best Method: Deploy an Azure Marketplace virtual machine image to function as a Virtual Server Agent proxy for Azure. For more information, see Deploying a Microsoft Azure VM from the Microsoft Azure Marketplace.

    • Alternative Method: Configure one of the following versions with the required software:

      CentOS Linux 7.4 or 8

      Red Hat Enterprise Linux (RHEL) 7.4 or 8

      Note

      For RHEL 8 VMs, to install operating system packages that are required to enable automatic installation of Mono, register the VMs with Red Hat.

• Minimum of 100 GB disk space.

• Minimum of 4 GB RAM beyond the requirements of the operating system and any other running applications. For more information, see Sizes for virtual machines in Azure.

• Minimum of 4 CPU cores.

• A VSA proxy for Azure Classic must have an Azure management certificate installed.

• If the Azure subscription includes multiple regions, deploy at least one VSA proxy per region.

• A VSA proxy for Azure must be accessible from Commvault resources outside of Azure. If the VSA proxy in Azure is not accessible using a private IP address from Commvault resources outside of Azure, a public IP address will be required. Note that if a VPN or ExpressRoute is available between on-premise resources and Azure, and if the VSA proxy is accessible using a private IP address from the Commserve and MediaAgent, then a public IP address is not required.

For best results:

• Deploy the VSA proxy and MediaAgent on virtual machines in the Azure cloud.

• Deploy the VSA proxy on an Azure VM that is compute optimized to support faster backups.

• Enable Azure accelerated networking on the VSA proxy/MediaAgent machines in Azure. This step must be completed at the time of deploying the virtual machine. For more information, see the following Microsoft articles:

  • For Linux: Create a Linux virtual machine with Accelerated Networking using Azure CLI

  • For Windows: Create a Windows VM with accelerated networking using Azure PowerShell

• Enable service endpoints for Microsoft Storage on the Azure virtual network subnet where the proxy and MediaAgent are connected. This will ensure that all network traffic from the proxy machine to the Azure storage account is securely flowing through the Microsoft Azure backbone network. For more information, see Microsoft Azure: Virtual Network service endpoints.

• Enable Changed Block Tracking for Azure. Changed Block Tracking (CBT) for Azure provides better backup performance than traditional cyclic redundancy check (CRC) backups. You can use CBT with unmanaged and managed disks.

Guest Operating Systems

Virtual machines being backed up can have any of the guest operating systems that are supported by the Azure platform.

Permissions

To back up Azure VMs that have been encrypted using Azure Key Vault, you need to provide the required permissions.

For more information, see Adding Permissions to Back Up Azure VMs Encrypted with Azure Key Vault.

Azure Endpoints

To support backups and restores that are not available through the Azure global endpoint, create the AzureRegion additional setting on the VSA access node and specify the additional endpoints as values.

For instructions on adding additional settings from the CommCell Console, see Add or Modify an Additional Setting.

Firewall Requirements

Tunnel ports (for example, 8400 and 8403) must be opened in the security group for the instance to enable installation of the Virtual Server Agent to Azure virtual machines and communication with the CommServe system.

If you deploy a CommServe host in an environment with firewalls, create a persistent route from the CommServe host to the VSA proxy, as documented in Setting Up Network Gateway Connections Using a Predefined Network Topology. Specify the RESTRICTED setting for connections from the CommServe host to the VSA proxy (step 3 under If you chose not to use predefined network topologies) and the BLOCKED setting in the CommServe node settings for the proxy (step 9).

If a firewall proxy is installed, configure Internet options for the firewall proxy machine. On the HTTP Proxy tab of the Internet Options dialog box, enter the user name and password for the firewall proxy machine, using only the user name and not including the domain name with the user name.

All requests from VSA proxy machines connect through port 443 of the Azure endpoints. Therefore:

• If a firewall is configured on the proxy machine, then port 443 must remain open.

• If the proxy machine is an instance in the cloud, then port 443 must be opened at the network security group level for the VSA proxy instance.

To access Azure backup and restore services for the Azure regions, incorporate the following URLs in your firewall or proxy settings.

Configuring a Firewall to Install the Virtual Server Agent on a Cloud VM or Instance

To deploy the Virtual Server Agent (VSA) or MediaAgent on a cloud VM or instance when other components (such as the CommServe host) are on premises, configure a Commvault firewall connection between the on premises components and the cloud VM or instance.

Hardware Specifications

For information about hardware requirements for the Virtual Server Agent, see Hardware Specifications for Virtual Server Agent.

DISCLAIMER

Certain third-party software and service releases (together, “Releases”) may not be supported by Commvault. You are solely responsible for ensuring Commvault’s products and services are compatible with any such Releases.