The POD concept

[pod] = a detachable or self-contained unit on an aircraft, spacecraft, vehicle, or vessel, having a particular function.

In IT architectural design, a POD refers to a self-contained and autonomous system that can supply its services without the help of external components. Also, a POD is usually a “unit” of measurement of these systems, like a rack or similar. Designing a solution “in PODs” means creating multiple copies of the same service, side by side, so that expanding the service becomes adding more pod’s to the overall environment.

Why is this done? Because there is no system in the IT industry that can grow infinitely. And even if there is one, experience suggests that at some point a system should stop growing, and a new one should be deployed next to the first one. This is because of multiple reasons:

• software has limits: some software have “hard limits” defined in the code. This is not the case in Veeam, but at some point the design of the software itself will prevent growth, as the software will start to misbehave. These are defined “soft limits”, and for example in Veeam Cloud Connect one soft limit is 1000 concurrent backup tasks.

• failure domains: they used to say “don’t put all your eggs in one basket”. This is true also for IT systems. If they are separated, a failure to one system will not affect the others. A failing pod will impact only the customers hosted into that pod, noone else.

For all these reasons, we suggest to build Veeam Cloud Connect using the pod concept.

POD sizing

• Concurrent backup tasks: 1000

Veeam Cloud Connect (VCC)

System requirements

Recommendation for up to 1000 concurrent tasks.

VCC Server

* 16 CPU cores minimum e.g. when using only management capabilities
** Depending on log level configured

VCC Cloud Gateway

In addition set the below setting at HKLM\SOFTWARE\Wow6432Node\Veeam\Veeam Gate Service

MaxSimultaneousCloudConnections
Type: REG_DWORD
Description: limits the total number of active connections to the gate. When reached, new connections are dropped.
Default value: 1024
Recommended value: 20000

WAN Accelerator

MSSQL Server

Database

“Should we use Microsoft SQL or PostGreSQL?”

PostgreSQL is using slightly more CPU and RAM on big deployments, compared to MS SQL. Overall, the choice of DB engine can be done based on service provider expertise in a specific DB engine, DB license cost considerations, Linux/Windows OS preference.

Another point of attention is the overall Veeam stack: VCC maybe be combined with VSPC and perhaps even Veeam ONE. Then it’s better to stick with Microsoft SQL, as the two mentioned solution can only use this database, so it’s more efficient to have 1 DB engine to host all 3 databases vs 2 engines.

For remote PGSQL design, modify DB limits https://helpcenter.veeam.com/docs/backup/powershell/set-vbrpsqldatabaseserverlimits.html

Pod sizing per tasks or per tenants?

The aforementioned sizing can handle 1000 concurrent tasks. This value has been tested with:

250 tenants with 4 tasks each, with worst possible scheduling (everything kicks in in parallel)

This means middle ground configurations can be realized when the scenario is a bit less demanding.

Registry keys

Additional registry keys can help to optimize the performance. Please refer to Veeam KB4217 for further information and a comprehensive list of keys.