- 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.
Комментариев нет:
Отправить комментарий