Make control-plane deployment optional

[cprass]

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?

[guilload]

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

[cprass]

@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.

[guilload]

Are you using a file-backed metastore or Postgres?

[cprass]

Currently the only option for me is a file-backed metastore.

[fmassot]

why not starting the control plane service on one indexer only? that would imply having a custom helm chart though.

[guilload]

@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)

[cprass]

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.