Nobody Knows What PGs are Good For, Only I Do
summary
Shows that PGs let a distributed block store trade recovery speed for safety using concrete numbers and setups: a tiny cluster of three machines with two disks each (six disks, 15 possible pairs) and replication 2 yields placement groups counts of 3, 6, 9, 12 that produce two-disk failure data loss probabilities of roughly 20%, 40%, 60%, and 80% respectively. Compares the ceph RADOS/CRUSH-style indirection to a DM-thin + SRP/iSCSI/NVMe‑oF stack and explains how PGs limit full declustering while tuning resync parallelism.
AI-written summary · about
chapters (8)
- 0:00RAID / lvm-based storage stack
- 0:52Toward distributed block store
- 1:18Problem: coincident device failures
- 2:06Example cluster
- 3:16Number of placement groups: a tradeoff
- 3:40P(data loss two random disks fail)
- 4:23PG-Indirection Layer - a general concept
- 6:04Challenges
related talks
26mImplementing a Resilient Ceph RGW Object Storage with Erasure Coded Data Pool as the Foundation...
42mPostgreSQL Distributed: Architectures & Best practices
02h 59mCeph Storage: a Caffeinated Primer
25mSupporting 3 Availability Zones Stretch Cluster
38mPostgreSQL as a distributed computing platform
24mPLOVER: Fast, Multi-core Scalable Virtual Machine Fault-tolerance
15mWhy We Have 17 Clusters Instead of One (and Why You Probably Shouldn’t Do Th...
17mMAPX: Controlled Data Migration in the Expansion of Decentralized Object Based Storage