# Any reason not to use ALL data nodes as coordinator nodes for queries/indexing? **URL:** \ **Category:** Elasticsearch\ **Created:** [September 28, 2023, 3:03pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077 "2023-09-28T15:03:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Mike\_Snare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_snare/32/1569_2.png) [@Mike\_Snare](https://discuss.elastic.co/u/Mike_Snare)\ **Post date:** [September 28, 2023, 3:03pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/1 "2023-09-28T15:03:19Z")
We have 37 data nodes but our clients only use 6 of them to send requests to. Is there any reason why the entire set of nodes couldn't be used by the clients? I know that some clusters use dedicated coordinator nodes, but I don't see a justification for that in our system given the sheer number of nodes we have since each can serve as a coordinator AND our generally low CPU usage. Is there any reason we couldn't just say that any one of the 37 nodes is a valid coordinator node to use for indexing/querying? By using all data nodes as coordinator nodes, I see it as reducing the coordination load by 83% on each of the 6 nodes that do it now, while adding just a marginal overhead to each of the remaining nodes (if these 6 nodes can do it and still handle their data responsibilities, then the others should be able to handle 1/6 of what the current coordinators are doing). It also seems like it's more resilient. Right now if one of the 6 goes down we've lost 16.6% of our coordination ability, vs 2.7% if one of the 37 goes down. Seems like a no brainer, which means I must be missing something. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [September 28, 2023, 4:00pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/2 "2023-09-28T16:00:44Z")
Hi @Mike_Snare The devil could be in the details ... 🙂 But no, from the top level, I don't think you are missing anything, assuming some homogeneity. Many customers put a load balancer in front of the data nodes to distribute the load across the node pool, just as you describe. We see what you describe when a user starts with "6" nodes and then grows but never re-addresses I do not see an obvious flaw with your thinking at this point. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [September 28, 2023, 4:03pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/3 "2023-09-28T16:03:17Z")
If you have dedicated master nodes, you generally want to leave these out and not send requests to them. If you have a tiered architecture, e.g. hot-warm-cold, it may also make sense to direct requests only to certain nodes. If the cluster however is homogenous it is generally better to distribute the load as evenly as possible. ---
**Author:** ![Dhineshkumar\_R](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dhineshkumar_r/32/122038_2.png) [@Dhineshkumar\_R](https://discuss.elastic.co/u/Dhineshkumar_R)\ **Post date:** [September 28, 2023, 4:11pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/4 "2023-09-28T16:11:38Z")
@Mike_Snare Do you mind sharing the way you found out that only 6 data nodes are used as coordinator nodes? ---
**Author:** ![Mike\_Snare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_snare/32/1569_2.png) [@Mike\_Snare](https://discuss.elastic.co/u/Mike_Snare)\ **Post date:** [September 28, 2023, 4:40pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/5 "2023-09-28T16:40:22Z")
The cluster is homogeneous for now, so any data node can coordinate as well as any other. ---
**Author:** ![Mike\_Snare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_snare/32/1569_2.png) [@Mike\_Snare](https://discuss.elastic.co/u/Mike_Snare)\ **Post date:** [September 28, 2023, 4:40pm UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/6 "2023-09-28T16:40:45Z")
Just a matter of looking at our clients and how they specify the nodes to connect to. ---
**Author:** ![Dhineshkumar\_R](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dhineshkumar_r/32/122038_2.png) [@Dhineshkumar\_R](https://discuss.elastic.co/u/Dhineshkumar_R)\ **Post date:** [October 1, 2023, 12:35am UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/7 "2023-10-01T00:35:40Z")
I see. Does your clients know the nodes where their data resides for a search request? Do they send search request with node\_ids set in [preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/search-search.html#search-preference) field? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 29, 2023, 12:36am UTC](https://discuss.elastic.co/t/any-reason-not-to-use-all-data-nodes-as-coordinator-nodes-for-queries-indexing/344077/8 "2023-10-29T00:36:07Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.