2.5 WAN Accelerators

WAN accelerators are optional components that can be deployed at the service provider to improve bandwidth utilization of remote backups and replicas sent by customers. Even if any Veeam Cloud Connect operation can be executed without WAN accelerators, WAN accelerators become useful components for a service providers willing to offer remote backup or replication services to customers with low bandwidth, or with the need to optimize the bandwidth usage. WAN accelerators are enabled in the Veeam Cloud Connect license given to service providers without need for further licensing, so there is no licensing concern for the service provider when deploying them.

In addition, when the target of a job is Veeam Cloud Connect customers using the Enterprise license are entitled to use WAN acceleration, while in private environments they have to have an Enterprise Plus license.

WAN accelerators at the service provider sit between cloud gateways and repositories (for backup copy jobs) or proxies (for replica jobs). They help improve the bandwidth utilization by caching blocks internally, avoiding the need to transmit every block over the wire.

WAN accelerator is a windows service, so the best platform is a modern 64-bit OS like Windows 2016 or 2019. The same design considerations made for local Veeam Backup & Replication deployments can be applied also in a Veeam Cloud Connect scenario when it comes to WAN accelerators: 8 GB of RAM at least, a fast disk for the cache (a SSD disk or SSD-backed volume is not mandatory, but highly suggested), and the correct sizing for the cache itself. A good choice is to use a dedicated volume for caching, so that in the event of a full disk, it does not create problems for the Windows OS and its running services.

2.9: Prefer a dedicated drive for the WAN accelerator cache

A single WAN accelerator can saturate links up to 100 Mbps on average using the “low bandwidth mode”, depending on the workload. For links faster than 100Mbps and up to 1 Gbps - starting from Veeam Backup & Replication v10 - users can choose to use the new “High Bandwidth mode”:

2.10: High Bandwidth mode

A target WAN accelerator working in Low bandwidth mode can only accept connections from source accelerators in the same mode. In a many-to-one scenario with various source modes like Cloud Connect, where the service provider cannot know in advance which mode each tenant will use, it’s better to choose High-bandwidth mode during initial configuration of the target WAN accelerator settings. In such a case the accelerator will be able to work in both low and high bandwidth modes.

When a service provider configures a new cloud repository for a customer and assigns a WAN accelerator, this relationship is fixed. Even if a service provider has multiple WAN accelerators, only one is used for a given cloud repository, until this configuration is changed. So, when adding new customers or assigning new resources, a service provider will need to balance the assignment of WAN accelerators to customers manually. When sharing one WAN accelerator among multiple customers, a service provider will have to take into account the total bandwidth of the customers and the expected storage consumption for the cache. For example, one WAN accelerator with a 50Mbits bandwidth could be the target of five customers having each a 10Mbits upload speed.

Experience in several environments suggests that the maximum ratio for sharing a WAN accelerator should be 5:1, that is no more than 5 tenants should be connected to the same WAN accelerator. This is however an average value, and on really small upload links (for example, 1-2 Mbps) we have seen a single accelerator capable of connecting up to 20 sources.

Additionally, you should always take into account the failure domain: the more tenants that are connected to the same WAN accelerator, the more that are affected when one of WAN accelerators is not available.

For all these reasons, another design choice that some providers prefer is to offered a dedicated WAN Accelerator to each tenant, in a 1:1 ratio, and describe it as an additional/premium option to customers using it.

Firewall

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

Service	Port
Veeam Installer Service	6160
Veeam Data Mover Service	6162
Veeam WAN Accelerator Service	6164
Veeam WAN Accelerator Service	6165

Ports 6160, 6162 and 6164 need to be open from the Veeam Backup & Replication server to the different WAN accelerator machines. There are also communications between the different WAN accelerators (source and target) happening over port 6164 (the controlling port for RPC calls) and 6165 (data transfer between WAN accelerators). This last communication is tunneled by the cloud gateway so it doesn’t have to be configured in any firewall.

Port tcp-445 needs to be temporarily open to deploy the Veeam components into the Windows server that will act as the WAN Accelerator. It can be then left open, or closed depending on the provider security preferences.

Finally, ports 2500 to 3300 need to be open between WAN accelerators and backup repositories for data transfers of WAN-accelerated jobs. In our design, Wan Accelerators and Repositories are in the same subnet, so there is no firewall between them; in case a provider wants to further segment these two components, keep in mind this additional requirement.

Monitoring

Once deployed, the WAN accelerator has different services installed on the Windows machine that you should monitor to guarantee the best Availability of the service:

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

Protection

From a protection standpoint, WAN accelerators need to be protected properly. A backup job that is WAN accelerated cannot failover to a direct connection if the WAN accelerator fails. The job itself fails until the WAN accelerator is restored or the job is reconfigured for direct mode, and this needs to be done at both ends (service provider and customer). For this reason, having WAN accelerators hosted as virtual machines on a hypervisor with High Availability capabilities is a best practice. There is no need to back up a WAN accelerator because its cache can be populated from scratch when it is redeployed. In order to avoid low performance while the cache is warming up after a redeployment, the service provider can warm the cache before placing the new WAN accelerator into production.