# Load balance on heterogeneous nodes in a cluster

**URL:** <https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553>\
**Category:** Elasticsearch\
**Created:** [February 3, 2014, 7:44am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553 "2014-02-03T07:44:35Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![xzer\_LR](https://avatars.discourse-cdn.com/v4/letter/x/2acd7d/32.png) [@xzer\_LR](https://discuss.elastic.co/u/xzer_LR)\
**Post date:** [February 3, 2014, 7:44am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553/1 "2014-02-03T07:44:35Z")

</div>

I am now evaluating elasticsearch as our text search solution. But the  
problem is that we cannot guarantee that we can always allocate same  
hardware for our cluster when new nodes are added, therefor we need a  
solution to distribute the load in a smart way based on the machine power.

I read the document and source, I found there is a BalancedShardsAllocator  
for balancing the shards between nodes with consideration of shards count.  
But basically, the BalancedShardsAllocator still considers the nodes in the  
cluster as homogeneous.

It seems that we can implement our own ShardsAllocator to distribute shards  
by predefined machine factor(the simplest way maybe), I want to know  
whether there is something I missed or there is already some built-in  
function affording the ability we want?

And I also have the related second question, currently our search is not  
IO-bound because we have big-enough memory on all of our machines but there  
are different counts of cpu cores in every machine, I want the client  
search can be distributed to nodes based on the count of cpu cores rather  
than simple round-robin. Is there any way to do that?

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/35708394-19e7-4ab2-ab1a-f632039da26e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/35708394-19e7-4ab2-ab1a-f632039da26e%40googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [February 3, 2014, 9:26am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553/2 "2014-02-03T09:26:23Z")

</div>

Hi,

please have a look at shard allocation, where you can define, that specific  
indices should be put into your stronger or weaker boxes (or whatever  
criteria you define). This might be sufficient for a first try

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

If you need more sophisticated logic (based on CPU power or memory), you  
could write your own decider, but I think you can go a mile with shard  
allocation.

This also applies to your second question, where you could put the indices,  
which are searched a lot, on the more powerful machines to make sure that  
indexing and querying is as fast as possible.

Hope this helps...

--Alex

On Mon, Feb 3, 2014 at 8:44 AM, xzer LR [xiaozhu@gmail.com](mailto:xiaozhu@gmail.com) wrote:

> I am now evaluating elasticsearch as our text search solution. But the  
> problem is that we cannot guarantee that we can always allocate same  
> hardware for our cluster when new nodes are added, therefor we need a  
> solution to distribute the load in a smart way based on the machine power.
> 
> I read the document and source, I found there is a BalancedShardsAllocator  
> for balancing the shards between nodes with consideration of shards count.  
> But basically, the BalancedShardsAllocator still considers the nodes in the  
> cluster as homogeneous.
> 
> It seems that we can implement our own ShardsAllocator to distribute  
> shards by predefined machine factor(the simplest way maybe), I want to know  
> whether there is something I missed or there is already some built-in  
> function affording the ability we want?
> 
> And I also have the related second question, currently our search is not  
> IO-bound because we have big-enough memory on all of our machines but there  
> are different counts of cpu cores in every machine, I want the client  
> search can be distributed to nodes based on the count of cpu cores rather  
> than simple round-robin. Is there any way to do that?
> 
> --  
> You received this message because you are subscribed to the Google Groups  
> "elasticsearch" group.  
> To unsubscribe from this group and stop receiving emails from it, send an  
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/35708394-19e7-4ab2-ab1a-f632039da26e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/35708394-19e7-4ab2-ab1a-f632039da26e%40googlegroups.com)  
> .  
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAGCwEM8oNLh3jVwDuTBaVnzgx-nJThWuEYjaQVr%2B%3DUpwb%3DiUGg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM8oNLh3jVwDuTBaVnzgx-nJThWuEYjaQVr%2B%3DUpwb%3DiUGg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [February 3, 2014, 10:42am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553/3 "2014-02-03T10:42:16Z")

</div>

Right now, ES can control total number of shards on a node, but not a CPU  
strength factor. You have to write your own decider that is based on the  
criteria you gave.

Note, the mere count of CPU core may not be reliable for an allocation  
decider, because it does not determine the total shard processing capacity

- there can be very strong cores, or weak cores on different CPUs.

Even if you write a CPU strength based decider, the weakest node will still  
determine the overall performance in query and index operations. That is  
you can not compensate weak CPU power by an allocation decider.

Jörg

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoE2%3Dm%2Bg5Vhc%3DpskFyJsz9EVurx2x7-h2Pe3kozC44dPbA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoE2%3Dm%2Bg5Vhc%3DpskFyJsz9EVurx2x7-h2Pe3kozC44dPbA%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![xzer\_LR](https://avatars.discourse-cdn.com/v4/letter/x/2acd7d/32.png) [@xzer\_LR](https://discuss.elastic.co/u/xzer_LR)\
**Post date:** [February 7, 2014, 9:53am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553/4 "2014-02-07T09:53:22Z")

</div>

Thanks for the replies, we are now considering and discussing our balance  
policy, all the information is helpful.

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/d5c82e84-9680-4d11-8e8f-d7fa0a9fcb37%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/d5c82e84-9680-4d11-8e8f-d7fa0a9fcb37%40googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:51am UTC](https://discuss.elastic.co/t/load-balance-on-heterogeneous-nodes-in-a-cluster/15553/5 "2017-07-06T01:51:51Z")

</div>


