Using External Persistent Volumes to Reduce Recovery Times and Achieve High Availability on DC/OS
summary
Portworx on DC/OS provisions external block volumes for stateful apps so a three node Cassandra cluster boots with volumes auto-created, a replication factor 3 ensures data exists on other nodes so a failed node is relaunched elsewhere by attaching the same volume without bootstrapping, the demo resizes a 10GB volume to 100GB live with no app restart, full Portworx + UI + cluster installs in about eight minutes and reads can use multiple replicas.
AI-written summary · about
chapters (16)
- 0:00Start
- 0:17Agenda
- 0:47Types of stateful services
- 1:52Why is the replication strategy important?
- 2:58How can External Persistent Storage help
- 3:56About Portworx
- 5:52Block Level Replication
- 6:47Recovery times - Without External Storage
- 8:03Recovery times - Using External Storage
- 8:56Advantages of using Portworx
- 11:03Why not just use EBS directly?
- 12:27Using Portworx with your stateful services
- 13:11Deploying through marathon
- 14:07Deploying through the Universe
- 15:39Creating services using doos-commons and Porto Volumes
- 16:41Demo - Deploying Portworx and Cassandra
related talks
44mAvailability, Latency and Cost: Withstanding Outages
31mScaling a Distributed Container Management System: Diego Performance
17mContinuous resilience: Managing your application risks
04mLightning Talk - Benchmarking Persistent Data Volumes
13mUsing Virtual Nodes to Auto-Scale Your Application on Kubernetes
08m⚡ Fast Restarts, Not Just Fast Starts: Accelerating Pod Recovery
15mBuilding Self-Healing Cache Infrastructure
18mReal-time adaptive controls for resilient container workloads