# Tiering storage / Curator

**URL:** <https://discuss.elastic.co/t/tiering-storage-curator/18668>\
**Category:** Elasticsearch\
**Created:** [July 15, 2014, 5:20am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668 "2014-07-15T05:20:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Patrick\_Proniewski](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@Patrick\_Proniewski](https://discuss.elastic.co/u/Patrick_Proniewski)\
**Post date:** [July 15, 2014, 5:20am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/1 "2014-07-15T05:20:30Z")

</div>

Hello,

Curator makes is possible to migrate an index to another storage programmatically, and that's very nice to keep old indices on cheap storage. But if I understand correctly, a unique ES cluster cannot handle two different storages. Hence, having small but fast storage for recent files and cheap but slow storage for old files requires building two clusters.  
Am I right?

thanks,  
Patrick

--  
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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [July 15, 2014, 5:25am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/2 "2014-07-15T05:25:31Z")

</div>

Nope, you can use allocation awareness to have indexes on different  
machines -

> **[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.

Regards,  
Mark Walkom

Infrastructure Engineer  
Campaign Monitor  
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)

On 15 July 2014 15:20, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:

> Hello,
> 
> Curator makes is possible to migrate an index to another storage  
> programmatically, and that's very nice to keep old indices on cheap  
> storage. But if I understand correctly, a unique ES cluster cannot handle  
> two different storages. Hence, having small but fast storage for recent  
> files and cheap but slow storage for old files requires building two  
> clusters.  
> Am I right?
> 
> thanks,  
> Patrick
> 
> --  
> 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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net)  
> .  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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/CAEM624aBWn1RruyyhchVeE5kOF\_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624aBWn1RruyyhchVeE5kOF_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Patrick\_Proniewski](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@Patrick\_Proniewski](https://discuss.elastic.co/u/Patrick_Proniewski)\
**Post date:** [July 15, 2014, 7:05am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/3 "2014-07-15T07:05:42Z")

</div>

Ok, so if I understand correctly I can have a single cluster with:

- machine A: fast storage (recent data)
- machine B & C: slow storage (old data)

In that case, I cannot have a homogeneous cluster with both fast and slow storage on each node and I'm losing the benefit of having multiple machines when I index new data and when I search recent data. Is that correct?

Regards,  
Patrick

On 15 juil. 2014, at 07:25, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) wrote:

> Nope, you can use allocation awareness to have indexes on different  
> machines -  
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html)
> 
> Regards,  
> Mark Walkom
> 
> Infrastructure Engineer  
> Campaign Monitor  
> email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> 
> On 15 July 2014 15:20, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:
> 
> > Hello,
> > 
> > Curator makes is possible to migrate an index to another storage  
> > programmatically, and that's very nice to keep old indices on cheap  
> > storage. But if I understand correctly, a unique ES cluster cannot handle  
> > two different storages. Hence, having small but fast storage for recent  
> > files and cheap but slow storage for old files requires building two  
> > clusters.  
> > Am I right?
> > 
> > thanks,  
> > Patrick
> > 
> > --  
> > 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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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/CAEM624aBWn1RruyyhchVeE5kOF\_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624aBWn1RruyyhchVeE5kOF_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com).  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [July 15, 2014, 7:33am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/4 "2014-07-15T07:33:32Z")

</div>

You cannot have multiple data.paths on a single node/instances. You could  
try running multiple instances of ES on a single physical, each pointing to  
either one of your tiered pools.  
But you aren't losing the benefit of multiple nodes, just the optimal use  
of your storage on those physical nodes.

You could look at something like L2ARC or similar though.

Regards,  
Mark Walkom

Infrastructure Engineer  
Campaign Monitor  
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)

On 15 July 2014 17:05, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:

> Ok, so if I understand correctly I can have a single cluster with:
> 
> - machine A: fast storage (recent data)
> - machine B & C: slow storage (old data)
> 
> In that case, I cannot have a homogeneous cluster with both fast and slow  
> storage on each node and I'm losing the benefit of having multiple machines  
> when I index new data and when I search recent data. Is that correct?
> 
> Regards,  
> Patrick
> 
> On 15 juil. 2014, at 07:25, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) wrote:
> 
> > Nope, you can use allocation awareness to have indexes on different  
> > machines -
> 
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html)
> 
> > Regards,  
> > Mark Walkom
> > 
> > Infrastructure Engineer  
> > Campaign Monitor  
> > email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > 
> > On 15 July 2014 15:20, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net)  
> > wrote:
> > 
> > > Hello,
> > > 
> > > Curator makes is possible to migrate an index to another storage  
> > > programmatically, and that's very nice to keep old indices on cheap  
> > > storage. But if I understand correctly, a unique ES cluster cannot  
> > > handle  
> > > two different storages. Hence, having small but fast storage for recent  
> > > files and cheap but slow storage for old files requires building two  
> > > clusters.  
> > > Am I right?
> > > 
> > > thanks,  
> > > Patrick
> > > 
> > > --  
> > > 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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net)
> 
> > > .  
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > --  
> > 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/CAEM624aBWn1RruyyhchVeE5kOF\_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624aBWn1RruyyhchVeE5kOF_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net)  
> .  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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/CAEM624Z6rMHS%2Br-2eeGWTpWq\_bZ4iraEp0sE\_91w8vDcJVe02w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624Z6rMHS%2Br-2eeGWTpWq_bZ4iraEp0sE_91w8vDcJVe02w%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Patrick\_Proniewski](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@Patrick\_Proniewski](https://discuss.elastic.co/u/Patrick_Proniewski)\
**Post date:** [July 15, 2014, 8:35am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/5 "2014-07-15T08:35:35Z")

</div>

It seems I can have multiple path.data on a single node, but it does not allow for storage tiering:

# Can optionally include more than one location, causing data to be striped across

# the locations (a la RAID 0) on a file level, favouring locations with most free

# space on creation. For example:

# 

# path.data: /path/to/data1,/path/to/data2

ES seems to be quite close to beeing able to provide storage tiering... Maybe in 1.4? 😉

On 15 juil. 2014, at 09:33, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) wrote:

> You cannot have multiple data.paths on a single node/instances. You could try running multiple instances of ES on a single physical, each pointing to either one of your tiered pools.  
> But you aren't losing the benefit of multiple nodes, just the optimal use of your storage on those physical nodes.
> 
> You could look at something like L2ARC or similar though.
> 
> Regards,  
> Mark Walkom
> 
> Infrastructure Engineer  
> Campaign Monitor  
> email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> 
> On 15 July 2014 17:05, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:  
> Ok, so if I understand correctly I can have a single cluster with:
> 
> - machine A: fast storage (recent data)
> - machine B & C: slow storage (old data)
> 
> In that case, I cannot have a homogeneous cluster with both fast and slow storage on each node and I'm losing the benefit of having multiple machines when I index new data and when I search recent data. Is that correct?
> 
> Regards,  
> Patrick
> 
> On 15 juil. 2014, at 07:25, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) wrote:
> 
> > Nope, you can use allocation awareness to have indexes on different  
> > machines -  
> > [Elastic — The Search AI Company | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html)
> > 
> > Regards,  
> > Mark Walkom
> > 
> > Infrastructure Engineer  
> > Campaign Monitor  
> > email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > 
> > On 15 July 2014 15:20, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:
> > 
> > > Hello,
> > > 
> > > Curator makes is possible to migrate an index to another storage  
> > > programmatically, and that's very nice to keep old indices on cheap  
> > > storage. But if I understand correctly, a unique ES cluster cannot handle  
> > > two different storages. Hence, having small but fast storage for recent  
> > > files and cheap but slow storage for old files requires building two  
> > > clusters.  
> > > Am I right?
> > > 
> > > thanks,  
> > > Patrick
> > > 
> > > --  
> > > 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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net)  
> > > .  
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > --  
> > 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/CAEM624aBWn1RruyyhchVeE5kOF\_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624aBWn1RruyyhchVeE5kOF_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com).  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net).  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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/CAEM624Z6rMHS%2Br-2eeGWTpWq\_bZ4iraEp0sE\_91w8vDcJVe02w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624Z6rMHS%2Br-2eeGWTpWq_bZ4iraEp0sE_91w8vDcJVe02w%40mail.gmail.com).  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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/68787163-5E12-448B-9C0B-553DECF8D613%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/68787163-5E12-448B-9C0B-553DECF8D613%40patpro.net).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [July 15, 2014, 12:20pm UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/6 "2014-07-15T12:20:19Z")

</div>

There you go, I didn't know it did that!

Regards,  
Mark Walkom

Infrastructure Engineer  
Campaign Monitor  
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)

On 15 July 2014 18:35, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net) wrote:

> It seems I can have multiple path.data on a single node, but it does not  
> allow for storage tiering:
> 
> # Can optionally include more than one location, causing data to be
> 
> striped across
> 
> # the locations (a la RAID 0) on a file level, favouring locations with
> 
> most free
> 
> # space on creation. For example:
> 
> # 
> 
> # path.data: /path/to/data1,/path/to/data2
> 
> ES seems to be quite close to beeing able to provide storage tiering...  
> Maybe in 1.4? 😉
> 
> On 15 juil. 2014, at 09:33, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) wrote:
> 
> > You cannot have multiple data.paths on a single node/instances. You  
> > could try running multiple instances of ES on a single physical, each  
> > pointing to either one of your tiered pools.  
> > But you aren't losing the benefit of multiple nodes, just the optimal  
> > use of your storage on those physical nodes.
> > 
> > You could look at something like L2ARC or similar though.
> > 
> > Regards,  
> > Mark Walkom
> > 
> > Infrastructure Engineer  
> > Campaign Monitor  
> > email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > 
> > On 15 July 2014 17:05, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net)  
> > wrote:  
> > Ok, so if I understand correctly I can have a single cluster with:
> > 
> > - machine A: fast storage (recent data)
> > - machine B & C: slow storage (old data)
> > 
> > In that case, I cannot have a homogeneous cluster with both fast and  
> > slow storage on each node and I'm losing the benefit of having multiple  
> > machines when I index new data and when I search recent data. Is that  
> > correct?
> > 
> > Regards,  
> > Patrick
> > 
> > On 15 juil. 2014, at 07:25, Mark Walkom [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> > wrote:
> > 
> > > Nope, you can use allocation awareness to have indexes on different  
> > > machines -
> 
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html)
> 
> > > Regards,  
> > > Mark Walkom
> > > 
> > > Infrastructure Engineer  
> > > Campaign Monitor  
> > > email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)  
> > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > > 
> > > On 15 July 2014 15:20, Patrick Proniewski [elasticsearch@patpro.net](mailto:elasticsearch@patpro.net)  
> > > wrote:
> > > 
> > > > Hello,
> > > > 
> > > > Curator makes is possible to migrate an index to another storage  
> > > > programmatically, and that's very nice to keep old indices on cheap  
> > > > storage. But if I understand correctly, a unique ES cluster cannot  
> > > > handle  
> > > > two different storages. Hence, having small but fast storage for  
> > > > recent  
> > > > files and cheap but slow storage for old files requires building two  
> > > > clusters.  
> > > > Am I right?
> > > > 
> > > > thanks,  
> > > > Patrick
> > > > 
> > > > --  
> > > > 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/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/487D9125-FC9B-43F9-B714-9C4EA2556A47%40patpro.net)
> 
> > > > .  
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > > 
> > > --  
> > > 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/CAEM624aBWn1RruyyhchVeE5kOF\_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624aBWn1RruyyhchVeE5kOF_vFFusv2fejvjjqM3Y8PSpRw%40mail.gmail.com)  
> > > .  
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > --  
> > 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/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/185792EE-3E9D-4EB6-A0B1-1E4B4FBC6F81%40patpro.net)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > --  
> > 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/CAEM624Z6rMHS%2Br-2eeGWTpWq\_bZ4iraEp0sE\_91w8vDcJVe02w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624Z6rMHS%2Br-2eeGWTpWq_bZ4iraEp0sE_91w8vDcJVe02w%40mail.gmail.com)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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/68787163-5E12-448B-9C0B-553DECF8D613%40patpro.net](https://groups.google.com/d/msgid/elasticsearch/68787163-5E12-448B-9C0B-553DECF8D613%40patpro.net)  
> .  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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/CAEM624Zxw2HNNvDFYdqsCurVFrFs\_9%3DLOk1JM%2BkYkEzp23hTjw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624Zxw2HNNvDFYdqsCurVFrFs_9%3DLOk1JM%2BkYkEzp23hTjw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![otisg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/otisg/32/492_2.png) [@otisg](https://discuss.elastic.co/u/otisg)\
**Post date:** [July 19, 2014, 5:18am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/7 "2014-07-19T05:18:59Z")

</div>

Hi,

On Tuesday, July 15, 2014 1:20:39 AM UTC-4, Patrick Proniewski wrote:

> Hello,
> 
> Curator makes is possible to migrate an index to another storage  
> programmatically, and that's very nice to keep old indices on cheap  
> storage. But if I understand correctly, a unique ES cluster cannot handle  
> two different storages. Hence, having small but fast storage for recent  
> files and cheap but slow storage for old files requires building two  
> clusters.  
> Am I right?

Not necessarily. We used the tiered storage approach in Logsene  
[http://sematext.com/logsene/](http://sematext.com/logsene/), for example, but we explicitly move older  
indexes to from more expensive nodes that deal with fresh data to cheaper  
nodes that host all data. It's automated, but it's not 100% done within  
ES. But it's done with a single ES cluster.

## Otis

Performance Monitoring \* Log Analytics \* Search Analytics  
Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)

--  
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/0bbe88ad-4c60-4383-8ae9-13ab15d02676%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0bbe88ad-4c60-4383-8ae9-13ab15d02676%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<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:14am UTC](https://discuss.elastic.co/t/tiering-storage-curator/18668/8 "2017-07-06T01:14:46Z")

</div>


