Настройка JGroups

Инструкции Кластер
,
1

В новой версии платформы изменилась версия библиотеки jgroups вследствие чего изменился конфигурационный файл, изменения для tcp приведены на скриншоте:

Описание настроек, используемых в стандартном файле JGROUPS:

<config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
 
    <!-- Определяет протокол по которому будет осуществляться передача сообщений -->
    <TCP bind_port="7800"
         bind_addr="${jgroups.bind_addr:127.0.0.1}"
         recv_buf_size="${tcp.recv_buf_size:5M}"
         send_buf_size="${tcp.send_buf_size:5M}"
         max_bundle_size="64K"
         sock_conn_timeout="300"
         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"/>
 
    <!--
        PING решает задачу INITIAL discovery. Т.е откуда нам брать изначальные адреса серверов при инициализации кластера.
        Так же периодически используется для задач проверки целостности кластера. Помимо простых имплементации типо TCP_PING
        в которой мы явно записываем адреса хостов также есть возможность указывать их через JDBC, через файл и др. возможности
    -->
       <TCPPING async_discovery="true"
             initial_hosts="${jgroups.tcpping.initial_hosts:192.168.10.137[7800],192.168.10.136[7800]}"
             port_range="2"/>
 
<!--  Пример discovery через JDBC_PING
 <JDBC_PING async_discovery="true"-->
<!--                   connection_url="jdbc:postgresql://{{ db_host }}/{{ db_name }}"-->
<!--                   connection_driver="org.postgresql.Driver"-->
<!--                   connection_username="{{ db_user }}"-->
<!--                   connection_password="{{ db_password }}"-->
<!--                   initialize_sql="create table if not exists JGROUPSPING (-->
<!--               own_addr varchar(200) not null,-->
<!--               cluster_name varchar(200) not null,-->
<!--               ping_data bytea,-->
<!--               primary key (own_addr, cluster_name))"/>-->
 
 
   <!-- Протокол для объединения распавшегося кластера. Работает таким образом, что координатор периодически рассылает
   состояние кластера и если оно попадает другому координатору (образовавшемуся вследствие распада кластера) инициируется объединение.
   При получении нового состояния кластера (объект view) вызывается метод ClusterManager.ClusterReceiver.viewAccepted в котором
   можно при необходимости добавить специфичную логику которая должна выполняться при объединении.
 
   На данный момент специфичной логики по объединению состояний кластера нет, на данный момент мы передаем STATE полностью
   из "главной" партиции в другую (детерменированного алгоритма выбора "главной" партиции нет), т.е. какие то данные вполне
   могут потеряться при объединении. Возможен так же вариант переинициализации состояния в случае если можно это сделать,
   например при объединении инициализировать реплицируемые структуры данных из БД.
   -->
    <MERGE3 min_interval="10000"
            max_interval="30000"/>
    <!-- FD - протоколы для определения отказов. Узлы объединяются в "кольцо" и при потере соединения с соседом отправляют
    координатору сообщение о том что надо проверить состояние узла, координатор делает это с помощью протокола VERIFY_SUSPECT -->
    <FD_SOCK/>
    <!-- Здесь таймаут и число попыток определяет через какое время мы должны начать "подозревать" узел в том что он вышел из строя -->
    <FD timeout="3000"
        max_tries="3"/>
    <!-- Здесь таймаут определяет сколько координатор ждет ответа от узла до того как исключить его из кластера -->
    <VERIFY_SUSPECT timeout="1500"/>
    <!-- По всей видимости не используется с версии jgroups 3.1 + -->
    <BARRIER/>
    <!-- Протокол для надежной передачи сообщений -->
    <pbcast.NAKACK2 use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <!-- Протокол для надежной передачи сообщений -->
    <UNICAST3/>
 
    <!-- Протокол для определения параметров очистки сообщений garbage collector-ом. Каждый участник кластера может локально
    сохранять сообщения для дальнейшей их ретрансляции -->
    <pbcast.STABLE stability_delay="1000"
                   desired_avg_gossip="50000"
                   max_bytes="4M"/>
 
    <!-- Протокол отвечающий за присоединении новых участников кластера и отправки SUSPECT сообщений от FD протоколов -->
    <!-- Алгоритм присоединения нового участника в кластер приблизительно выглядит следующим образом:
    1. Выполняем INITIAL Discovery запрос, т.е. получаем изначальное состояние кластера, например initial_hosts в случае
    TCP_PING (ну и отправляем им соответствующие запросы при необходимости - являются ли они координатором или нет).
    2. Если никого не нашли, считаем что текущий узел - кластер из 1 участника.
    3. Если нашли уже существующих участников, определяем координатора и пытаемся отправить ему запрос на объединение
    с текущим узлом.
    -->
    <pbcast.GMS print_local_addr="true"
                join_timeout="2000"
                view_bundling="true"/>
 
    <!-- Flow control - пытается ограничить частоту отправки сообщений в соответствии с самым медленным получателем -->
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <!-- Протокол для разбиения больших сообщений -->
    <FRAG2 frag_size="60K"/>
    <!-- Дополнительные параметры для повторной отправки сообщений и тому подобное -->
    <RSVP resend_interval="2000"
          timeout="10000"/>
    <!-- Протокол для отправки состояния между элементами кластера. Для больших объемов рекомендуют использовать STATE или STATE_SOCK -->
    <pbcast.STATE_TRANSFER/>
</config>

Изменение настроек при переходе на версию Тезис 5.0

Слева версия файла до 5.0, справа - версия после версии 5.0

jgroups.xml
jgroups.xml1604×724 187 KB

Примеры файлов

jgroups_5x.xml (1,6 КБ)
jgroups_4x.xml (2,1 КБ)