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.
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:
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.
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:
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 188.8.131.52 -IncomingPort 6180 -NetworkMode Direct $gtw2 = Get-VBRServer -Name "gtw2.cloudconnect.local" Add-VBRCloudGateway -Server $gtw2 -IpAddress 184.108.40.206 -IncomingPort 6180 -NetworkMode Direct $gtw3 = Get-VBRServer -Name "gtw3.cloudconnect.local" Add-VBRCloudGateway -Server $gtw3 -IpAddress 220.127.116.11 -IncomingPort 6180 -NetworkMode Direct $gtw4 = Get-VBRServer -Name "gtw4.cloudconnect.local" Add-VBRCloudGateway -Server $gtw4 -IpAddress 10.10.109.100 -IncomingPort 6180 -NetworkMode Direct
BONUS! UPDATE 4 NEW “GATEWAY POOLS”
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!