2.11 Additional components
Even if they are not part of the Veeam Cloud Connect infrastructure, the following components help to successfully create and operate the infrastructure.
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 the network based on a Windows domain, assigning and enforcing security policies for all computers and users and installing or updating software.
The ability to centrally authenticate and authorize access to resources is a good solution to guarantee better manageability of the environment. In addition, all Veeam Cloud Connect components (with the exception of Linux repositories and the network extension appliances) are designed to be executed on Windows machines, so having Active Directory in place may be a welcomed solution.
Also, if you plan to run Veeam Backup for Office365 (VBO) and offer self-service restore options to your customers, at least the VBR server and the VBO proxies (not to be confused with backup proxies) need to be joined to the same Active Directory domain.
Finally, Active Directory offers integrated DNS services. Any IT infrastructure heavily relies on proper DNS configuration (with both forward and reverse resolution correctly configured) to reach all the different components. Regardless if you plan to have a central authentication system or not, it’s mandatory to have proper DNS configuration across the entire Cloud Connect environment.
Firewalls
By its nature, Veeam Cloud Connect is a service that needs to be exposed over the public internet to serve users. Because of this, network security solutions like firewalls should be deployed and properly configured in order to protect Veeam Cloud Connect.
Different technical solutions and business requirements lead to different security designs. For this reason, it makes little sense to describe a detailed firewall design for Veeam Cloud Connect. Instead, this book suggests two high-level design concepts to use when protecting Veeam Cloud Connect:
- Separate different logical components in different security zones: For example, keep cloud gateways and NEAs in different and separated areas. Because they are components that need to be exposed over the internet, a compromise on these machines will not lead to a compromise of the entire Veeam Cloud Connect environment.
- Reduce network connections to a minimum: You should have firewalls authorizing any communication between components. You can do so by opening the minimum number of required TCP/UDP ports. Chapter 3 and 4 describe these ports in detail.
Load balancers
As explained before, 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.
To better understand this design principle, remember this important design consideration: Each cloud gateway needs to have its own public IPv4 address, regardless of whether 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, there is no need to have a large amount of cloud gateways even on large installations, so the use of public addresses should not be an issue for most service providers.
These requirements have a direct consequence on load balancing: A service provider doesn’t need to use a load balancer with shared IP address to publish multiple cloud gateways.
Only the initial connection from a tenant to the Veeam Cloud Connect environment needs balancing. This can be accomplished by using simple DNS Round Robin: The public FQDN (fully qualified domain name) of Veeam Cloud Connect can be configured in the DNS to have multiple A (host) records. This way, when a tenant connects to the assigned resources in Veeam Cloud Connect, he connects to one of the registered public IP addresses, realizing a simple balancing between the cloud gateways. An example configuration would look like this:
| DNS name | record type | IP address |
|---|---|---|
| cc.virtualtothecore.com | A | 185.62.37.98 |
| cc.virtualtothecore.com | A | 185.62.37.99 |
| cc.virtualtothecore.com | A | 185.62.37.100 |
NOTE: This example uses a personal but real domain name because when creating a real SSL certificate, every certificate authority checks the information of the applicant and the registered domain. A fake domain would create errors during the SSL verification phase.
For proper operations when using wildcard certificates (like * .virtualtothecore.com ), the public hostname that resolves to each public IP assigned to a cloud gateway must use the same domain of the common DNS name used to publish the service. The same must be used in the SSL certificate. Therefore, in the example, the gateways must have their host names mapped in DNS as:
| DNS name | record type | IP address |
|---|---|---|
| gtw1.virtualtothecore.com | A | 185.62.37.98 |
| gtw2.virtualtothecore.com | A | 185.62.37.99 |
| gtw3.virtualtothecore.com | A | 185.62.37.100 |
One limit of this design may be that DNS does not have any notion of the state of the different cloud gateways, and users may receive information regarding failed or disabled gateways. This is not an issue in reality because Veeam Cloud Connect’s client component reads all the A records from the DNS resolution and tries to connect to each of them until it can establish an initial connection. Once it has reached one of the cloud gateways, it receives a list of all the existing and available cloud gateways directly from the service provider’s Veeam Backup & Replication server. The Veeam cloud service installed on the Veeam Backup & Replication server maintains and updates this list.
NOTE: In order to optimize the use of DNS Round Robin and avoid connection problems caused by DNS caching, you should configure low TTL (time to live) values for the A records.
If a service provider still wants to optimize the configuration of its DNS service, he can use some advanced mechanism like Amazon Web Services Route53 DNS health checks, explained in Chapter 8.
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 result, Veeam Cloud Connect load balances directly without any need for external load-balancing solutions. Load balancing is based on the number of active connections per gateway.
When one of the cloud gateways fails, all existing connections are lost. Depending on the type of job that was going through this gateway, two scenarios can occur:
- Backup jobs are sensitive 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 advise 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 timeout threshold has been reached, backup copy jobs will 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 an end-user perspective: The list of available gateways is retrieved by the end-user component of Veeam Cloud Connect upon any job start or retry. The available gateways are listed in a specified order in which the first usable gateway is assigned #1, the second #2 and so on. The number assignment and the priority depends on the actual load (number of active tasks) of all gateways.
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, 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, the running job fails and a new list is retrieved for the following retry.