Make "one node per server" the Ansible-Elasticsearch default

[hatdropper1977]

The current Docker Ansible playbook is not in the spirit of "convention over configuration." By default, it assumes the obscure and infrequent "multiple nodes per server" use case. This use case changes default config directories as well as the service name (Centos).

This is highly confusing to System Admins who are making the change from a manual (or container based) install to an Ansible playbook install.

Furthermore, the Elasticsearch documentation states that a multiple node per server configuration leads to "logistical complexity."

I propose Elastic makes the default "one node per server," maintaining the expected defaults and service names. In such a case, the playbook would require configuration for the "multiple nodes per server" use case.

I copied the following text from @jogaco https://github.com/jogaco/ansible-elasticsearch:

elastic.co recommends to run ES on machines with 64, 32 OR 16 GB of RAM, and to avoid large machines with multiple nodes:

At the same time, avoid the truly enormous machines. They often lead to imbalanced resource usage (for example, all the memory is being used, but none of the CPU) and can add logistical complexity if you have to run multiple nodes per machine. https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html

The original implementation of Ansible Role is geared towards machines running multiple nodes of ES, and adds a lot of unnecessary complexity to the daily admin of such deployments:

Installed Service name: node1_elasticsearch

• Data dir: /opt/elasticsearch/data/138.68.xx.xxx-node1
• Logs dir: /opt/elasticsearch/logs/138.68.xx.xxx-node1
• Work dir: /opt/elasticsearch/temp/138.68.xx.xxx-node1

You can check here more details: https://github.com/elastic/ansible-elasticsearch/issues/205

[gingerwizard]

@hatdropper1977 we have many users who install multiple ES instances on a single server. Given we don't recommend greater than 31GB heap, this can be the limiting factor for single ES instances with respect to how much data they can hold. Users with larger machines (common for cost effectiveness) are therefore presented with a few options:

1. Under utilise resources
2. Containerisation/Virtualisation to divide resources - this is actually the approach we use for cloud, but we have to appreciate our users are not "ideal" and have a wide variety of constraints imposed on them.

I am potentially +1 on removing the logic for directory renaming in cases where a single node is installed. The issue is its hard to determine if a single instance is being deployed or not.

[tsouza]

@gingerwizard Auto detecting might not be the easiest, but maybe a configuration flag could do it?

[hatdropper1977]

@tsouza and @gingerwizard (great name btw) a single flag would be excellent.

[gingerwizard]

This https://github.com/elastic/ansible-elasticsearch/pull/301 will likely get merged which should solve this. I think we'll cut a release before hand, however, as its quite significant and is going to break the tests. I'd also like the automated test infrastructure in place before we merge it, but this feature is coming.

[hatdropper1977]

What is the staus of the fix?

[jmlrt]

Hello @hatdropper1977, Sorry for the late answer. This should be fixed by https://github.com/elastic/ansible-elasticsearch/pull/566 very soon.

[hatdropper1977]

Excellent!

[jmlrt]

https://github.com/elastic/ansible-elasticsearch/pull/566 is merged. I'm closing the issue, don't hesitate to reopen it if you have any question.