1. Кластерная среда и описание проблемы
Версия кластера: 6.8.X
Узлы кластера: 5 узлов (три узла — главные + узлы данных, а два других — независимые узлы данных).
Описание проблемы: Из-за конфликтов IP был изменен IP одного сервера, а затем изменена конфигурация пяти серверов и перезапущены.Они могли быть запущены, но не могли подключиться, и сообщалось о различных ошибках в фон.
2. Обсуждение
Обсуждение причины смены IP узла: IP-адрес хост-сервера конфликтует с IP-адресом других серверов, поэтому необходимо изменить IP-адрес одного сервера.
Не рекомендуется часто менять IP узлов кластера по следующим причинам:
Частая замена IP-адресов узлов кластера Elasticsearch может привести к снижению стабильности кластера, трудностям в обнаружении узлов, сложному управлению конфигурацией, проблемам репликации и восстановления данных, проблемам конфигурации балансировки нагрузки и потенциальным рискам безопасности. Поэтому для поддержания стабильности и безопасности кластера мы обычно не рекомендуем часто менять IP-адреса узлов.
Есть еще одна проблема, которую следует учитывать: если размер кластера больше и количество узлов больше, время недоступности сервиса, вызванное сменой IP, будет больше.
Так как это версия кластера 6.8.X, необходимо изменить на каждом узле: discovery.zen.ping.unicast.hosts, что означает перезапуск всех кластеров. Следовательно, чем больше узлов, тем дольше будет время восстановления раздачи после перезапуска и тем дольше сервис будет недоступен. Особенно онлайн-бизнес с интенсивным доступом должен быть очень осторожным.
Вышеизложенное является основной предпосылкой познания.
3. Устранение неполадок
Однако вышеупомянутая замена IP-адреса узла стала неизбежным.Следующим шагом является поиск способа изменения IP-адреса и изменения конфигурации каждого узла, а затем поиск способа запуска кластера.
Здесь сначала доработайте идеи по устранению неполадок, чтобы максимально минимизировать проблему. В противном случае логи пяти узлов будут «пестрить».
Идеи расследования, которые я завершил прошлой ночью, следующие:
Начиная с трех основных + узлов данных node1, node2 и node3, почему они не могут сформировать кластер?
Другими словами, узлы данных не присоединяются к кластеру первыми, только узел 1, узел 2 и узел 3 являются тремя узлами, чтобы проверить, могут ли они быть сформированы в кластер и выборы мастера прошли успешно?
Основная идея: найти и определить причину, по которой текущий узел не может сформировать кластер?
Процесс основного исследования записывается и распределяется следующим образом:
3.1 Запускайте узлы один за другим и не отпускайте хитрые логи.
Обнаружена вчерашняя проблема с ошибкой конфигурации ip.
[2023-07-15T23:46:02,908][WARN ][o.e.d.z.UnicastZenPing ] [node-1] failed to resolve host [10.14.2·30.41:9300]
java.net.UnknownHostException: 10.14.2¡¤30.
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[?:1.8.0_291]
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929) ~[?:1.8.0_291]
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName0(InetAddress.java:1277) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName(InetAddress.java:1193) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName(InetAddress.java:1127) ~[?:1.8.0_291]Это неправильная операция по изменению IP-адреса, и его необходимо изменить, иначе будет много сообщений об ошибках. IP-адрес неправильный, поэтому нет возможности поговорить об этом позже.
3.2 Когда вспомогательные инструменты, такие как головной плагин, недоступны, используйте командную строку, чтобы проверить, присоединяется ли узел к кластеру.
Основная предпосылка: только после успешной сборки кластера можно использовать головной плагин; только когда кластер находится в некрасном состоянии (желтом или предпочтительно зеленом), кибана может получить к нему правильный доступ.
Однако наши узлы не могут создавать успешные кластеры, поэтому для устранения неполадок нельзя использовать такие инструменты, как подключаемые модули kibana и head. Однако некоторые оригинальные методы командной строки все же можно использовать.
Суть в том, чтобы проверить, образуют ли узлы кластер, с помощью следующей команды.
GET http://IP:端口/_cat/nodesПроверьте через инструмент postman, как показано ниже, возникает исключение «master_not_discovered_exception», то есть мастер-узел не может быть найден.
Сравните и посмотрите на правильную ситуацию.Следующее состоит в том, что два узла сформировали кластер.Значения mdi: главный узел, узел данных и тип принимающего узла.
Младшая версия называется типом узла, а версия 8.X называется ролью узла.
Вот еще одна деталь, если uuid кластера "_na_", это всего лишь означает, что он запущен, но мастер еще не выбран!
Если мастер выбран успешно, это должно примерно выглядеть следующим образом (uuid всех узлов согласованы, что очень важно).
3.3 В среднем звене было много аномалий, и я чуть не сбился с пути.
В следующем журнале я всегда думал, что это проблема с сетью.
Проверил брандмауэр, и команды ping проверяются одна за другой без проблем.
org.elasticsearch.transport.ConnectTransportException: [node-1][10.14.XXX.XX:9300] handshake_timeout[30s]
at org.elasticsearch.transport.TransportHandshaker.lambda$sendHandshake$1(TransportHandshaker.java:77) ~[elasticsearch-6.8.12.jar:6.8.12]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:681) [elasticsearch-6.8.12.jar:6.8.12]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_291]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_291]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291]
[2023-07-16T00:58:53,697][WARN ][o.e.t.TcpTransport ] [node-2] exception caught on transport layer [Netty4TcpChannel{localAddress=/10.14.XXX.yy:60218, remoteAddress=/10.14.xxx.zz:9300}], closing connection
java.io.IOException: 远程主机强迫关闭了一个现有的连接。
at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) ~[?:?]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:?]
at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[?:?]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378) ~[?:?]
at io.netty.buffer.PooledHeapByteBuf.setBytes(PooledHeapByteBuf.java:261) ~[netty-buffer-4.1.32.Final.jar:4.1.32.Final]
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132) ~[netty-buffer-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:347) ~[netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:656) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:556) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:510) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909) [netty-common-4.1.32.Final.jar:4.1.32.Final]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291]Позже я думаю, что узел отключен из-за нехватки памяти! Это должна быть цепная реакция другого узла после того, как один из двух узлов отключится.
В течение периода также было обнаружено несоответствие даты каждого узла, и выравнивание согласованности времени выполнялось путем ручного выравнивания времени.
Также измените значение discovery.zen.ping_timeout с 3 до 100 с.
discovery.zen.ping_timeout — это параметр в настройках кластера Elasticsearch, который определяет, как долго узел должен ждать ответа ping, прежде чем считать другие узлы «недоступными». Этот параметр очень важен для связи между узлами кластера и стабильности кластера. Если вы установите для discovery.zen.ping_timeout значение 3 секунды (3 с), это означает, что каждый узел будет ждать 3 секунды ответа от другого узла, прежде чем считать его отключенным. Плохие сетевые условия или сильно загруженный кластер Elasticsearch могут вызывать тайм-ауты, заставляя узлы ошибочно думать, что другие узлы отключены. Это может привести к ненужным перевыборам и повторной балансировке узлов, что повлияет на производительность и стабильность кластера.
3.4 Я пытался этого избежать, но это основная причина.
После неоднократных расследований было обнаружено, что основной причиной был следующий журнал, и память переполнилась.
[2023-07-16T00:52:39,878][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][153] overhead, spent [985ms] collecting in the last [1s]
[2023-07-16T00:52:44,238][INFO ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][154] overhead, spent [1.6s] collecting in the last [4.3s]
[2023-07-16T00:52:44,253][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-2] fatal error in thread [elasticsearch[node-2][generic][T#1]], exiting
java.lang.OutOfMemoryError: Java heap space
at org.apache.lucene.util.fst.FST.<init>(FST.java:342) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.util.fst.FST.<init>(FST.java:274) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.codecs.blocktree.FieldReader.<init>(FieldReader.java:91) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.codecs.blocktree.BlockTreeTermsReader.<init>(BlockTreeTermsReader.java:202) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
2023-07-16T00:51:59,263][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][124] overhead, spent [875ms] collecting in the last [1.1s]
[2023-07-16T00:52:00,826][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][125] overhead, spent [1s] collecting in the last [1.5s]
[2023-07-16T00:52:01,920][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][126] overhead, spent [938ms] collecting in the last [1s]
[2023-07-16T00:52:03,811][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][127] overhead, spent [1.1s] collecting in the last [1.8s]
[2023-07-16T00:52:06,639][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][129] overhead, spent [1s] collecting in the last [1.8s]
[2023-07-16T00:52:08,264][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][130] overhead, spent [1.2s] collecting in the last [1.6s]
[2023-07-16T00:52:09,468][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][131] overhead, spent [1s] collecting in the last [1.1s]Что вызывает это? Установка кучи памяти необоснованна.
Но jvm.options, очевидно, был изменен, и все они являются официальными рекомендуемыми значениями.
Однако при проверке логов я увидел следующие логи.
[node-2] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75В методе запуска службы я изменил jvm.options на 128 ГБ, но он по-прежнему показывает 1 ГБ, что является корнем проблемы.
256 ГБ оперативной памяти практически не используются.
Позже, после изменения метода запуска elasticsearch.bat, это будет сделано.
Далее: при запуске службы Windows конфигурация кластера jvm.options не читала вышеуказанные проблемы с памятью и различные отчеты об ошибках!
Наконец, кластер запускается нормально, и состояние работоспособности кластера становится зеленым.
4. Резюме
Для подобных проблем нет более быстрой стратегии, и мы можем устранять неполадки только узел за узлом и журнал за журналом. Совокупное исследование вышеуказанных проблем заняло более 6 часов, и только небольшое расследование может найти проблему.
Добро пожаловать, чтобы оставить сообщение для обсуждения и обмена подобными вопросами.
рекомендуемое чтение
Приобретайте больше галантерейных товаров быстрее за более короткое время!
Совершенствуйтесь с более чем 2000 энтузиастов Elastic по всему миру!
В эпоху больших моделей изучайте передовые галантереи на шаг впереди!