Well, then maybe my questions were not precise enough. My first goal was to make sure ES does work sharing a unique storage for all nodes. My second gaol was to learn if each node requires to have its dedicated file tree, or if you can put every files together as if there's only one ES node. Does-it make sense to have replicas when eventually filesystem IOs are shared? Does moving a shard from a node to another makes data passing through the CPU, or is ES smart enough to just pass the pointer to the file?
On 30 avr. 2014, at 18:33, Mohit Anchlia wrote: > I think anyone will find it difficult to answer such questions just because > there are several factors that derive the decision like latency requirements, > high availability requirements, how shared SAN storage is and impact of > somebody stealing IO under the hood etc. The best way is to develop a test > model and test it out. Look at cluster settings on how to disable/enable > shard allocation. > > On Wed, Apr 30, 2014 at 8:47 AM, Patrick Proniewski > <[email protected]> wrote: > Hello, > > I'm still testing ES at a very small scale (1 node on a multipurpose server), > but I would like to extend it's use at work as a backend for logstash. It > means that the LS+ES cluster would have to eat few GB of data every day, up > to 15 or 20GB later if things go well. > I'm doing all this as a side project: no investment apart from work hours. I > will recycle blades and storage we plan to decommission from our > virtualization farm. > So I'm likely to end with 2 or 3 dual-xeon blades, but no real internal > storage (an SD-card), and a LUN on a SAN. > > How does ES behave is shared storage condition? What are the best practices > about nodes/shards/replicas/...? > Intended audience is Operation team, so less than 10 persons. So no big > search concurrency but probably mostly "deep" search and ill-designed queries > :) > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/F6DDE665-B311-4964-A0BF-FFEF156E4FA3%40patpro.net. For more options, visit https://groups.google.com/d/optout.
