-
Notifications
You must be signed in to change notification settings - Fork 515
Open
Description
I’m currently running ClickHouse with the Altinity ClickHouse-Operator on Kubernetes, hosted on Hetzner Cloud.
Right now each ClickHouse pod uses a network volume (Hetzner Cloud Volume) via a standard StorageClass, but I’ve noticed that disk I/O is by far the biggest bottleneck in my setup.
I’m considering switching to node-local NVMe storage instead, using a StorageClass of type local that binds a PersistentVolume directly to the node’s SSD (since hetzner does not support any high performant volumes)
My plan is to:
- Add 6 dedicated AX-series servers (each with fast local SSDs 2-4tb).
- Schedule one ClickHouse pod per node, each pod having its own PVC that maps to the local disk on that node (not a network-attached volume).
- Use ClickHouse replication between pods/shards for durability.
Before I start, I’d like to understand:
- Does the ClickHouse-Operator fully support local storage classes?
(i.e., PVCs backed by node-local PersistentVolumes with node affinity) - If a node with local storage is destroyed and replaced, can ClickHouse replication automatically recover the data on the new node — or would I need to manually resync data / recreate replicas?
- Are there any best practices or known limitations for running the operator with local storage instead of network volumes?
Any guidance or examples would be really appreciated. Especially around handling node replacement and ensuring data safety when using local disks.
Metadata
Metadata
Assignees
Labels
No labels