CephXXIX · Network DesignNetwork Design
Switches as failure domains
What you'll learn
- Identify switch failure domains in a cluster topology
- Design host and OSD placement across switches
- Align CRUSH buckets with network topology
- Evaluate MLAG and independent-switch designs
Prerequisites
None — start here.
Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18
Why this matters in production
CRUSH protects against the failure domains you tell it about. A
top-of-rack switch that takes twenty hosts offline is a failure domain
whether or not it appears in ceph osd tree, and the mismatch between
physical topology and CRUSH hierarchy is one of the more common ways a
well-designed cluster fails badly.
The three topologies
Single ToR per rack. Simple and cheap. The switch is a single point of failure for every host in the rack. Ceph must treat the rack as a failure domain — which it should anyway for power reasons.
Dual ToR with MLAG. Two switches presenting as one to LACP bonds. A switch failure removes one bond member per host and Ceph notices nothing. This is the standard production design.
Dual ToR, independent, no MLAG. Each host has separate links to two switches, in active-backup or with separate addressing. More complex, avoids MLAG’s shared control plane, requires more care in Ceph configuration.
Aligning CRUSH with the network
The rule: every level of your physical topology that can fail as a unit should be a CRUSH bucket.
ceph osd crush add-bucket rack1 rack
ceph osd crush add-bucket rack2 rack
ceph osd crush add-bucket rack3 rack
ceph osd crush move rack1 root=default
ceph osd crush move ceph-osd-01 rack=rack1
ceph osd crush rule create-replicated by-rack default rack
ceph osd pool set rbd-vms crush_rule by-rack
ceph osd tree
If a switch serves exactly one rack, the rack bucket covers it. If a switch spans racks — a leaf serving half of two racks — then the switch is a failure domain that the rack hierarchy does not represent, and you need a bucket type that matches the switch boundary.
Counting domains
For size 3 with failure_domain=rack you need at least 3 racks, and
meaningfully more for recovery headroom. For EC k+m you need k+m.
A common mistake: two racks with failure_domain=rack on a size-3 pool.
CRUSH cannot place three replicas in two racks, so the pool never goes
clean. The rule silently produces undersized PGs rather than an error at
pool creation.
Spine-leaf
At scale, leaf switches serve racks and spine switches interconnect them. The failure domains become:
- Leaf — takes out its rack; covered by a rack bucket
- Spine — reduces inter-rack bandwidth; with several spines, degradation rather than failure
- Uplink oversubscription — not a failure, but a throughput ceiling that recovery traffic will find
Quiz
Knowledge check · 4 questions
Q1. A cluster has two racks and a size-3 pool with failure_domain=rack. What happens?
Q2. Changing the failure domain from host to rack increases the proportion of replication traffic crossing leaf-spine uplinks.
Q3. Plan a failure-domain change alongside its network impact.
A cluster currently uses failure_domain=host across 4 racks of 15 hosts each, at 25 GbE per host with 2 × 100 Gb leaf uplinks per rack. A recent power incident took out a whole rack and caused a partial outage, so the team wants to move to failure_domain=rack.
Q4. Why can a leaf switch that spans two racks make a rack-based CRUSH hierarchy insufficient?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Draw the physical topology and the CRUSH hierarchy side by side during design review and confirm every unit that can fail together appears in both. Review uplink oversubscription against recovery traffic whenever the failure domain changes — the two are coupled and are usually reviewed by different teams.
Cross-course references
- Kubernetes: zone and region topology labels serve the same alignment purpose
- Linux: cluster manager fencing domains have the same requirement to match physical reality