Первичная настройка кластера DataGrid#

Пример создания и настройки кластера DataGrid#

В данном примере демонстрируются создание и настройка кластера DataGrid, состоящего из двух узлов:

для демонстрации будет использоваться клиентский узел;
на серверных узлах будет включен режим persistence (данные в кешах не будут потеряны при отключении и повторном включении узлов);
для обнаружения узлов в примере будет использоваться механизм Static IP Discovery.

Примечание

В данном руководстве конфигурационный файл сервера называется serverExampleConfig.xml, но он может иметь любое имя по желанию пользователя.

Используемая в примере конфигурация (XML) указывается в конфигурационном файле $IGNITE_HOME/config/serverExampleConfig.xml.

XML#

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  <!-- Включение Apache Ignite Persistent Store. -->
  <property name="dataStorageConfiguration">
    <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
      <property name="defaultDataRegionConfiguration">
        <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
          <property name="persistenceEnabled" value="true"/>
        </bean>
      </property>
    </bean>
  </property>
  <property name="consistentId" value="myIgniteNode01"/>
  <property name="cacheConfiguration">
  <list>
    <bean class="org.apache.ignite.configuration.CacheConfiguration">
      <!-- Настройка имени кеша. -->
      <property name="name" value="myReplicatedCache"/>
      <!-- Настройка режима работы кеша. -->
      <property name="cacheMode" value="REPLICATED"/>
      <!-- Другие параметры конфигурации кеша. -->
    </bean>
    </list>
  </property>

  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
          <property name="addresses">
            <list>
              <!--
                   Явное указание адреса локального узла для его запуска и нормальной работы, даже если больше узлов в кластере нет. Опционально можно указать собственный порт или диапазон портов.
              -->
              <value>IP OF NODE01</value>
              <value>IP OF NODE02</value>
            </list>
          </property>
        </bean>
      </property>
    </bean>
  </property>
</bean>

Для создания кластера из двух узлов:

Распакуйте ZIP-архив с бинарными файлами и поместите XML-файл конфигурации serverExampleConfig.xml с заранее заданными IP-адресами ваших серверов в папку $IGNITE_HOME/config/.
Экспортируйте конфигурацию кластера при помощи команды:
```
export JVM_OPTS="-DIGNITE_CLUSTER_TYPE=prom -DIGNITE_CLUSTER_NAME=mycluster"
```

Запустите DataGrid с помощью команды:

./bin/ignite.sh config/serverExampleConfig.xml

Примечание

Если не указать конфигурационный файл при запуске, то будет использоваться конфигурационный файл по умолчанию — default-config.xml.

После запуска вы увидите примерно следующий вывод:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.ignite.startup.cmdline.CommandLineStartup (file:/Users/user/ignite/Ignite-SE-15.0.0/libs/ignite-core-15.0.0-p1.jar) to method com.apple.eawt.Application.getApplication()
WARNING: Please consider reporting this to the maintainers of org.apache.ignite.startup.cmdline.CommandLineStartup
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[11:13:43]    __________  ________________
[11:13:43]   /  _/ ___/ |/ /  _/_  __/ __/
[11:13:43]  _/ // (7 7    // /  / / / _/
[11:13:43] /___/\___/_/|_/___/ /_/ /___/
[11:13:43]
[11:13:43] ver. 15.0.0-p1#20220404-sha1:c5e1625b
[11:13:43] 2022 Copyright(C) Apache Software Foundation
[11:13:43]
[11:13:43] Ignite documentation: http://ignite.apache.org
[11:13:43]
[11:13:43] Quiet mode.
[11:13:43]   ^-- Logging to file '/Users/user/ignite/Ignite-SE-15.0.0/work/log/ignite-3f988f41.0.log'
[11:13:43]   ^-- Logging by 'JavaLogger [quiet=true, config=null]'
[11:13:43]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
[11:13:43]
[11:13:43] OS: Mac OS X 10.16 x86_64
[11:13:43] VM information: Java(TM) SE Runtime Environment 15+36-1562 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 15+36-1562
[11:13:43] Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible problems in mixed environments.
[11:13:43] Configured plugins:
[11:13:43]   ^-- grid-security-basic-plugin 1.0
[11:13:43]   ^-- null
[11:13:43]
[11:13:43] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]]]
[11:13:44] Initial heap size is 256MB (should be no less than 512MB, use -Xms512m -Xmx512m).
[11:13:44] Message queue limit is set to 0 which may lead to potential OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to message queues growth on sender and receiver sides.
[11:13:45] Security status [authentication=on, sandbox=off, tls/ssl=on]
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[11:13:46] Encryption keys loaded from metastore. [grps=, masterKeyName=null]
[11:13:46] Data Regions Started: 5
[11:13:46]     ^--   sysMemPlc region [type=internal, persistence=true, lazyAlloc=false,
[11:13:46]       ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, allocRam=99MB, allocTotal=0MB]
[11:13:46]     ^--   default region [type=default, persistence=true, lazyAlloc=true,
[11:13:46]       ...  initCfg=256MB, maxCfg=3276MB, usedRam=0MB, freeRam=100%, allocRam=0MB, allocTotal=0MB]
[11:13:46]     ^--   metastoreMemPlc region [type=internal, persistence=true, lazyAlloc=false,
[11:13:46]       ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, allocRam=99MB, allocTotal=0MB]
[11:13:46]     ^--   TxLog region [type=internal, persistence=true, lazyAlloc=false,
[11:13:46]       ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, allocRam=99MB, allocTotal=0MB]
[11:13:46]     ^--   volatileDsMemPlc region [type=user, persistence=false, lazyAlloc=true,
[11:13:46]       ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, allocRam=0MB]
[11:13:46]     ^-- Ignite persistence [used=0MB]
[11:13:47] Performance suggestions for grid 'serverNodeXml' (fix if possible)
[11:13:47] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:13:47]   ^-- Disable fully synchronous writes (set 'writeSynchronizationMode' to PRIMARY_SYNC or FULL_ASYNC)
[11:13:47]   ^-- Switch to the most recent 11 JVM version
[11:13:47]   ^-- Specify JVM heap max size (add '-Xmx<size>[g|G|m|M|k|K]' to JVM options)
[11:13:47]   ^-- Set max direct memory size if getting 'OOME: Direct buffer memory' (add '-XX:MaxDirectMemorySize=<size>[g|G|m|M|k|K]' to JVM options)
[11:13:47] Refer to this page for more performance suggestions: https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning
[11:13:47]
[11:13:47] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:13:47]
[11:13:47] Ignite node started OK (id=3f988f41, instance name=serverNodeXml)
[11:13:47] Topology snapshot [ver=1, locNode=3f988f41, servers=1, clients=0, state=INACTIVE, CPUs=12, offheap=3.2GB, heap=4.0GB]
[11:13:47]   ^-- Baseline [id=0, size=1, online=1, offline=0]
[11:13:47]   ^-- All baseline nodes are online, will start auto-activation

Примечание

В случае возникновения проблем и необходимости получить более подробную информацию из журналов выполните команду ignite.sh -v.

После запуска узлов и изменения топологии необходимо активировать кластер. Процесс активации автоматически создаст базовую топологию из всех серверных узлов со включенным persistence. Для активации откройте новое окно терминала и выполните следующую команду:
```
./bin/control.sh --set-state ACTIVE --user operationAdmin --keystore ./config/certs/operationAdmin.jks --truststore ./config/certs/truststore.jks --password Default-password-1  --keystore-password password --truststore-password password
```
Внимание

Опции указаны для примера. Значения опций можно изменить на необходимые.

Теперь можно подключаться к этому кластеру с клиентского узла независимо от того, какой из узлов сейчас подключен, а какой — нет.

Примечание

Необходимо дождаться, пока первый узел синхронизирует кеш с кластером, и только потом отключать второй, поскольку количество узлов, которые находятся в сети в базовой топологии — 2:

[15:34:39,988][INFO][main][GridDiscoveryManager] Topology snapshot [ver=1, locNode=16835415, servers=2, clients=0, state=ACTIVE, CPUs=16, offheap=6.4GB, heap=4.0GB]
[15:34:39,988][INFO][main][GridDiscoveryManager] ^-- Baseline [id=0, size=2, online=2, offline=0]

где ^-- обозначает, что сообщение относится к сообщению строкой выше.

Подключение дополнительных модулей, включенных в поставку DataGrid, описано в подразделе «Дополнительные модули, которые входят в поставку DataGrid» раздела «Подключение и конфигурирование» документа «Руководство прикладного разработчика».

Решение проблем с подключениями узлов#

В случае, если узлы DataGrid связаны сетью, которая работает медленно или нестабильно, могут возникать проблемы с целостностью кластера. Вследствие работы «плохой» сети отдельные узлы могут исключаться из топологии как недоступные, а кластер может распадаться на несколько сегментов.

Чтобы решить эту проблему, можно изменить значения тайм-аутов в параметрах failureDetectionTimeout и connRecoveryTimeout.

Параметр failureDetectionTimeout в классе IgniteConfiguration задает количество времени, в течение которого узел ожидает ответа от узлов в установленной сессии в рамках communication или discovery SPI.

Если эта сессия прерывается по какой-либо причине, в работу силу вступает параметр connRecoveryTimeout в конфигурации TcpDiscoverySPI. Этот параметр регулирует количество времени, в течение которого узел должен продолжать попытки переподключения перед самостоятельным сегментированием.

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

Подробнее настройка параметров failureDetectionTimeout и connRecoveryTimeout описана в документе «Часто встречающиеся проблемы и пути их устранения».