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

В этой главе приводятся рекомендации и инструкции по настройке кластерных ролей на экземплярах TDG.

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

• Core: настройка и администрирование.
• Storage: проверка и хранение данных.
• Runner: исполнение бизнес-логики с помощью кода на Lua.
• Connector: обмен данными с внешними системами.

Подробная информация о кластерных ролях приведена в разделе Кластерные роли главы Архитектура.

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

• Роль core: все экземпляры должны быть объединены в один набор реплик для обеспечения отказоустойчивой работы ядра TDG. В кластере может быть только один набор реплик с ролью core.
• Роль storage: для обеспечения распределения (sharding) и резервирования экземпляры должны объединяться в наборы реплик из двух и более экземпляров. Точное число экземпляров в наборе реплик определяется требованиями бизнес-решения к избыточности хранения данных. Для большей надёжности рекомендуется объединять в каждом наборе реплик экземпляры из разных дата-центров. Количество наборов реплик storage следует масштабировать горизонтально пропорционально объему данных.
• Роль runner: все экземпляры runner эквивалентны и не хранят состояние, поэтому нет необходимости объединять их в наборы реплик. Количество экземпляров runner следует масштабировать горизонтально в зависимости от входящей нагрузки и утилизации CPU.
• Роль connector: все экземпляры connector эквивалентны и не хранят состояние, поэтому нет необходимости объединять их в наборы реплик. Количество экземпляров connector следует масштабировать горизонтально в зависимости от входящей нагрузки и утилизации CPU.
• Объединение ролей connector и runner: обычно имеет смысл назначать роли connector и runner на экземпляры вместе. Таким образом минимизируется сетевое взаимодействие при обработке входящих объектов или вызове сервисов извне.

Для настройки кластерных ролей через веб-интерфейс TDG используются инструменты на вкладке Cluster.

Чтобы назначить роль экземпляру впервые, найдите его в списке Unconfigured Instances и нажмите соответствующую кнопку Configure.

В открывшемся окне вы можете назначить роль одним из двух способов:

• Создать новый набор реплик с нужными ролями. Для этого введите имя нового набора реплик, выберите необходимые роли и нажмите Create replica set.

  

• Добавить экземпляр в существующий набор реплик. Для этого перейдите на вкладку Join replica set, выберите один из существующих наборов реплик с необходимыми ролями и нажмите Join replica set.

  

Чтобы изменить роли набора реплик, откройте окно его редактирования (Edit replica set) и включите или отключите роли. Эти изменения применятся ко всем экземплярам выбранного набора реплик.

Если вы разворачиваете кластер TDG с помощью Ansible, вы можете определить наборы реплик и их роли в inventory-файле [hosts.yml]{.title-ref}.

Наборы реплик и их роли определяются в inventory-файле в разделе all.children.

Для каждого набора реплик необходимо создать узел с именем replicaset_<name>, где <name> - название, под которым набор реплик будет использоваться в кластере. Пример создания набора реплик с именем storage_01:

 
all:   children:    replicaset_storage_01:

В узле набора реплик задаются два раздела:

• vars - параметры набора реплик, в том числе параметр roles - список назначенных ролей.
• hosts - список узлов, входящих в набор реплик.

Пример конфигурации набора реплик с ролью storage из двух узлов:

 
all:   children:    replicaset_storage_01:      vars:  # replica set configuration        replicaset_alias: storage-01        weight: 1        failover_priority:          - storage-01  # leader          - storage-01-r        roles:          - 'storage'

Конфигурация кластера из пяти узлов с тремя наборами реплик (два storage и один с ролями core, runner, connector) может выглядеть следующим образом:

 
all:   children:    replicaset_storage_01:      vars:  # replica set configuration        replicaset_alias: storage-01        weight: 1        failover_priority:          - storage-01  # leader          - storage-01-r        roles:          - 'storage'      hosts:   # replica set instances        storage-01:        storage-01-r:    replicaset_storage_02:      vars:  # replica set configuration        replicaset_alias: storage-02        weight: 1        failover_priority:          - storage-02  # leader          - storage-02-r        roles:          - 'storage'      hosts:   # replica set instances        storage-02:        storage-02-r:    replicaset_app_01:      vars:  # replica set configuration        replicaset_alias: app-01        failover_priority:          - app-01  # leader        roles:          - 'core'          - 'connector'          - 'runner'