Архитектура | Tdg

Версия:

2.x
Архитектура

Архитектура

В этой главе описывается архитектура Tarantool Data Grid.

Основные архитектурные компоненты TDG изображены на схеме ниже.

Архитектурная диаграмма

Как видно из схемы, различные аспекты работы TDG разделены по соответствующим кластерным ролям: Storage, Connector, Runner и Core. Каждый экземпляр (узел) в кластере может иметь одну или более ролей. Подробнее о кластерных ролях рассказывается в разделе Кластерные роли.

Хранение данных: Tarantool

Для хранения данных в TDG используется распределённое хранилище Tarantool. Его функциональность включает:

  • хранение данных в оперативной памяти;

  • репликацию данных в рамках набора реплик (replicaset);

  • шардирование данных (сегментирование, sharding) по разным экземплярам.

Таким образом, TDG обеспечивает «из коробки» распределённое, высокопроизводительное, отказоустойчивое и масштабируемое хранение данных.

Кроме того, в TDG доступны другие функции хранения данных, такие как:

Доступ к данным: GraphQL и REST API

Для доступа к данным TDG используются два основных способа: GraphQL и REST API.

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

Точки доступа создаются автоматически на основе модели данных и доступных сервисов. Эти сервисы также можно вызывать через GraphQL и REST API.

Исполнение бизнес-логики: Lua

TDG предоставляет возможность хранения и исполнения пользовательской бизнес-логики, например, валидации или преобразования данных.

Для добавления необходимой бизнес-логики нужно реализовать её в виде функций на языке Lua и загрузить их в TDG.

Загруженные функции можно использовать несколькими способами:

  • Вызывать извне. Для этого нужно добавить их в конфигурацию доступных сервисов. Такие сервисы доступны для вызова через GraphQL, REST API или iproto (бинарный протокол Tarantool).

  • Привязать к коннектору. В этом случае функции будут вызываться при каждом взаимодействии через этот коннектор, например, при поступлении нового объекта.

  • Выполнять по расписанию. Для этого в TDG есть планировщик задач, который позволяет настроить автоматическое выполнение пользовательской бизнес-логики.

Взаимодействие с внешними системами

Для обмена данными с внешними системами в TDG используются коннекторы. Коннекторы бывают двух типов: входящие (input) для получения данных извне и исходящие (output) для отправки данных из TDG.

Коннекторы позволяют обмениваться данными с такими источниками как:

  • Apache Kafka;

  • Oracle Database и другие базы данных, поддерживающие ODBC;

  • HTTP;

  • Файлы;

  • Бинарный протокол Tarantool (iproto).

Администрирование и безопасность

TDG предоставляет инструменты для управления различными техническими функциями, в том числе:

  • топологией кластера;

  • моделью данных;

  • сервисами;

  • коннекторами;

  • настройками безопасности.

Для управления конфигурацией TDG доступны два способа:

  • Веб-интерфейс (WebUI) позволяет управлять TDG в визуальном режиме в браузере;

  • Конфигурационные файлы позволяют хранить и распространять конфигурации в виде готовых артефактов.

Для мониторинга и расследования инцидентов TDG предоставляет метрики кластера в формате Prometheus. Метрики доступны для получения через REST API и визуализации в Grafana.

Встроенные инструменты безопасности TDG позволяют настроить доступ к различным функциям для пользователей и внешних систем. Для этого используется ролевая модель доступа. Роли могут быть приписаны как к профилям (для настройки доступа пользователей), так и к токенам приложений – средству авторизации приложений для взаимодействия с TDG. Для расследования инцидентов безопасности доступен журнал аудита.

Кластерные роли

Экземпляры TDG в кластере выполняют те или иные функции в соответствии с назначенными им кластерными ролями. Каждый экземпляр может иметь одну или несколько ролей.

В TDG существует четыре основных кластерных роли:

  • Core: настройка и администрирование.

  • Storage: проверка и хранение данных.

  • Runner: исполнение бизнес-логики с помощью кода на Lua.

  • Connector: обмен данными с внешними системами.

Еще одна кластерная роль, failover-coordinator, позволяет включать режим восстановления после сбоев с сохранением состояния (stateful failover). Подробности можно найти в документации Tarantool Cartridge.

Кластерные роли назначаются наборам реплик (replica set). Каждый экземпляр получает роли того набора реплик, в который он входит. В каждом наборе реплик все экземпляры взаимозаменяемы: на них хранится одно и то же состояние. Таким образом обеспечивается резервирование и устойчивость к сбоям.

Архитектура кластерных ролей

Роль Core

Роль core используется для выполнения собственных функций TDG. Экземпляры с этой ролью обеспечивают управление моделью данных, сервисами, настройками безопасности и доступа и другими функциями. На этих экземплярах хранится внутренняя информация TDG и не хранятся пользовательские данные.

В кластере может быть только один набор реплик с ролью core.

Роль Storage

Роль storage используется для хранения пользовательских данных. На экземплярах с этой ролью создаются спейсы Tarantool в соответствии с моделью данных.

Объединение экземпляров storage в наборы реплик обеспечивает шардирование и репликацию данных: каждый набор реплик хранит своё подмножество данных (shard), и это подмножество реплицируется на все экземпляры набора реплик.

Количество наборов реплик Storage определяется объемом хранимых данных.

Роль Runner

Роль runner используется для выполнения пользовательской бизнес-логики. На этих экземплярах с помощью встроенного в Tarantool Lua-интерпретатора выполняются загруженные в TDG пользовательские скрипты: сервисы, задачи, обработчики входящих и исходящих данных.

Экземпляры runner не хранят состояние и используются только для исполнения кода. Таким образом, они все эквивалентны, и объединение в наборы реплик не влияет на их функциональность.

Роль Connector

Роль connector используется для сетевого взаимодействия с внешними системами. На экземплярах с этой ролью создаются адреса (endpoints) для обращения к кластеру через GraphQL и REST API, а также коннекторы для подключения по различным протоколам: HTTP (JSON или SOAP), Apache Kafka или iproto.

Экземпляры connector не хранят состояние и используются только для внешних подключений. Таким образом, они все эквивалентны, и объединение в наборы реплик не влияет на их функциональность.

Нашли ответ на свой вопрос?
Обратная связь