Разрывы кластера Jgroups при перезапуске отдельных элементов кластера

Question

Я испытываю проблему с нашим кластером jgroups, теряющим друг друга, когда несколько участников кластера перезапускаются. У нас есть 13 узлов в кластере, и все они находятся в одной подсети. При перезапуске 4 узлов весь кластер выходит из строя. Все участники перестают узнавать друг друга, и существующие участники, которые не были перезапущены, также не находят друг друга.

Мы начали получать сообщения SUSPECT и не смогли собрать все ACK

0;33mWARN [Входящий-1, широковещательная рассылка, узел-12] [GMS] узел-12: не удалось собрать все ACK (ожидается =11) для представления [узел-12|27] после 2000 мс, пропустив 11 ACK от узла-12, узел-4, узел-6, узел-13, узел-11, узел-2, узел-7, узел-8, узел-9, узел-0, узел-3

0;33mWARN [INT-2, широковещательная рассылка, узел-12] [FD] узел-12: я подозревался узлом-5; игнорирование сообщения SUSPECT и отправка HEARTBEAT_ACK

PFB конфигурация, которую мы используем, пожалуйста, дайте мне знать, если есть какие-либо проблемы с конфигурацией. Мы используем 3.4.1. Окончательная версия JGroups

<TCP loopback="true"
recv_buf_size="${tcp.recv_buf_size:20M}"
send_buf_size="${tcp.send_buf_size:640K}"
discard_incompatible_packets="true"
max_bundle_size="64K"
max_bundle_timeout=“5"
enable_bundling="true"
use_send_queues="true"
sock_conn_timeout="300"
timer_type="new"
timer.min_threads="4"
timer.max_threads="10"
timer.keep_alive_time="3000"
timer.queue_max_size="500"
thread_pool.enabled="true"
thread_pool.min_threads="1"
thread_pool.max_threads="10"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled=“true"
thread_pool.queue_max_size="100000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="discard"
bind_addr="${jgroups.bind_addr}"
bind_port="${jgroups.bind_port}" />

<JDBC_PING connection_driver="${database.driver}"
            connection_password="${database.password}"
            connection_username="${database.user}"
            connection_url="${database.url}"
            initialize_sql="${jgroups.schema}"
    datasource_jndi_name="${datasource.jndi.name}"/>

    <MERGE2 min_interval="10000" max_interval="30000" />
    <FD_SOCK />
    <FD timeout="3000" max_tries="3" />
    <VERIFY_SUSPECT timeout="1500" />
    <BARRIER />
    <pbcast.NAKACK use_mcast_xmit="false" exponential_backoff="500" discard_delivered_msgs="true" />
    <UNICAST2 />
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="4M" />
    <pbcast.GMS print_local_addr="true" join_timeout="3000" view_bundling="true" />
    <UFC max_credits="20M" min_threshold="0.4" />
    <MFC max_credits="20M" min_threshold="0.4" /`enter code here`>
    <FRAG2 frag_size="60K" />
    <pbcast.STATE_TRANSFER />

Answer 1

Как вы перезапустите свои узлы? Убивая их, или из-за постепенного отключения (= уход кластера)? Несколько комментариев к вашему конфигу:

• В обычном пуле потоков работает только 1 поток, пока очередь не заполнится (100000 элементов), поэтому в очереди может быть довольно много ожидающих сообщений. Предлагаю отключить очередь (thread_pool.queue_enabled=“false") или увеличьте минимальное количество потоков и / или уменьшите размер очереди (скажем, 100)

• Пытаться TCPPING вместо JDBC_PINGпросто чтобы посмотреть, поможет ли это

• использование MERGE3 вместо MERGE2

• использование NAKACK2 вместо NAKACK, В общем, я предлагаю использовать udp.xml поставляется с версией JGroups, которую вы используете, и примените мои рекомендации выше. Это мешает вам использовать старые протоколы.

• использование FD_ALL вместо FD

• Максимальные кредиты в 20 млн. Это слишком много для MFC/UFC и эффективно побеждает цель управления потоком.

Также беги probe.sh (обратитесь к руководству по JGroups за подробностями), чтобы получить информацию о различных протоколах, например, об использовании пула потоков в транспорте (TCP), подозрения в FD_ALL и т.п.

Надеюсь, это поможет,