Veeam (DDBoost) Gateway Sizing

[jj281]

Are there sizing guidelines? Assuming we're using a dedicated Gateway.

I can't find it in the User Guide and didn't see anything in the forum search.

Thanks in advance.

[foggy]

Jonathan, system requirements for the gateway are similar to those for backup repository (additional 1,5 GB RAM max is needed for DD Boost library):

CPU: x86 processor (x86-64 recommended)
Memory: 6 GB RAM plus 2 GB RAM for each concurrent job
Disk space: 200 MB for Veeam B&R components

[jj281]

I'm going to test this out, but assuming we don't have a dedicated Gateway how does Veeam determine what transport to use? I'm concerned because we utilize NBD (10Gig) and I'd prefer the Transport NICs to be on same subnet as the Hosts... and the DataDomain is not on that subnet

If I add another NIC to the Transports on the DataDomain Subnet will Veeam recognize that only those Transports should be used to communicate?

[foggy]

If you explicitly specify that specific server (with the NIC on the DD subnet) as the gateway, communication will be performed over that NIC. However, if the device itself has several NICs, we do not control which network will be selected, this is handled by DD Boost.

[jj281]

I mean if you're not setting a specific Gateway in the Repository settings, how is that determination made. It does mention it in the documentation, I guess I'll take it at face value, that it's random. Seems like it in my testing.
"The gateway server is picked at random and per job session. Veeam Backup & Replication may use one gateway server for one job session and another gateway server for another job session."

The only issue I see is we have two physical sites connected to the same Backup Server, with proxies ("DDBoost Library") in both sites, if we select "Any Server" and if it's truly random then it may choose a Proxy/GW in the other physical site. It would be nice to pick multiple potential GW servers per repository instead of random or one.

[tsightler]

I don't think it's quite that random. This same "gateway" concept has been used for CIFS ever since the whole proxy/repository scale out architecture was introduced in v6. Based on both my own testing and field results, the gateway will always be the first proxy that is used for a VM in that job. So imagine you have the following:

Site 1 -- Proxy 1, Proxy 2
Site 2 -- Proxy 3, Proxy 4

So if you're running a backup job at site one it might be "random" whether the jobs initially starts on Proxy 1 or 2, but the job will never use Proxy 3 and Proxy 4, so neither of those will ever be the gateway.

So in other words, if a job starts, and the first proxy it selects to use is proxy 1, it will run both the source data mover (proxy) and the target data mover (repository/gateway) process. If proxy 2 is also used for the job any data it reads is streamed to the repository/gateway process running on proxy 1.

For smaller environments this is probably no big deal, but it can lead to difficulty in predicting the exact data flow between proxies on any given run. In many cases when I'm asked to review environments that are having issues with jobs running great sometimes, and poorly other times, it's because of this unexpected data flow. Imagine if I had 10 proxies running 10 different jobs, data could be flowing in all directions!

Because of this, depending on the specific network topology, manually selecting the gateway server can be advantageous. For example if you have a physical server that acts as a gateway you can specify one NIC for all the proxies to stream their data to, but then have the second NIC dedicated to streaming data to the DD. This will give very predictable results but has the disadvantage that if the gateway server is offline backups will fail until a new gateway is selected (or the gateway server comes back online).

With proper design and planning either option can be a good design.