2.4. Роли

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 нет

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

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

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

  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 выше).