我应该在ElasticSearch集群中设置多少个机架

Question

My ES cluster has 20 machines with 50 nodes(ES instances), I'm not sure how many racks should I set. Is two racks enough? or 3 or 4 racks better.

As I know if I set rack_id in ES configuration, it can provide the following functions:

1, Select data location or relocation(to make sure replicas in different racks)
2, Use Rack_id as doc routing

Any reasons should I set more racks, but I think even just one rack by default is good too.

Answer 1

The chance of an outage of two machines is highest if they share hardware because you use VMs, smaller if they share a rack but not hardware, and again smaller if they share a building but not a rack. So it makes sense to use more than a single rack.

Whether you need more than 2 racks depends on your replicas. The default number of replications is 1. If you require a higher value, strictly speaking you will degrade the Availability of your cluster a bit if you use only 2 racks because the >= 3 setting will not be effective on the rack level.

Answer 2

I think that in your case, it's simpler and easier to just set cluster.routing.allocation.same_shard.host to true . (See https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html ) This will prevent copies of the same shard to be placed on the same host (host is identified by address and host name). Please, test this before going in production with this approach.

Also, keep in mind that you need to specify the processors setting ( http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-threadpool.html#processors ) accordingly. Each ES node detects the # of cores available on the machine (not aware of other nodes present). With multiple nodes on the same machine, each node can think that it has dedicated access to all cores on the machine (this can be problematic for the default thread pool sizes are derived from this). So you will want to explicitly specify the # of cores available via the processors setting so that it does not end up over-allocating the thread pools.

I recommend using dedicated master nodes and to ensure cluster stability, each dedicated master node instance should be on its own machine (certainly can be a much smaller machine, eg 4Gb of RAM to start with).