14. Data Persistence challenges
14
● Ephemeral nodes
● Capacity based scheduling
● Reuse of disks
● Unavailability of disks or disk space
○ Auto provisioning of disks and then localpv
● Scaling down
Basic provisioning can be done statically or
some automation. But what about:
23. So MayaData put the storage
array inside K8s with OpenEBS,
and now devs can do their own
storage management.
24. OpenEBS
24
• Most active community in the Container Attached Storage space
• GitHub: https://github.com/openebs/openebs
• Website: https://openebs.io/
• Slack: https://slack.openebs.io
• Twitter: https://twitter.com/openebs
• Overall 350+ Code contributors (https://devstats.openebs.io/)
• 1400+ Slack Members, 600+ Forks, 6000+ stars
• 1.0 released in June
• Deployed in 100s of clusters every week.
• Kubernetes Native, 100% Userspace
25. OpenEBS NDM
25
● NDM runs as a
daemonset and
maintains the block
devices as CRs
● NDM operator links
north bound and
sound bound
interfaces
Application
Developer PVC
OpenEBS LocalPV
Provisioner
OpenEBS cStor/Jiva
volume Provisioner
cStor Pool
Provisioner
NDM Operator
NDM Sound bound
provisioner
CSI Drivers
OpenStack VSAN OpenSDS Legacy
(NetApp/Pure)
Block devices
in etcd Director
(DataOps)
Auto provisioning
of disks
VSANEBS/GPD/
Azure Disks
Any CSI driver
● Complete disk
management
including auto
provisioning to
smoothen the data
ops
● Data mobility
becomes easier with
auto provisioning on
remote clouds
26. OpenEBS Architecture
26
K8s api
Maya api
Browser
/
Terminal
---
kubectl
NDM
for underlying
block dev
discovery
Block
devices
OpenEBS
Provisioner
For disk setup
OpenEBS CRDs
} OpenEBS cStor Storage Pool
PVC
PV
POD
etcd
SnapClone
} OpenEBS LocalPV
PVC
PV
POD
Node 1
Node 2
Node 3
Node 4
27. Summary - OpenEBS LocalPV
27
● Ephemeral nodes
● Capacity based scheduling
● Reuse of disks
● Unavailability of disks or disk space
○ Auto provisioning of disks and then localpv
● Scaling down
Node Disk Manager and a bunch of operators
to solve the following problems:
30. Chaos Engineering
● Practice chaos engineering to increase resiliency
Resiliency Achieved by
CI Pipelines
Functional
Tests
Failure Tests
+
Achieved by
Staging / Production
Good CI
Random
Chaos+
30
32. Cloud-Native environment
● My code is 1%. Rest is not controlled by me.
● Linux is the least dynamic stack
● Rest is all microservices, based - highly dynamic CHAOS ENGINEERING
Then, how to achieve Resilience ?
32
33. Cloud-Native Chaos Engineering
Cloud Native
APIs
POD Deployment
PVC Statefulset
SVC CRDs
For
Development
For Chaos Testing
Cloud Native
APIs
?
Cloud-native
Application
33
34. Cloud Native
APIs
POD Deployment
PVC Statefulset
SVC CRDs
For Chaos Testing
Cloud Native
APIs
Chaos
Engine
Chaos
Experiment
Chaos Result
New CRDs
Cloud-native
Application
For
Development
Cloud-Native Chaos Engineering
34
41. What can you do?
41
● Join OpenEBS and Litmus slack to keep in touch
● Try using OpenEBS for Kafka and provide feedback
○ Open Source Karma
● Try using Litmus for Kafka
● Create issues for
○ Your challenges related to data
○ More chaos scenarios
42. Open Source Karma
42
● Like OpenEBS ?
○ https://bit.ly/staropenebs
● Like Litmus?
○ https://bit.ly/starlitmus
Help yourself with some cool stickers
44. Quick Look at the setup
44
Broker Broker Broker Broker
Konvoy with OpenEBS LocalPV
45. A Quick Kafka Refresher
● Kafka is the current go-to solution for building maintainable, extendable and scalable data
pipelines.
● Applications (producers) send (publish) messages (records) to a Kafka node (broker) and
said messages are processed by other applications (consumers).
● Said messages get stored in a topic and consumers subscribe to the topic to receive new
messages.
● Topics are broken down into partitions, for better performance & scalability. These partitions
consist of ordered data units identified by their offsets.
● The partitions are often replicated with one broker owning it (handle writes), called Leader
Broker with data replicated written into followers.
● A Controller Broker manages the administrative tasks to topic creation, leader assignments,
failover to in-sync replicas etc.,
● Kafka Cluster State is typically maintained in ZooKeeper (a distributed key value store), with
brokers keep a ZooKeeper watch to know events.
46.
47. Kafka Chaos Experiment: Kill the Kafka Broker Pod
● Objective: Test the deployment sanity of the Stateful Kafka Cluster
● Approach: Setup a liveness message stream with test producer/consumer & specify a
message timeout. Identify a partition leader & kill the pod. Verify if the liveness stream is
un-interrupted
● Health Checks: Verify broker list via ZooKeeper
● Tools: Litmus Chaos Operator & Kafka Chaos Experiment Chart
● Tested: CP-Kafka, Kudo-Kafka