Hi all,
Maybe I’m not understanding how the Backup Server calculation at https://www.veeam.com/calculators/simple/vbr/server is supposed to work, but seems to give inexplicable results.
1000 Workloads with 500 workloads per job (2 jobs) == 36 cores, 80 GB RAM
99999 Workloads with 500 workloads per job (300 jobs) = 12 cores, 24 GB RAM
Less extreme examples produce similar results, seems like we end up with kind of strange requirements no matter what values are added.
Best answer by adamC
Hi
Thanks for pointing this out!
There are a couple of things to unpack here:
First, Version 12 formulas are using traditional sizing based on the jobs concurrency. Version 13 is no longer using this math. Instead, we have t-shirts published on the VeeamBP site for v12 that will be updated for v13. What you see in the calculator for v13 is the t-shirt sizing.
We did not yet update v12 to use the t-shirts as the focus has been more on v13 sizing. It’s certainly an area of concern that does need to be addressed. The plan is to remove the old math and stick with the t-shirts as they have been throughly tested by QA.
The second part: the number of workloads. We forgot to implement overflow for the workloads when they go over the max recommended workloads per VBR Server. We’re discussing how to implement this and will work to do so soon.
For the moment, I pushed a fix to the backend that will prevent overflow and show and error if the workloads go above the single recommended workloads per VBR.
+13this seems to be an issue… if you choose V12 you will receive a small amount of required resources:
Hi
Thanks for pointing this out!
There are a couple of things to unpack here:
First, Version 12 formulas are using traditional sizing based on the jobs concurrency. Version 13 is no longer using this math. Instead, we have t-shirts published on the VeeamBP site for v12 that will be updated for v13. What you see in the calculator for v13 is the t-shirt sizing.
We did not yet update v12 to use the t-shirts as the focus has been more on v13 sizing. It’s certainly an area of concern that does need to be addressed. The plan is to remove the old math and stick with the t-shirts as they have been throughly tested by QA.
The second part: the number of workloads. We forgot to implement overflow for the workloads when they go over the max recommended workloads per VBR Server. We’re discussing how to implement this and will work to do so soon.
For the moment, I pushed a fix to the backend that will prevent overflow and show and error if the workloads go above the single recommended workloads per VBR.
Thanks for the explanation Adam, makes sense, and looks like fix is sensible and using “sane” numbers works
I wasn’t aware it was intended to be limited to the vbr maximums, so while obv 99999 is a bit absurd, having clients with 15000 workloads not so absurd, so understanding the upper limit helps
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
