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.

DNS Servers

In previous versions of this book, this section was dedicated to Microsoft Active Directory. However, since more and more Veeam components can now run on Linux, operating an Actice Directory solution to centrally authenticate and authorize the access to Veeam servers is becoming less important. Since there are only a few components running on Windows, service providers can use local authentication on those servers.

What’s important to have is instead a DNS service. Any IT infrastructure heavily relies on proper DNS configuration (with both forward and reverse resolution correctly configured) to reach all the different components. 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, we suggest 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. Note that firewall placed in between Gateways and Wan Accelerators/Repositories/Proxies should be able to sustain the heavy traffic that is expected, otherwise the firewall may become a bottleneck of the Cloud Connect environment.

Load balancers

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 on 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	203.0.113.35
cc.virtualtothecore.com	A	203.0.113.36
cc.virtualtothecore.com	A	203.0.113.37

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	203.0.113.35
gtw2.virtualtothecore.com	A	203.0.113.36
gtw3.virtualtothecore.com	A	203.0.113.37

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 wants to further optimize the use of its DNS service, he can use some advanced mechanism like Amazon Web Services Route53 DNS health checks. You can read more about this technology in this blog post Load balancing services with AWS Route53 DNS health checks.

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.

At the client side, 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 tenant 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.