Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Storage substrate requirements

What kaas demands of the shared volume: same-directory rename atomicity, fsync durability, and close-to-open consistency.

kaas has no replication — durability is exactly as good as the volume underneath it. That makes the storage substrate the most important operational decision in a deployment.

The three-property contract

Multi-broker kaas requires a ReadWriteMany volume with NFSv4-class semantics. Each property is load-bearing in a specific place:

  1. Same-directory rename atomicity — every metadata file (manifest.json, assignment.json, txn slot files, credentials) is written tmp + fsync + rename; a crash mid-write must leave either the old or the new file, never a torn one.
  2. Fsync durability — the group-commit sync_all() is the acks=all promise (storage hot path).
  3. Close-to-open consistency — a file written and closed on one broker must read back complete on the next broker that opens it; transaction coordinator failover is literally "open the slot file" (transactions).

Single-writer enforcement does not come from the filesystem — no flock() needed. It comes from coordinator ownership plus epoch-prefixed segment filenames.

Provider matrix

StorageClassStatusNotes
CephFS (Rook / ceph-csi)productionstrong same-directory rename atomicity
csi-driver-nfs / NFSv4.1 serverproductionsee mount options below
AWS EFS / Azure Files Premium NFS / GCP FilestoreproductionNFSv4-class semantics
Longhorn / OpenEBS RWXproductionblock-backed RWX
local-path / hostPathsingle-broker dev onlynot RWX; requires broker.replicaCount: 1 and storage.accessMode: ReadWriteOnce

The single-broker RWO shape is a real configuration, not a hack — the chart accepts it, and it sidesteps NFS entirely for edge/dev deployments.

NFS mount options that matter

Set on the StorageClass (mountOptions), not the PVC:

mountOptions:
  - nfsvers=4.1
  - nconnect=8    # parallel TCP connections; faster concurrent fsyncs
  - acregmax=1    # sub-second attribute-cache expiry
  - hard          # block on server unavailability instead of EIO

acregmax=1 matters most: brokers poll assignment.json's mtime as the failover signal, and NFS's default 60 s attribute cache would delay every controller failover by up to a minute. nconnect raises throughput when multiple brokers fsync concurrently.

One reclaim-policy caution: keep the data PV on reclaimPolicy: Retain (or the chart's kept PVC) — with Delete and a templated NFS subdirectory, a PVC recreate can race the old PV's deletion into removing the new volume's directory.

The durability dial

KAAS_FLUSH_INTERVAL_MESSAGES (chart value broker.flushIntervalMessages) defaults to 1: every batch waits for its group-commit fsync — honest acks=all against the substrate. Raising it (e.g. 10000) approximates Apache's default posture, where acks=all acknowledges replicated page-cache writes and log.flush.interval.messages is effectively unbounded — comparable durability semantics to a single Apache broker, and the setting used in the recorded benchmarks (performance). NFS COMMIT latency dominates either way; this dial decides how often you pay it.