Примеры инвентарей

Здесь собраны примеры файлов инвентаря inventory.yml для различных продуктов, используемых в тестах. Эти файлы содержат пример конфигурации инвентаря для каждого продукта.

Статический инвентарь — это вручную созданный текстовый файл со списком хостов, групп и переменных.

Инвентарь для генератора — это файл для инвентарного плагина коллекции, который на основе описанных в нём данных формирует список хостов, групп и переменных.

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

Сценарии для приложений и продуктов на основе Tarantool 3.x Enterprise Edition приведены в разделе Tarantool 3.x. Пример инвентаря для централизованного хранилища конфигурации на основе Tarantool приведен в разделе Tarantool-based Configuration Storage.

Централизованное хранилище конфигурации на основе Tarantool, TbCS (Tarantool-based Configuration Storage), используется с кластерами на основе Tarantool 3.x. Подробная информация о таком типе хранилища приведена в документации Tarantool: Централизованное хранилище конфигурации.

Сценарии для работы с TCM приведены в разделе Tarantool Cluster Manager.

Информация о настройке TCF и сценарии для работы с этим продуктом приведены в разделе Tarantool Clusters Federation.

Топология репликаторов данных между кластерами (Gateway и Destination) формируется автоматически на основе описания кластеров в инвентаре. Указывать её вручную необязательно -- автоматическая настройка покрывает типовые случаи. При необходимости топологию можно задать вручную.

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

Информация о настройке TCS и сценарии для работы с этим продуктом приведены в разделе Tarantool Column Store.

Не работает для версии TCS 1.1 и выше

Информация о настройке Tarantool DB и сценарии для работы с этим продуктом приведены в разделе Tarantool DataBase.

Tarantool DB (RESP) начиная с версии 2.1.0 Sentinel является отдельной ролью tdb_redis_sentinel (на базе встроенного stateboard) и больше не переопределяет failover-координатор; порт Sentinel задаётся настройкой port роли tdb_redis_sentinel (старая sentinel_port роли tdb_redis_role удалена).

Роль tdb_redis_sentinel работает на базе Tarantool-based Configuration Storage (читает config.storage), поэтому кластер TDB RESP обязан использовать его (не etcd) как централизованное хранилище конфигурации. Пример ниже предполагает, что TbCS уже развёрнут.

В модели с отдельными узлами экземпляры Sentinel и Redis разворачиваются в разных наборах реплик. На наборе реплик хранения укажите roles: ["tdb_redis_role"], а для Sentinel выделите отдельный набор реплик с roles: ["tdb_redis_sentinel"] и нужным числом экземпляров (рекомендуется 3 — для кворума). Поскольку роль tdb_redis_sentinel читает состояние экземпляров из stateboard, ей не обязательно работать на тех же узлах, что и Redis.

Тот же кластер в модели с отдельными узлами можно описать инвентарём для генератора. Для этого укажите product: tdb_redis. Роли задаются так же, как в статическом инвентаре: на наборе реплик хранения — tdb_redis_role, на наборе реплик Sentinel — tdb_redis_sentinel. Порт каждой роли генератор назначает автоматически (по умолчанию 6379 для Redis и 26379 для Sentinel); при необходимости начало диапазона можно изменить через port_starts.redis и port_starts.sentinel на уровне сервера или компонента.

В co-located-модели роли задаются не в config.replicaset.roles, а в tarantool_config_global.roles секции constants.

Сценарии для работы с TQE приведены в разделе Tarantool Queue Enterprise (MQ).

Сценарии для работы с Tarantool CDC приведены в разделе Tarantool Change Data Capture.

Для использования генератора инвентаря укажите product: CDC и задайте параметры обработчика CDC в секции config компонента.

Ниже приведён пример инвентарей для топологии TDB (5 шардов) → TQE (3 шарда) → PostgreSQL. Для развертывания этой топологии необходимо три отдельных файла для генератора, которые комбинируются при запуске через несколько ключей --inventory:

 
ansible-playbook -i inventory_tdb_source.yml -i inventory_tqe.yml -i inventory_cdc.yml playbooks/install.yml

Стандартный инвентарь Tarantool DB, используемый в качестве источника данных для CDC. Для корректной работы репликации CDC необходимо включить расширенный формат WAL (wal.ext.old: true, wal.ext.new: true).

Инвентарь TQE для использования с CDC. gRPC-сервер TQE используется обработчиком CDC для подключения к очереди.

Конфигурация ниже актуальна для CDC 0.12.0+.

Для топологии через TQE используются два обработчика CDC:

1. Source-обработчик — читает данные из TDB (TarantoolConnector) и записывает в очередь TQE (TQESinkConnector);
2. Sink-обработчик — читает данные из очереди TQE (TQESourceConnector) и записывает в PostgreSQL (JdbcSinkConnector).

Оба обработчика хранят контрольные точки в TQE (storage.type: tqe).

В примере ниже для топологии TDB (5 шардов) → TQE (3 шарда) → PostgreSQL используются пять обработчиков источника CDC (по одному на каждый шард TDB) и один обработчик приёмника CDC.

Параметры, общие для любого инвентаря CDC:

• В параметре cdc_worker_port каждого обработчика укажите уникальный порт сервера для подключения приложения, чтобы избежать конфликтов при запуске нескольких обработчиков на одном сервере.
• В параметре cdc_source_connector_params.connect.targets укажите адрес узла соответствующего набора реплик TDB-источника.
• В параметре cdc_source_connector_params.replication.id укажите уникальный идентификатор репликации для каждого обработчика.
• В параметре cdc_sink_connector_params.connection.url укажите JDBC-URL приёмника PostgreSQL.
• Для корректного обнаружения плагинов (TQESinkConnector, TQESourceConnector, JdbcSinkConnector) укажите cdc_source_connector_package_name: "" и cdc_sink_connector_package_name: "" — это заставит сканер плагинов искать во всех подкаталогах бандла. Требуется бандл tarantool-cdc-jar-bundle версии 0.11.0 и выше (содержит debezium-connector-jdbc).
• Если spaces.include не указан, CDC реплицирует все пространства источника. Укажите список пространств для выборочной репликации.

Специфично для топологии через TQE:

• В параметре cdc_sink_connector_params.target source-обработчика укажите адрес gRPC-сервера TQE (совпадает с grpc_host:grpc_port из инвентаря TQE).
• В параметре cdc_source_connector_params.target sink-обработчика укажите тот же адрес gRPC-сервера TQE.
• И source-, и sink-обработчики хранят контрольные точки в TQE (storage.type: tqe).

Ниже приведён пример инвентарей для топологии TDB (5 шардов) → PostgreSQL (без TQE). Для развертывания этой топологии необходимо два отдельных файла для генератора:

 
ansible-playbook -i inventory_tdb_source.yml -i inventory_cdc.yml playbooks/install.yml

Инвентарь TDB-источника аналогичен инвентарю из предыдущего примера (TDB → TQE → PostgreSQL: инвентарь для генератора).

Обработчик CDC читает данные из TDB через source-коннектор (TarantoolConnector), записывает в PostgreSQL через sink-коннектор (JdbcSinkConnector) и хранит контрольные точки в файле (storage.type: file).

Общие параметры CDC (cdc_worker_port, connect.targets, replication.id, connection.url, пакеты плагинов, spaces.include) описаны в предыдущем разделе (TDB → TQE → PostgreSQL: инвентарь для генератора).

Специфично для топологии без TQE:

• cdc_sink_connector_params каждого обработчика должен использовать JdbcSinkConnector для прямой записи в PostgreSQL.
• В параметре cdc_offset_params.storage.file.name укажите путь к файлу контрольных точек на целевом сервере. Путь должен быть доступен для записи пользователю, от имени которого запускается CDC (cdc_user).