Another Veeam Cloud Connect (VCC) feature included on 9.5 update 4 that has made our life easier is the inclusion of Cloud Gateway Pools. These give us the ability to create groups of VCC Gateways that can then be assigned to individual clients.
Before Cloud Gateway Pools
We have a ‘unique’ issue where this functionality shines – aside from being a managed service provider, we also are a colocation provider. Many of our clients are purchasing DIA from us, which we still sell on the traditional bandwidth model (committed rate or burst w/95th percentile). After introducing the Veeam Cloud Connect functionality, a lot of our colo customers jumped on the service. The main issue we experienced with this service is bandwidth overages on our customers’ links because they were pushing these backups to our environment through the public internet. Even though this would turn into additional dollars for AIS, we want to enable them to replicate to us without having to cannibalize their DIA bandwidth. We believe that giving our customers a “Direct Connection” into our VCC environment is a great benefit over other Veeam Cloud Connect service providers. This is the path taken by the VCC replica traffic:
Customer Hypervisor -> Customer B&R Server -> Customer FW -> AIS Internet Router(s) -> AIS FW -> AIS public VCC GW -> AIS FW -> AIS B&R Server -> AIS VMware Environment
Before this feature became available, we started running dedicated cross-connects between our VCC infrastructure and customer environments. Our customers would then perform the necessary DNS tricks on their end to redirect traffic to our VCC Gateways to an IP (RFC1918) existing at the other end of that cross-connect. Eventually, they would be hitting a different interface on the cloud connect gateways, but they would not be going through their primary Internet drain.
With Cloud Gateway Pools
With this feature we’re now able to stand-up and assign (what we’re calling) “internal gateways” to individual customers. These gateways have two NICs: one facing the customer, the other facing our VCC infrastructure. This architecture has also provided some network relief on our edge as traffic flows migrate to dedicated links.
The new feature works as follows:
- Service provider configures additional gateways (as required)
- Depending on security and network architecture
requirements, there could be a 1:1 relationship between customer and gateway.
However, for small environments, it should be possible to use one “internal”
gateway for multiple customers. Conversely, service providers can assign or
dedicate multiple gateways for a single customer.
- Service provider adds the gateways to a “Gateway Pool” object
- Once the gateway pool(s) is created it can then be assigned to a single or multiple customers.
This functionality allows the service provider to check a box to allow the customer to “Failover to other cloud gateways if all gateways from the selected pool are unavailable”. This is convenient as it allows for an additional level of redundancy in case the connectivity to the dedicated gateway is lost.
- Once this is complete, customer jobs will automatically be sent to the proper gateway. There is no need to change any settings in the Client’s “Service Provider” configuration – they can continue to have this pointing to the SP’s publicly facing gateways, Veeam will take care of the rest.
- The caveat here is that we had to have our customers create hosts file entries on their Veeam B&R server for the gateways, so that their server is able to ‘find’ our internal gateway on the interface available to them through the dedicated cross-connect link.
This is the new path taken for replication traffic using this method:
Customer Hypervisor -> Customer B&R Server ->
FW -> AIS Internet Router(s) -> AIS FW -> AIS public
internal VCC GW -> AIS FW -> AIS B&R Server -> AIS VMware
Official Veeam documentation on this feature can be found here: https://helpcenter.veeam.com/docs/backup/cloud/cloud_gateway_pool.html?ver=95u4