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

Здесь собраны примеры файлов инвентаря 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.

Все примеры ниже, кроме раздела «Динамический инвентарь с TCM», приведены для статического инвентаря.

В примере ниже TCM подключается к собственному etcd по TLS с проверкой сертификата сервера (tcm_etcd_tls_ca_file) и клиентским сертификатом (tcm_etcd_tls_cert_file/tcm_etcd_tls_key_file — требуется, если на etcd включён --client-cert-auth). TLS для подключения TCM к etcd управляемого кластера настраивается независимо — блоком tls в etcd-connection записи кластера, а TLS к экземплярам кластера (iproto) — блоком ssl в tarantool-connection записи кластера.

Обратите внимание на различие имён: для etcd используется блок tls и ключ trusted-ca-file, для Tarantool-подключений (TbCS, iproto) — блок ssl и ключ ca-file. Провайдер собственного хранилища TCM и провайдер хранилища кластера независимы: например, TCM может хранить своё состояние в TbCS (пример с TbCS), а конфигурация кластера — в etcd, как в примере ниже.

TCM обслуживает веб-интерфейс и API по HTTPS на том же адресе и порту (tcm_host:tcm_port). Сертификат и ключ — серверные. Проверка клиентских сертификатов (mTLS) для этого подключения не поддерживается, параметра ca-file у секции http.tls нет. При включённом HTTPS рекомендуется установить tcm_http_websession_cookie_secure: true; плейбуку tcm_add_tbcs при этом нужен tcm_api_scheme: https (по умолчанию http) — иначе он обратится к API по http и не подключится.

Генератор сформирует в tcm_initial_clusters блок etcd-connection.tls (с ключом trusted-ca-file) из tarantool_config_etcd_ssl_* и блок tarantool-connection.ssl (с ключом ca-file) из tarantool_iproto_ssl_params. Для хранилища конфигурации на TbCS TLS задаётся в params конечных точек tarantool_config_storage_endpoints, а собственное хранилище TCM на TbCS — переменными tcm_tarantool_ssl_* в секции tcm: (tcm_storage_provider: tarantool).

Вариант предыдущего примера с хранилищем конфигурации на TbCS. TLS к TbCS управляемого кластера задаётся в params конечных точек tarantool_config_storage_endpoints в constants: (генератор создаст storage-connection.tarantool-connection.ssl), а TLS собственного хранилища TCM на TbCS — переменными tcm_tarantool_ssl_* в секции tcm: (tcm_storage_provider: tarantool; TLS включается транспортом, ключа enabled у секции storage.tarantool.ssl нет).

Генератор сформирует в tcm_initial_clusters блок storage-connection.tarantool-connection.ssl (с ключом ca-file) из params первой TLS-точки tarantool_config_storage_endpoints и блок tarantool-connection.ssl для iproto-подключения из tarantool_iproto_ssl_params. SSL-блок един для всех конечных точек TbCS; учётные данные TCM берутся из tarantool_config_storage_username/ tarantool_config_storage_password (login/password внутри точки используются экземплярами, а не TCM). Подробности — в разделе Автоматическая генерация TLS в initial_clusters.

Информация о настройке 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 уже развёрнут.

Начиная с версии 2.1.0 в состав дистрибутива TDB RESP входят штатные роли Tarantool для экспорта метрик — roles.httpd и roles.metrics-export. Эти роли не применяются автоматически: чтобы включить экспорт метрик, добавьте обе роли в список roles кластерной конфигурации и задайте адрес и порт HTTP-сервера (параметр roles_cfg.roles.httpd.default.listen; в динамическом инвентаре генератор назначает порт каждому экземпляру автоматически). Метрики доступны по адресу http://<хост>:<порт>/metrics/prometheus в формате Prometheus. Примеры ниже показывают конфигурацию с включённым экспортером метрик.

В модели с отдельными узлами экземпляры 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 на уровне сервера или компонента.

Роли метрик включаются так же, как в статическом инвентаре: добавьте roles.httpd и roles.metrics-export в config.replicaset.roles. Порт HTTP-сервера roles.httpd генератор назначает каждому экземпляру автоматически (по умолчанию начиная с 8081); начало диапазона можно изменить через port_starts.http на уровне сервера или компонента. Явно задавать roles_cfg.roles.httpd.default.listen не нужно: значение уровня набора реплик будет переопределено сгенерированным портом экземпляра. Настройки экспортера — путь и формат endpoint'а — задаются в config.replicaset.roles_cfg.roles.metrics-export и применяются ко всем экземплярам набора реплик одинаково.

В 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).