Рекомендации по развертыванию и конфигурации кластера в нескольких ЦОД#

Введение#

Развертывание единого кластера DataGrid в нескольких центрах обработки данных (далее ЦОД) повышает гарантии сохранности данных и их доступность. Такой кластер (единый кластер DataGrid в нескольких ЦОД) называется растянутым.

Если изначально данные реплицировались между ЦОД с помощью механизма CDC и хранились на отдельных кластерах, переход на единый растянутый кластер позволит сэкономить ресурсы и упростить эксплуатацию системы (так как настроить один растянутый кластер проще, чем настраивать два обычных кластера и репликацию между ними). Но если исходная система работала в одном ЦОД и не включала механизмов репликации данных между ЦОД, добавление второго ЦОД и миграция на растянутый кластер сделают эксплуатацию системы сложнее.

С точки зрения функциональности растянутый кластер работает идентично обычному кластеру DataGrid. Однако эффективность выполнения отдельных операций, например чтения данных, можно улучшить за счет дополнительной конфигурации кластера. Новые параметры конфигурации и примеры вариантов использования описаны в разделах ниже.

Общее описание функциональности#

Растянутый кластер должен обеспечивать два основных требования:

1. Потеря сегмента кластера в произвольном ЦОД (вследствие сетевой недоступности или отключения ЦОД) не должна приводить к потере данных. Это означает, что как минимум одна копия данных должна находиться в каждом ЦОД.

   Выполнение данного требования может быть реализовано с помощью стандартной аффинити-функции RendezvousAffinityFunction с дополнительной конфигурацией — аффинити-фильтром. Можно выбрать один из трех фильтров: MdcAffinityBackupFilter, ClusterNodeAttributeAffinityBackupFilter и фильтр с ячейками ClusterNodeAttributeColocatedBackupFilter. Они отличаются по конфигурации и по логике распределения партиций при изменении топологии. Подробнее о настройке, преимуществах и недостатках фильтров написано в разделах ниже.

2. Компоненты DataGrid, которые требуют сетевых взаимодействий при обработке запросов пользователей, сначала должны обращаться к узлам кластера из локального ЦОД. Обращение к узлам из внешних (по отношению к узлу-обработчику пользовательского запроса) ЦОД допустимо только в том случае, когда ни один узел из локального ЦОД не подходит для выполнения запроса.

Метаинформация о расположении узлов кластера#

Идентификатор ЦОД, на котором запущен узел (сервер или толстый клиент), должен передаваться на узел с помощью системного свойства (SystemProperty) IGNITE_DATA_CENTER_ID при запуске узла. Например, как параметр Java-команды при запуске узла из командной строки: -DIGNITE_DATA_CENTER_ID=DC_0.

Идентификатором может быть произвольная строка, например - DC_0, DC_1. У разных ЦОД должны быть разные идентификаторы, а у узлов в пределах одного ЦОД — одинаковые.

Идентификатор ЦОД, в котором запущен узел (сервер или толстый клиент), должен передаваться узлу с помощью свойства IGNITE_DATA_CENTER_ID при запуске узла. Способы передачи идентификатора:

1. С помощью системного свойства IGNITE_DATA_CENTER_ID. Например, как параметр Java-команды при запуске узла из командной строки: -DIGNITE_DATA_CENTER_ID=DC_0.

2. С помощью пользовательского атрибута конфигурации узла:

   Java#

   IgniteConfiguration cfg = new IgniteConfiguration();
   cfg.setUserAttributes(Collections.singletonMap(IgniteSystemProperties.IGNITE_DATA_CENTER_ID, "DC_0"));
   

Конфигурация функции распределения для обеспечения гарантии сохранности данных#

Чтобы в каждом ЦОД была полная копия данных, воспользуйтесь одним из способов ниже.

Использование бэкап-фильтра MdcAffinityBackupFilter#

ignite.getOrCreateCache(
            new CacheConfiguration<>()
                .setBackups(3)
                .setAffinity(
                    new RendezvousAffinityFunction()
                        .setAffinityBackupFilter(new MdcAffinityBackupFilter(2 /* количество ЦОД */, 3 /* количество резервных копий, такое же значение передается в `setBackups` */))));

Бэкап-фильтр MdcAffinityBackupFilter поддерживает только равномерное распределение копий между ЦОД, поэтому не все сочетания параметров (количество ЦОД и количество резервных копий) допустимы.

Примеры допустимых сочетаний:

• Два ЦОД и три резервные копии партиций. Общее количество копий каждой партиции — четыре (три резервных копии партиции (backup) и одна основная (primary)). Четыре копии можно равномерно распределить по двум ЦОД (в каждый ЦОД будет назначено по две резервные копии).

• Три ЦОД и две резервные копии партиций. Общее количество копий — три, в каждый ЦОД будет назначено по одной резервной копии.

Примеры недопустимых сочетаний:

• Два ЦОД и две резервные копии партиций. Общее количество копий (три) невозможно равномерно распределить между двумя ЦОД.

• Три ЦОД и одна резервная копия. Общее количество копий (две) меньше количества ЦОД.

Общее правило: полное количество копий (все резервные копии партиций +1) делится без остатка на количество ЦОД.

Важная особенность распределения, формируемого фильтром#

Фильтр назначает резервные (backup) копии партиции в первую очередь в те ЦОД, в которых нет других копий этой партиции. Это может приводить к неравномерности распределения партиций между узлами в ситуации, когда базовая топология кластера содержит разное количество узлов в разных ЦОД. Неравномерность может возникнуть, например, при выходе узла in-memory-кластера в одном из ЦОД. В этом случае базовая топология будет переназначена автоматически, что приведет к изменению распределения партиций и переназначению резервных копий на другие узлы. При неизменной базовой топологии переназначения партиций не произойдет и перекоса данных не возникнет.

Использование бэкап-фильтра ClusterNodeAttributeAffinityBackupFilter#

Фильтр ClusterNodeAttributeAffinityBackupFilter при назначении резервной копии на узел проверяет, что значение хотя бы одного учитываемого при распределении партиций атрибута узла отличается от значений этого атрибута у остальных узлов, на которые уже назначены копии партиции. Атрибуты, которые анализирует фильтр, задает пользователь. Если передать фильтру атрибут ЦОД DC_ID, который всегда доступен в растянутом кластере, фильтр сможет распределять копии партиций между ЦОД.

ignite.getOrCreateCache(
    new CacheConfiguration<>()
        .setBackups(1)
        .setAffinity(
            new RendezvousAffinityFunction()
                .setAffinityBackupFilter(new ClusterNodeAttributeAffinityBackupFilter("DC_ID"))));

Из-за того, что у всех узлов в одном ЦОД одинаковое значение атрибута DC_ID, фильтр может назначить в каждый ЦОД только по одной копии партиции. Чтобы фильтр мог назначить больше одной копии в каждый ЦОД, на узлы нужно добавить дополнительные атрибуты.

В примере ниже на каждый узел добавляется дополнительный атрибут NODE_GROUP, и в каждом ЦОД запускается один узел со значением этого атрибута GROUP_A и один узел со значением GROUP_B (суммарно четыре узла в кластере). Таким образом фильтр может назначить по две копии каждой партиции в каждый ЦОД:

ignite.getOrCreateCache(
    new CacheConfiguration<>()
        .setBackups(3)
        .setAffinity(
            new RendezvousAffinityFunction()
                .setAffinityBackupFilter(new ClusterNodeAttributeAffinityBackupFilter("DC_ID", "NODE_GROUP"))));

Использование фильтра с ячейками ClusterNodeAttributeColocatedBackupFilter#

Фильтр ClusterNodeAttributeColocatedBackupFilter требует настройки одного дополнительного атрибута на каждом узле. Группа узлов с одинаковым значением такого атрибута называется ячейкой.

В фильтре с ячейками все копии одной партиции назначаются в одну ячейку, поэтому использовать параметр DC_ID в качестве атрибута для организации ячеек не получится: в этом случае все копии каждой партиции будут назначены в один ЦОД и требование «копия данных в каждом ЦОД» не будет выполнено. В растянутом кластере узлы с одинаковым значением атрибута должны присутствовать в каждом ЦОД, формируя растянутые ячейки — именно такая конфигурация позволяет добиться гарантий сохранности данных.

ignite.getOrCreateCache(
            new CacheConfiguration<>()
                .setBackups(3)
                .setAffinity(
                    new RendezvousAffinityFunction()
                        .setAffinityBackupFilter(new ClusterNodeAttributeColocatedBackupFilter("CELL"))));

Сравнение фильтров#

Фильтр MdcAffinityBackupFilter#

Преимущества:

• Более простая конфигурация — не требует дополнительной конфигурации узлов, кроме атрибута DC_ID.

• Автоматически поддерживает количество копий в каждом ЦОД. Эта функциональность может одновременно быть и недостатком, так как может приводить к ребалансировке.

Недостатки:

• Поддерживает только равномерное распределение — одинаковое количество копий партиции в каждом ЦОД.

• Может приводить к запуску ребалансировки при выходе узлов (для in-memory сценария или при разрешенном baseline.autoAdjust).

Фильтр ClusterNodeAttributeAffinityBackupFilter#

Преимущества:

• Дает точный контроль размещения партиций за счет управления атрибутами и их значениями на узлах.

• Позволяет избежать запуска ребалансировки при выходе узла и смене базовой топологии (baseline topology).

• Для кешей с одной резервной копией можно использовать атрибут DC_ID. В этом случае дополнительная конфигурация атрибутов на узлах не нужна.

Недостатки:

• При выходе узлов из топологии кластера количество партиций в отдельном ЦОД может снижаться до одной, если значения атрибутов на оставшихся узлах не позволяют назначить в этот ЦОД дополнительные резервные копии.

• Требует дополнительной конфигурации узлов (для схемы «2+ резервные копии в каждом ЦОД» требуются дополнительные атрибуты).

Фильтр с ячейками ClusterNodeAttributeColocatedBackupFilter#

Преимущества:

• Обладает всеми преимуществами ClusterNodeAttributeAffinityBackupFilter.

• Более высокая степень защиты от потери данных при выходе узлов: потеря происходит только при выходе всех узлов одной ячейки. При использовании ClusterNodeAttributeAffinityBackupFilter выход того же количества узлов с высокой вероятностью приведет к потере некоторых партиций.

Недостатки:

• Требует обязательной конфигурации дополнительного атрибута для организации ячеек, переиспользовать атрибут DC_ID не получится.

• Как и ClusterNodeAttributeAffinityBackupFilter, при выходе узлов не позволяет назначить дополнительные копии партиций, если в ЦОД нет узлов с подходящими значениями атрибутов (даже если остались другие активные узлы).

Рекомендации по выбору фильтра#

Общие рекомендации по выбору бэкап-фильтров при использовании растянутого кластера:

1. Эксплуатация растянутого кластера совсем без фильтров не рекомендуется, поскольку в этом случае наличие полной копии данных в каждом ЦОД не гарантируется.

2. Рекомендуется мигрировать на растянутый кластер ту же конфигурацию, которая использовалась в предыдущей версии системы. У пользователей уже есть опыт работы с данной конфигурацией и поведение будет для них ожидаемым.

3. Фильтр MdcAffinityBackupFilter стоит использовать, если его преимущества (поддержание гарантии полной копии данных) перевешивают потенциальные риски, которые связаны с неравномерным распределением данных по узлам.

Конфигурация тонких клиентов для оптимизации выполнения запросов#

Тонкие клиенты также поддерживают оптимизацию операций чтения, когда запросы отправляются сначала в локальный ЦОД. Для этого требуется выполнение трех условий:

1. Тонкий клиент запущен с указанием локального ЦОД. Для этого укажите IGNITE_DATA_CENTER_ID в SystemProperty или передайте IGNITE_DATA_CENTER_ID с помощью пользовательских атрибутов: ClientConfiguration#setUserAttributes(...).

2. Кеш, запросы к которому требуется оптимизировать, допускает чтение из резервных копий: readFromBackup=true.

3. Режим синхронизации записи (write synchronization mode) кеша — FULL_SYNC.

Оптимизация не распространяется на запросы модификации данных — этот тип запросов всегда выполняется на основных узлах вне зависимости от ЦОД, в котором они размещены.

Дополнительные метрики для контроля конфигурации кешей и безопасности текущего распределения партиций#

Добавлены дополнительные метрики кешей:

Конфигурация TopologyValidator для обработки сценария разрыва связи между ЦОД#

DataGrid поставляется с плагином DynamicTopologyValidator, который предназначен для обеспечения целостности данных в условиях разрыва сети между ЦОД.

Подключение и использование плагина#

Для подключения плагина добавьте в конфигурацию DataGrid провайдер MdcDynamicTopologyValidatorPluginProvider:

IgniteConfiguration cfg = new IgniteConfiguration();

cfg.setPluginProviders(
	new MdcDynamicTopologyValidatorPluginProvider(
    	new MdcDynamicTopologyValidatorConfiguration(
    		numberOfDatacenters, // Количество ЦОД, в которых разворачивается кластер DataGrid.
    		mainDatacenter) // Основной ЦОД (нужен только в случае, если количество ЦОД четное).
));

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
	...
    <property name="pluginProviders">
        <bean class="com.sbt.ignite.topology.MdcDynamicTopologyValidatorPluginProvider">
            <property name="configuration">
                <bean class="com.sbt.ignite.topology.MdcDynamicTopologyValidatorConfiguration">
                    <property name="numberOfDatacenters" value="2"/>
                    <property name="mainDataCenter" value="DC_0"/>
                </bean>
            </property>
        </bean>
    </property>
    ...
</bean>

После подключения плагина MdcTopologyValidator будет автоматически назначаться всем запущенным в кластере кешам. Дополнительная настройка конфигурации кешей не требуется.

Конфигурация плагина#

Свойства для настройки плагина:

• numberOfDatacenters — общее количество ЦОД, в которых развернут кластер (обязательное свойство).

• mainDataCenter — основной ЦОД (один из ЦОД, в которых развернут кластер). Свойство mainDataCenter нужно указывать только в том случае, если количество ЦОД четное (если оно нечетное, значение свойства можно оставить пустым).

Алгоритм работы#

Для четного количества ЦОД нужно настроить свойство mainDataCenter. При разрыве сети между ЦОД все узлы, для которых недоступны узлы из mainDataCenter, переходят в режим только для чтения (read-only). Из-за этого при физической потере mainDataCenter (если все узлы в нем остановились) все остальные узлы перейдут в режим только для чтения. Для восстановления их функций требуется вернуть в топологию узлы из mainDataCenter. Также поддерживается динамическое переназначение mainDataCenter — об этом написано в следующем разделе.

Для нечетного количества ЦОД свойство mainDataCenter следует оставить пустым. В этом случае узлы, которые переходят в режим только для чтения, определяются на основе большинства (majority). В режим read-only переходят те узлы, ЦОД которых остался в меньшинстве при разрыве связи между ЦОД. В сценарии разрыва связи одновременно между всеми ЦОД ни один сегмент кластера не сможет продолжить работу: они все перейдут в режим read-only. Но в этом случае тоже возможно назначить один из ЦОД как mainDataCenter, и сегмент кластера в этом ЦОД сможет продолжить обработку запросов на модификацию данных.

Динамическое переназначение основного ЦОД в аварийных ситуациях#

В аварийной ситуации (например, при длительном разрыве сети между ЦОД или физической потере одного или нескольких ЦОД) предусмотрена команда динамического переназначения основного ЦОД.

Примеры аварийных ситуаций:

1. Схема развертывания — 2 ЦОД. Сегмент кластера в основном ЦОД перестает работать из-за отключения электроснабжения ЦОД. Восстановление ЦОД и последующее восстановление кластера потребуют несколько часов. На это время второй сегмент кластера с помощью команды назначается новым основным и продолжает обрабатывать запросы на модификацию данных.

2. Схема развертывания — 3 ЦОД. Все ЦОД потеряли связь друг с другом и большинства нет ни в одном из сегментов кластера. В соответствии с алгоритмом работы MdcTopologyValidator все сегменты переходят в режим «только для чтения». Для восстановления сервиса один из сегментов назначается основным и продолжает обрабатывать запросы на модификацию данных. Другие сегменты рекомендуется остановить, так как восстановление полной топологии кластера в любом случае потребует перезагрузки сегментов, не выполнявших модификацию данных.

Для назначения нового основного ЦОД администратору нужно выполнить команду set-main-data-center:

control.sh --set-main-data-center --new-main-data-center DC_1

Ограничения:

1. Команда должна выполняться в том же ЦОД, который будет назначен новым основным. Если она запущена в другом ЦОД, запуск завершится с ошибкой.

2. Команда позволяет назначить новый основной ЦОД только в том случае, если в топологии присутствуют серверные узлы только одного ЦОД. Если на момент запуска команды в топологии есть серверы из других ЦОД, запуск завершится с ошибкой.

Принципы работы функциональности:

1. При полной перезагрузке сегмента кластера логика MdcTopologyValidator возвращается к статической конфигурации, динамическое переназначение сбрасывается. Если сегмент кластера был динамически переназначен как главный, после перезагрузки команду переназначения нужно выполнить повторно (если этот сегмент должен оставаться главным).

2. При присоединении серверных узлов из других ЦОД логика MdcTopologyValidator также возвращается к статической конфигурации. Присоединение толстых клиентов из любых ЦОД не сбрасывает динамическое переназначение.

3. При присоединении к топологии нового серверного узла из того же ЦОД, который был динамически переназначен как главный, данный серверный узел получает эту динамическую конфигурацию и учитывает ее при валидации текущей топологии.

Рекомендации по сетевым тайм-аутам и запуску кластера#

ConnectionRecoveryTimeout#

Свойство ConnectionRecoveryTimeout конфигурируется в TcpDiscoverySpi. Установите у свойства ConnectionRecoveryTimeout значение 0, чтобы отключить функции восстановления сетевого соединения. Это необходимо, так как в настоящее время функция не учитывает специфику растянутого кластера и может приводить к последовательной сегментации всех узлов кластера при разрыве связи между ЦОД.

TcpDiscoverySpi tcpDisco = new TcpDiscoverySpi();
tcpDisco.setConnectionRecoveryTimeout(0);
 
IgniteConfiguration cfg = new IgniteConfiguration().setDiscoverySpi(tcpDisco);

// Запуск кластера с помощью `cfg`.

Запуск растянутого кластера#

В растянутом кластере по умолчанию включен механизм оптимизации топологии, который группирует принадлежащие одному ЦОД узлы внутри топологии. Это позволяет минимизировать количество соединений между узлами из разных ЦОД внутри кольца.

Инструменты для получения информации о топологии#

CLI (интерфейс командной строки)#

Для получения информации о топологии растянутого кластера используются две команды утилиты control.sh:

• --data-center print_topology — просмотр текущей топологии кластера и задержек на уровне discovery-кольца;

• --data-center communication_latency — измерение задержек (RTT) между узлами на уровне Communication SPI.

Команда –data-center print_topology#

Команда выводит подробную информацию о растянутом кластере:

• получение информации о настроенных ЦОД и их идентификаторах;

• распределение узлов по ЦОД;

• количество переходов между ЦОД в discovery-кольце (cross-DC ring hops);

• распределение соединений тонких клиентов по ЦОД клиента;

• поддержка переключения обозначения узлов (согласованный идентификатор узла (consistent ID)/имя экземпляра (instance name), идентификатор узла (node ID));

• просмотр количества подключений тонких клиентов в разрезе ЦОД;

• просмотр карты топологии и переходов между ЦОД;

• предупреждение пользователя в случаях, если:

  • количество переходов между ЦОД в топологическом кольце неоптимально (больше минимального);

  • присутствуют клиентские узлы, для которых не задан идентификатор ЦОД;

  • присутствуют клиентские узлы, которые подключены не к своему ЦОД.

• поддерживается только TcpDiscoverySpi (ZookeeperSPI не поддерживается).

Для тонких клиентов выводится количество физических соединений, а не количество экземпляров клиентов. Подключения утилиты управления кластером не учитываются.

control.(sh|bat) --data-center print_topology [--node-format CONSISTENT_ID|ID|INSTANCE_NAME] [--timings]

Параметры:

DC IDs: DC0, DC1

Nodes distribution by data centers:
Data center    Server nodes    Client nodes
DC0            3               1
DC1            3               2

Thin client connections by client data center:
Data center    Connections
DC0            6
DC1            6

--- Ring summary ---
Cross-DC ring hops: 2 (minimum: 2)

Ring map:
Legend: -> same data center, ==> cross-data-center hop
[DC0] srv0-dc0 ->
      srv1-dc0 ->
      srv2-dc0 ==>
[DC1] srv0-dc1 ->
      srv1-dc1 ->
      srv2-dc1 ==>
back to DC0

WARNING: TCP discovery ring has non-minimal cross-DC ring hops. Actual: 4. Minimum: 2.

WARNING: Data center ID is not set for the following client nodes: client-no-dc.

WARNING: The following client nodes are connected to a data center other than their own: cli0-dc1.

DC IDs: DC0, DC1

Nodes distribution by data centers:
Data center    Server nodes    Client nodes
DC0            3               1
DC1            3               1
Number of client nodes without data center ID: 1

Thin client connections by client data center:
Data center    Connections
DC0            1
DC1            1
<not set>      5

--- Ring summary ---
Cross-DC ring hops: 4 (minimum: 2)

Ring map:
Legend: -> same data center, ==> cross-data-center hop
[DC0] srv0-dc0 ==>
[DC1] srv0-dc1 ->
      srv1-dc1 ==>
[DC0] srv1-dc0 ->
      srv2-dc0 ==>
[DC1] srv2-dc1 ==>
back to DC0

Client nodes connected to a data center other than their own:
Client node    Client node DC    DC, node connected to
cli0-dc1       DC1               DC0

control.sh --data-center print_topology --timings

--- Ring summary ---
Cross-DC ring hops: 2 (minimum: 2)
Full-ring latency (single pass): 142.418 ms

Ring map:
Legend: -> same data center, ==> cross-data-center hop, [N ms] estimated delivery*
[DC0] srv0-dc0 -> [2 ms]
      srv1-dc0 -> [0 ms]
      srv2-dc0 ==> [36 ms]
[DC1] srv0-dc1 -> [0 ms]
      srv1-dc1 -> [0 ms]
      srv2-dc1 ==> [35 ms]
back to DC0

* Per-hop delivery is estimated using operating system time and requires different
  nodes' clocks to be synchronized.
  Full-ring latency uses a monotonic clock.

Оценку задержек отдельных переходов ([N ms]) команда выполняет с использованием системного времени ОС, поэтому она корректна только при синхронизированных часах узлов кластера. Задержка полного прохода по discovery-кольцу (Full-ring latency) измеряется монотонными часами и к синхронизации часов нетребовательна.

Задержка полного прохода выводится только при наличии как минимум двух серверных узлов. При одном серверном узле команда с опцией --timings выводит Full-ring latency: n/a (requires at least two server nodes).

Команда –data-center communication_latency#

Команда измеряет RTT (Round-Trip Time) Communication SPI между всеми направленными парами серверных узлов. Это позволяет сравнить задержки между ЦОД и найти отдельный проблемный сервер или сетевой маршрут.

control.(sh|bat) --data-center communication_latency \
    [--node-format CONSISTENT_ID|ID|INSTANCE_NAME] [--warmup MILLIS] [--duration MILLIS] \
    [--payload-size BYTES] [--process-in-nio-thread] [--client-nodes]

Параметры:

RTT измеряется монотонными часами. При обработке в системном пуле в RTT включается время постановки задачи в executor.

control.sh --data-center communication_latency

Communication SPI latency between server nodes
Parameters: warmup=1000 ms | duration=5000 ms | payload=0 bytes
Handling: system pool

From DC    From node    To DC    To node    Samples    Min RTT, ms    Avg RTT, ms    Max RTT, ms
DC0        srv0-dc0     DC0      srv1-dc0         49          0.182          0.296          0.911
DC0        srv0-dc0     DC1      srv0-dc1         49         33.408         34.115         37.902
DC0        srv0-dc0     DC1      srv1-dc1         49         33.617         34.306         38.174
DC0        srv1-dc0     DC0      srv0-dc0         49          0.176          0.271          0.873
DC0        srv1-dc0     DC1      srv0-dc1         49         33.522         34.201         37.681
DC0        srv1-dc0     DC1      srv1-dc1         49         33.746         34.488         38.029
DC1        srv0-dc1     DC0      srv0-dc0         49         33.602         34.281         38.143
DC1        srv0-dc1     DC0      srv1-dc0         49         33.731         34.405         38.309
DC1        srv0-dc1     DC1      srv1-dc1         49          0.171          0.263          0.822
DC1        srv1-dc1     DC0      srv0-dc0         49         33.468         34.101         37.703
DC1        srv1-dc1     DC0      srv1-dc0         49         33.592         34.233         37.924
DC1        srv1-dc1     DC1      srv0-dc1         49          0.185          0.278          0.891

* RTT uses a monotonic clock. System-pool handling includes executor dispatch time.

control.sh --data-center communication_latency --client-nodes

Communication SPI latency from client nodes to server nodes
Parameters: warmup=1000 ms | duration=5000 ms | payload=0 bytes
Handling: system pool

From DC    From node    To DC    To node    Samples    Min RTT, ms    Avg RTT, ms    Max RTT, ms
DC0        cli0-dc0     DC0      srv0-dc0         49          0.221          0.342          1.064
DC0        cli0-dc0     DC0      srv1-dc0         49          0.237          0.361          1.138
DC0        cli0-dc0     DC1      srv0-dc1         49         33.681         34.395         38.247
DC0        cli0-dc0     DC1      srv1-dc1         49         33.846         34.576         38.492
DC1        cli0-dc1     DC0      srv0-dc0         49         33.712         34.441         38.310
DC1        cli0-dc1     DC0      srv1-dc0         49         33.887         34.602         38.577
DC1        cli0-dc1     DC1      srv0-dc1         49          0.215          0.329          1.018
DC1        cli0-dc1     DC1      srv1-dc1         49          0.229          0.348          1.097

* RTT uses a monotonic clock. System-pool handling includes executor dispatch time.

Системное представление#

dataCenterId — поле в системном представлении SYS.NODES, позволяет в табличном виде вывести информацию о настроенных в топологии ЦОД.

Лог-файл#

Сообщения, которые выводятся в лог-файл:

• При запуске узла выводится идентификатор ЦОД:

  >>> Data center ID: DC1
  

• При появлении изменений в топологии кольца выводится список изменений:

  Ring topology changed. Transitions map:
  [DC0] srv-0-dc-0 ==>
  [DC1] srv-0-dc-1 ->
        srv-1-dc-1 ==>
  back to DC0
  

• Периодически выводятся метрики (распределение узлов, количество соединений между ЦОД и так далее):

  Data centers metrics. Cross connections: 4 (not minimal).
      ^-- DC0 [servers=2, clients=0]
      ^-- DC1 [servers=2, clients=0]
  

Метрики#

Используйте системное представление NODES для проверки идентификаторов ЦОД узлов кластера и системное представление CLIENT_CONNECTIONS для проверки идентификаторов ЦОД подключений тонких клиентов. Это позволит быстрее обнаружить клиентов с некорректным или отсутствующим идентификатором.

Для тонких клиентов Java системное свойство IGNITE_DATA_CENTER_ID имеет приоритет над пользовательским атрибутом с тем же именем.

Метрика io.discovery.ClientRouterNodeId — идентификатор узла, к которому подключен толстый клиент (TCP Discovery SPI, пересылка сообщений из кольца). Метрика может использоваться, например, для выяснения, подключен ли толстый клиент к своему ЦОД.