Veeam Backup & Replication v8: Cloud Connect Reference ... · PDF fileVeeam Backup Replication...

Veeam Backup & Replication v8:Cloud ConnectReference ArchitectureLuca Dell’Oca vExpert, VCAP-DCD, CISSP

Veeam Backup & Replication v8: Cloud Connect Reference Architecture

2© 2015 Veeam Software

Contents1. Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Component Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.1.1 Veeam Backup & Replication Server and Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.1.2 Enterprise Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.1.3 Cloud Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.1.4 WAN Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.1.5 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.5.1 Pod Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.5.2 Single Namespace Scale-out Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Additional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Active Directory Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2 Firewalls (and Load Balancers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Overall Network Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Reference Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Firewall considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Management Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.2 DMZ Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.3 Storage Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



4.4 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.1 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.2 Veeam Management servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.3 Cloud Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4.4 WAN Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4.5 Backup Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5. Customer creation and initial connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

APPENDIX A: SSL Certificates generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.1 Create the Certificate Signing Request (CSR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A.2 Obtain a Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.3 Install the Signed Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

About Veeam Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43



1. Executive SummaryVeeam Backup & Replication v8 has introduced a new technology, named Cloud Connect, specifically

developed to create and serve remote backup repositories.

Cloud Connect is a new component that can be used by Service Providers who subscribed to the

Veeam Cloud Provider Program (VCP) to offer to their customers Backup Storage as a Service, while

every Veeam Backup & Replication v8 customer can buy this service from their service provider of

choice to send backups offsite.

With Cloud Connect, service providers are able to build their own remote repositories with an architecture

that was built from the ground up to be multi-tenant and scalable.

Veeam Cloud Connect removes the two main hurdles that such a service required in the past: VPN tunnels

and dedicated repositories. VPN is not easy to be automatically configured, and usually requires an interaction

between the service provider and the customer. With Veeam Cloud Connect, the connection will happen

directly over the Internet, using a single TCP port, protected by SSL encryption. This will be possible thanks to

a new Veeam component, called the Cloud Gateway, responsible for the tranfer of all the backup traffic over

the single port connection.

Figure 1 : General overview of Cloud Connect



The second new component is called the Cloud Repository. Its role is simple and powerful at the same

time: it creates an abstraction layer over an existing backup repository, so that multiple customers can

store their backups inside the same shared repository, with the same level of confidentiality they have

with a dedicated repository.

The final component is the existing WAN Accelerator: any customer with Veeam Backup & Replication

Enterprise Plus Edition will be able to use the acceleration and speed up their backup copy operations.

All this is managed by the service provider via the Veeam backup console, automated with PowerShell,

or integrated in an existing customer portal thanks to a RESTful API.

Any customer with a paid license of Veeam Backup & Replication v8 will have the client component of Veeam

Cloud Connect available in the same user interface. Directly inside the Veeam backup console, it will be

possible to find a service provider offering Veeam Cloud Connect, selecting the desired one by country and/or

other parameters; once the service has been subscribed between the service provider and the customer, the

latter will receive the needed parameters to activate the Veeam Cloud Connect service.

Veeam Backup & Replication installed at the customer site will connect to the Cloud Gateway(s) at the

service provider, it will authenticate the customer, and the subscribed resources will be enumerated

and exposed as if they were local.

Once the new repository is added to the console, customers can start using it just like a regular backup

repository: make it a target for any backup or backup copy job, and perform restore operations.

And for complete security, the recently announced encryption capability will be available for any job

pointed at Veeam Cloud Connect. The final result will be an end-to-end encryption solution, from

the customer site, through the Internet, up to the final Cloud Repository. And data reduction ratios of

Veeam Built-in WAN Acceleration will not be impacted by the fact that the data is encrypted, as is the

case with general-purpose WAN acceleration.



2. Introduction2.1 AudienceThis Reference Architecture is intended for use by individuals working at service providers and

responsible for the architecture, design, deployment and support of Veeam Backup & Replication Cloud

Connect. Consumers of this document should be familiar with concepts pertaining to Veeam Backup &

Replication.

2.2 PurposeThis document describes a possible Architecture of a service provider offering Backup Storage as a

Service to its customers using Veeam Cloud Connect.

This design is not supposed to be the only or the best possible design, but more a reference guide

to design and deploy the service. Other possible designs can be architected and deployed by service

providers following their specific requirements and business objectives.

This document refers to Veeam Cloud Connect as available in Veeam Backup & Replication v8 Update 2

(build 8.0.0.2029). Service Providers are always invited to use the latest version of Veeam Cloud Connect:

the software allows for backward compatibility, but the installation at the Service Provider side MUST

be at least at the same version of the connected customers; for this reason we invite Service Providers

to install any Update as soon as they are available.



3. ArchitectureVeeam Cloud Connect is a modular architecture, comprised of several modules. Each module has a

precise function, and all together they work to provide the overall functionality.

Some of them can and should be deployed in multiple instances for high availability and scalability purposes;

in each section the document will clearly state if the described component can be deployed multiple times.

3.1 Component OverviewIn this chapter, we will explain and analyze the characteristics of all the needed components. Sizing

considerations will be described in Chapter 4, where we will further explain the reference design.

3.1.1 Veeam Backup & Replication Server and Console

As in every Veeam Backup & Replication deployment, this is the central component. It holds the main

Veeam Backup Service, that manages all the configuration and saves them into the backend Microsoft

SQL Server. Also, it is the entry point for management thanks to the integrated graphical console.

Veeam Backup & Replication requires a 64-bit Windows operating system. Because Cloud Connect does not

involve local activities on service provider’s hypervisor hosts, instead it only receives backups from customers

that are already processed at customers’ sites, the requirements for its installation are lower than usual; a

simple VM with 2 vCPU and 4 GB of RAM will suffice to hold both Veeam Backup Service and Microsoft SQL

Server. About the latter, the default Microsoft SQL Server Express can be enough, unless the Cloud Connect

infrastructure is going to host a really large amount of customers, and so activity logs can fill the maximum

size of an Express database (10 GB). If this is the case, you should plan to use a regular SQL installation

(standard or enterprise) either in the same machine or in a dedicated one.

When the Cloud Connect infrastructure is configured, there is an additional service in the Veeam

Backup & Replication Server, called Veeam Cloud Service. This is the specific service managing the

Cloud Connect infrastructure. You should carefully monitor the status of this service to guarantee the

health of your Cloud Connect environment.

From a protection standpoint, this machine is the most important piece of the environment. Since it

cannot be installed in multiple instances, a good way to protect it is to run it as a virtual machine, and

to rely then on the underlying hypervisor high availability. Features like VMware vSphere HA or Hyper-V

failover clustering can protect it and guarantee quick recovery times if the hypervisor fails; if you need

additional level of protection, you can also plan to use Veeam Backup & Replication and replicate every

few hours this virtual machine. If anything happens, you can power up the replicated machine in a few

minutes; in addition, service providers can and should use Veeam Configuration Backup in order to

backup the overall configuration of the Cloud Connect environment, and plan to have a restore plan if

anything happens to this machine and the corruption is replicated to its replica.



3.1.2 Enterprise Manager

Veeam Enterprise Manager is the service responsible for exposing to users the web interface of Veeam

Backup & Replication and the RESTful APIs. In a Veeam Cloud Connect environments, the latter is a

really important component if the service provider plans to develop and offer to his users a custom

portal for managing their Cloud Connect subscriptions.

The Enterprise Manager is a Windows Service; Veeam requires a modern 64 bit OS, like Windows

Server 2008 R2 and above. It can be deployed in the same machine as Veeam Backup Service, or in

a dedicated machine. The choice to create and operate a separated machine for Enterprise Manager

involves scalability considerations: if a large amount of users are going to interact with Cloud Connect

via RESTful APIs, a service provider should plan to have a dedicated machine.

Also, a dedicated machine is an additional and effective layer of security: since a custom portal will only

connect to the Enterprise Manager, by separating it from the Veeam Backup Service a service provider

can have additional firewall rules for the communications between the Enterprise Manager itself and

the Veeam Backup Server.

If a service provider chooses a dedicated machine, it should also have a dedicated Microsoft SQL server

locally installed, to manage data stored by the Enterprise Manager itself. Because of the light load

created by Cloud Connect, the default SQL Express installation is fine to be used.

From a protection standpoint instead, there is no need to separate this service: Enterprise Manager does not

hold any Cloud Connect information, and only communicates to Veeam Backup Service. If anything happens

to the latter, the Enterprise Manager is not able to operate. The suggestion is to have Enterprise Manager

running in a virtual machine, protected with an image-level backup of the entire VM.

3.1.3 Cloud Gateways

Cloud Gateways are the components responsible to receive external connections from customers, and

tunnel all the data transmissions over a single TCP port, protected by a SSL certificate.

A cloud gateway is comprised of two windows services, so the best platform, again, is a modern 64 bit OS like

Windows Server 2012 R2. The correct sizing of a Cloud Gateway depends on the expected amount of traffic

the service provider will receive, and also on the redundancy design to be realized. One important note is

about encryption: proprietary Veeam encryption is not managed by the Cloud Gateways, but directly by the

target data movers (WAN accelerators or backup repositories). Cloud Gateways are responsible for the SSL

communications and data transfers, and their compute requirements are pretty low.

A group of Cloud Gateways can work in concert to create a “pool”. They can all receive and manage

incoming connections from customers, and can balance these connections between them, without

the help of any external load balancer. If any gateway fails, another gateway can take care of the

existing connections, and so give continuity to customers’ operations. We will explained the interaction

with external load balancers in Chapter 3.2.2.



In order to offer a reliable connection to customers, a service provider will deploy multiple Cloud Gateways,

following N+N redundancy. The first N is the minimum number of always available gateways, and the second

N is the number of gateways that can be lost. A typical redundancy design is N+1, where there is one more

gateway than the required number to manage all incoming connections, so the service provider can lose up

to 1 Cloud Gateway at a time and still guarantee the level of service he planned. Additional designs can be

N+2, or others. Any service provider can find the right balance between the desired level of redundancy, and

the need to deploy additional gateways in advance.

From a protection standpoint, a Cloud Gateway does not need to be saved, since there is no

permanent data on it. Also, a new Cloud Gateway can be deployed in a few minutes while other

existing Cloud Gateways are serving customers.

3.1.4 WAN Accelerators

WAN accelerators are optional components that can be deployed at the service provider to improve

the bandwidth utilization of remote backups sent by customers. Even if any Cloud Connect operation

can be executed without WAN accelerators, for a service provider willing to offer remote backup

services WAN accelerators become mandatory components: several customers will probably have

Veeam WAN Accelerators in their infrastructure, so in order to leverage them, the Service Provider will

need to deploy and configure them. Also, in the Cloud Connect license given to service providers WAN

accelerators are enabled without further needed licensing, so there is no licensing concern for the

service provider in deploying them.

WAN accelerators sit between Cloud Gateways and Repositories, and help to improve the bandwidth

utilization by caching blocks internally, thus avoiding the need to transmit every block over the wire.

Usual design considerations made for Veeam Backup & Replication deployments can be applied also

in a 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 preferred), and the correct sizing for the cache itself. In

addition to the global cache configured during its deployment, a WAN accelerator consumes 20GB per

1 TB of source data. A good choice is to use a dedicated volume for caching, so when it gets filled it

does not creates problems to the Windows OS and its running services.

A single WAN accelerator can saturate links up to 100 Mbps (on average, depending on the workload).

However, many users choose to use WAN acceleration even on much faster links in order to optimize

bandwidth consumption of a shared WAN link. If bandwidth consumption is not a concern, using

Direct transfer mode usually allows achieving a better data transfer performance, and thus shorter job

completion time, on links faster than 300 Mbps.

An additional consideration is about WAN accelerator balancing: when a service provider configures a new

customer and assigns a WAN accelerator, this relationship is permanent. 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 them new cloud repositories, a service provider will need to balance

manually the assignment of WAN accelerators to customers (more specifically, assignment is done at the

cloud repository level). When sharing one WAN accelerator among multiple customers, a service provider will

have to take into account the total bandwidth of said customers. For example, one WAN Accelerator with 50

Mbits bandwidth could be the target of 10 customers having each a 5 Mbits upload speed.



Finally, 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. For this reason, having

WAN accelerators hosted as virtual machines on a hypervisor with HA (high availability) capabilities is heavily

suggested. There is no need to backup a WAN Accelerator, since its cache can be populated from scratch

when it is redeployed; in order to avoid low performances while the cache is warming up after a redeploy, the

service provider can warm the cache before placing the new WAN Accelerator into production.

3.1.5 Repositories

Backup Repositories are the destinations of backup and backup copy jobs in Veeam Backup & Replication.

They can be created using Windows or Linux machines with local attached or remote storage carved out of a

SAN, or they can be a storage appliance exposing its disk space via SMB protocol.

Once a Backup Repository is configured and registered into the Veeam Backup & Replication console,

during the creation of a new Cloud Connect customer a new “Cloud Repository” is created and

assigned to the user, using a portion of an existing Backup Repository. From a service point of view, a

Cloud Repository is a remote repository exclusively assigned to its user. From an infrastructure point of

view instead, a Cloud Repository is a sub-folder of a Backup Repository with an applied quota.

For a Cloud Connect deployment, there are no special requirements for Repositories, but the

general rules of Veeam Backup & Replication are still valid. It’s preferred to use a Windows or Linux

server instead of an SMB share, so that a proper Veeam Data Mover service can be deployed on the

repository machine. With this service running, all write/read operations are delegated to this service.

The concurrency limits of a Repository should be carefully evaluated by the Service Provider, otherwise

customers could be stuck with their jobs waiting for available resources to be freed at the Service

Provider. The use of deduplication appliances should be carefully evaluated, because their algorithms

can be severely impacted by the optional encryption tenants can enable on their backups.

In regards to the memory sizing of a Backup Repository, it’s important to know how the Veeam repository uses

memory. Veeam Backup & Replication has 4 different levels of Storage optimization for a backup job:

First of all, a repository uses memory to store incoming blocks. This queue collects all blocks coming

from proxies, caches them in memory and after some optimizazions it is flushed to disk. This allows

to reduce to a minimum random IO impacting the backup files, while trying to serialize as much

as possible the writes operations. The amount of memory consumed by the queue is simple to be

calculated: it uses 2 GB of memory per active job.



But this is not the only memory consumed by the repository: Veeam backup files contains

deduplicated informations of the saved blocks. As in any deduplicated storage, in order to keep track of

stored blocks, there are metadata informations stored along the file itself.

To improve performances, the repository loads dynamically these metadata informations into memory.

In Veeam Backup & Replication v8 Update 2, the cache is used to accelerate both writes and read

operations; but there are also differences in the way the cache is populated and used. The amount of

consumed memory for metadata depends on the selected block size for deduplication:

VBK size Optimization VBK block size Memory consumption for VBK metadata

1 TB WAN target 256 KB 700 MB

1 TB LAN target 512 KB 350 MB

1 TB Local target 1024 KB 175 MB

1 TB Local target 16+ TB 8192 KB 22 MB

By adjusting these values to a real scenario, you can estimate how much data a given Repository will

be able to process at a certain point in time, or said differently how much memory is needed for some

expected amount of processed data.

If for example the amount of memory is 8 GB, and we assume 1 GB is used by the Operating System

and all the other running processes, 7 GB of memory can handle around 41 TB of backup files at the

default block size. This also includes the additional incremental files of a backup chain.

If a given backup repository is assigned to 10 different customers, and all of them are executing their

jobs at the same time, the total amount of memory must be divided among all the jobs. The Veeam

repository won't be constantly consuming the same amount of RAM, because it can dynamically

offload/load metadata, but planning for the maximum possible consumption is a good choice in order

to be prepared for the worst case scenario.

Finally, backup and backup copy jobs are configured by the customer and not by the Service Provider, so

there is no direct way for the latter to plan for an accurate utilization of the Backup Repository RAM, because

he doesn’t know in advance which block size will be used and what the total size of a backup set will be

(however the quota configured for a tenant in Cloud Connect can also be considered as the maximum

possible size of a backup file of a customer). For these reasons, proper monitoring of the Backup Repository is

paramount, so the provider can quickly identify when the system starts to be too stressed.

The maximum possible size of a single Cloud Repository is 2 petabyte (2097151 GB to be precise);

the memory required to manage this amount of data at the default block size would be theoretically

around 350 GB. This value will never be reached as there are mechanisms in place to flush the cache,

but still it’s up to the Service Provider to design a single large backup repository, or decide to have

multiple “pods” (see later in this chapter), and size the memory accordingly.

Because of the creation of several Cloud Repositories on top of the same Backup Repository, some

additional design principles should be considered.



There are two main designs that can be suggested. Both solutions are effective and can be used for a

Veeam Cloud Connect infrastructure. The choice between the two depends, among other technical

and business reasons, also on the technical skills of the IT Department of the service provider, and their

knowledge of some of the described technologies.

3.1.5.1 Pod Design

The first one is what can be called “pod”. A pod is a single repository, built with the use of any supported

storage (local disks in a windows or linux machine, a SAN, a NAS, a deduplication appliance) that has a

fixed size or it can be expanded but up to a certain limit.

With this kind of repository, service provider needs to plan ahead how to distribute customers among

the several repositories he could have, but most of all keep some free space for future increase in the

Cloud Repositories quotas. A customer may start with a small amount of space, but after some time he

could ask for an increase in the storage quota. If there is no free space left in the repository, the service

provider will be able to satisfy the customer’s request only by migrating the customer’s backup files

into another repository. This can be done in an “almost” transparent way, but it involves some manual

activities from the service provider, and some downtime in the Cloud Connect service for the customer.

Cloud repositories quotas are strictly applied, but as long as the customer is not using the whole amount of

assigned quota, some overcommit can be used by the service provider. The level of over commitment tough

should be carefully evaluated by the service provider to avoid any interruption of the service.

A pod design can be expanded by adding additional pods aside of the first one (thus the meaning

of the name). The pods do not share their storage resources to each other, but it’s up to the service

provider to manually balance cloud repositories among them, and move any customer from one to

another if and when needed.



3.1.5.2 Single Namespace Scale-out Design

The second type of design is a “single namespace scale-out” design. This design is more complex than

the previous one, but at the same has some advantages. To create it, a Veeam Repository is connected

and uses storage resources from a scale-out storage solution, that can be expanded over time without

changing the exposed resources. There are several solutions, both open-source and commercial, with

these capabilities, and Veeam is not promoting any of them above the others.

The important aspect of this design is the “single namespace”. Instead of adding additional storage with a

new path to the Veeam Console, in this scenario the addition of a new node to the scale-out array does not

changes the path Veeam needs to use to save data into it. Simply put, once a new node with some capacity is

added, the repository is going to expose the same path, with a transparently increased capacity.

This solution can be helpful for service providers to avoid any capacity problem in their repository

design, especially when enabling complete self-service capabilities to their customers: if a customer

can freely setup his storage quota, a proper capacity planning cannot be effective; a scale-out

approach can help to quickly react to a capacity shortage without changing any configuration to the

repository structure.

If concurrency at some point can become a problem with this approach, a Service Provider can deploy

additional Repositories all using the same scale-out storage; even if the same storage path cannot be exposed

by more than one Repository at the same time, a Service Provider can create multiple paths (directories) in

the same storage, and thus use multiple Repositories at the same time. This will add more concurrency to

accommodate customer’s activities.



3.2 Additional ComponentsEven if they are not part of the Veeam Cloud Connect infrastructure, these components are recommended to

successfully create and operate the infrastructure.

3.2.1 Active Directory Domain Controllers

Active Directory is the directory service developed by Microsoft years ago, starting with Windows

2000. Directory Services allow central authentication and authorization for all users and computers

in a Windows domain type network—assigning and enforcing security policies for all computers and

installing or updating software.

The ability to centrally authenticate and authorize access to resources is an important solution to

guarantee optimal security of any IT environment. Also, all Cloud Connect components are developed

to be executed on Windows machines, so having Active Directory in place makes perfect sense.

Finally, Active Directory offers integrated DNS services. An IT infrastructure heavily relies on proper DNS

configuration (with both forward and reverse resolution correctly configured) to reach all the different

components.

For these reasons, Active Directory is recommended in a Cloud Connect environment.

3.2.2 Firewalls (and Load Balancers)

Cloud Connect, by its nature, is a service that needs to be exposed over public Internet to serve its users.

Because of this, network security solutions like firewalls should be deployed and properly configured in order

to protect Cloud Connect.

Different technical solutions and business requirements lead to different security designs; for this reason, it

makes little sense to describe a detailed security design for Cloud Connect. Instead, in this paper we’d like to

suggest two high level design concepts, that should be used when protecting Cloud Connect:

• Separate different logical components in different security zones: this will keep Cloud Gateways in

a different and separated area. Since they are the only components that need to be exposed over

the Internet, a compromise on these machines will not lead to a compromise of the entire Cloud

Connect environment, especially repositories that hold customers’ backups.

• Reduce network connections to a minimum: we suggest to have firewalls authorizing any

communication between components, by opening the minimum amount of TCP/UDP ports

required. In Chapter 4 we will describe in detail the required ports.

Finally, a note on Load Balancers. As explained in Chapter 3.1.3, different Cloud Gateways work as one

logical pool to share the load and guarantee high availability. They are designed to balance themselves,

without the help of any additional load balancer.



One important design consideration: each Cloud Gateway needs to have its own public IPv4 address, regardless it is directly configured on the Cloud Gateway itself (direct mode) or with a firewall in front of it (NAT mode). This is a mandatory configuration. For service providers worried

about the consumption of public IP addresses, as explained in Chapter 3.1.3, even on large installations

there is no need to have a large amount of Cloud Gateways, so the usage of public addresses should

not be an issue for most service providers.

This requirements has a direct consequence on load balancing: a service provider cannot use a load

balancer with shared IP address to publish multiple Cloud Gateways.

What is needed to be balanced is only the initial connection from a tenant to the Cloud Connect

environment. This can be accomplished by using simple DNS Round Robin: the public FQDN (fully qualified

domain name) of Cloud Connect can be configured in the DNS to have multiple A (host) records. In this way,

when a tenant connects to its resources, it connects to one of the registered public IP addresses, thus realizing

a simple balancing between the Cloud Gateways. An example configuration is like this:

cc.virtualtothecore.com A 10.2.50.201



NOTE: I used my personal blog domain because, when creating a real SSL certificate, every Certificate

Authority checks the information of the applicant and the registered domain. A fake domain cannot be used. I

also used my lab internal IP addresses instead of public IP addresses.

For proper operations when using wildcard certificates (like *.virtualtothecore.com), the public hostname of

each gateway must use the same domain of the common DNS name, and the same must be used in the SSL

certificate. So, in my example, the gateway must have their hostnames mapped in DNS as:

gateway1.virtualtothecore.com A 10.2.50.201



The drawback of this design is that DNS does not have any notion of the state of the Cloud Gateways, but this

is not an issue since the client component of Cloud Connect reads the A records from the DNS resolution, and

tries to connect to each of them until an initial connection can be established. Once it has reached a Cloud

Gateway, it receives a list of all the existing and available Cloud Gateways. This list is maintained and updated

by the Veeam Cloud Service installed into the Veeam Backup & Replication server.

NOTE: in order to optimize the use of DNS Round Robin, and avoid connection problems caused by DNS

caching, we suggest to configure low TTL (Time To Live) values for the A records. Values like 15 or 30 seconds

are good configuration options.



During regular operations, the Veeam Cloud Service keeps a list of all existing activities happening on all Cloud

Gateways, and it instructs new incoming tenants to use the less used Cloud Gateway. As a consequence, load

balancing is made directly by Cloud Connect without any need for external load balancing solutions.

When one of the Cloud Gateway fails, all the existing connections are lost. Depending on the type of job that

was going through this gateway, two scenarios can occur:

• Backup jobs are sensible to network interruptions. Running jobs will fail, but subsequent retries will

be sent to surviving Cloud Gateways. Customers will see a failed job and then a successful retry.

Retry attempts are configured by default in any backup job; service providers should advice their

customers to not change these parameters.

• Backup Copy jobs can survive network interruptions. Depending on the duration of a network

interruption, Backup Copy jobs are likely to restore the connection in place, or if the TCP timeouts

has been reached, to be redirected to a surviving Cloud Gateway without any notification to the

user about a failed connection.

Finally, a note on the failover process of Cloud Gateways from a end user perspective: the list of

available gateways is retrieved by the end user component of Cloud Connect upon any job start or

retry. The available gateways are listed in a specified order where the first usable gateway is assigned

#1, the second #2, and so on. The number assignment and so the priority is not fixed, but depending as

said on actual load of all repositories.

As long as the gateway marked as #1 is available, the end user keeps using this one. As soon as this gateway

is not available anymore, a new connection is automatically tried against #2; if this is available, the connection

is automatically established and any running job is continued; if not, a connection is tried against the next

gateway on the list. When all the gateways have been tried unsuccessfully, down to the last one, the running

job fails and a new list is retrieved for the following retry.

3.3 Overall Network DiagramIn order to better understand the relationships between the different components of Veeam Cloud

Connect, you can look at the Network Diagram in the next page. Here are depicted only the specific

Cloud Connects communications, remember there are additional connections between components

that you can find in the Veeam Backup & Replication User Guide, or in the knowledge base article

KB1518 (http://www.veeam.com/kb1518).

There are two specific use cases where additional firewall rules are needed, even if not directly related to

Cloud Connect components:

1. Disabling a gateway

Veeam Cloud Service running in the VBR Server (Management Zone) needs to access the Installer

Service running on the gateway (DMZ Zone) on TCP/6160 in order to disable a gateway. If this port

is not open, the gateway can still be disabled but the User Interface will freeze for a minute.

http://www.veeam.com/kb1518



2. Installing Updates

It’s recommended to temporarily disable firewall rules between the different Security Zones during

updates, as many operations requires multiple open ports. To name a few: SMB access to upload

new .MSI installers to windows machines, RPC access to restart services remotely, and others.

Also, the diagram lists all the installed services running in Veeam Cloud Connect. Those should be monitored

to guarantee the health of the overall solution.



4. Reference DesignIn this chapter, we will describe a complete Veeam Cloud Connect deployment at a Service Provider.

The provider will design and deploy all the necessary servers, networks, network rules, in order to run

Veeam Cloud Connect.

All the components will be deployed in virtual machines running on top of a hypervisor in order to

leverage the quick deployment times of new VMs starting from templates, and to protect those single

components like the Veeam Backup & Replication Server that cannot be executed in multiple instances.

Because of this, sizing rules will be based on vCPUs (virtual CPUs) rather than sockets and cores; also,

the size adjustments to virtual disk will be easier than in a physical server, for example when it will be

needed to increase the WAN accelerator cache size. The only exception are Backup Repositories: for

better performances, we suggest to have physical backup repositories.

During the document, we will refer to these virtual machines as “servers”; please remember we are talking

about physical servers only for the Repositories.

Note: if you plan to use physical servers, adjust CPU considerations to existing and available CPUs.

4.1 Security ZonesThe Service Provider uses different security zones, and places different server types in each zone. All the

zones are protected from each other and from outside by firewalls.

By applying different firewall rules to allow only the needed connections between the different zones,

the level of security is the best possible.

As described in the General Network Diagram, we have 4 different areas:

DMZThis area hosts the Cloud Gateways, and an optional Web Portal to offer self-service capabilities to users. It’s the only area connected and reachable from users via public Internet connection (directly or via firewall/NAT).

Management This area hosts the management components of Veeam Cloud Connect. This area is not reachable from outside.

StorageThis area hosts the WAN accelerators and the Backup Repositories. This area is not reachable from outside. A more complex design can also have WAN accelerators and Repositories in two separated areas

ExternalThis area is the public Internet, or in general the network outside of the Cloud Connect infrastructure, where tenants are supposed to connect to the Cloud Gateways and their Cloud Repositories.



4.2 SubnetsEach Security Zone is isolated thanks to dedicated VLANs, and firewalls that are the only entry point to and

from each Security Zone to another, with rules limiting connections to the minimum required to operate a

Cloud Connect environment.

The Service Provider uses one IPv4 subnet for each Security Zone. In this way, firewall rules can be

written per subnet more easily.

DMZ 192.168.100.0/24, VLAN 100, gateway 192.168.100.254

Management 192.168.101.0/24, VLAN 101, gateway 192.168.101.254

Storage 192.168.102.0/24, VLAN 102, gateway 192.168.102.254

External10.2.50.0/24 These are internal IP addresses used for demonstration purposes; on real deployments obviously a service provider will use proper public IP addresses.

All internal subnets have a geteway address; this IP addresses are configured and managed by one or

more firewalls. In this way, every communication between the security zones is filtered.

4.3 Firewall considerationsOne of the reason to separate the environment in several distinguished Security Zones is the possibility

to limit at a minimum the TCP/IP connections between them. Inside the same Zone, all servers are free

to communicate with each other, so for example Veeam Backup & Replication Server can connect to

both Domain Controllers.

In this chapter, we will assume all connections between Security Zones are denied, unless explicitly allowed

via a firewall rule. For a complete list of the required network ports, please refer to the Network Diagram at

page 14 and the additional general required ports in the Veeam Backup & Replication User Guide, or in the

knowledge base article KB1518 (http://www.veeam.com/kb1518).

4.3.1 Management Zone

The two domain controllers are contacted by Veeam Backup & Replication Server and the Enterprise

Manager server. Outside of the Management Zone, no server needs to connect to Active Directory

services. All Cloud Gateways, WAN Accelerators and Windows-based Repositories will use local

authentication only. In this way, any security breach in these zones (especially the DMZ) will not expose

Active Directory to any risk.

Also, the management components of Cloud Connect will be kept isolated with this design.

However, for better management, all servers will be registered in the DNS services running on the domain

controllers. Even the servers running with workgroup authentication will be reachable using their hostname

and the general domain suffix, cloudconnect.local in this guide. For the same reason, the only connections

allowed to the Domain Controllers will be towards the DNS servers.

http://www.veeam.com/kb1518



4.3.2 DMZ Zone

This security zone hosts the cloud gateways. These components are the only ones directly reachable via

public Internet connections. For best protection, a service provider should isolate this zone from both

public Internet (allowing only the single TCP port needed for publishing the service) and the rest of the

Cloud Connect infrastructure.

The cloud gateways need to talk with the Management Zone for DNS resolution using the domain

controllers (and also for Active Directory operations if they were joined to the Cloud Connect internal

domain), and to the Storage Zone to allow communications between the data mover components at

the customer site and the WAN accelerators and Repositories at the Service Provider site.

4.3.3 Storage Zone

This security zones hosts the data movers managing all the inbound and outbound data streams.

Backup repositories are the foundations to create the logical Cloud Repositories used by customers,

while the (optional) WAN accelerators allow with their technology huge bandwidth savings, for those

customers having WAN accelerators at their own side.

Both components need to talk with cloud gateways, and through them to the customers; also, they will

communicate with the Veeam Backup Server and with the domain controllers.

Direct access should be limited to few authorized people, since on the Backup Repositories an

administrator can see all the customers’ backup files. If those are not encrypted, unauthorized access to

customers data could happen.

4.4 ServersOnce VLAN and subnets are created, and the firewall is in place to protect communications between

the different security zones, it’s time to deploy the needed servers.

4.4.1 Active Directory

The internal domain is named cloudconnect.local, and is managed by two domain controllers:

dc1.cloudconnect.local 192.168.101.1

Windows Server 2012 (AD, DNS, Global Catalog, FSMO roles)

1 vCPU, 2 GB RAM, 40 GB disk

dc2.cloudconnect.local 192.168.101.2

Windows Server 2012 (AD, DNS, Global Catalog)


Active Directory should use at least Windows Server 2008 and be configured with no backwards

compatibility with older domain controllers. In this way, additional security can be reached.



192.168.101.1 and 192.168.101.2 are also the DNS servers to be configured in all other servers of the Cloud

Connect infrastructure. Since all other components will use local authentication, DNS records should be

configured manually.

4.4.2 Veeam Management servers

There are two windows servers, so Veeam Backup & Replication and Enterprise Manager can be

separated.

em.cloudconnect.local 192.168.101.12

Windows Server 2012 (joined to cloudconnect.local)


This server holds the installation of Veeam Enterprise Manager, and its related database. By having a

separated installation, a Service Provider can better manage the different performance requirements of

Enterprise Manager and Veeam Backup & replication server, and also configure a specific security rule

to only allow access to the RESTful API service running on the Enterprise Manager only to an optional

web portal.

The installation has no specific requirements, and the default wizard can be followed from start to

finish. A dedicated Microsoft SQL Server 2012 Express is installed locally as part of the installation

wizard, and it will be used by the Enterprise Manager itself.

Once the installation of Veeam Backup & Replication is completed on vbr.cloudconenct.local, the

configuration of Enterprise Manager can be completed by adding this server to the list of managed

backup servers.

vbr.cloudconnect.local 192.168.101.11

Windows Server 2012 (joined to cloudconnect.local)


This server holds the installation of Veeam Backup & Replication. In a Cloud Connect infrastructure, this

server is the central location for daily activities, from configurations to user creations, to log controls.

The installation has no specific requirements, and the default wizard can be followed from start to

finish. A dedicated Microsoft SQL Server 2012 Express is installed locally as part of the installation

wizard, and it will be used by the Backup & Replication server itself. During the component selection,

a Service Provider should also choose to install the optional PowerShell SDK: Cloud Connect can be

heavily automated via RESTful API or PowerShell, so having both available is a good choice.

Once the setup is completed, and the license for enabling Cloud Connect is installed (directly or

pushed via the Enterprise Manager), the initial management interface can be reached by opening the



Veeam console and selecting the node “Cloud Connect Infrastructure”:

The required step to have a fully functional Cloud Connect infrastructure are:

3. Create and install a proper certificate (See Appendix A for detailed instructions)

4. Deploy and configure the required Cloud Gateways (See chapter 4.4.3)

5. Deploy and configure the optional WAN Accelerators (See chapter 4.4.4)

6. Deploy and configure at least one Backup Repository (See chapter 4.4.5)

Once all the configurations steps are completed, a Service Provider will be able to create and manage

users/tenants.

4.4.3 Cloud Gateways

A Cloud Connect infrastructure requires at least one Cloud Gateway, but as explained in Chapter 3.1.3

multiple gateways are mandatory to deploy a reliable solution. In this scenario, the Service Provider

will deploy 3 Cloud Gateways, to satisfy a 2+1 redundancy: 3 gateways will be available to accept and

manage incoming connections, and in case of a failure of one of them, there will always be 2 available

gateways, thus guarantying load balancing and redundancy even in a degraded situation. Furthermore,

the use of 3 gateways allows maintenance activities to any of the gateways (patching, hardware

maintenance or upgrades, others) while always leaving 2 running gateways.

cc-gtw1.cloudconnect.local 192.168.100.1

Windows Server 2012 (workgroup)










For the sizing of a Cloud Gateway, a Service Provider should follow these reccomendations:

CPU: 2 vCPU or core can manage a bandwidth up to 10Gbit/s.

RAM: around 512 KB per single connection. From a load perspective, we suggest to limit a gateway to 1000

connections by adding multiple instances when the total amount of conenctions goes above this value.

With 1000 connections, the total memory requirement for the Cloud Gateway services is around

512MB; the requirements of the underlying Operating System must be taken into consideration and

added to this value, hence the 2GB suggested value.

The Cloud Gateway is directly exposed over Internet. In order to be protected by DoS (Denial of

Service) attacks trying to saturate all the available connections, this component has default limits on

the amount of connections it can accept:

number of connections from the same IP address = 16

number of total connections = 256

To change this values, a Service Provider needs to create two new DWORD registry keys in each Cloud

Gateway, in

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Veeam\Veeam Gate Service

and configure them as follows (and restart the service to apply the new numbers):

PeerCloudConnectionsLimit (per IP, default is 16)

MaxSimultaneousCloudConnections (total, default is 256)

Note: a Cloud Gateway is a “failure domain” when evaluating the impact on connections caused by its loss.

1000 connections lost on a failed Cloud Gateway will impact several customers. A Service Provider should

carefully evaluate these scenario and eventually deploy multiple Cloud Gateways to spread the connections

over a higher number of smaller failure domains.

Once the three Cloud Gateways are added to the Backup Infrastructure as managed windows servers,

the service provider will deploy on each of them the cloud gateway component. The procedure is

quick and easy, and should be repeated for all the three gateways.



1. From the Cloud Connect Infrastructure node, go to Cloud Gateways and select Add Cloud Gateway

2. Select one of the previously added servers:



3. Configure the desired networking mode:

In this Reference Architecture we are suggesting, and thus explaining, the NAT mode. Direct mode is available

to directly expose a cloud gateway over the Internet with a public IP address directly configured on the

gateway machine. Veeam Cloud Connect fully supports both deployment modes, however placing the cloud

gateways behind a protecting system like a firewall is a best practice all service providers should apply: in this

way, several advantages can be achieved.

From a security perspective, all connections arriving to the gateways can be inspected by an IDS/IPS

system (Intrusion Detection/Intrusion Prevention) to avoid attacks from malicious sources.

But there are advantages also from an operational perspective: a service provider can apply QoS (quality

of service) and bandwidth throttling rules to incoming connections, and lifecycle operations can be

accomplished more easily: for example when a gateway needs to be retired and replaced with a new one,

the NAT rule in place can be easily updated to point to the new gateway, thus reducing to few seconds the

downtime of a given public IP address.

When configuring the cloud gateways in NAT mode, the wizard needs to be filled with the expected

public IP that will be used to connect to the gateway itself. Following our example explained in Chapter

3.2.2, the mappings will be:



HOST INTERNAL IP NAT IP

cc-gtw1.cloudconnect.local 192.168.100.1 10.2.50.201



The overall cloud gateway configuration will be similar to this:

The public IP will be then loaded on the external firewall (declared as gateway on the cloud gateway

servers), and using Port Address Translation each public IP will be mapped to the corresponding

internal IP, remembering also to make the necessary TCP port translations:

PUBLIC IP PUBLIC TCP PORT

→INTERNAL IP INTERNAL TCP PORT

10.2.50.201 6180 192.168.100.1 8080

10.2.50.202 6180 192.168.100.2 8080

10.2.50.203 6180 192.168.100.3 8080

Once the DNS A (host) record is configured with all the public IP addresses so to enable round robin,

the Internet-facing part of Cloud Connect is ready.

4.4.4 WAN Accelerators

cc-wan1.cloudconnect.local 192.168.102.1


4 vCPU, 8 GB RAM, 40 GB for OS disk and 200 GB for cache disk

(on SSD or fast volume)

cc-wan2.cloudconnect.local 192.168.102.2


4 vCPU, 8 GB RAM, 40 GB for OS disk and 200 GB for cache disk

(on SSD or fast volume)



As explained in chapter 3.1.4, WAN accelerators are optional components, but any Service Provider

should deploy them. The Cloud Connect license enables the use of WAN Accelerators at no additional

cost, and most of all their presence allow a Service Provider to offer a complete solutions to those

customers owning Veeam licenses with WAN acceleration enabled.

The 200 GB disk is a suggested starting point. 100 GB are assigned to the general cache, plus additional 100

GB are allocated for each job cache requirements. Depending on the amount of customers assigned to a

specific WAN accelerator and thus the total amount of managed data, the cache should be then increased to

guarantee optimal performance to all customers connecting to a given WAN accelerator.

Finally, the use of at least two WAN accelerators is a good design solution in terms of high availability. Even if

multiple WAN accelerators cannot be assigned to the same customer, the presence of an additional server

eventually allow to quickly reconfigure all customers linked to a failed WAN accelerator to use the other one.

The deployment and configuration of a WAN accelerator component is, again, a simple and quick

process. When starting the wizard to deploy a new WAN accelerator, select the corresponding

managed server and accept the default values. If needed, the number of streams can be increased at a

second time to increase the utilization of the WAN accelerator:

Cache should be configure taking into account the calculations explained in chapter 3.14. The cache will be

placed in a dedicated disk, so any disk consumption problem will not affect the operating system partition:



After the configuration of the two WAN accelerators is completed, they will be both listed in the

corresponding section:

4.4.5 Backup Repository

As suggested in chapter 3.1.5, it’s preferred to use a Windows or Linux server as a Backup Repository,

so that a proper Veeam Data Mover service can be deployed on the repository machine itself. With this

service properly deployed and running, all write/read operations are delegated to this service and all

the available compute resources can be used by the data mover.

SMB shares are totally supported by Veeam Cloud Connect, but also in this scenario it’s advisable to

deploy a dedicated Windows machine that will act as the “gateway server” to directly communicate

with the SMB share. The data mover will be deployed on this machine and not on other systems,

especially the Veeam Backup Server that should be only used as a management console:



This server will ultimately act like a proper repository machine.

There are several design choices for a Backup Repository, and to list them all here will be simply impossible

since many will be surely left out. Instead, this Reference Architecture will describe a simple Pod solution

(see Chapter 3.1.5.1) realized with a Windows machine. This is not intended to suggest this one as the best

storage solution, it’s simply an example to better describe the process of adding a backup repository to

the Veeam Cloud Connect infrastructure.

cc-repo1.cloudconnect.local 192.168.102.101


4 vCPU, 8 GB RAM, 40 GB for OS disk, 200 GB for backup disk

A secondary dedicated disk was created and connected to the server, to avoid problems to the operating system

if the backup disk becomes full. This disk is then selected as the target for the customer’s backup files:

Managing the ingestion rate of the repository is without any doubt the most important configuration

aspect of the repository:



A typical Cloud Connect customer will be limited by the upload bandwidth he/she has available; this

will be the main bottleneck. But this doesn’t mean it will be the primary bottleneck of the Service

Provider: since the service provider is accepting several concurrent connections, the number of

concurrent tasks connecting to the repository could be notable.

For this reason, a service provider needs to check beforehand the performance of a given storage

solution, and configure the limits for concurrent tasks and/or data rate accordingly. On the other hand,

a service provider needs to have room for enough concurrent connections so that customers do not

end up waiting for available resources for their jobs.

Finally, since vPower NFS is not supported to date via Cloud Connect, a service provider can safely

disable the configuration of this component during the repository creation wizard, and complete it.



5. Customer creation and initial connectionOnce the Cloud Connect infrastructure is completely configured, a Service Provider can start to

configure users and accept their incoming backups. In this chapter, we will describe the main steps of

this process, and show how a customer will connect to the Cloud Connect service.

In the Cloud Connect Infrastructure node, select Add User to start the quick wizard. A username

and a password needs to be configured, and a lease time can optionally be configured, for

example for trial purposes:

In the second step, at least one Cloud Repository needs to be configured. A user can have multiple cloud

repositories, for example with or without WAN acceleration, or stored on Backup Repositories with different

characteristics and price per GB:



The Cloud Repository is created and is ready to be used.

In the Veeam Backup & Replication v8 installation at the customer site, the customer goes into the Backup

Infrastructure node, Service Providers sub-node, and select to add a new Service Provider. A wizard is started.

In the first step, the customer inputs the DNS name configured with Round Robin by the Service

Provider (as explained in Chapter 4.4.3). Unless the TCP port has been changed by the Service Provider,

no configuration is needed here:

When hitting the Next button, Veeam Backup & Replication connects to one of the Cloud Gateways

and retrieves the SSL certificates:



As explained in more details in Appendix A (section 3), the certificate is issued by a recognized

Certification Authority, so no security warning is raised. In the same step of the wizard, the customer

will add the username and password created for him by the Service Provider.

By hitting Next again, Veeam Backup & Replication logs in to the Cloud Connect infrastructure with the

given credentials, and Cloud Connect returns the resources the user is entitled to consume:

When the customer completes the wizard, the service provider is registered in the corresponding section:



and even more important, the Cloud Repository is registered under the available backup repositories of

the user and can be used as a target for backup and backup copy jobs:



APPENDIX A: SSL Certificates generationEvery connection going through the Cloud Gateways is protected with SSL certificates.

During the initial configuration of Cloud Connect, Veeam Backup & Replication gives to Service

Providers the possibility to generate and use a self-signed certificate. This is a quick and easy method

to complete the deployment and to test it, but gives no security to customers, since they cannot verify

the certificate, and thus the authenticity of the Service Provider.

When a user connects to a Cloud Connect environment, this is the result when a self-signed certificate is used:

In order to properly protect Cloud Connect and give their customer comfort, the Service Provider

should use a proper and generally recognized certificate, issued by one of the Certification authorities

recognized by Internet browsers and operating systems.



A.1 Create the Certificate Signing Request (CSR)In public key infrastructure (PKI) systems, a certificate signing request (also CSR or certification request) is a message sent from an applicant (the Service Provider running Cloud Connect in our case)

to a Certificate Authority in order to apply for a digital identity certificate. The most common format for

CSRs is the PKCS #10 specification.

Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains

information identifying the applicant (such as a distinguished name in the case of an X.509 certificate)

which must be signed using the applicant's private key. The CSR also contains the public key chosen by the

applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate

authority, and the certificate authority may contact the applicant for further information.

The first operation a Service Provider should do is to decide the public fully qualified domain name

Cloud Gateway will use to be contacted by users. This name should match the one used in DNS and

the one used in the CSR. In this reference architecture, the public domain of the Cloud Connect service

is serviceprovider.com, and the fqdn is:

cc.serviceprovider.com

In order to create the CSR, on the Windows Server running Veeam Backup & Replication (vbr.

cloudconnect.local in this reference architecture) a Service Provider needs first to create with a text

editor an .inf file. This file (it can be called request.inf ) should contain a text like this:

;----------------- request.inf -----------------

[Version]

Signature="$Windows NT$"

[NewRequest]

Subject = "CN= FQDN, OU=Organizational_Unit_Name, O=Organization_

Name, L=City_Name, S=State_Name, C=Country_Name" ; replace

attributes in this line

KeySpec = 1

KeyLength = 2048

; Can be 2048, 4096, 8192, or 16384.

; Larger key sizes are more secure, but have

; a greater impact on performance.

Exportable = TRUE

FriendlyName = "cc"



MachineKeySet = TRUE

SMIME = False

PrivateKeyArchive = FALSE

UserProtected = FALSE

UseExistingKeySet = FALSE

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

ProviderType = 12

RequestType = PKCS10

KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

[RequestAttributes]

; SAN="dns=FQDN_you_require&dns=other_FQDN_you_require"

The text parts in red are to be changed with the specific values of the Service Provider. To obtain a valid

certificate from a Certificate Authority, a proper domain name should be use. Thus, I’ve used for this procedure

my blog domain name virtualtothecore.com, and so the FQDN is cc.virtualtothecore.com

After the configuration file has been edited, it can be saved in a useful location like a dedicated folder

c:\certificates. Then, open a command prompt with Administrator rights (right click and select “Run as

Administrator), move into c:\certificates and use this command:

certreq -new request.inf certreq.txt

If you open the certreq.txt file, its content is like this:

-----BEGIN NEW CERTIFICATE REQUEST-----

MIID9jCCAt4CAQAwdTELMAkGA1UEBhMCSVQxETAPBgNVBAgMCExvbWJhcm

R5MQ8wDQYDVQQHDAZWYXJlc2UxEzARBgNVBAoMClNrdW5rd29ya3MxCzAJ

BgNVBAsMAklUMSAwHgYDVQQDDBdjYy52aXJ0dWFsdG90aGVjb3JlLmNvbT

CCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJUBkduH0xQfJbnt

2ryIjdn5z8euMM4zHyd4CFBd2eCXAnfaskOc3F9eW9zP1KMk0Z/8K9Gfez

ZDkMcbno5hnIkuwBcLoHJUeiWQDm1aDutxvgvo1RO2TEQJes5CBKB7vrEa

kRCco3Cq26rXEparx1MjdmcOVyk2weF9TJNIUIFr1Tadw/NWCLqwUw4ZGBs

DJL0lftuQe0VmxJciZC1EZQXppsXSanSdaIZECJzHUSu0wA5nZL9pltvO3

593Kqr+qYkbocRj+T2hixA7n+Y8Bi5pO6pDOs/UdCQodteb0qCcLUCXBtQ

oimEL7uwtAPQ07RfiTX9EIeeIxX0+FHD6T7UCAwEAAaCCATowGgYKKwYBBA

GCNw0CAzEMFgo2LjIuOTIwMC4yMFMGCSqGSIb3DQEJDjFGMEQwDgYDVR0P



AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBTEao

WXriXLI1DePK17Mxh2s8ryRzBTBgkrBgEEAYI3FRQxRjBEAgEJDBZ2YnIu

Y2xvdWRjb25uZWN0LmxvY2FsDBpDTE9VRENPTk5FQ1RcYWRtaW5pc3RyYXR

vcgwLY2VydHJlcS5leGUwcgYKKwYBBAGCNw0CAjFkMGICAQEeWgBNAGkAY

wByAG8AcwBvAGYAdAAgAFIAUwBBACAAUwBDAGgAYQBuAG4AZQBsACAAQwB

yAHkAcAB0AG8AZwByAGEAcABoAGkAYwAgAFAAcgBvAHYAaQBkAGUAcgMBA

DANBgkqhkiG9w0BAQUFAAOCAQEAQaUqU2Y97wH3JhgiDvn85HEZq+60a4W

qgXXHiriIG1FnJwuzdG3k+m185N+smSX/VlIXT9fITak034muIRpqwNJR7

fz4gPaLnmNowa3Don1la8TihI47Pezl8h76ig04hFfSOUH7Z4Atq+2XZ55

lj/mRksq2oVZUeEzHCf0V7MSQD6M3Yf/WLJGLZG/kDexwDz2I5W9q6vu2O

wmD0eA2mHW1RjycqBJktyaZ7Hy6BF1T1F3AVyJYpTVMT/IbDAzMYZQ4U1/b

sKD5ZHkY2WhrRkD4D2UQpFShPdlaCYf3OP9F9FbLY4mZ7yKaQxrZWaKqRz

KEaEMPng8IKtDYJRCVAw==

-----END NEW CERTIFICATE REQUEST-----

A.2 Obtain a Signed CertificateWith the Certificate Request correctly created, it’s time to obtain a signed certificate from a Certificate

Authority. There are several online services where you can get a certificate, and some of them also offer

free time-limited certificates that are useful to test SSL connections at no expense.

The involved steps vary depending on the selected Certificate Authority, but it usually involves a

validation of the CSR, a check against the registered domain via whois protocol to collect the registrant

email address, and a verification sent to this email to validate the authenticity of the request.

Whatever are the differences in the procedures, the final result is a Signed Certificate with the needed

configuration information in it. It can usually be retrieved in text format, and its content is going to be

like this:

-----BEGIN CERTIFICATE----- MIIFLTCCBBWgAwIBAgIQLgiJg4U3yi

jkhjzA5FK1VjANBgkqhkiG9w0BAQUFADBy MQswCQYDVQQGEwJHQjEbMBk

GA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3Jk

MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDEYMBYGA1UE AxMPRXNzZ

W50aWFsU1NMIENBMB4XDTE0MDgwNTAwMDAwMFoXDTE0MTEwMzIzNTk1

OVowWDEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMREwDw

YDVQQL EwhGcmVlIFNTTDEgMB4GA1UEAxMXY2MudmlydHVhbHRvdGhlY29

yZS5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVAZHb

h9MUHyW57dq8iI3Z+c/H rjDOMx8neAhQXdnglwJ32rJDnNxfXlvcz9Sj

JNGf/CvRn3s2Q5DHG56OYZyJLsAX C6ByVHolkA5tWg7rcb4L6NUTtkxEC

XrOQgSge76xGpEQnKNwqtuq1xKWq8dTI3Zn DlcpNsHhfUyTSFCBa9U2nc

PzVgi6sFMOGRgbAyS9JX7bkHtFZsSXImQtRGUF6abF 0mp0nWiGRAicx1E

rtMAOZ2S/aZbbzt+fdyqq/qmJG6HEY/k9oYsQO5/mPAYuaTuq QzrP1HQk

KHbXm9KgnC1AlwbUKIphC+7sLQD0NO0X4k1/RCHniMV9PhRw+k+1AgMB



AAGjggHXMIIB0zAfBgNVHSMEGDAWgBTay+qtWwhdzP/8JlTOSeVVxjj0+D

AdBgNV HQ4EFgQUxGqFl64lyyNQ3jytezMYdrPK8kcwDgYDVR0PAQH/BA

QDAgWgMAwGA1Ud EwEB/wQCMAAwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCs

GAQUFBwMCBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwTwYDVR0gBEgwRjA6

BgsrBgEEAbIxAQICBzArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZ

S5jb21vZG8uY29tL0NQUzAIBgZngQwBAgEw OwYDVR0fBDQwMjAwoC6gLI

YqaHR0cDovL2NybC5jb21vZG9jYS5jb20vRXNzZW50 aWFsU1NMQ0EuY3J

sMG4GCCsGAQUFBwEBBGIwYDA4BggrBgEFBQcwAoYsaHR0cDov L2NydC5j

b21vZG9jYS5jb20vRXNzZW50aWFsU1NMQ0FfMi5jcnQwJAYIKwYBBQUH

MAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTA/BgNVHREEODA2ghdjYy

52aXJ0 dWFsdG90aGVjb3JlLmNvbYIbd3d3LmNjLnZpcnR1YWx0b3RoZWN

vcmUuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQCEUHCth5o9h6MYINOnx6GM

H3NchYo+BXPtCMsUyf2R CB/iuteEODUW8Up+UWffF8tFSb9eIuNXyjhzK

xqWcSms4qQkvVcH7WI4EZNvczzz e8WGvbEckoCeGapYS+r5Z6hG865/BX

/iiCHFyEB7UwR4xYtMis4XxFNGZLhtOX6D zmLyVVTYFLyrhrFqOSxjRD2

5yfKdvG3dKKVBIwnb4xKdNZX/37KSkW15lIz0t2Bx laMqyZZAOxvKMXRp

iAKcReEKQg+TRjdPd0TL9uNOk6YWph/HQX2W7jSlm6HJRvNF IGNh1H6V2

REtiTSnTaFdvbhptJq0oc+N/sRGvvOhKMu/

-----END CERTIFICATE-----

A.3 Install the Signed CertificateBack in the Veeam Backup & Replication server, create a text file in c:\certificates and call it cert.cer.

Open it with a text editor and paste in it the certificate text received from the Certification Authority.

Then, open again a high privileges command prompt, go into the c:\certificates directory, and run this

command:

certreq –accept cert.cer

Once the command is executed, the certificate is stored in the local Certificate Store of the Veeam

Backup & Replication server.

In the Cloud Connect Infrastructure node of the Veeam Console, you can now select “Manage



Certificates” and use the new certificate. First, you choose “Select certificate from Certificate Store”:

In the following screen “Pick Certificate” you see the imported certificate. You select it.



Before completing the wizard, you can see a summary of the certificate’s parameters. Among them, you

can see the Thumbprint of the certificate; this can be sent to customers for additional verifications.

The certificate is now ready to be used for SSL cyphered connections.

NOTE: to manage certificates, service providers can use the Certificates MMC (Microsoft management

console), that is another graphical access to the Certificate Store. When configured, it only requires to select

“Computer account” and then “local computer”.



If a service provider opens the certificate to see additional details, this is what he will see:

the certificate is issued to cc.virtualtothecore.com as requested, it’s valid, and the Certification Path

is recognized; this means Windows is able to recognize the Certificate Authority that signed the

certificate as valid.



Luca Dell’Oca (vExpert, VCAP-DCD, CISSP) is an EMEA Evangelist for Veeam

Software based in Italy. Luca is a popular blogger and active member of the

virtualization community. Luca’s career started in information security before

focusing on virtualization. His main areas of expertise are VMware and storage

design, with a deep focus on Cloud Service Providers and Large Enterprises.

Follow Luca on Twitter @dellock6

About Veeam Software Veeam® recognizes the new challenges companies across the globe face in enabling the Always-

On Business™, a business that must operate 24/7/365. To address this, Veeam has pioneered a

new market of Availability for the Modern Data Center™ by helping organizations meet recovery

time and point objectives (RTPO™) of less than 15 minutes for all applications and data, through

a fundamentally new kind of solution that delivers high-speed recovery, data loss avoidance,

verified protection, leveraged data and complete visibility Veeam Availability Suite™, which

includes Veeam Backup & Replication™, leverages virtualization, storage, and cloud technologies

that enable the modern data center to help organizations save time, mitigate risks, and

dramatically reduce capital and operational costs.

Founded in 2006, Veeam currently has 29,000 ProPartners and more than 135,000 customers

worldwide. Veeam’s global headquarters are located in Baar, Switzerland, and the company has

offices throughout the world. To learn more, visit http://www.veeam.com.

About the Author

https://twitter.com/dellock6

http://www.veeam.com/?ad=pr

http://www.veeam.com/data-center-availability-suite.html?ad=pr

http://www.veeam.com/vm-backup-recovery-replication-software.html

http://www.veeam.com



NEW Veeam® Availability Suite™ v9

COMING SOON

RTPOTM<15 minutes for ALL applications and data Enabling the Always-On BusinessTM

with Availability for the Modern Data CenterTM

To learn more, visit www.veeam.com

Veeam Backup & Replication v8: Cloud Connect Reference ... · PDF fileVeeam Backup Replication...

Documents

Transcript of Veeam Backup & Replication v8: Cloud Connect Reference ... · PDF fileVeeam Backup Replication...