The Case for Benchmarking Control Operations in Cloud Native Storage
Talkat 12th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage '20) · 2020-07-13..07-14·
summary
Argues that current benchmarks omit storage control operations and demonstrates with a five‑node Kubernetes cluster using gluster, ceph and open ebs that these operations matter: starting a single container with a fresh volume shows open ebs takes ~2× longer, but attaching 50 preexisting volumes makes open ebs ~2× faster than gluster/ceph. Running fio while taking 0/20/40 snapshots shows per‑provider tail latency differences (open ebs shows large tail spikes). Proposes a Kubernetes operator style benchmark controller, declarative specs, reuse of fio/pgbench, and ELK/Grafana for metrics.
AI-written summary · about
chapters (11)
- 0:00The Case for Benchmarking Control Operations in Cloud Native Storage
- 2:13Benchmarking's Blind Spot
- 3:06Storage Control Operations
- 5:45Create Volume (Storage Control Operation #1)
- 5:58Volume Mounted on Node
- 7:31Experimental Setup
- 8:06Experiment 1: Volume Creation and Attachment
- 9:50Experiment 2: Snapshotting Write Latencies
- 11:41Benchmark Design Requirements Result Measurement
- 13:10Proposed Design
- 14:23Conclusion
related talks
12mCNSBench: A Cloud Native Storage Benchmark
29mReliable and Cost-Effective: Open Storage Strategies for Kubernetes
56mBenchmark Your Cloud-Native Database
25mContainer Attached Storage: Open Source Extensions: Kubernetes + Data
28mPersistent Storage with Kubernetes in Production - Which Solution and Why?
37mBuild a Kubernetes Based Cloud Native Storage Solution From Scratch
04mLightning Talk - Benchmarking Persistent Data Volumes
27mThe Kubernetes Hunger Games: Distro Performance in the Edge