Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Apache Ignite – это высокопроизводительная распределенная база данных с открытым исходным кодом, предназначенная для хранения и распределенной обработки больших объемов данных в кластере узлов. Мы в Сбере активно его используем, и у нас есть команда, занимающаяся разработкой этого продукта. 23 октября 2020 года вышла новая версия Apache Ignite 2.9.0. Как менеджер данного релиза от лица всей команды разработчиков Apache Ignite хочу поделиться информацией об основных нововведениях.
В Ignite 2.9.0 появилась возможность создания резервной копии всех сохраняемых на диске кэшей (то есть кэшей, работающих в режиме Ignite Native Persistence) со всего кластера. Снапшоты могут создаваться онлайн, на активном кластере с пользовательской нагрузкой. При этом создается полностью консистентная копия всех данных кластера.
Запустить создание резервной копии можно одним из следующих способов:
Где
После окончания формирования снапшота в директории
С более подробной информацией о работе со снапшотами вы можете ознакомиться в официальной документации.
Система мониторинга Ignite продолжает улучшаться, и одним из значимых нововведений в релизе 2.9 является подсистема трейсинга. Трэйсинг позволяет получить информацию, полезную как для отладки на этапе разработки, так и для анализа инцидентов. С помощью трейсинга появилась возможность собрать распределенную низкоуровневую информацию о ходе выполнения различных задач, запущенных в кластере, и использовать эту информацию для диагностирования проблем с производительностью. Трэйс, показывающий путь выполнения задачи в системе, формируется в виде дерева, каждый следующий уровень которого дает более детальную информацию чем предыдущий.
В Ignite 2.9.0 трэйсинг охватывает следующие внутренние компоненты:
Чтобы посмотреть трэйсы, их необходимо экспортировать во внешнюю систему. Для этих целей Ignite использует библиотеку OpenCensus, которая «из коробки» предоставляет несколько экспортеров в различные системы (например, в Zipkin).
Ограничить объем экспортируемой информации можно, задав один или несколько перечисленных выше компонентов в качестве области интересов (scope) и установив частоту сэмплирования (настройки доступны для изменения в runtime).
С более подробной информацией о трейсинге вы можете ознакомиться в официальной документации.
В тонких клиентах java и .NET появился функционал Ignite, который до этого был доступен только в толстом клиенте.
Была добавлена возможность использовать:
Кроме этого тонкий клиент .NET получил функцию автоматического обнаружения узлов кластера (Automatic Server Node Discovery), которая включается совместно с функционалом «осведомленность о партициях» (partition awareness). При использовании «осведомленности о партициях» клиент устанавливает соединение не с одним серверным узлом, а сразу с несколькими, для того чтобы по возможности отправить запрос на узел, который является основным для данных в этом запросе. Автоматическое обнаружение узлов кластера при этом позволяет не перечислять в конфигурации клиента все адреса узлов кластера. Достаточно чтобы клиент мог подключиться хотя бы к одному живому узлу, используя перечисленные в конфигурации адреса. Адреса остальных узлов клиент получит уже из кластера.
Подробнее об использовании новых возможностей можно узнать в соответствующих подразделах документации тонкого клиента java и тонкого клиента .NET.
До релиза 2.9.0 в Ignite было только два состояния кластера: кластер мог быть либо неактивным (узлы собирались в топологию, но любые действия с кэшами были запрещены), либо активным (разрешены любые действия). В релизе 2.9.0 было добавлено новое состояние кластера – «только чтение». Оно будет полезно для проведения некоторых работ в режиме обслуживания (например проверка целостности данных).
С более подробной информацией о состояниях кластера вы можете ознакомиться в официальной документации.
Ignite может запускать пользовательский код (такой как compute-задачи, слушатели событий, различные фильтры) на серверных узлах. Такой код выполнялся с теми же правами что и системный код Ignite и ему был доступен весь java API без ограничений. Потенциально опасный код мог нарушить работоспособность кластера (например, удалить файлы данных Ignite, завершить работу JVM и т.д.).
В версии 2.9.0 появилась возможность выполнения такого кода в «песочнице» с теми правами, которые были явно назначены субъекту доступа, запросившему исполнение этого кода (например клиентскому узлу). Права, назначенные субъекту доступа – это коллекция объектов класса
Для функционирования Ignite Sandbox необходимо наличие двух установленных и включенных компонентов:
С более подробной информацией об Ignite Sandbox вы можете ознакомиться в официальной документации.
Прозрачное шифрование данных (TDE – Transparent data encryption) – функционал, позволяющий не хранить данные на диске в открытом виде. Шифрование данных на диске средствами СУБД требуется, например, для сертификации по стандарту безопасности данных PCI DSS. В Apache Ignite базовый функционал TDE (первая фаза) был реализован в версии 2.7. В текущей версии была реализована вторая фаза TDE – ротация мастер-ключа (мастер-ключом зашифрованы хранящиеся на диске кэш-ключи). Третья фаза TDE (ротация кэш-ключей) будет реализована в следующем релизе.
С более подробной информацией о ротации мастер-ключа вы можете ознакомиться в официальной документации.
В предыдущих версиях Ignite не было целостного механизма прерывания пользовательских задач и запросов администратором. У пользователей была возможность отмены своих задач и запросов. Для администраторов были доступны отдельные, никак друг с другом не коррелирующие, инструменты (например, можно было прервать транзакции списком, по фильтру, через JMX или утилиту control.sh, и «убить» SQL-запрос с помощью SQL-команды
используя унифицированный интерфейс.
Все эти виды задач и запросов могут быть прерваны любым из следующих способов:
С более подробной информацией о прерывании пользовательских задач и запросов вы можете ознакомиться в официальной документации.
В Ignite.NET добавлена возможность использовать дополнительный кэширующий слой на стороне .NET-платформы. Данные в памяти .NET в этом слое сохраняются в десериализованном виде, соответственно считывать уже закэшированные данные можно без дополнительного JNI-вызова и десериализации. Благодаря этому скорость выполнения нетранзакционных операций чтения значительно увеличивается.
С более подробной информацией о кэшировании на стороне платформы вы можете ознакомиться в официальной документации.
В Ignite 2.9.0 появился режим сетевого взаимодействия, при котором соединения между «толстым» клиентом и сервером инициируются только на клиентской стороне (сервер не инициирует соединения к клиенту, но, при необходимости прямого взаимодействия с клиентом, просит клиента подключится к нему через уже установленные соединения клиента с другими серверами). Такой режим работы позволяет использовать конфигурации кластера, в которых между клиентскими и серверными узлами находится NAT (например, когда клиенты запущены в виртуальном окружении).
С более подробной информацией о подключении клиентских узлов через NAT вы можете ознакомиться в официальной документации.
Выше перечислены наиболее значимые изменения в релизе Apache Ignite 2.9.0. Но список изменений не ограничивается только ими. Как обычно, мы исправили множество ошибок и внесли множество других полезных улучшений. Полный список изменений можно посмотреть в release notes.
- Snapshots (Резервное копирование)
- Трэйсинг
- Новые возможности тонких клиентов
- Режим работы кластера «Только чтение»
- Запуск пользовательского кода в «песочнице»
- Прозрачное шифрование данных: ротация мастер ключа
- Инструменты для прерывания пользовательских задач и запросов
- Кэширование на стороне платформы (.NET)
- Подключение клиентских узлов к серверным через NAT
Snapshots (Резервное копирование)
В Ignite 2.9.0 появилась возможность создания резервной копии всех сохраняемых на диске кэшей (то есть кэшей, работающих в режиме Ignite Native Persistence) со всего кластера. Снапшоты могут создаваться онлайн, на активном кластере с пользовательской нагрузкой. При этом создается полностью консистентная копия всех данных кластера.
Запустить создание резервной копии можно одним из следующих способов:
- с помощью command-line утилиты control.sh:
control.sh --snapshot create <snapshot name>; - JMX операцией:
MBean group="Snapshot", name=SnapshotMXBeanImpl, операция createSnapshot(<snapshot name>); - через Java API:
Ignite.snapshot().createSnapshot("<snapshot name>").
Где
<snapshot name> – это уникальное имя снапшота.После окончания формирования снапшота в директории
work/snapshots/<snapshot name> (с настройками по умолчанию) каждого узла будет воссоздана структура файлового хранилища этого узла на момент старта снапшота. Сформированную файловую структуру можно использовать в дальнейшем для восстановления из резервной копии путем замены файлов с данными узла на файлы из директории снапшота. С более подробной информацией о работе со снапшотами вы можете ознакомиться в официальной документации.
Трэйсинг
Система мониторинга Ignite продолжает улучшаться, и одним из значимых нововведений в релизе 2.9 является подсистема трейсинга. Трэйсинг позволяет получить информацию, полезную как для отладки на этапе разработки, так и для анализа инцидентов. С помощью трейсинга появилась возможность собрать распределенную низкоуровневую информацию о ходе выполнения различных задач, запущенных в кластере, и использовать эту информацию для диагностирования проблем с производительностью. Трэйс, показывающий путь выполнения задачи в системе, формируется в виде дерева, каждый следующий уровень которого дает более детальную информацию чем предыдущий.
В Ignite 2.9.0 трэйсинг охватывает следующие внутренние компоненты:
- сообщения Discovery;
- сообщения Communication;
- процесс Exchange;
- транзакции.
Чтобы посмотреть трэйсы, их необходимо экспортировать во внешнюю систему. Для этих целей Ignite использует библиотеку OpenCensus, которая «из коробки» предоставляет несколько экспортеров в различные системы (например, в Zipkin).
Ограничить объем экспортируемой информации можно, задав один или несколько перечисленных выше компонентов в качестве области интересов (scope) и установив частоту сэмплирования (настройки доступны для изменения в runtime).
С более подробной информацией о трейсинге вы можете ознакомиться в официальной документации.
Новые возможности тонких клиентов
В тонких клиентах java и .NET появился функционал Ignite, который до этого был доступен только в толстом клиенте.
Была добавлена возможность использовать:
- cluster API & cluster group API (в .NET и java):
- изменение режимов работы кластера;
- получение информации о кластере;
- фильтрация, группировка и получение информации об узлах кластера;
- выполнение различных операций над группами узлов;
- compute API (в .NET и java):
- выполнение распределенных вычислений в кластере. В отличии от подобного функционала в толстом клиенте, который может использовать p2p class loader и сам автоматически загружать необходимые классы с клиента на серверные узлы, для запуска задачи тонким клиентом требуется чтобы весь исполняемый код уже был доступен в class-path серверных узлов (автоматическая загрузка классов с тонких клиентов не происходит);
- Service Grid (пока только в java):
- вызов сервисов Ignite. Как и в случае с compute API, тонким клиентом не предоставляется функционал по загрузке классов и развертыванию сервисов, возможен только вызов уже развернутых в кластере сервисов.
Кроме этого тонкий клиент .NET получил функцию автоматического обнаружения узлов кластера (Automatic Server Node Discovery), которая включается совместно с функционалом «осведомленность о партициях» (partition awareness). При использовании «осведомленности о партициях» клиент устанавливает соединение не с одним серверным узлом, а сразу с несколькими, для того чтобы по возможности отправить запрос на узел, который является основным для данных в этом запросе. Автоматическое обнаружение узлов кластера при этом позволяет не перечислять в конфигурации клиента все адреса узлов кластера. Достаточно чтобы клиент мог подключиться хотя бы к одному живому узлу, используя перечисленные в конфигурации адреса. Адреса остальных узлов клиент получит уже из кластера.
Подробнее об использовании новых возможностей можно узнать в соответствующих подразделах документации тонкого клиента java и тонкого клиента .NET.
Режим работы кластера «Только чтение»
До релиза 2.9.0 в Ignite было только два состояния кластера: кластер мог быть либо неактивным (узлы собирались в топологию, но любые действия с кэшами были запрещены), либо активным (разрешены любые действия). В релизе 2.9.0 было добавлено новое состояние кластера – «только чтение». Оно будет полезно для проведения некоторых работ в режиме обслуживания (например проверка целостности данных).
С более подробной информацией о состояниях кластера вы можете ознакомиться в официальной документации.
Запуск пользовательского кода в «песочнице»
Ignite может запускать пользовательский код (такой как compute-задачи, слушатели событий, различные фильтры) на серверных узлах. Такой код выполнялся с теми же правами что и системный код Ignite и ему был доступен весь java API без ограничений. Потенциально опасный код мог нарушить работоспособность кластера (например, удалить файлы данных Ignite, завершить работу JVM и т.д.).
В версии 2.9.0 появилась возможность выполнения такого кода в «песочнице» с теми правами, которые были явно назначены субъекту доступа, запросившему исполнение этого кода (например клиентскому узлу). Права, назначенные субъекту доступа – это коллекция объектов класса
java.security.Permission, которые проверяются java перед выполнением некоторых действий.Для функционирования Ignite Sandbox необходимо наличие двух установленных и включенных компонентов:
- Java security manager. Отвечает за авторизацию субъектов при выполнении вызовов системных java-библиотек. По умолчанию отключен;
- Ignite security processor. Отвечает за аутентификацию субъектов доступа. «Из коробки» с Ignite не поставляется, требуется самостоятельная реализация и подключение с помощью плагина.
С более подробной информацией об Ignite Sandbox вы можете ознакомиться в официальной документации.
Прозрачное шифрование данных: ротация мастер ключа
Прозрачное шифрование данных (TDE – Transparent data encryption) – функционал, позволяющий не хранить данные на диске в открытом виде. Шифрование данных на диске средствами СУБД требуется, например, для сертификации по стандарту безопасности данных PCI DSS. В Apache Ignite базовый функционал TDE (первая фаза) был реализован в версии 2.7. В текущей версии была реализована вторая фаза TDE – ротация мастер-ключа (мастер-ключом зашифрованы хранящиеся на диске кэш-ключи). Третья фаза TDE (ротация кэш-ключей) будет реализована в следующем релизе.
С более подробной информацией о ротации мастер-ключа вы можете ознакомиться в официальной документации.
Инструменты для прерывания пользовательских задач и запросов
В предыдущих версиях Ignite не было целостного механизма прерывания пользовательских задач и запросов администратором. У пользователей была возможность отмены своих задач и запросов. Для администраторов были доступны отдельные, никак друг с другом не коррелирующие, инструменты (например, можно было прервать транзакции списком, по фильтру, через JMX или утилиту control.sh, и «убить» SQL-запрос с помощью SQL-команды
KILL QUERY). В текущем релизе у администратора появилась возможность прерывать- различные виды запросов (SQL, scan, continous),
- транзакции,
- сompute-задачи,
- Ignite-сервисы,
используя унифицированный интерфейс.
Все эти виды задач и запросов могут быть прерваны любым из следующих способов:
- утилитой control.sh;
- через JMX;
- SQL-командой.
С более подробной информацией о прерывании пользовательских задач и запросов вы можете ознакомиться в официальной документации.
Кэширование на стороне платформы (.NET)
В Ignite.NET добавлена возможность использовать дополнительный кэширующий слой на стороне .NET-платформы. Данные в памяти .NET в этом слое сохраняются в десериализованном виде, соответственно считывать уже закэшированные данные можно без дополнительного JNI-вызова и десериализации. Благодаря этому скорость выполнения нетранзакционных операций чтения значительно увеличивается.
С более подробной информацией о кэшировании на стороне платформы вы можете ознакомиться в официальной документации.
Подключение клиентских узлов к серверным через NAT
В Ignite 2.9.0 появился режим сетевого взаимодействия, при котором соединения между «толстым» клиентом и сервером инициируются только на клиентской стороне (сервер не инициирует соединения к клиенту, но, при необходимости прямого взаимодействия с клиентом, просит клиента подключится к нему через уже установленные соединения клиента с другими серверами). Такой режим работы позволяет использовать конфигурации кластера, в которых между клиентскими и серверными узлами находится NAT (например, когда клиенты запущены в виртуальном окружении).
С более подробной информацией о подключении клиентских узлов через NAT вы можете ознакомиться в официальной документации.
Заключение
Выше перечислены наиболее значимые изменения в релизе Apache Ignite 2.9.0. Но список изменений не ограничивается только ими. Как обычно, мы исправили множество ошибок и внесли множество других полезных улучшений. Полный список изменений можно посмотреть в release notes.
