Vadosware is Victor's blog on self-hosted infrastructure, covering Postgres on ZFS, Hetzner servers, Kubernetes storage, Haskell, and consensus protocols.
HN commenters call the posts deep and informative, and cite the ZFS and Postgres tuning guide and the Hetzner drive failure write-up.
I'll have to admit that over time I've ended up with mixed feelings about this paper. This is mainly due to people reading this paper without knowing much about consensus and drawing conclusions like "Raft is better than Paxos" or "Raft is the best consensus algorithm" though. Some thoughts (please elaborate if you think I'm simplifying it too much or if you disagree with me!):
First of all remember that Paxos is a family of protocols for solving consensus. When doing research it's useful to reduce a problem into smaller and smaller parts. The "standard" Paxos algorithm is a very simple consensus algorithm which can only decide a single value once. It's not practical at all, but provides a good framework for thinking about consensus.
When this article proposes "Raft vs Paxos" they are actually comparing Raft against a standard way of configuring Paxos with a leader (MultiPaxos). Note that MultiPaxos allows a lot of nuances in the implementations while still being called "MultiPaxos". MultiPaxos is not a spec you implement; it's a set of ideas.
Raft on the other hand is a concrete protocol with well-defined, specified behavior. In fact, Raft is essentially an implementation of MultiPaxos[1]. This is a very good thing! Paxos provides a framework for thinking about consensus, while Raft puts some of these ideas into a concrete specification which is easy to implement. And it is a good point that we should make the knowledge in the field of consensus available for a wider…
It’s been a a long road but I’m finally at a point where I can definitively sat that this advice is some of the best you can give anyone in or out of tech.
Writing about software I’m building, errors I run into, and situations I get into (and often stumble through) has been huge for my own development and my career (https://vadosware.io).
Doing this has led me to habitually bite off more than I can chew which seems to be the only way to really grow:
- A managed services provider for smaller clouds/infrastructure providers called NimbusWS (https://nimbusws.com), which came out of all my blogging about Hetzner and kubernetes.
- LoginWithHN.com from how often I write about cool stuff on HN that was built for HN
- A salary sharing site for Accountants (https://nomorepizzaparties.com), which came about due to trying and investigating Baserow and NocoDB.
Outside of tech there’s awesome collectives like MoonMusiq (https://moonmusiq.com/), a collaboration of musicians that I was made aware of via HN actually -- its obviously an outlet for people to do these two things, in that order. Make cool shit, share it.
As always[1], this paper compares MultiPaxos, not Paxos. Paxos is more like the conceptual underpinning to a family of protocols, one leaf of which arguably includes Raft itself. A summary and evolutionary timeline (up to 2018) of the various algorithms in the Paxos lineage is https://vadosware.io/post/paxosmon-gotta-concensus-them-all/
Raft looks good next to MultiPaxos, but MultiPaxos is hardly the state of the art in the mainline Paxos lineage. MultiPaxos was published in 2001, over a decade before Raft. EPaxos is more of a contemporary to Raft, and arguably more in the spirit of Paxos as originally conceived--truly distributed, leaderless consensus.
[1] Practically every paper discussing Raft, including the original Raft paper(s), aliases Paxos to MultiPaxos.
Depends on your goals, but I would say the default should be AGPLv3 without CLA, funded by donations and maybe sponsorship and other no-strings-attached sources, with the money going into a non-profit foundation, and the trademarks, domains and other assets owned by the foundation, and the copyrights owned by individual contributors.
https://vadosware.io/post/the-future-of-free-and-open-source-is-agpl/
I wonder how much their tuned ZFS config looked like this.
https://vadosware.io/post/everything-ive-seen-on-optimizing-postgres-on-zfs-on-linux/
For example making sure ZFS compression is on while Postgres compression is off. Also checksumming where ZFS takes care of it.
I'd also be curious to see results where the Write Ahead Log was located on separate drives.
A super deep and informative post as always Victor.
I'm still digesting it, also cross-referencing it with the ZFS section of your Hetzner drive failure write up of December 13th.
https://vadosware.io/post/handling-your-first-dead-hetzner-hard-drive/#zfs
An idea for a future post might be
"Our ZFS and Postgres setup for Nimbus WS: Hetzner, OVH and LeaseWeb"