quickwit-oss
Make control-plane deployment optional
Hi, I'm using Quickwit in a distributed setup, using a S3 file-based metastore.
Server 1 has the following components:
- control plane
- indexer
- metastore
Server 2 is using the helm chart to add the searcher UI with those components:
- searchers
- metastore
- janitor
Since the values.yaml in cludes this part
control_plane:
replicaCount: 1
I assumed if it is possible to disable the control-plane completely in such a distributed setup. The docs also say that the control-plane is only about indexing tasks. Now the replicaCount value doesn't seem to have any effect, it isn't used in the control-plane deployment file. It's using a hard-coded replicas: 1.
Would it make sense to have a deployment with only metastore, janitor and searchers and without control-plane?
Would it even make sense to have multiple control planes or would a simple enable: true/false suffice?
Hi @ChrisGitter,
The control plane is in charge of spinning and monitoring indexing tasks (pipelines) on indexers. Without this component, no indexing happens in a cluster. Consequently, the control plane is a mandatory service of a Quickwit deployment. We should clarify that in the documentation and make the Helm chart less ambiguous by removing the replicaCount option.
Secondly, if you are using a file-backed metastore, there should be only one metastore service in the cluster.
Finally, the janitor can potentially perform some CPU-heavy tasks (deletions), which can affect the performance of your searchers, so I would not collocate janitors and searchers.
Here's how I would deploy Quickwit with two nodes and three nodes with a file-backed metastore:
Two-node setup Node 1:
- control-plane
- indexer
- janitor
Node 2:
- metastore
- searcher
Three-node setup Node 1:
- control-plane
- janitor
Node 2:
- indexer
Node 3:
- metastore
- searcher
@guilload thanks for the example. I think I should have used a better terminology. I have two (almost) completely isolated Quickwit clusters. Cluster 1 is only indexing the data from the logs on that server, there is no janitor and no searcher. Cluster 2 is only providing the searchers, I also added the Janitor there, because performance on the node is not a critical as in cluster 1.
why not starting the control plane service on one indexer only? that would imply having a custom helm chart though.
@guilload thanks for the example. I think I should have used a better terminology. I have two (almost) completely isolated Quickwit clusters. Cluster 1 is only indexing the data from the logs on that server, there is no janitor and no searcher. Cluster 2 is only providing the searchers, I also added the Janitor there, because performance on the node is not a critical as in cluster 1.
Ok, I see. So basically, you want a write cluster and a read cluster. The file-backed metastore does not support multiple concurrent writers so you'll have to place the janitor in the write cluster too:
Write cluster:
- control-plane (at most one replica)
- indexer (any number of replicas)
- janitor (at most one replica)
- metastore (at most one replica)
Read cluster:
- searcher (any number of replicas)
- metastore (at most one replica)
why not starting the control plane service on one indexer only? that would imply having a custom helm chart though.
I guess that answers my question if the control-plane was necessary for a cluster with only searchers. In my current setup the write-cluster is done with a manual docker deployment, only the read-cluster is using the helm chart.
@guilload thanks I updated the setup to match the one you provided.
I have a similar requirement: 2 clusters, one for read only, and the other as a full cluster. I'm using a shared RDS instance so both metastores are in sync.
I would like also to deactivate the control_plane on the read only (not used because it only works in joint with the indexer).
I will add a PR for this.
