EFCX Hardware Sizing: Node-Pool Options
Overview
EFCX-Hardware-Sizing-Within-a-Site.md currently carries one way of turning the Kubernetes-hosted workload total, 26 vCPU / 52 GB, into actual node-pool capacity: a per-workload-group breakdown across six pools (Application, Data-platform/batch, Stateful, Edge & Identity, Secrets, Observability). This note lays that option side by side with a coarser alternative, so the two can be compared before one is picked as the reference figure.
Both options share the same control-plane, load-balancer, and Voice VM tier figures from the main doc; they differ only in how the Kubernetes-hosted worker capacity is carved up.
Option A: Coarse, uniform worker pool
Two worker nodes, 13 vCPU / 26 GB each, all Kubernetes-hosted workload groups (Application, Data-platform, Stateful, Edge & Identity, Secrets, Observability) sharing the same two nodes rather than each getting a dedicated pool. 13 vCPU / 26 GB is the per-node figure already validated as sufficient to carry the complete Kubernetes-hosted load on its own; the second node is a 1:1 failover pair, not added headroom.
|
Item |
Instances |
vCPU each |
RAM each |
Total vCPU |
Total RAM |
|---|---|---|---|---|---|
|
Kubernetes worker (uniform) |
2 |
13 |
26 GB |
26 |
52 GB |
In favor: matches the validated single-node capacity exactly, no padding beyond the 1:1 pair; fewest instances to provision and operate.
Against: one node below EFCX-High-Availability-Within-a-Site.md’s stated three-worker tested minimum; two nodes can’t host a three-member quorum (MongoDB replica + arbiter, PostgreSQL’s default three replicas) or MinIO’s distributed-mode pattern (four or more nodes, one drive per node) without co-locating replicas anti-affinity is meant to keep apart; stateless and stateful workloads share the same blast radius, so losing one node affects every workload group at once rather than one at a time.
Option B: Per-workload-group pools
Six separate pools, sized and counted to match each workload group’s own scaling shape and replica/anti-affinity pattern, per efcx-kubernetes-workload-groups.md. This is the option currently written into the main sizing doc.
|
Node pool |
Instances |
vCPU each |
RAM each |
Total vCPU |
Total RAM |
|---|---|---|---|---|---|
|
Application (stateless) |
3 |
4 |
8 GB |
12 |
24 GB |
|
Data-platform/batch |
2 |
4 |
8 GB |
8 |
16 GB |
|
Stateful |
3 |
2 |
4 GB |
6 |
12 GB |
|
Edge & Identity |
3 |
2 |
4 GB |
6 |
12 GB |
|
Secrets |
2 |
2 |
4 GB |
4 |
8 GB |
|
Observability |
2 |
1 |
2 GB |
2 |
4 GB |
|
Subtotal |
15 |
38 |
76 GB |
In favor: matches the three-worker tested minimum and gives each stateful component room for its own quorum/anti-affinity spread; isolates blast radius by workload type, a Stateful-pool node loss doesn’t touch the Application pool; matches the placement model the workload-groups doc already defines, so it doesn’t introduce a second, conflicting node-pool story.
Against: more instances to provision and operate; the per-pool split of CX-Core’s bundled 12 vCPU / 24 GB is a rough percentage estimate, not a measured figure, until real per-component numbers land per that doc’s “Numeric sizing” open item.
Side-by-side
|
Option A: Coarse |
Option B: Per-workload-group |
|
|---|---|---|
|
Kubernetes-hosted instances |
2 |
15 |
|
Kubernetes-hosted vCPU |
26 |
38 |
|
Kubernetes-hosted RAM |
52 GB |
76 GB |
|
Meets three-worker tested minimum |
No |
Yes |
|
Meets MinIO’s four-node distributed-mode pattern, if used |
No |
Yes (Stateful pool can be sized to it) |
|
Total incl. control plane, LB, Voice VM hosts (instances / vCPU / RAM) |
10 / 62 / 124 GB |
23 / 74 / 148 GB |
Open question
Neither option is settled here. The gap between them is really a question of how much operational isolation is worth trading for fewer instances, and that answer depends on what the hosting platform makes cheap to run, and on confirming whether MinIO’s distributed mode (four-node minimum) is actually in play for this deployment.