Learn MicroCloud - Performance & Capacity Planning

#Introduction

Episode 17 confirmed your release track choices. But versions don't determine speed — hardware and configuration do. In episode 18 you learn two things that are often mixed up: tuning (making what you have as optimal as possible) and capacity planning (calculating needs before buying). A fast cloud starts from a calculation sheet, not from luck.

An analogy: buying a sports car doesn't make you the race winner. The choice of tires, fuel, and route — plus calculating how many liters you need for 500 km — is what decides it. Your MicroCloud is that sports car; this episode is its pit-stop engineer.

#Hardware Tuning

#Disks: NVMe for OSDs

Storage is the heart of MicroCloud. All instance I/O — volumes, snapshots, Ceph replication — passes through the OSDs. The recommendation is firm:

• NVMe for OSDs is the best choice for performance. Sub-millisecond latency and high IOPS make Ceph replication (3 copies) feel light.
• SATA/SAS SSDs remain viable for medium workloads.
• HDDs only for archival/pure capacity — expect lower latency and throughput.

lsblk -d -o NAME,ROTA,SIZE,TRAN,MODEL

Rows with ROTA=0 and TRAN=nvme are ideal OSD targets.

#Networking: 10GbE

The underlay network determines how fast replication data and instance traffic move between nodes:

• Serious minimum: 1GbE for small labs, with reduced throughput.
• Production recommendation: 10GbE between nodes — Ceph replication and live migration run smoothly without becoming the bottleneck.
• Low latency: make sure the switch isn't overloaded; don't let storage traffic mix with public traffic without segment planning (episode 14).

#Ceph Tuning

#Pool Size and Replication

A Ceph pool has parameters that decide the balance between availability and capacity:

• Size (replication factor): how many copies of the data. MicroCloud's default is 3 — tolerates losing 2 OSDs/nodes. size=2 saves space but only tolerates 1 failure.
• Min_size: the minimum copies so the pool keeps accepting writes. The common default is 2 for size=3 — the cluster still writes even with one copy down.

Check the pool configuration:

ceph osd pool ls detail

#Placement Groups (PGs)

PGs divide data into units distributed across OSDs. The right number of PGs spreads data evenly without wasting resources:

• Too few PGs: uneven distribution, overloaded OSDs.
• Too many PGs: more memory and recovery overhead.

A general guide: about 100 PGs per OSD is a reasonable point. A practical formula per pool:

PG = (jumlah OSD × 100) / jumlah pool

MicroCeph usually sets a sensible default during init. Manual intervention is only needed when the scale changes significantly (episode 11).

ceph osd pool get rbd pg_num
ceph osd pool get rbd pgp_num

#Capacity Planning

#Calculating Capacity with Replica 3

Usable capacity isn't the same as raw capacity. With replication 3, every byte of data is stored 3 times:

usable = total raw disk / size
 
contoh: 3 node × 1TB NVMe = 3TB raw
        size=3 → usable = 3TB / 3 = 1TB
        size=2 → usable = 3TB / 2 = 1.5TB

Add other overheads:

• Bluestore/Ceph overhead: about 2-3% of space per OSD.
• Operational headroom: keep pool usage below about 80% so rebalancing and recovery have room to breathe.

#Node Sizing: 3-50 Nodes

MicroCloud is designed for 3-50 nodes — flexible from homelabs to medium edge fleets:

• 3 nodes (production minimum): full HA — replication 3, losing 1 node doesn't kill services. A perfect candidate for HA trials (episode 9).
• 3-9 nodes: small-to-medium scale; add OSDs and nodes as needs grow (episode 11).
• 10-50 nodes: edge fleets / multi-site; consider MicroCloud Cluster Manager for cross-cluster observability (episode 12) and mature network planning (episode 14).

Node A ─┐
Node B ─┼─► 3× 2TB NVMe OSD ─► 6TB raw ─► ±2TB usable (size 3)
Node C ─┘

#Workload as the Primary Input

Don't start from hardware, start from workload:

1. How many instances, and what average vCPU/RAM per instance?
2. How much storage per instance plus snapshots?
3. What network throughput is required?

From there, determine the number of nodes, disk types, and network links. This calculation becomes the basis of the production checklist in episode 22.

#Common Pitfalls

• HDDs for production OSDs: high latency hampers replication 3 — use NVMe/SSD.
• NVMe without 10GbE: the bottleneck just moves to the network.
• Adding PGs without a maintenance window: a large rebalance shakes the cluster — plan a window.
• Calculating capacity without replication: 3TB raw isn't 3TB usable when size=3.
• Fill ratio approaching 100%: Ceph rejects writes before it's full — keep at least 20% headroom.
• Size 2 to save space: saves space, but losing one node can halt writes — know the consequences.

#Closing

Key takeaways:

• NVMe for OSDs + a 10GbE underlay is the recommended production combination.
• Ceph tuning: size=3, min_size=2, about 100 PGs per OSD — measure before changing.
• Usable capacity = raw ÷ size; leave Bluestore overhead and at least 20% headroom.
• 3 nodes is the minimum for HA; MicroCloud supports up to 50 nodes.
• Start from workload, not hardware — calculate first, buy later.

In the next episode, we'll cover ecosystem: Ubuntu Pro & LXD — commercial support with Ubuntu Pro (LTS eligibility, LXD 5.21/6.x, auto-attach guests) plus tooling integrations: the Ansible inventory and LXD connection plugins, the Terraform provider, and the Packer builder. You'll see MicroCloud as part of a broader automation ecosystem!