https://vccbook.io/3.Backups/3.4-cloud_gateways.html
 

the end bit has the CNAME part you’re referencing

Ive been out the MSP game for coming up 18 months now but IIRC it doesn’t matter what name is resolved as once it connects to VCC it’ll get all the gateways from the pool.

A CNAME record just redirects to an A record anyway so what you’re saying makes sense but I’m not familiar with VSPC anymore to comment further

When I spoke to Chris Arceneaux, he told me this for the A record setup -

GW1 = external IP

GW2 = external IP

GW3 = external IP

Primary URL - points to GW1 external IP

Primary URL - points to GW2 external IP

Primary URL - points to GW3 external IP

This then does the Round Robin using DNS.

@Chris.Childerhose ,

I thought he had mentioned using CNAMES like this:

GW1 = CNAME for Primary URL (eg. vgw1.domain.com points to vcc.domain.com)

GW2 = CNAME for Primary URL (eg. vgw2.domain.com points to vcc.domain.com)

GW3 = CNAME for Primary URL (eg. vgw3.domain.com points to vcc.domain.com)

Primary URL (vcc.domain.com) - Three separate A name records pointing to each of the external IPs for round robin.

Am I remembering this correctly?

I have some more context for this. I am working with a customer who is deploying VSPC and when an VSPC management agent is deployed to a backup and replication server both the agent and the service provider part of the backup infrastructure are automatically populated with the DNS name of one of the gateways which is a single point of failure. It should really be using the common/primary DNS name for full round robin redundancy, IMHO. Configuring DNS as above with CNAMEs would be a workaround for this issue.

I have noted what I posted above and this is the diagram which no CNAME is mentioned he gave me.

This wouldn’t make sense because Veeam can’t load balance as it would give a gateway and then DNS could redirect it elsewhere.

Veeam Cloud Connect documentation also states: 

Configurations with one DNS record for multiple IP addresses are not supported.

The SP can use one public DNS name for their Veeam Cloud Connect infrastructure and provide the tenant with this DNS name instead of DNS names of cloud gateways. In this case, the SP must create DNSrecords for both public Veeam Cloud Connect DNSname and DNS names of cloud gateways. For example:

Was struggling to find the other part I wanted to add but I’ve got it: https://vccbook.io/3.Backups/3.5-cloud-gateway-pools.html

When initiating a connection, a client resolves the record cc.virtualtothecore.com and it can receive any of the possible records from the DNS server thanks to round robin. As long as at least one gateway is available, the connection is successful. Once the connection is established, Cloud Connect server sends to the tenant the entire list of all the available gateways, listed with both their DNS name and IP address, and also tells the tenant to which Gateway it should connect, which is usually the one with the lowest amount of active connections. This design works perfectly over public internet, but it may lead to some connection issues in other scenarios; this can be solved thanks to Cloud Gateway Pools.

—-

This is why you create a round Robin DNS to give a customer for initial connection, then VCC instructs to which cloud gateway endpoint the tenant should connect, by giving the individual DNS Records and IP addresses of the Cloud Gateways

This is good to know.  Since I only have one Gateway, I guess vspc.domain.com and vcc.domain.com pointing to the same server (Gateway and console are the same server) but I had planned on if we grew to needing additional gateways I'd add as needed. 

Hi @dloseke  when time permits you should consider splitting those out onto separate servers. A cloud gateway should reside in a DMZ with limited internal access due to it being web facing, and it would do a lot of damage if your VSPC server was compromised

I wouldn’t mind doing that anyway...I hate the name I’m using for the server and as it’s using a old naming convention.  With that said, I need to reread the documentation I think.  I was thinking they were both web-facing, just with the needed specific ports.

So I’ve found out more about how VSPC Management Agent communication and VCC Cloud Gateway communication happens. Turns out the information is in the documentation but who reads ALL the documentation? 

It seems to me that the round-robin DNS isn’t necessary as the first (and subsequent) connections to a Cloud Gateway will provide the VSPC Management Agent or VBR or Backup Agent on the tenant side with a full list of the gateways to connect to. This answers the main question I had which was more of a cosmetic issue as both the Management Agent and the service provider settings for a VBR deployed using VSPC shows only one of the gateway DNS names. Under the hood, all gateway IPs or DNS names are understood.

Reference:

Very interesting.  Thanks for sharing the update.  Time to get reading some more.  

Thanks for this.  I need to read more on this myself.  I don’t have multiple cloud gateways or VCC servers, so I kinda glossed over that part a little when I was performing my setup, but I did look at it because I wanted to set it up in a way that would be scalable if/when the time came that I needed a gateway and multiple VCC servers.  But I think that was also two versions ago, so I need to reread to refresh my memory, but also in the event of updates/changes in the product as well.

Hello hello, the post is some time old, I hope you can help me.

Understanding the documentation, but I have the following doubt, if the client when it connects to the gateway, and it is not available, performs the failover, how should I configure my nat, that is, it is not clear to me if I only do the Is NAT a single gateway or if I do 1 nat for each Gateway? I don't know if I can explain myself? Thanks for the prompt response.

Which product are you referring to for Veeam?  Veeam Cloud Connect?  Gateways use DNS round robin typically for load balancing.  We need a bit more clarity to help or make suggestions.

The set up should be multiple A records in public DNS entries for the main URL which provides round robin redundancy. Each IP should be set up with one to one NAT to a single internal gateway server. Each internal gateway server should be set up with unique URL (eg prefix gw1, gw2, etc to the main URL) and those DNS records should also be configured in public DNS with one to one mapping. Eg main URL has three A records. Gw1.mainURL has one IP. Gw2.mainURL has second IP, etc.

Thanks for the prompt response and explanation, now if I add one of that url that would belong to a single Gateway, but this gateway at some point becomes unavailable, could it automatically and/or natively do the switching error even though the client side was added with the URL belonging to that gateway that would be dowm in this example?

You would not use a GW URL as it would be the main URL for the service which points to the GW URLs.  This way it can failover to another.  If you use a specific GW URL then you have failures until changed.

Sorry, it's still not very clear to me, I'm going to put it more or less as it would be so that you can guide me better, I thank you very much.

Suppose my domain is mydomain.com

I have 3 gateway servers with the following private and public IPs with their respective NAT on my firewall

Gateway 1=190.168.20.90 with private IP 192.168.10.10
Gateway 2=190.168.20.91 with private IP 192.168.10.11
Gateway 3=190.168.20.92 with private IP 192.168.10.12

I understand that the urls would remain

G1= gw1.mydomain.com
G2= gw2.mydomain.com
g3= gw3.mydomain.com

I understand that the A records within my DNS will be these:

G1= gw1.mydomain.com
G2= gw2.mydomain.com
g3= gw3.mydomain.com

But what URL should you give to the client to connect to the gateways.

As I understand it, it would be "mydomain.com"

Assuming this is the case, shouldn't I do anything in my DNS hosting for it to recognize the gateways?

Sorry if it doesn't explain it to me and thanks for the response.

You need three more records for the primary URL that point to the same IPs as the GW URLs.

Service.mydomai.com = IP1

Service.mydomain.com = IP2

Service.mydomain.com = IP3

This is the URL customers use but the GWs in Veeam use the gateway URLs.