2.9 Proxies

Proxies, which are deployed at the service provider, are the components responsible for receiving replication data from customers (from their source proxies) and writing data onto the virtual disks of the VMs hosted on the hypervisor where the service provider offers the DRaaS service.

The Veeam proxy is a Windows service, so the best platform to use is a modern 64-bit OS like Windows Server 2016. The correct sizing of a proxy depends on the expected amount of traffic the service provider will receive and on the redundancy design to be realized. At least one proxy per hypervisor cluster must be deployed so that this proxy has access to all the available underlying storage and can then write the received data onto it. To improve performance and resiliency, multiple proxies should be deployed.

A group of proxies can work in concert to create a pool. They can all receive and manage incoming replication data from customers and balance these connections between them. If any proxy fails, another proxy can take care of the existing connections, giving continuity to customer operations.

To streamline the replication process, service providers can deploy a proxy as a virtual machine. The virtual proxy must be deployed on an ESXi host that has a direct connection to the target datastore. In this way, the proxy will be able to use the virtual appliance transport mode (also known as HotAdd mode) to write replica data to the target. This is the most effective transport mode for a target-side proxy:

2.31: Backup proxy transport mode

We suggest to use virtual proxies because, even if Direct Storage access available mainly in physical proxies has limits. While it’s totally fine at the source side of a Replication, it’s heavily limited by VMware VDDK at target: direct SAN is only supported for thick-provisioned disks, while Veeam incremental replication data goes into a snapshot file, which is always thin-provisioned. (You can read here for more information: https://helpcenter.veeam.com/docs/backup/vsphere/direct_san_access_writing.html?ver=95).

By deploying physical proxies, you risk to have those proxies only doing Direct SAN mode on the first day of each replica and then always go for network mode, which is where they will failover. Virtual proxies instead ca use both Virtual appliance mode (when applicable) or Network mode.

During the first run of a replication job, Veeam Backup & Replication creates a replica with empty virtual disks on the target datastore. If the virtual appliance mode is used, replica virtual disks are mounted to the backup proxy and populated through the ESXi host I/O stack. This results in increased write speed and fail-safe replication to ESXi targets.

If the proxy is deployed on a physical server or if the virtual appliance mode cannot be used for other reasons, Veeam Backup & Replication uses the network transport mode to populate replica disk files. For these reasons, service providers should deploy proxies VMs and leave the transport mode configuration as automatic selection with Failover to network mode if primary mode fails, or is unavailable selected.

Concurrency

The service provider should carefully evaluate the concurrency capabilities of a proxy. Supposing that a completely shared environment exists and every proxy deployed in the environment can access every available datastore, Veeam Cloud Connect would dsitribute and assign replication tasks equally to every proxy, but as we explained already for backup repositories, the amount of replications a service provider can receive concurrently is NOT the sum of the maximum concurrent tasks of all the proxies, but the sum of all the tasks assigned to tenants:

2.32: Proxy maximum concurrent tasks

For this reason, service providers should carefully evaluate the overload that proxies can receive, and design their infrastructure accordingly. Veeam best practices suggest a 1:1 ratio between available CPUs in a proxy and the number of maximum concurrent tasks it can manage. If for example a service provider has four virtual proxies, each with four virtual CPUs, his total “theoretical” capacity is 20 concurrent replication jobs from tenants, but still tenants could send more replication jobs, thus overloading the proxies.

For this reason, we suggest to enable Backups and/or Replication services only to tenants that actually requested it, and to avoid to enable by default both options into every tenant setup:

2.33: Don’t enable unnecessary services

Firewall

Once deployed, a proxy has different components listening over different TCP ports:

** Service**	** Port**
Veeam Installer Service	6160
Veeam Data Mover Service (control)	6162
Veeam Data Mover Service (data)	2500-5000

Ports from 2500 to 5000 need to be open between proxies and cloud gateways and between WAN accelerators and proxies for WAN-accelerated data transfers.

** * NOTE: this book is designed for VMware vSphere environments, even if many recommendations can be applied to Microsoft Hyper-V environments as well. For Hyper-V proxies, we suggest to use on-host proxies. Because these components run in the Hyper-V hosts, proper network configuration is required, for example in the firewall rules that allow communications between the cloud gateways and the proxies during replication jobs.* **

Monitoring

Once deployed, a proxy has different services installed in the Windows machine that should be monitored to guarantee the best Availability of the service:

** Service Display name**	Service Name	Startup Type	Log On as
Veeam Data Mover Service	VeeamTransportSvc	Automatic	Local System
Veeam Installer Service	VeeamDeploySvc	Automatic	Local System

Protection

From a protection standpoint, a proxy does not need to be saved because there is no permanent data on it. Also, a new proxy can be deployed in a few minutes while other existing proxies receive customer data.