ispconfig3multiserver What's the recommended min resource requirements per service? Or ratio split?

I'm new to ISPCONFIG3 multiserver (on Debian 10), and trying to familiarize myself with its setup.

Assuming lower usage (a.k.a. Small audience, small wordpress sites, simple sites, no big email campaigns. )

And no local networking.

And the default tutorial setup:

• panel panel.example.com 10.0.64.12
• web01 web01.example.com 10.0.64.13
• mx1 mx1.example.com 10.0.64.14
• mx2 mx2.example.com 10.0.64.15
• ns1 ns1.example.com 10.0.64.16
• ns2 ns2.example.com 10.0.64.17
• webmail webmail.example.com 10.0.64.18

What should the minimum resources for each service server be?

In the event of up scaling, what services require what resources ratio-wise?
(Diskspace e.g. I don't know what the panel server needs for disk space, will it ever need extra disk space past the minimum? Or can I just slap 10gb on it & then dump all future diskspace into websiteserver/webmail? How much Diskspace does my Mail-exchange servers need in comparison to my webmail server?)

Starting resources to split are:

• unlimited bandwidth
• 330gb SSD
• 28gb RAM
• 19 vCPU

Intel(R) Xeon(R) CPU Platinum 8268 @ 2.9 GHz
cpu MHz : 2900
cache size: 20480 KB

 

I assume you are running some virtualization software and the hosts run as guests on that? Remember to leave 1 or 2 GB for the host, if guests use all the RAM things suffer.
For the guests, I would put 20 GB disk, then dist-upgrading to the next Linux release has enough disk space. Name servers have so little packages installed they may get along with 10 GB disk, but smaller than that is trouble. Make 4 GB swap and rest as root partition. If you know how much disk space your websites use, add that amount on the web server. If you know how much disk space your e-mail users need, add that amount to mx servers.
Give 2 GB RAM for each guest. Name servers might get along with 1 GB unless you have tens of thousands of zones. If there is unused ram on the host, you might use 4GB on e-mail servers and web server. If the guests are virtual machines you can adjust amount of memory according to experiences when in actuall use.
You can overcommit cores, so if host has N cores you can give up to 2N cores to guests. Use one or two cores on the small guests, 2 to 4 on the web and e-mail servers. Adjust after using in production.

 

Thank you very much for your response.

Yes I'm using VPS's, my apologies I should have clarified that.
(On top of that, I'm using a terrible service that doesn't let me add or remove resources once the server has been built... but it's dirt cheap.)

So if I understand you & the services clearly,

THE MOST LIKELY REQUIRMENTS (but individual hosting experiences may vary):

• Nameservers - light resources.
• Panel and Webmail - moderate resources. (they are just user interfaces, active user resources, and some config files.)
• Mail exchange and Websites - heavy resources. ( MX2 doesn't need to be as heavy as MX1? Because MX2 is an overflow who tries to give everything back to MX1 when it's free? or is that wrong for ISPCONFIG3? )
• Each VPS Host should get a base amount of CPU/RAM to accommodate the needs of the VPS itself, before guest services are considered.

Example breakdown of 330gb SSD, 28.5gb RAM, 19vCPU:

• ns1 ns1.example.com 10.0.64.16
  2 vCPU, 2.5gb RAM, 10gb SSD
• ns2 ns2.example.com 10.0.64.17
  1 vCPU, 2gb RAM, 10gb SSD
  

• webmail webmail.example.com 10.0.64.18
  2 vCPU, 4gb RAM, 20gb SSD

• panel panel.example.com 10.0.64.12
  2 vCPU, 4gb RAM, 20gb SSD

• mx1 mx1.example.com 10.0.64.14
  5 vCPU, 6gb RAM, 70gb SSD

• mx2 mx2.example.com 10.0.64.15
  2 vCPU, 4gb RAM, 30gb SSD

• web01 web01.example.com 10.0.64.13
  5 vCPU, 6gb RAM, 170gb SSD

 

Where does that assumption come from? I think it is not true.
MX2 must handle all mx tasks when MX1 is not available, so it must have the same resources.
Same goes for ns1 and ns2.

 

My mistake. I was used to using a different MX layout, it was a combination of ratio balancing incoming mail, and apparently a non-standard setup of shifting emails back to a larger server.