Automated Veeam Cloud Connect deployment: 2 – install all the roles

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

In my previous post, I explained how to automatically add all the different managed server to a Veeam Cloud Connect installation. The servers are now all listed in the Console, but still no role has been assigned to them. That’s what we will do together in this post.

Who does what

In my Veeam Cloud Connect installation, these are the servers I used and their roles:

vbr       Veeam Server (already installed)
em        Enterprise Manager (already installed)

wan1      WAN Accelerator
wan2      WAN Accelerator

lnxrepo   Linux repository
refs1     Windows Repository extent for SOBR
refs2     Windows Repository extent for SOBR
refs3     Windows Repository extent for SOBR
refs4     Windows Repository extent for SOBR

proxy1    Proxy for Replica jobs
proxy2    Proxy for Replica jobs

gtw1      Cloud Gateway
gtw2      Cloud Gateway
gtw3      Cloud Gateway
gtw4      Cloud Gateway

As you can see, there are enough machines to test each possible component and its unattended deployment.

WAN Accelerator

Let’s start with this first role. WAN Accelerator role can be installed with its dedicated cmdlet:

Add-VBRWANAccelerator -Server wan1.cloudconnect.local -CachePath "E:\VeeamWAN" -CacheSize 100 -CacheSizeUnit GB
Add-VBRWANAccelerator -Server wan2.cloudconnect.local -CachePath "E:\VeeamWAN" -CacheSize 100 -CacheSizeUnit GB

The command is executed against the two servers, and it installs the new role, configured the cache into the dedicated E: disk, with a cache size of 100 GB. The execution is extremely fast and the two new WAN accelerators are quickly configured:

Linux Repository

Now, we need the different repositories. Let’s start from the Linux repository, that will be added as a simple repository and used primarely for Configuration backups. Again, there’s a dedicated cmdlet:

Add-VBRBackupRepository -Name lnxrepo -Type LinuxLocal -Server lnxrepo.cloudconnect.local -Folder /mnt/lnxrepo/backups -LimitConcurrentJobs -MaxConcurrentJobs 10 -UsePerVMFile -MountServer refs1.cloudconnect.local -Credentials $LinuxAdministrator

If you are familiar with Veeam the options in the cmdlet are easy: we give the repository a name, we say it’s going to be a Linux type, we point to the server who will act as a repository and the starting folder, we decide to enable the limit of concurrent tasks and we set it to 10; we also choose to use per-vm backup files, and since it’s a Linux machine we need to enable the Mount Server role on another Windows machine. In my case, I picked one of the REFS windows repository, since they are in the same network; finally we re-use the credentials already created in the previous post when we registered the Linux server in the console.

Windows Repositories

We have four Windows repositories to configure this time. Let’ go:

Add-VBRBackupRepository -Name REFS1 -Type WinLocal -Server refs1.cloudconnect.local -Folder E:\Backups -LimitConcurrentJobs -MaxConcurrentJobs 16 -UsePerVMFile -MountServer refs1.cloudconnect.local -Credentials $DomainAdmin

In order to configure all the REFS servers, we only need to replace the name with 2,3 and 4 and run the same line other three times. It’s important to always specify the Mount server and to point this role to the same REFS machine, otherwise Veeam will select the VBR server, which is not a good choice in this case since the repositories and the Veeam server are in two different network segments. Once it’s done, we have all our Windows repositories ready:

Well, almost ready. In fact, we also want these four Windows repository to be grouped into a SOBR group. We can obviously create also this one with Powershell:

Add-VBRScaleOutBackupRepository -Name SOBR-REFS -PolicyType DataLocality –Extent “REFS1”, “REFS2”, “REFS3”, “REFS4” -UsePerVMBackupFiles


Another role, another cmdlet:

Add-VBRViProxy -Server proxy1.cloudconnect.local -MaxTasks 4 -TransportMode HotAdd -ConnectedDatastoreMode Auto -EnableFailoverToNBD
Add-VBRViProxy -Server proxy2.cloudconnect.local -MaxTasks 4 -TransportMode HotAdd -ConnectedDatastoreMode Auto -EnableFailoverToNBD
Remove-VBRViProxy -Proxy "VMware Backup Proxy"

In the first two lines, I’ve configured two proxies and set the maximum concurrent tasks of each to 4 (same as the number of CPUs, following Veeam best practices), transport mode is HotAdd with possible failover to Network Mode. In the last line I’ve also removed the proxy that is installed by default on the Veeam server. The final result is this:

Cloud Gateways

Finally, I need to install the four Cloud Gateways. This cmdlet doesn’t accept a string as the name of the server, so I need to first save the names of the servers as variables:

$gtw1 = Get-VBRServer -Name "gtw1.cloudconnect.local"
Add-VBRCloudGateway -Server $gtw1 -IpAddress -IncomingPort 6180 -NetworkMode Direct
$gtw2 = Get-VBRServer -Name "gtw2.cloudconnect.local"
Add-VBRCloudGateway -Server $gtw2 -IpAddress -IncomingPort 6180 -NetworkMode Direct
$gtw3 = Get-VBRServer -Name "gtw3.cloudconnect.local"
Add-VBRCloudGateway -Server $gtw3 -IpAddress -IncomingPort 6180 -NetworkMode Direct
$gtw4 = Get-VBRServer -Name "gtw4.cloudconnect.local"
Add-VBRCloudGateway -Server $gtw4 -IpAddress -IncomingPort 6180 -NetworkMode Direct


Have you noticed under Cloud Gateways a new node, called Gateway Pools? Yes, I’m playing in my Lab with a Beta version of Veeam Backup & Replication 9.5 Update 4, and among the cool enhancements that are coming in Cloud Connect, it’s Gateway Pools. With them, a provider can group different repositories into pools, and assign only one of the pool to a tenant, so that custom network connections like MPLS or dedicated links can be served at the same time as public Internet.

In my lab, gateways 1 to 3 are exposed over Internet, while gtw4 is dedicated to a (simulated) MPLS connection. To create the two gateway pools is a really simple operation:

$gt1 = Get-VBRCloudGateway -Name "gtw1.cloudconnect.local"
$gt2 = Get-VBRCloudGateway -Name "gtw2.cloudconnect.local"
$gt3 = Get-VBRCloudGateway -Name "gtw3.cloudconnect.local"
$gt4 = Get-VBRCloudGateway -Name "gtw4.cloudconnect.local"
Add-VBRCloudGatewayPool -Name CG-Pool-Internet -CloudGateway $gt1, $gt2, $gt3
Add-VBRCloudGatewayPool -Name CG-Pool-MPLS -CloudGateway $gt4

Now each tenant can received the proper pool it needs. By the way, we’ll see how to automatically configure new tenants in one the next post!