3.5 Cloud gateway pools
A new feature of Veeam Backup & Replication 9.5 Update 4 is Cloud Gateway Pools.
CG-pools are designed to overcome the previous limit of publishing Veeam Cloud Connect over multiple networks. Previously, the process of publishing and connecting to a Cloud Connect environment was bounded to a single network, because of the way that Cloud Gateways were announced to clients.
In a common deployment, like the one described in this book, multiple Cloud Gateways are deployed over the same network, and they are all published under the same DNS Round Robin resource record. As a recap, this is the configuration of the lab used for this book:
|HOST||INTERNAL IP||DNS HOST||NAT IP|
Upon connecting to the pool of gateways, a client resolves the record cc.virtualtothecore.com and it can receive any of the possible records from the DNS server. As long as at least one gateway is available, the connection is successful. Once the connection is established, Cloud Connect server sends to tenants the entire list of all the available gateways, listed with both their DNS name and IP address, and tells the tenant to which Gateway it should connect, which is usually the one with the lowest amount of active connections. This may lead to some connection issues that has been solved thanks to Cloud Gateway Pools.
Imagine the use case where a different network needs to be used to connect the client to Cloud Connect, for example a private line over MPLS. This is a common scenario in service providers offering dedicated links to large customers, or when the service provider is also a telecommunication provider.
Architects would have probably deployed a dedicated Cloud Gateway over this different line, and configured its networking in a proper way to make the new gateway part of the Cloud Connect environment, like this:
3.10: Cloud Gateway Pools architecture
Without the new Cloud Gateway Pools feature, every gateway will be announced to every tenant connecting to Cloud Connect, regardless his source network. So, customers connecting from public Internet will also receive in the listing the GTW4 machine, which has no public IP address and cannot be reached from Internet.
In the same way, a customer connecting via MPLS will receive together with the correct GTW4, also the other three gateways, which are not reachable over MPLS.
Cloud Gateway Pools are designed to make these situations work in a proper way.
Cloud gateway pools architecture
A cloud Gateway Pool is a logical group made by one or more gateways. A gateway can only belong to one pool, or to no pool (the “default” pool). A customer can receive one or more pools, if selected, otherwise he will connect to the default pool (if existent).
During the tenant configuration, for either backup or replication services, the provider can assign a specific pool:
3.11: Cloud Gateway Pools assignment
In the dedicated box, the tenant has two options:
3.12: Cloud Gateway Pools configuration
- Automatic selection: the least loaded gateway not belonging to any gateway pool will be selected each time the tenant connects. This means that the same existing algorithm for assigning a connection to a tenant is in place also here, but the selection is not made among all the gateways, but only among the gateway not assigned to any pool. If there are no free gateways, the software will return an error:
3.13: There are no default gateways
In this case, the provider has to assign one of the available pools, choosing the other option;
- Use the selected gateway pools” Again, the algorithm for gateway assignment is in action, but it will assign the least loaded gateway from the gateways belonging to the pool(s) assigned to the tenant. In fact, multiple pools can be assigned. Also, the additional option to Failover to the default group allows to connect to the other gateways if none of the gateways in the pool are available. This could be a common scenario for MPLS customers for example, when the private link is down and so Cloud Connect can failover to public Internet for proceeding in the backup or replication.
Because of this behaviour, a good design could involve the creation of dedicated pools for specific needs like MPLS, private links or internal tenants, and leave the gateways connected to public Internet without a pool, so that they will become both the default pool and the failover pool.