2.4. Роли

2.4. Роли

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

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

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

  • connector – прием запросов по сети на обработку;

  • input_processor – обработка запроса;

  • storage – хранение данных (обработанных объектов);

  • 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

нет

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

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

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

  1. Роли connector, input_processor, task_runner и output_processor задействованы в обработке объектов. Их нужно горизонтально масштабировать пропорционально входящей нагрузке и утилизации CPU на серверах.

  2. Если вы создаете на инстансе роль connector или input_processor, обычно рекомендуется создать на этом же инстансе и вторую роль из этой пары. Исключение может быть в случае, когда первоначальная обработка объекта на роли connector является трудозатратной операцией и имеет смысл масштабировать эту роль отдельно.

  3. Роль storage (хранит состояние, не singleton): создание репликесета с нодами в разных дата-центрах. Количество репликасетов (горизонтальное масштабирование) — пропорционально объему данных, хранимых в RAM.

    Важно

    Если инстансу назначена роль storage, то после этого исключить (expel) из кластера этот инстанс будет нельзя.

  4. Роли logger, notifier, scheduler (хранят состояние, singleton): обычно достаточно репликасета с 2 нодами, разнесенными по разным дата-центрам.

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