Automated Veeam Cloud Connect deployment 4: Create new tenants

Luca Dell'Oca,

In the first three posts of this series I’ve showed you how to automate the building of a Veeam Cloud Connect environment. Now that the environment is ready, today we’ll automate also the onboarding of new customers.

Part 1: Credentials

Before we assign any service to a new tenant, the tenant itself needs to have his credentials properly configured. It’s in fact totally possible to create a user with NO services at all, but with a username and password to connect to Cloud Connect. A use case for this is Veeam Backup for Office365 when connected to Cloud Connect for self-service restores.

By the way, I’ve already used this piece of powershell code in my previous posts, to randomly create complex password:

$asci = [char[]]([char]33..[char]95) + ([char[]]([char]97..[char]126))
$tenant_pwd = (1..$(Get-Random -Minimum 9 -Maximum 14) | % {$asci | get-random}) -join “”

The script is this:

### Create new VCC tenant
# Ask tenant account name
$tenant_account = Read-Host -Prompt 'Input tenant name '
# Password is randomly generated
$asci = [char[]]([char]33..[char]95) + ([char[]]([char]97..[char]126))
$tenant_pwd = (1..$(Get-Random -Minimum 9 -Maximum 14) | % {$asci | get-random}) -join “”
 
# Create the tenant
 
try
{
    Add-VBRCloudTenant -Name $tenant_account -Password $tenant_pwd -Description $tenant_account
    Write-Host "New tenant $tenant_account has been created, please save the password: $tenant_pwd "
}
 
catch
{
    Write-Output "User creation failed, see errors below."
    throw
}

The script asks for a tenant name, and tries to create. If a tenant with the same name already exists, it errors out, otherwise it uses the random password code and creates it:

(don’t worry, the password you see here has been changed after I took the screenshot).

The user is immediately created with no assigned services:

Part 2: backup services

If the user also request some services, we need to create them and assign them. The first one is backup, and the code we need is this one:

 ### Assign Backup Resources
$tenant = Get-VBRCloudTenant -Name $tenant_account
$repository = Get-VBRBackupRepository -ScaleOut -Name SOBR-REFS
$repository_name = $tenant_account + "_repository"
$cloudrepo = New-VBRCloudTenantResource -Quota 200 -Repository $repository -RepositoryFriendlyName $repository_name
# List available Gateway pools to be used
$cgpool = Get-VBRCloudGatewayPool | Format-List -Property Name
Write-Host "Avaiable Gateway pools to be assigned are:"
Echo $cgpool
$selected_cgpool = Read-Host -Prompt 'Write the desired Gateway pool '
$tenant_cgpool = Get-VBRCloudGatewayPool -Name $selected_cgpool
Set-VBRCloudTenant -CloudTenant $tenant -EnableResources -Resources $cloudrepo -EnableBackupProtection -BackupProtectionPeriod 14 -GatewayPool $tenant_cgpool -GatewaySelectionType GatewayPool -EnableGatewayFailover -MaxConcurrentTask 1

This code is created to quickly build a working Lab, so as you can see some variable are already configured. You can use Read-Host to ask the administrator to input them during the execution of the script if you prefer. The script also lists the available Cloud Gateway Pools and asks to select one (as explained in the previous posts, this is a Beta version of Cloud Connect 9.5 Update 4, with this new feature):

This is because, once all the existing gateways are assigned to a pool, there’s no “default” pool anymore and thus it has to be explicitely selected. The backup resources are now enabled for the “test” user and a new cloud repository is available:

In the script you can also see the options to configure the use of Capacity Tier, another new feature of upgrade 4.

Part 3: replication services for vSphere

When consuming vSphere for replication resources, every configuration has to be in place before we start to onboard customers. This means that we have to configure in advance the networking part. To do so, we need to load the needed VLANs into Veeam Cloud Connect:

$vcc_replica_cluster = Find-VBRViEntity | where Type -EQ "Cluster"
$dv_switch = Get-VBRViVirtualSwitch -Server $vcc_replica_cluster

New-VBRCloudVLANConfiguration -Server $vcc_replica_cluster -ViVirtualSwitch $dv_switch -FirstVLANWithInternet 120 -FirstVLANWithoutInternet 135 -LastVLANWithInternet 134 -LastVLANWithoutInternet 149

This command gets first the underlying vSphere cluster, reads the distributed virtual switch that’s available (I only have one so the command is simplified), and uses these parameters to create the needed VLANs on top of the defined virtual switch:

And we can immediately see the VLANs loaded into Cloud Connect interface:

Then, we need the public IPs to be assigned to the external interface of the Network Extension Appliance. Again, there’s a command for it:

Add-VBRCloudPublicIP -FirstIpAddress 185.62.37.101 -LastIpAddress 185.62.37.104

This commands loads my 4 public IPs into Cloud Connect, ready to be assigned to new tenants:

Before we can create replication resources for our first tenant, we also need a hardware plan. This can be done with this command:

$replica_datastore = Get-VBRServer -Name esx1.cloudconnect.local | Find-VBRViDatastore -Name vsanDatastore

$replica_ds_friendlyname = $tenant_account + "_replica_repo"

$replica_hwp_datastore = New-VBRViCloudHWPlanDatastore -Datastore $replica_datastore -FriendlyName $tenant_account -Quota 1000

What are we doing here? We start from identifying which vSphere datastore will be used to store replicated virtual machine, and to do so we need to read the datastore connected to one of the hosts of the cluster (the cluster itself cannot be passed as a parameter).

Then, we give it a friendly name since this will be the name that will appear to the customer.

We then set the quota for this datastore to 1000 GB, that is 1 TB.

Finally we “combine” the different objects into the Hardware Plan:

Add-VBRViCloudHardwarePlan -Description $tenant_account -Datastore $replica_hwp_datastore -Name $tenant_account -Server $vcc_replica_cluster -CPU 1000 -Memory 1200 -NumberOfNetWithInternet 1 -NumberOfNetWithoutInternet 0

We have here a plan that offers 1 Ghz of CPU (value in the powershell command is in Khz), 1.2 GB of memory (value in the powershell command is in MB), 1 network with internet access, and uses the Replica Datastore created before that has a quota of 1 TB.

Now we can finally assign this hardware plan to our tenant:

$HwPlan = Get-VBRCloudHardwarePlan -Name $tenant_account

$rpl_options = New-VBRCloudTenantHwPlanOptions -HardwarePlan $HwPlan

$rpl_resources = New-VBRCloudTenantReplicationResources -EnableNetworkFailoverResources -HardwarePlanOptions $rpl_options -EnablePublicIp -NumberOfPublicIp 1

Set-VBRCloudTenant -CloudTenant $tenant -EnableReplicationResorces -ReplicationResources $rpl_resources

The script takes a while to complete, since the software here does multiple things, not just in Veeam but also in the consumed vSphere environment:

Inside the starting resource pool used for the whole Replication services, a new pool for this tenant has been created (test_test because tenant name and hardware plan names are the same) and also a new Veeam Network Extention appliance has been deployed.

Also the single port group in the hardware plan has been created:

We then check in Veeam that the tenant has effectively received his hardware plan:

The network appliance has been configured with a randomly selected external network and a dynamic IP, but we can also fix this part:

$nea = Get-VBRCloudTenantNetworkAppliance -Tenant $tenant

$nea_name = $tenant.Name + "_nea"

$nea_ext_net = Get-VBRViServerNetworkInfo -Server esx1.cloudconnect.local | Where {$_.NetworkName -eq "DPG-vcc_public"}

Set-VBRCloudTenantNetworkAppliance -Appliance $nea -IpAddress 185.62.37.108 -DefaultGateway 185.62.37.97 -SubnetMask 255.255.255.240 -Name $nea_name -ProductionNetwork $nea_ext_net

We have reconfigured the NEA to use the proper network and a fixed IP address:

Cloud Connect is fully configured now, and our “test” tenant can start consuming backup and replication services.

Tech