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

0 Flares Twitter 0 Facebook 0 Google+ 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:

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:

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:

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:

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:

Proxies

Another role, another cmdlet:

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:

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:

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!

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