# Disk space cosideration for elasticsearch in production

**URL:** https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825
**Category:** Elasticsearch
**Created:** [January 25, 2017, 9:57pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825 "2017-01-25T21:57:55Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![krishna\_chaitanya](https://avatars.discourse-cdn.com/v4/letter/k/b5a626/32.png) [@krishna\_chaitanya](https://discuss.elastic.co/u/krishna_chaitanya)
#### Post date: [January 25, 2017, 9:57pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/1 "2017-01-25T21:57:55Z")

</div>

I was going through 2 good posts to determine the size of ES servers in production. [Here](https://www.elastic.co/blog/elasticsearch-storage-the-true-story) and [here](https://www.elastic.co/blog/elasticsearch-storage-the-true-story-2.0)

Do we need to account for extra size (free) on disk ? So, if all of my indices occupy, say 3 TB (with replication) and I want to start 3 nodes with 1 TB size on each node? Will that work?

Or do I need to keep 50% space unused for any internal elasticsearch operations? i.e, 1.5 TB on each node?

---

<div class="post-metadata">

### 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: [January 25, 2017, 10:05pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/2 "2017-01-25T22:05:05Z")

</div>

As Elasticsearch writes to immutable segments during indexing, which then are merged, you will need some free disk space to account for this. Exactly how much will depend on the workload. You should also consider what would happen if you lost one node. In this case, assuming that you have a replication factor of 1, Elasticsearch will want to allocate the shards on the missing node to the other nodes in the cluster, which in your case could result in about 1.5TB of data per node. If there is not enough room, replica shards will remain unassigned, which may be perfectly acceptable for your use case.

---

<div class="post-metadata">

### Author: ![krishna\_chaitanya](https://avatars.discourse-cdn.com/v4/letter/k/b5a626/32.png) [@krishna\_chaitanya](https://discuss.elastic.co/u/krishna_chaitanya)
#### Post date: [January 25, 2017, 10:34pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/3 "2017-01-25T22:34:50Z")

</div>

So, if I have 3 X 1.5 TB nodes, which have 500GB free disk space for these merge operations and one node failure considerations.

If 1 node goes down in above cluster, 1 TB of index data needs to be distributed to 2 other nodes to ensure replication (1 replica). So, the free 500GB on each of these nodes is filled up, and they dont have sufficient space of merge operations until a new node is added. Am I right ?

So, it is better to keep, say 50% of free disk space, in this case? This makes each node 2 TB.  
My load is something close to 10 GB/day (without replication)

---

<div class="post-metadata">

### 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: [January 26, 2017, 5:35am UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/4 "2017-01-26T05:35:06Z")

</div>

Having more disk space will also gives you room to grow, but regarding the relocation of shards on node failure it comes down to how long you need to handle a node being down and whether it is acceptable or not to not have all replica shards assigned during this time.

---

<div class="post-metadata">

### Author: ![krishna\_chaitanya](https://avatars.discourse-cdn.com/v4/letter/k/b5a626/32.png) [@krishna\_chaitanya](https://discuss.elastic.co/u/krishna_chaitanya)
#### Post date: [January 26, 2017, 3:28pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/5 "2017-01-26T15:28:22Z")

</div>

Thanks for the info. I looked into documentation and found [this](https://www.elastic.co/guide/en/elasticsearch/guide/current/_delaying_shard_allocation.html). Much helpful.

---

<div class="post-metadata">

### Author: ![krishna\_chaitanya](https://avatars.discourse-cdn.com/v4/letter/k/b5a626/32.png) [@krishna\_chaitanya](https://discuss.elastic.co/u/krishna_chaitanya)
#### Post date: [January 26, 2017, 7:26pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/6 "2017-01-26T19:26:47Z")

</div>

I have one more question, and this is about how master election is done if I have 3 nodes(2master+data and 1 dedicated master).

I have gone through [this](https://discuss.elastic.co/t/hardware-recommendation/66833/12) post, where you have given some details about using such configuration(3 nodes startup) for small clusters. With 10GB/day and holding 3 TB of index data, I believe my cluster is also a small one. I have also gone through master-election documentation [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html).

Since I don't want my data nodes to be doing extra work, I would like to have my only dedicated master node to be the actual master. How can I make sure that happens during Master-Election? Or is this the default behavior?

---

<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: [February 23, 2017, 7:27pm UTC](https://discuss.elastic.co/t/disk-space-cosideration-for-elasticsearch-in-production/72825/7 "2017-02-23T19:27:22Z")

</div>

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