Apache Ignite Baseline Topology на примерах

Ignite Baseline Topology или BLT представляет набор серверных узлов в кластере, который сохраняет данные на диске.

Где серверные узлы N1-2 и N5 являются членами кластеров Ignite с собственным постоянством, которые позволяют данным сохраняться на диске. Серверные узлы N3-4 и N6 являются членами кластера Ignite, но не являются частью базовой топологии.

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

Узлы сервера, которые не используются Ignite native persistence для сохранения данных на диске. Обычно они хранят данные в памяти или сохраняют данные в сторонней базе данных или NoSQL. В приведенном выше уравнении узел N3 или N4 может быть одним из них.
Клиентские узлы, в которых не хранятся общие данные.

Чтобы лучше понять концепцию базовой топологии, давайте начнем с самого начала и попытаемся понять ее цель и то, какую проблему она помогает нам решить.

База данных, такая как Ignite, предназначена для поддержки массового хранения и обработки данных. Базы данных Ignite обладают высокой масштабируемостью и отказоустойчивостью. Эта особенность Ignite с высокой масштабируемостью ставит перед администратором базы данных несколько задач, таких как: как управлять кластером? Как правильно добавить / удалить узлы или как сбалансировать данные после добавления / удаления узлов? Потому что кластер Ignite с множеством узлов может значительно увеличить сложность инфраструктуры данных. Давайте рассмотрим на примере Apache Ignite.

Концепция кластера в режиме зажигания в памяти очень проста. В кластере нет главного или выделенного узла, и каждый узел равен. Каждый узел хранит подмножество разделов и может участвовать в распределенных вычислениях или развертывать любые сервисы. В случае сбоев любого узла пользовательские запросы, обслуживаемые другими узлами, и данные отказавших узлов больше не будут доступны. Операции управления кластером Ignite очень похожи на следующие:

Чтобы запустить кластер, запустите все узлы.
Чтобы расширить топологию кластера, добавьте несколько узлов.
Чтобы уменьшить топологию кластера, удалите некоторые узлы.

Части этой статьи были взяты из книги The Apache Ignite book . Если это заинтересовало вас, ознакомьтесь с остальной частью книги для получения более полезной информации.

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

В постоянном режиме узел сохраняет свое состояние даже после перезапуска. Во время любой операции чтения данные считываются с диска и восстанавливают состояние узла. Следовательно, в отличие от режима в памяти, перезапуск узла в режиме постоянного хранения не требует перераспределения данных с одного узла на другой. Данные при сбое узла будут восстановлены с диска. Эта стратегия открывает возможности не только для предотвращения перемещения огромного объема данных во время сбоя узла, но и для сокращения времени запуска всего кластера после перезапуска. Итак, нам нужно как-то различать эти узлы, которые могут сохранять свое состояние после перезапуска. Другими словами, базовая топология Ignite предоставляет эту возможность.

Короче говоря, базовая топология Ignite представляет собой набор узлов, которые были настроены для хранения постоянных данных на диске. Базовая топология отслеживает историю изменений топологии и предотвращает расхождения данных в кластере во время восстановления. Давайте возобновим цели базовой топологии:

Избегайте избыточной перебалансировки данных, если узел перезагружается.
Автоматически активируйте кластер, как только все узлы базовой топологии соединились после перезапуска кластера.
Предотвращение несоответствия данных в случае разделения мозга.

Apache Ignite предоставляет инструмент командной строки (CLI), который позволяет отслеживать базовую топологию кластера и управлять ею. В этой статье мы рассмотрим несколько распространенных сценариев администрирования базовой топологии с помощью этого инструмента, когда используется постоянство Ignite.

Сценарий командной строки ./control.sh находится в папке / bin каталога распространения Apache Ignite. Основная цель этого скрипта (инструмента) — активировать / деактивировать и управлять набором узлов, которые представляют базовую топологию. Однако этот инструмент является многоцелевым и может активно использоваться для мониторинга состояний кэша или обнаружения любых блокировок транзакций, которые могут возникнуть во всем кластере.

Готовим песочницу. Как мы уже говорили ранее, скрипт, который запускает инструмент, находится в папке {Ignite_home} / bin и называется control.sh. Существуют версии скрипта для Unix (control.sh) и Windows (control.bat). Для демонстрации я буду использовать следующие конфигурации:

название	Описание
Операционные системы	MacOS, вы можете использовать операционную систему Windows или Linux по вашему выбору.
Зажечь версию	2.6.0 или выше.
Количество узлов Ignite	3 узла в одном хосте.
JVM	1,8
Обнаружение TCP	Multicast

Шаг 1 Мы собираемся запустить три узла Ignite в постоянном режиме на одном хосте. По умолчанию Ignite создает каталог WORK в папке IGNITR_HOME для хранения архивов WAL и файлов журналов. Загрузите дистрибутив Ignite и разархивируйте его в 3 различных каталогах в вашей операционной системе, например / usr / ignite / 2.6.0-s1, /usr/ignite/2.6.0-s2, /usr/ignite/2.6.0-s3 , У вас должна быть похожая иерархия папок, как показано на рисунке 4.

Обратите внимание, что это самый простой способ запустить несколько узлов с включенным постоянством на одном хосте без какой-либо дополнительной настройки. Однако вы можете настроить Ignite таким образом, чтобы он позволял запускать несколько узлов Ignite с разными архивными папками WAL.

Шаг 2 Чтобы включить постоянное хранилище, мы используем конфигурацию хранилища данных Ignite через Spring. Создайте файл XML с именем ignite-book-baseline.xml и скопируйте в него следующее содержимое.

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemalocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean class="org.apache.ignite.configuration.IgniteConfiguration" id="ignite.cfg">
        <property name="cacheConfiguration">
            <list>
                <bean class="org.apache.ignite.configuration.CacheConfiguration">
                    <property name="name" value="TestCache">
                    <property name="atomicityMode" value="ATOMIC">
                    <property name="backups" value="1">
                </property></property></property></bean>
            </list>
        </property>
        <!-- Enabling 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">
                        <property name="metricsEnabled" value="true">
                    </property></property></bean>
                </property>
            </bean>
        </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.multicast.TcpDiscoveryMulticastIpFinder">
                        <property name="addresses">
                            <list>
                                <value>127.0.0.1:47500..47509</value>
                            </list>
                        </property>
                    </bean>
                </property>
            </bean>
        </property>
    </bean>
</beans>

Сохраните файл где-нибудь в вашей файловой системе.

Шаг 3 Мы будем запускать каждый узел сервера Ignite по одному, начиная с нашего первого узла Ignite. Откройте терминал и измените каталог IGNITE_HOME на папку, в которой вы разархивируете дистрибутив Ignite для узла Ignite 1.

export IGNITE_HOME=PATH_TO_THE_IGNITE_NODE_ONE/ignite/2.6.0-s1

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

ignite.sh /PATH_TO_THE_SPRING_CONFIG_FILE/ignite/ignite-book-baseline.xml

Ваш вывод на консоль должен выглядеть примерно так:

ver. 2.6.0#20180710-sha1:669feacc
2018 Copyright(C) Apache Software Foundation
Ignite documentation: http://ignite.apache.org Quiet mode.
^-- Logging to file '/usr/ignite/2.6.0-s1/work/log/ignite-f0ef6ecc.0.log'
Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, offheap=3.2GB, heap=1.\
^-- Node [id=F0EF6ECC-D692-4862-9414-709039FE00CD, clusterState=INACTIVE] Data Regions Configured:
^-- default [initSize=256.0 MiB, maxSize=3.2 GiB, persistenceEnabled=true]

Проверьте журналы, отображаемые на консоли, сообщения журнала подтверждают, что наш первый сервер Ignite запущен и работает и режим постоянства включен. Теперь сделайте то же самое снова для второго узла Ignite.

export IGNITE_HOME=PATH_TO_THE_IGNITE_NODE_ONE/ignite/2.6.0-s2 
ignite.sh /PATH_TO_THE_SPRING_CONFIG_FILE/ignite/ignite-book-baseline.xml

В этот момент вы можете видеть, что 2-й узел Ignite запустился в постоянном режиме и присоединился к кластеру. Вы должны увидеть очень похожие сообщения в терминале, как показано ниже.

[16:13:35] >>> Ignite cluster is not active (limited functionality available). Use contro\ l.(sh|bat) script or IgniteCluster interface to activate.
[16:13:35] Topology snapshot [ver=2, servers=2, clients=0, CPUs=8, offheap=6.4GB, heap=2.\ 0GB]
[16:13:35] ^-- Node [id=6DB02F31-115C-41E4-BECC-FDB6980F8143, clusterState=INACTIVE] [16:13:35] Data Regions Configured:
[16:13:35] ^-- default [initSize=256.0 MiB, maxSize=3.2 GiB, persistenceEnabled=true]

Ignite также предупредил, что кластер еще не активирован, и вы должны активировать кластер с помощью сценария control.sh. Давайте активируем кластер и создадим несколько таблиц для хранения данных.

Шаг 4 Прежде чем активировать кластер, давайте рассмотрим особенности инструмента control.sh. В настоящее время сценарий control.sh поддерживает следующие команды:

команда	Описание
-activate	Эта команда переводит кластер в активное состояние. В этом случае, если в кластере отсутствует базовая топология, во время активации кластера будет создан новый базовый уровень. Новая базовая топология будет включать все подключенные узлы в топологии кластера.
-deactivate	Деактивировать кластер. Ограниченная функциональность будет доступна в этом состоянии.
-штат	Распечатать текущее состояние кластера.
-baseline	Эта команда предназначена для управления базовой топологией. Когда эта команда используется без каких-либо параметров, она печатает информацию о базовой топологии кластера. С этой командой можно использовать следующие параметры: добавить, удалить, установить и версию.

Чтобы вызвать определенную команду, используйте следующий шаблон:

UNIX/LINUX/MacOS
$IGNITE_HOME/bin/control.sh

Теперь активируйте кластер. Запустите следующую команду:

$IGNITE_HOME/bin/control.sh

Если команда выполнена успешно, вы должны увидеть следующие сообщения в консоли.

Control utility [ver. 2.6.0#20180710-sha1:669feacc] 2018 Copyright(C) Apache Software Foundation
User: shamim 
-------------------------------------------------------------------------------- 
Cluster activated

В этот момент вы также можете использовать команду –state для проверки текущего состояния кластера. Команда – state должна вернуть сообщение о том, что кластер активирован.

Шаг 5 Теперь создайте таблицу и заполните некоторые данные. Мы используем инструмент SQLLINE для подключения к кластеру. Запустите следующую команду, чтобы запустить инструмент SQLLINE:

sqlline.sh --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1/

Создайте таблицу с именем EMP и вставьте в нее 1000 строк. Используйте следующий сценарий DDL для создания таблицы EMP следующим образом:

CREATE TABLE IF NOT EXISTS EMP
(
 empno LONG, ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate DATE,
sal LONG,
comm LONG,
deptno LONG,
CONSTRAINT pk_emp PRIMARY KEY (empno)
) WITH "template=partitioned,CACHE_NAME=EMPcache";

Затем используйте сценарий EMP_001.sql из репозитория GitHub, чтобы вставить 1000 записей в таблицу.

0: jdbc:ignite:thin://127.0.0.1/> !run /PATH_TO_THE_FILE/the-apache-ignite-book/chapters/\ chapter-10/baseline/EMP_001.sql

Приведенная выше команда вставляет 1000 записей в таблицу EMP или EMPcache. Используйте инструменты интерфейса командной строки Visor, чтобы увидеть размер кэша во всем кластере. Запустите кеш команд -a в консоли IgniteVisor. Команда должна вернуть следующий вывод, как показано на рисунке 5.

Посмотрите на столбец с именем РАЗМЕР. В этом столбце уточняется количество записей, хранящихся в каждом узле. В нашем случае один из наших узлов содержит 504 записи, а другой содержит 496 записей в кеше EMPcache.

Шаг 6 Пока что мы запустили только 2 узла Ignite и создали базовую топологию в кластере. Давайте начнем другой узел Ignite. Повторите те же действия, что и для третьего узла Ignite.

export IGNITE_HOME=PATH_TO_THE_IGNITE_NODE_ONE/ignite/2.6.0-s3 
ignite.sh /PATH_TO_THE_SPRING_CONFIG_FILE/ignite/ignite-book-baseline.xml

Вход в консоль должен подтвердить, что узел успешно запущен в постоянном режиме. Более того, вы должны получить предупреждение на консоли, что локальный узел не включен в базовую топологию и не будет использоваться для постоянного хранения данных. Теперь мы можем играть с командой –baseline. Давайте запустим команду без параметров следующим образом:

$IGNITE_HOME/bin/control.sh --baseline

Вывод может быть следующим:

shamim:~ shamim$ control.sh --baseline
Control utility [ver. 2.6.0#20180710-sha1:669feacc] 2018 Copyright(C) Apache Software Foundation
User: shamim -------------------------------------------------------------------------------- 
 Cluster state: active
Current topology version: 6
Baseline nodes:
ConsistentID=1640f655-4065-438c-92ca-478b5df91def, STATE=ONLINE ConsistentID=d8b04bc3-d175-443c-b53f-62512ff9152f, STATE=ONLINE
-------------------------------------------------------------------------------- 
Number of baseline nodes: 2
Other nodes: ConsistentID=3c2ad09d-c835-4f4b-b47a-43912d04d30e
Number of other nodes: 1

Приведенная выше базовая информация показывает состояние кластера, версию топологии, узлы с их согласованными идентификаторами, которые являются частью базовой топологии, а также те, которые не являются частью базовой топологии. Здесь количество базовых узлов равно 2, а базовая линия состоит из нашего 1-го и 2-го узлов Ignite.

Иногда может случиться, что во время первой активации кластера базовая топология не была создана. В таких случаях команда –baseline вернет сообщение типа «Базовые узлы не найдены». В этой ситуации остановите 3-й узел и подождите несколько секунд. Затем установите базовую топологию вручную с помощью числовой версии топологии кластера следующим образом:

control.sh --baseline version topologyVersion

В приведенной выше команде замените версию топологии фактической версией топологии. Вы можете найти версию топологии в любой консоли узла Ignite, как показано ниже:

Topology snapshot [ver=6, servers=3, clients=0, CPUs=8, offheap=9.6GB, heap=3.0GB]

Выберите последнюю версию снимка топологии с консоли.

На этом этапе наш третий узел Ignite не является частью нашей базовой топологии. Этот узел не будет использоваться для постоянного хранения данных. Это означает, что если мы создадим какие-либо новые таблицы и вставим в них данные, узел не будет хранить данные для новой таблицы. Давайте проверим концепцию.

Шаг 7 Создайте новую таблицу DEPT с помощью следующего сценария DDL:

CREATE TABLE IF NOT EXISTS DEPT (
deptno LONG,
dname VARCHAR,
loc VARCHAR,
CONSTRAINT pk_dept PRIMARY KEY (deptno)
) WITH "template=partitioned,CACHE_NAME=DEPTcache";

Также добавьте 100 отделов, используя DEPT.SQL. Скрипт DEPT.SQL доступен в репозитории GitHub .

0: jdbc:ignite:thin://127.0.0.1/> !run /PATH_TO_THE_FILE/github/the-apache-ignite-book/ch\ apters/chapter-10/baseline/DEPT.sql

Теперь запустите кеш команды -a в консоли visor, которая должна напечатать аналогичный вывод, показанный на рисунке 6.

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

Шаг 8 Далее, давайте добавим новый пустой узел в базовую топологию для хранения данных персистентности. Вызвать команду –baseline add

добавить новый узел к существующей базовой линии.

control.sh --baseline add 3c2ad09d-c835-4f4b-b47a-43912d04d30e

В приведенной выше команде замените непротиворечивый идентификатор 3c2ad09d-c835-4f4b-b47a-43912d04d30 на свой постоянный идентификатор 3-го узла зажигания. После выполнения команды –baseline add появится сообщение, подтверждающее, что новая базовая топология содержит 3 узла.

Cluster state: active
Current topology version: 10
Baseline nodes:
ConsistentID=1640f655-4065-438c-92ca-478b5df91def, STATE=ONLINE 
ConsistentID=3c2ad09d-c835-4f4b-b47a-43912d04d30e, STATE=ONLINE 
ConsistentID=d8b04bc3-d175-443c-b53f-62512ff9152f, STATE=ONLINE
-------------------------------------------------------------------------------- Number of baseline nodes: 3
Other nodes not found.

После формирования новой базовой топологии из 3 узлов перебалансировка данных начнется немедленно. Новый пустой узел (в нашем случае это третий узел) получит свою часть данных от других узлов. Если вы снова запустите команду cache -a в CLI Ignite Visor, вы можете подтвердить перебалансировку данных. На рисунке 7 показан результат перебалансировки данных после добавления 3-го узла в базовой топологии.

Теперь каждый узел хранит практически равномерный раздел записей (около 300 записей) для кэширования EMPcache. Однако что произойдет, если один из узлов базовой топологии будет перезапущен? Остановим один узел и попробуем вставить некоторые данные в таблицу EMP.

Шаг 9 Остановите 2-й узел, нажав клавишу CRTL + X. Выполните команду –baseline без каких-либо параметров, чтобы вывести состояние базовой топологии.

control.sh --baseline

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

-------------------------------------------------------------------------------- 
Cluster state: active
Current topology version: 11
Baseline nodes:
ConsistentID=1640f655-4065-438c-92ca-478b5df91def, STATE=OFFLINE 
ConsistentID=3c2ad09d-c835-4f4b-b47a-43912d04d30e, STATE=ONLINE 
ConsistentID=d8b04bc3-d175-443c-b53f-62512ff9152f, STATE=ONLINE
-------------------------------------------------------------------------------- 
Number of baseline nodes: 3
Other nodes not found

Один из узлов в автономном режиме, как и ожидалось. Теперь попробуйте вставить некоторые данные в таблицу EMP с помощью инструмента SQLLINE следующим образом:

insert into EMP (empno, ename, job, mgr, hiredate, sal, comm, deptno) values (2009, 'Sall\ ie', 'Sales Associate', 96, null, 3619, 34, 78);
insert into EMP (empno, ename, job, mgr, hiredate, sal, comm, deptno) values (2010, 'Cori\ ', 'Human Resources Manager', 65, null, 1291, 86, 57);
insert into EMP (empno, ename, job, mgr, hiredate, sal, comm, deptno) values (2011, 'Myrt\ le', 'VP Quality Control', 88, null, 5103, 21, 48);
insert into EMP (empno, ename, job, mgr, hiredate, sal, comm, deptno) values (2012, 'Ches\ ', 'Desktop Support Technician', 46, null, 6352, 29, 21);

Вы должны заметить, что несколько операторов вставки не с ошибками, которые показаны в следующем фрагменте.

Caused by: class org.apache.ignite.internal.cluster.ClusterTopologyServerNotFoundExceptio\ n: Failed to map keys for cache (all partition nodes left the grid).
at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSing\ leUpdateFuture.mapSingleUpdate(GridNearAtomicSingleUpdateFuture.java:562)

Эта ошибка произошла, потому что у нас нет резервных копий для нашей таблицы EMP. Узел, который должен хранить данные, был остановлен, и Ignite не может сохранить данные. Чтобы избежать такой ситуации, рассмотрим кеш / таблицу с одной резервной копией. Если один узел выходит из строя, он не потеряет данные. На данный момент у нас есть несколько вариантов:

Перезагрузите автономный узел как можно скорее с минимальным временем простоя для предотвращения потери данных.
Удалите автономный узел из базовой топологии и перебалансируйте данные.

Шаг 10 Давайте удалим автономный узел из базовой топологии. Выполните следующую команду:

Caused by: class control.sh --baseline remove 1640f655-4065-438c-92ca-478b5df91def

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

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

В дополнение к управлению топологией сценарий control.sh также может использоваться для мониторинга и управления состоянием кластера, что хорошо задокументировано на сайте Ignite. Поэтому, пожалуйста, обратитесь к разделу сценария управления документации Ignite для получения дополнительной информации.

Опубликовано на Java Code Geeks с разрешения Шамима Бхуияна, партнера нашей программы JCG. См. Оригинальную статью здесь: Apache Ignite Baseline Topology в примерах

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

Apache Ignite Baseline Topology на примерах

Категории

Последние статьи

Рефакторинг Hudson God Class

Альтернативы синтаксиса Java лямбда

Morphia и MongoDB: развивающиеся структуры документов

OpenShift Express: развертывание приложения Java EE (с поддержкой AS7)

Интеграция jqGrid, REST, AJAX и Spring MVC