Upload
vudat
View
268
Download
0
Embed Size (px)
Citation preview
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
3© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
4© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
5© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
6© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
7© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
8© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
9© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
10© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
11© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
12© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
13© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
14© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
15© 2015 Veeam Software
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
cc.virtualtothecore.com A 10.2.50.202
cc.virtualtothecore.com A 10.2.50.203
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
gateway2.virtualtothecore.com A 10.2.50.202
gateway3.virtualtothecore.com A 10.2.50.203
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
16© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
17© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
18© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
19© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
20© 2015 Veeam Software
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)
1 vCPU, 2 GB RAM, 40 GB disk
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
21© 2015 Veeam Software
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)
2 vCPU, 2 GB RAM, 40 GB disk
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)
2 vCPU, 4 GB RAM, 40 GB disk
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 Backup & Replication v8: Cloud Connect Reference Architecture
22© 2015 Veeam Software
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)
2 vCPU, 2 GB RAM, 40 GB disk
cc-gtw2.cloudconnect.local 192.168.100.2
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
23© 2015 Veeam Software
Windows Server 2012 (workgroup)
2 vCPU, 2 GB RAM, 40 GB disk
cc-gtw3.cloudconnect.local 192.168.100.3
Windows Server 2012 (workgroup)
2 vCPU, 2 GB RAM, 40 GB disk
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
24© 2015 Veeam Software
1. From the Cloud Connect Infrastructure node, go to Cloud Gateways and select Add Cloud Gateway
2. Select one of the previously added servers:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
25© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
26© 2015 Veeam Software
HOST INTERNAL IP NAT IP
cc-gtw1.cloudconnect.local 192.168.100.1 10.2.50.201
cc-gtw2.cloudconnect.local 192.168.100.2 10.2.50.202
cc-gtw3.cloudconnect.local 192.168.100.3 10.2.50.203
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
Windows Server 2012 (workgroup)
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
Windows Server 2012 (workgroup)
4 vCPU, 8 GB RAM, 40 GB for OS disk and 200 GB for cache disk
(on SSD or fast volume)
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
27© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
28© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
29© 2015 Veeam Software
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
Windows Server 2012 (workgroup)
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
30© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
31© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
32© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
33© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
34© 2015 Veeam Software
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:
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
35© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
36© 2015 Veeam Software
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"
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
37© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
38© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
39© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
40© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
41© 2015 Veeam Software
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”.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
42© 2015 Veeam Software
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.
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
43© 2015 Veeam Software
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
Veeam Backup & Replication v8: Cloud Connect Reference Architecture
44© 2015 Veeam Software
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