7. What Jepsen Is
A blog series about distributed systems behavior
A talk series about distributed systems behavior
A Clojure library to test the behavior of distributed systems
A collection of tests written using those libraries
9. What I Did
Jepsen Tests
lein test
On GitHub – available at riptano/jepsen
10. A Test Incarnate
{:name …
:os …
:db …
:client …
:generator …
:conductors {:nemesis …}
:checker …}
names the results
prepares the os
configures/starts/stops the db
interacts with the db
instructions on how to interact
interacts with the environment
looks at and assesses test run
11. What You Need
One machine to run the tests
+
n machines to run Cassandra
17. Single Test Name
Test name used to label folder where
test results, logs, and history will be
stored with timestamp
cassandra cql set isolate node decommission
20. Single Test OS
debian/os
(setup! ;adjust hostfile
;update package manager
;install base packages like curl, iptables, etc.
;make sure network is healed)
(teardown!)
21. Single Test DB
cassandra.core/db
(setup! ;shutdown and wipe Cassandra if running
;install, configure, and start Cassandra)
(teardown! ;shutdown and wipe Cassandra)
(log-files ;return path to log files)
22. Single Test Client
cql-set-client
(setup! ;driver connect to all nodes
;create schema)
(invoke! ;add? Run CQL to add to set, handle errors
;read? Read value of CQL set, handle errors)
(teardown! ;disconnect driver)
26. Single Test Checker
checker/set
(check ;look at history of run
;find ok or uncertain adds
;compare these to final read
;return map with validity and
;ok, lost, unexpected, recovered)
27. Invariants We Test
Do CQL collections (maps, sets) merge cleanlywhen add-only?
Do counters merge to accuratelyreflect increments/decrements?
Does LWT in a single datacenterallow us linearizability?
Do materialized views converge to matching the base table?
Do batch writes eventually get applied atomically?
28. Failures We Consider
How does this work under a variety of network partitions?
What about with node crashes?
Even if nodes are flushing and compacting?
And when nodes are being bootstrapped?
Or decommissioned?
While clocks drift?
29. How We Run
Start the Docker container
Install Java driver, Cassaforte, clj-ssh, and Jepsen
Use environment variables to point to build under test
Run lein test with any desired selectors and profiles
30. Tunable Options
Should we make a best-effort attempt to scale test length?
Should we enable commitlog compression, the coordinator
batchlog on materialized views, or hinted handoff?
Is a different compaction strategy or phi value in the failure
detector appropriate for this test?
Should we install from a tagged release, a URL pointing to a
tarball, or a local tarball?
Should we leave Cassandra running after the test?
31. What We’ve Found
Issues with counter undercounting/overcounting(#10143)
Decommission race conditions causing gossip problems (#10231)
Write durability violations when recovering commitlog (#9851)
Problems with merging of collections (#10001)
Batchlog replay failures after decommission/crash (#10068)
Incorrect asserts in counter write-path when timestamps collide
A variety of materialized view issues during development
32. Work We Shared
Minor Jepsen fixes/features (Jepsen PRs #58, 59, 62)
Docker images to run Jepsen tests (Docker Hub: tjake/jepsen)
Multibox Vagrant configurations to run Jepsen tests (on GitHub)
Upstream library fixes (clj-ssh PR #36)
Cassandra Jepsen tests (on GitHub)
Available on CassCI (on cassci.datastax.com)
34. Lessons I Learned
Tests verifying invariants under failures are valuable and practical
These tests can and should be a part of regular development
Testing complex systems is hard, but there are low-hanging fruit
Jepsen provides one readily available way to accomplish this goal
Considering invariants against a recorded test run is effective
Invariants should be explicit and carefully considered in design