2.9 Proxies

Proxies, deployed at both the tenant and 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.

Veeam offer different types of proxies in Veeam Backup and Replication, but for Veeam Cloud Connect two types are usable:

• VMware Backup Proxy (for Snapshot-based replication)
• VMware CDP Proxy (for streaming replication)

2.24: Available proxies types

Veeam proxies can be installed on Windows or Linux machines. 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.

For more specific sizing, please refer to the official Veeam User Guide or the VBR Best practices.

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.

Considerations for Snapshot Replication

Service providers can deploy a proxy as a virtual machine. This is especially important for Snapshot Replication: if the virtual proxy is deployed on an ESXi host that has a direct connection to the target datastore, 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.25: Backup proxy transport mode

We suggest to use virtual proxies because, because Direct Storage access - available mainly in physical proxies - can be faster but 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).

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.26: 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 16 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.27: Don’t enable unnecessary services

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

Monitoring considerations are different for Windows and Linux repositories.

Windows proxy

The services running on a Windows proxy are:

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
Veeam CDP Proxy Service	VeeamCdpProxySvc	Automatic	Local System

Linux proxy

The services running on a Linux proxy are:

Service Name
veeamdeployment
veeamtransport
veeamcdpproxy

Obviously, CDP services are available only if CDP service has been configured.

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.