Elasticsearch 6 node sizing and configuration


(Nitish Goyal) #1

I am setting up a new elasticsearch 6 cluster. Our cluster is going to be write heavy cluster.
We ingest roughly 1 TB of data each day

Config of the machines is as follows :
Disk : 1.5TB * 2
Memory : 256 GB
Cores : 40

I have read in blogs that Elasticsearch works best with heap less than 32 GB

I am thinking of two options here :

  1. Divide each machine into 2 VMs
    Each VM(node) will have 128 GB RAM, 30 GB heap for ES, 20 cores and 1.5TB

  2. Let each machine be one node
    Each node will have 256 GB RAM, 30GB heap, 40 cores and 3.0TB disk space

Kindly suggest what config would be the best for my cluster? I need to set this cluster on this weekend.
Kindly suggest asap

Thanks,
Nitish Goyal


(Nitish Goyal) #2

@elastic Any help on the above?


(Jake Landis) #3

The general advice is prefer medium-to-large boxes [1] to avoid having to make these types of decisions to get the most of the hardware. There are lots of factors that go into optimal sizing, and if possible try a few configuration under production load and monitor to see which provides the best performance and usage of hardware.

In your case, my gut says option 1 will provide will provide slightly better performance especially if you can separate disks and pin CPU's to the VM's. You may also want to consider 3 nodes with that much memory. You may also want to consider using cgroups or docker instead of VM's to help limit the overhead of the separation.

Also when running multiple instances per host, and you are using replicas (the default) you will likely need to use allocation awareness [2] to ensure that primaries and replica's don't end up on the same physical host.

Also be sure to checkout [3] for index heavy optimizations.

[1] https://www.elastic.co/guide/en/elasticsearch/guide/2.x/hardware.html#_general_considerations
[2] https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html
[3] https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html


(Nitish Goyal) #4

Thanks a lot @jakelandis for the suggestions