Separated restAPI server - in a cluster?

[flavio.santos]

Hello team,

Good morning!

We are testing a cluster of 3 VMs for the restAPI server, and we are trying to figure out what the best solution is for the load-balancer.

We tried the round-robin and least_conn, but in both cases, after getting the token, the other requests fail 66%. So I believe the token was created only in one restAPI server, not in the entire cluster, and as the load-balancer is rotating the requests, it will work only in one server (33%).

Using IP_HASH, it works, but as the requester will be our portal, it will come from one single IP, and with that, all requests will be pinned to one node.

Do you guys know any solution for that? Perhaps a configuration where the REST API server can share the token with the other REST API servers? Or another solution for load-balancer?

Thanks!

[chris.arceneaux]

Hi Flavio,

I know we worked on this offline. Just sharing our results for the benefit of the community.

For the Load Balancer (LB) configuration, the session must be persistent (or sticky).

The next question - Is this a recommended configuration? It depends...

Let's start off by defining the use case for the separated REST API server: (Not related to a cluster with an LB)

• Internet-facing Restore Portal
  • If the Restore Portal is made publicly accessible over the internet, best practice is to leverage a separated REST API server. This enables this server to be placed in a more restrictive security zone separate from the Veeam environment. An LB or Reverse Proxy could also be placed in front of this server. This not only increases security but doesn't automatically compromise the Veeam environment if a threat actor gains access to the server.
• Security
  • Even if the Restore Portal is not internet-facing, business and/or security requirements could mandate it be placed in its own more restrictive security zone.
• Reduce Controller server resource consumption for Restore Portal
  • If the Restore Portal is hosted using the separated REST API server, this alleviates the Controller server from hosting it.

Armed with this knowledge only use the separated REST API server if your use case fits one of the above options.

Back to the topic on hand, multiple separated REST API servers with an LB are supported and can be used for limited high availability. Please note the controller server and its config DB are still single points of failure.

Hope this helps!

[jorgedlcruz]

Hello Flavio,
To Chris first point about a reverse proxy, I cover this back in 2022. To me it is the winner scenario at all times when trying to expose the portal to the Internet:

• https://jorgedelacruz.uk/2022/11/04/vee ... re-portal/

I would also recommend these reads as I think you want to use the restore portal extensively:

• https://jorgedelacruz.uk/2022/03/29/loo ... gin-audit/
• https://jorgedelacruz.uk/2022/03/24/vee ... ft-365-v6/
• https://jorgedelacruz.uk/2022/03/21/vee ... ft-365-v6/
• https://jorgedelacruz.uk/2022/03/18/vee ... ft-365-v6/

Posts are a bit old, but still solid guides to use restore portal a bit deeper and at scale.

Let us know!