URL для доступа к кластерной среде для ElasticSearch2.4.3 - PullRequest
0 голосов
/ 10 февраля 2020

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

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

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

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

Я чувствую, что URL-адрес, который я даю, неверен, и он должен быть чем-то другим, чтобы обеспечить автоматический c переключатель.

Журналы с узла 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

1 Ответ

0 голосов
/ 10 февраля 2020

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

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

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

...