veeam backup & replication v8: cloud connect reference...

Luca Dell’Oca vExpert, VCAP-DCD, CISSP

Veeam Backup & Replication v8:Cloud ConnectReference Architecture

2

Veeam Backup & Replication v8:Cloud Connect Reference Architecture

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

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

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

3.1.5.1Pod Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

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

3.2Additional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1Active Directory Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . 13

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

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

4. Reference Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2S ubnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Firewall considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.1 Management Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.2 DMZ Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.3 Storage Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

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

4.4.2 Veeam Management servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

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

4.4.4 WAN Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4.5 Backup Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3


5. Customer creation and initial connection . . . . . . . . . . . . . . . . . . . . . . . . . 30

APPENDIX A: SSL Certificates generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

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

A.2 Obtain a Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

About Veeam Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4


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.

5


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.

6


2. Introduction

2.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.

7


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.

8


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.

9


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.

10


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.

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). A single WAN Accelerator can optimize data transfers of connections up to around 50-60 Mbs (Megabits per second). So, when sharing one WAN accelerators among multiple customers, a service provider will have to take into account the total bandwidth of said customers. For example, one WAN Accelerator could be the target of 10 customers having each a 6 Mbits upload speed. For customers with higher upload bandwidth, Veeam recommends a direct connection without involving a WAN Accelerator.

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.

11


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.

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.

12


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.

13


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.

14


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:

15


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.

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.

16


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).

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.

http://www.veeam.com/kb1518

17


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:

DMZ

This 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).

ManagementThis 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.

18


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.100.0/24, VLAN 100, gateway 192.168.100.254

Storage 192.168.100.0/24, VLAN 100, gateway 192.168.100.254

External

10.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 getaway 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.

http://www.veeam.com/kb1518

19


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.

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.

20


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, FMSO 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.

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.

21


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 console and selecting the node “Cloud Connect Infrastructure”:

22


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

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

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

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

4. 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



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.

23


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.

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:

24


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



25


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)

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.

26


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:

27


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:

28


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:

29


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.

30


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:

31


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:

32


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 login into the Cloud Connect infrastructure with the given credentials, and Cloud Connect returns the resources the user is entitle to consume:

33


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:

34


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.

35


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.

36


; 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

37


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.

38


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-----

39


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.

Them, 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.

40


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”.

41


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.

42


About the AuthorLuca 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® provides Availability for the Modern Data Center™ by leveraging virtualization, storage, and cloud technologies to deliver recovery time and point objectives (RTPO™) of < 15 minutes for all data and applications. Veeam’s solutions enable the Always-On Business™ with high-speed recovery, data loss avoidance, verified protection, leveraged data and complete visibility. Veeam Backup & Replication™ lleverages technologies that enable the modern data center, including VMware vSphere, Microsoft Hyper-V, NetApp storage, and HP 3PAR StoreServ and StoreVirtual Storage, to help organizations meet RTPOs, save time, mitigate risks, and dramatically reduce capital and operational costs. Veeam Availability Suite™ provides all of the benefits and features of Veeam Backup & Replication along with advanced monitoring, reporting and capacity planning for the backup infrastructure. Veeam Management Pack™ is the most comprehensive, intuitive and intelligent extension for app-to-metal management of Hyper-V and vSphere infrastructures, and includes monitoring and reporting for Veeam Backup & Replication. The Veeam Cloud Provider Program (VCP) program offers flexible monthly and perpetual licensing to meet the needs of hosting, managed service and cloud service providers. The VCP program currently includes more than 5,000 service provider partners worldwide.

Founded in 2006, Veeam currently has 25,000 ProPartners and more than 111,500 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.

https://twitter.com/dellock6

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

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

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

http://www.veeam.com/vmware-microsoft-esx-monitoring.html

http://www.veeam.com/cloud-providers

http://www.veeam.com/cloud-providers

http://www.veeam.com

43


To learn more, visit http://www.veeam.com/backup

veeam backup & replication v8: cloud connect reference...

Documents