Using External Persistent Volumes to Reduce Recovery Times and Achieve High Availability on DC/OS
summary
Claim: using Portworx external persistent volumes with DC/OS and dcos-commons cuts recovery to the time a scheduler reschedules tasks instead of hours or days of rebootstrap. Demonstrated: Portworx deployed across 5 agents, a 3‑node Cassandra with replication factor 3 and three 10 GB volumes, killing one node immediately reschedules the task on another node and volumes attach, and volumes are dynamically resized to 100GB. Notes: replication overhead measured ~3–5% performance hit; demo works end-to-end.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 0:53Stateful Services
- 2:15Why is Replication Important
- 4:15External Persistent Storage
- 5:22Portworks
- 7:51Portworks Deployment
- 8:48BlockLevel Replication
- 10:15Recovery Times
- 13:19Advantages
- 15:56Why not EBS
- 18:33How to use Portworks
- 19:24Portworks Example
- 20:39DCOS Comments
- 22:05Decius Commons
- 23:54Demo
- 25:09Port Works
- 27:54Port Works Cassandra
- 29:25What happens if a node fails
- 31:49How to dynamically resize volumes
- 33:09Questions
related talks
34mData Management in Kubernetes – Backup, DR, HA
35mDataStax Enterprise on DC/OS - Yes, It’s Possible; Customer Case Studies
29mMoving & managing k8s persistent data across clusters and cloud
48mContainer: check! Aber wohin mit Persistent Data, Big Data oder Fast Data?!
35mWhat You Need to Know Before Using Local Persistent Volumes
33mSponsored Session: Open Source Cloud Native Storage Solutions for Stateful Applications from ...
25mTuning Elastic on Kube...
32mCozystack Storage Deep Dive