URL для доступа к кластерной среде для ElasticSearch2.4.3

Question

У нас есть кластерная среда ElasticSearch2.4.3 из двух узлов. Я хочу спросить, какой URL-адрес я должен предоставить для доступа к среде, чтобы она работала в режиме высокой доступности?

У нас есть два главных узла Node1 и Node2. Имя хоста для Node1 - node1.elastic.com, а Node2 - node2.elastic.com. Оба узла являются ведущими согласно формуле (n/2 +1).

Мы включили настройку кластера, изменив файл elastic.yml, добавив discovery.zen.ping.unicast.hosts для двух узлов.

Из нашего java-приложения мы подключаемся к node1.elastic.com. Он отлично работает, пока оба узла не подняты. Данные заполняются на обоих серверах ES, и все в порядке. Но как только Node1 выходит из строя, весь эластичный поисковый кластер отключается. И он автоматически не переключается на Node2 для обработки запросов.

Мне кажется, что URL-адрес, который я даю, неправильный, и это должно быть что-то еще, чтобы обеспечить автоматическое переключение.

Журналы с узла 1[2020-02-10 12:15:45,639][INFO ][node ] [Wildpride] initialized [2020-02-10 12:15:45,639][INFO ][node ] [Wildpride] starting ... [2020-02-10 12:15:45,769][WARN ][common.network ] [Wildpride] _non_loopback_ is deprecated as it picks an arbitrary interface. specify explicit scope(s), interface(s), address(es), or hostname(s) instead [2020-02-10 12:15:45,783][WARN ][common.network ] [Wildpride] _non_loopback_ is deprecated as it picks an arbitrary interface. specify explicit scope(s), interface(s), address(es), or hostname(s) instead [2020-02-10 12:15:45,784][INFO ][transport ] [Wildpride] publish_address {000.00.00.204:9300}, bound_addresses {[fe80::9af2:b3ff:fee9:90ca]:9300}, {000.00.00.204:9300} [2020-02-10 12:15:45,788][INFO ][discovery ] [Wildpride] XXXX/Hg_5eGZIS0e249KUTQqPPg [2020-02-10 12:16:15,790][WARN ][discovery ] [Wildpride] waited for 30s and no initial state was set by the discovery [2020-02-10 12:16:15,799][WARN ][common.network ] [Wildpride] _non_loopback_ is deprecated as it picks an arbitrary interface. specify explicit scope(s), interface(s), address(es), or hostname(s) instead [2020-02-10 12:16:15,802][WARN ][common.network ] [Wildpride] _non_loopback_ is deprecated as it picks an arbitrary interface. specify explicit scope(s), interface(s), address(es), or hostname(s) instead [2020-02-10 12:16:15,803][INFO ][http ] [Wildpride] publish_address {000.00.00.204:9200}, bound_addresses {[fe80::9af2:b3ff:fee9:90ca]:9200}, {000.00.00.204:9200} [2020-02-10 12:16:15,803][INFO ][node ] [Wildpride] started [2020-02-10 12:16:35,552][INFO ][node ] [Wildpride] stopping ... [2020-02-10 12:16:35,619][WARN ][discovery.zen.ping.unicast] [Wildpride] [17] failed send ping to {#zen_unicast_1#}{000.00.00.206}{000.00.00.206:9300} java.lang.IllegalStateException: can't add nodes to a stopped transport at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:916) at org.elasticsearch.transport.netty.NettyTransport.connectToNodeLight(NettyTransport.java:906) at org.elasticsearch.transport.TransportService.connectToNodeLight(TransportService.java:267) at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing$3.run(UnicastZenPing.java:395) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) [2020-02-10 12:16:35,620][WARN ][discovery.zen.ping.unicast] [Wildpride] failed to send ping to [{Wildpride}{Hg_5eGZIS0e249KUTQqPPg}{000.00.00.204}{000.00.00.204:9300}] SendRequestTransportException[[Wildpride][000.00.00.204:9300][internal:discovery/zen/unicast]]; nested: TransportException[TransportService is closed stopped can't send request]; at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:340) at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing.sendPingRequestToNode(UnicastZenPing.java:440) at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing.sendPings(UnicastZenPing.java:426) at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing$2.doRun(UnicastZenPing.java:249) at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: TransportException[TransportService is closed stopped can't send request] at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:320) ... 7 more [2020-02-10 12:16:35,623][INFO ][node ] [Wildpride] stopped [2020-02-10 12:16:35,623][INFO ][node ] [Wildpride] closing ... [2020-02-10 12:16:35,642][INFO ][node ] [Wildpride] closed

Answer 1

TL;DR: в elasticsearch нет автоматического переключателя, и вам понадобится какой-то балансировщик нагрузки перед кластером elasticsearch.

Для настройки высокой доступности вам потребуется как минимум 3 основных соответствующих узла. Перед кластером должен быть балансировщик нагрузки (также HA) для распределения запросов по кластеру. Или клиенту нужно каким-то образом знать о кластере и в случае сбоя переключиться на любой оставшийся узел.

Если вы используете 2 главных узла, кластер может перейти в состояние "разделенного мозга". Если ваша сеть каким-то образом фрагментируется и узлы становятся невидимыми друг для друга, оба они будут думать, что это последний работающий, и будут продолжать обслуживать запросы чтения / записи независимо. Таким образом, они отдаляются друг от друга, и исправить это станет практически невозможно - по крайней мере, когда фрагментация исчезнет, ​​придется исправить много проблем. С 3 узлами в сценарии фрагментации кластер будет продолжать обслуживать запросы только в том случае, если есть по крайней мере 2 узла, видимые друг другу.