2.4. Роли¶

В кластере функции инстансов распределяются на основе ролей. Кластерные роли — это Lua-модули, которые реализуют специфическую для инстанса логику.

Существуют 2 вида ролей: встроенные и пользовательские (настраиваемые). Встроенные роли, vshard-router и vshard-storage, и логика их работы уже определены в Tarantool Enterprise, на базе которого построена система TDG, и не требуют дополнительной конфигурации. Логику работы пользовательских ролей необходимо дополнительно сконфигурировать. Это выполняется администратором.

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

connector — прием запросов по сети на обработку;
input_processor — обработка запроса;
storage — хранение данных (обработанных объектов);
account_manager — обеспечение работы ролевой модели доступа;
logger — сбор логов (со всех инстансов всех ролей);
notifier — отправка нотификаций о событиях в ремонтной очереди;
output_processor — преобразование объекта в формат сторонней системы и отправка объекта в эту систему;
task-runner — выполнение задач;
scheduler — старт задач (по расписанию или вручную) на инстансе с ролью task-runner;
frontend — служит для загрузки статического расширения пользовательского интерфейса.

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

Пользовательская роль	Автоматически подключаемые роли
connector	vshard-router, tracing
input_processor	vshard-router, tracing
storage	vshard-router, vshard-storage, tracing
logger	vshard-router
notifier	vshard-router, tracing
output_processor	vshard-router, tracing
scheduler	vshard-router, tracing
task_runner	vshard-router, tracing
frontend	vshard-router

2.4.1. Рекомендации по назначению ролей на инстансах¶

Хотя в системе нет понятия «обязательная роль», имеет смысл говорить о минимально необходимом наборе ролей — connector, input_processor, storage, который обеспечивает основные функции системы — получение объекта, его обработку и хранение в системе. Остальные роли назначаются по необходимости, в зависимости от решаемых бизнес-задач.

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

по концепции хранения состояния: не хранят состояние (stateless) / хранят состояние (stateful);
по количеству экземпляров в кластере: singleton / произвольное количество экземпляров.

Роль	Stateless / Stateful	Singleton
connector	stateless	нет
input_processor	stateless	нет
storage	stateful	нет
logger	stateful	да
notifier	stateful	да
output_processor	stateless	нет
scheduler	stateful	да
task_runner	stateless	нет

Все роли являются реплицируемыми (репликасет с ролью может содержать более одной ноды).

На одном инстансе можно назначить одну или несколько ролей.

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

Роли connector, input_processor, task_runner и output_processor задействованы в обработке объектов. Их нужно горизонтально масштабировать пропорционально входящей нагрузке и утилизации CPU на серверах.
Если вы создаете на инстансе роль connector или input_processor, обычно рекомендуется создать на этом же инстансе и вторую роль из этой пары. Исключение может быть в случае, когда первоначальная обработка объекта на роли connector является трудозатратной операцией и имеет смысл масштабировать эту роль отдельно.
Роль storage (хранит состояние, не singleton): создание репликесета с нодами в разных дата-центрах. Количество репликасетов (горизонтальное масштабирование) — пропорционально объему данных, хранимых в RAM.

Важно

Если инстансу назначена роль storage, то после этого исключить (expel) из кластера этот инстанс будет нельзя.
Роли logger, notifier, scheduler (хранят состояние, singleton): обычно достаточно репликасета с 2 нодами, разнесенными по разным дата-центрам.
Роль output_processor не хранит состояние напрямую. Функционально роль реплицирует объекты во внешние системы, но для хранения объектов, предназначенных для репликации, а также объектов, чья репликация завершилась с ошибкой, используется роль storage. Поэтому логика горизонтального масштабирования роли output_processor аналогична логике для ролей, используемых для обработки объектов (см. п.1 выше).