# ECE and Shard Size adjustments on Cluster Re-Size events

**URL:** <https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224>\
**Category:** Elastic Cloud Enterprise (ECE)\
**Created:** [March 20, 2019, 9:12pm UTC](https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224 "2019-03-20T21:12:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Randy-312](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/randy-312/32/19451_2.png) [@Randy-312](https://discuss.elastic.co/u/Randy-312)\
**Post date:** [March 20, 2019, 9:12pm UTC](https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224/1 "2019-03-20T21:12:16Z")

</div>

Has anyone addressed Auto-Scaling the Shards per index, currently via templates, when ECE expands the cluster's nodes ?

Today, we have 24 Data Nodes in our non-ECE based cluster.

- Via our Templates, we have set  
Per index, 11 Primary and 1 Replica shards per index, (so totaling 22) and  
The total\_shards\_per\_node set to 1 in the templates, _so that we don’t get a busy node w/ multiple shards on it._

This allows us to take 2 nodes offline (or to have hit the high/low water marks) without having an impact.

The ECE ‘challenge’ is to be able to increase the number of shards per index as we expand the nodes.

While we are considering how Shard Size limitations coming will help with this, we could still end up with a full node or more likely a Busy node when we have everything going to a single node.

---

<div class="post-metadata">

**Author:** ![Alex\_Piggott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_piggott/32/11053_2.png) [@Alex\_Piggott](https://discuss.elastic.co/u/Alex_Piggott)\
**Post date:** [March 20, 2019, 9:31pm UTC](https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224/2 "2019-03-20T21:31:22Z")

</div>

Interesting use case - ECE doesn't add any more (or less) support than ES currently

(the only possible benefit is being able to infer the expected number of nodes per availability zone from an ECE API call instead of from a slightly "messier" ES call for automation purposes, but it's obviously a marginal improvement. In a similar vein it makes it easier to listen for cluster change events to know that it's happened so you can take whatever steps are needed)

Alex

---

<div class="post-metadata">

**Author:** ![Randy-312](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/randy-312/32/19451_2.png) [@Randy-312](https://discuss.elastic.co/u/Randy-312)\
**Post date:** [March 20, 2019, 10:37pm UTC](https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224/3 "2019-03-20T22:37:32Z")

</div>

This is where having ES' base template (and inheritability) would come in.  
By having only critical settings related to the nodes at the root+1 level, we could update it and roll it out to the cluster on a resize event.

But, it does seem like the 'check', and then 'update' is something best devised by the vendor.  
An ILM feature for the Hot Nodes perhaps.

---

<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:** [April 3, 2019, 10:37pm UTC](https://discuss.elastic.co/t/ece-and-shard-size-adjustments-on-cluster-re-size-events/173224/4 "2019-04-03T22:37:33Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
