Архитектура¶

Tarantool Clusters Federation (TCF) позволяет построить отказоустойчивую систему из двух кластеров Tarantool. В такой системе один из кластеров является активным и принимает все запросы от приложения. Второй кластер является пассивным и содержит копию данных активного кластера.

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

Поддерживаемые типы кластеров
Обзор работы TCF

Поддерживаемые типы кластеров¶

TCF поддерживает следующие типы кластеров Tarantool и продуктов на его основе:

кластер Tarantool 2.x на основе Cartridge;
кластер Tarantool 3.x Enterprise Edition (EE);
кластер Tarantool Data Grid на основе Tarantool 2.x;
кластер Tarantool DB 1.x на основе Tarantool 2.x;
кластер Tarantool DB 2.x на основе Tarantool 3.x;
кластер Tarantool Column Store на основе Tarantool 3.x.

Начиная с версии 0.7.0, TCF поддерживает кластеры Tarantool, запущенные в режиме синхронной репликации. Межкластерная репликация при этом работает в асинхронном режиме. Узнать больше: Работа TCF с кластерами, запущенными в режиме синхронной репликации.

Обзор работы TCF¶

Данная диаграмма демонстрирует взаимодействие компонентов TCF между собой:

Основные компоненты TCF

TCF включает следующие компоненты:

Приложение (Client app на диаграмме выше)
Внешний балансировщик (Load balancer)
Активный и пассивный кластеры (Cluster A и Cluster B)
- TCF-координатор
- TCF-worker
Репликаторы данных (TCF Gateway и TCF Destination)
Хранилище состояния кластеров (etcd или Tarantool-based configuration storage)

На диаграмме цифрами обозначены элементы и участники взаимодействия в TCF:

1 – DML-пользователь;
2 – служебный пользователь репликации данных;
3 – взаимодействие через gRPC-протокол. В gRPC-конфигурации нет пользователей: в конфигурации Gateway указывается адрес для приёма входящих gRPC-запросов от Destination. В конфигурации Destination указывается тот же адрес, что и в Gateway, на который компонент отправляет gRPC-запросы. Внешние подключения не предполагаются. Разграничение доступа можно обеспечить через TLS и выдачу компонентам сертификатов для безопасного взаимодействия друг с другом. Подробнее про настройку TLS-соединения см. Конфигурация репликаторов данных;
4 – пользователь хранилища состояния кластеров: etcd или Tarantool-based configuration storage.

Приложение¶

Client app: приложение, отправляющее запросы на активный кластер Tarantool через внешний балансировщик. Данное приложение устанавливает соединение с кластером от имени пользователя, у которого есть необходимые права на чтение и запись в кластер.

Внешний балансировщик¶

Load balancer: внешний балансировщик, выполняющий переключение трафика между приложением и кластерами Tarantool. Балансировщик отправляет все запросы на адреса роутеров активного кластера. При штатной работе трафик от приложения на роутеры пассивного кластера не направляется. Для определения состояния кластера необходимо отправить HTTP-запрос к любому из узлов кластера на заданный адрес обработчика запроса.

При активном кластере HTTP-ответ содержит код 200 и строку active. При пассивном — также код 200, но со строкой passive. При наличии неполадок возможны другие коды ответа из диапазонов 4xx или 5xx. Балансировщик должен направлять запросы только на активный кластер, то есть на узлы, возвращающие строку active, и не отправлять запросы на пассивные или неработоспособные кластеры, идентифицируемые по строке passive или по ошибочным HTTP-кодам.

Активный и пассивный кластеры¶

TCF в типичной конфигурации содержит два идентичных кластера - активный и пассивный:

Cluster A: активный кластер Tarantool, на который перенаправляются запросы от приложения;
Cluster B: пассивный кластер Tarantool, который содержит копию данных активного кластера, но не принимает запросы от приложения.

Кластеры хранят свое состояние в централизованном хранилище. Состояние кластеров может быть изменено вручную или автоматически.

Технологические роли¶

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

TCF-координатор – отвечает за автоматическое переключение состояния. Чтобы обеспечить отказоустойчивость, в каждом кластере должно быть запущено два и более экземпляра Tarantool с этой ролью. Назначается выборочным экземплярам типа storage и router в кластере Tarantool, которыми управляет TCF. Смотрите также: Смена состояния кластеров;
TCF-worker – инициализирует и координирует переключение статусов кластеров (активный ↔ пассивный) и предоставляет базовый HTTP API для управления TCF. Назначается всем экземплярам типа storage и router в кластере Tarantool, которыми управляет TCF.

Подробнее о настройке технологических ролей читайте в разделе Конфигурация кластера в YAML (Tarantool 3.x).

Репликаторы данных¶

Данные с активного кластера на пассивный реплицируются по протоколу gRPC в асинхронном режиме с помощью пары Gateway/Destination (шлюз/приемник):

Gateway: подключается к активному кластеру в режиме анонимной реплики для получения потока транзакций. Поток транзакций сериализуется в gRPC.
Destination: подключается к Gateway по gRPC и запрашивает поток транзакций. Destination десериализует поток транзакций и записывает их в пассивный кластер по протоколу iproto.

На диаграмме выше присутствуют две пары Gateway/Destination:

TCF Gateway (A->B) и TCF Destination (A->B): Gateway и Destination, которые используются для репликации данных из Cluster A в Cluster B, когда Cluster A является активным;
TCF Gateway (B->A) и TCF Destination (B->A): Gateway и Destination, которые используются для репликации из Cluster B в Cluster A, когда Cluster B становится активным.

Направление репликации определяется конфигурацией репликаторов данных. Если адреса Gateway/Destination не указаны в конфигурации, репликация выполняется в обе стороны. Если адреса заданы, переключение кластера в пассивный режим останавливает соответствующую пару. Односторонняя репликация снижает риск конфликтов, двусторонняя — компенсирует отставания асинхронной репликации.

Например, в случае сбоев на активном кластере (включая полную временную недоступность), активным становится текущий пассивный кластер, но из-за асинхронности не гарантируется, что он содержит все актуальные данные. После восстановления старый активный кластер возвращается в систему как пассивный. Если в его WAL остались непереданные данные, при двусторонней репликации они будут доставлены на новый активный кластер; при односторонней — нет, так как пассивный кластер не инициирует передачу данных.

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

Хранилище состояния кластеров¶

Для работы TCF требуется внешний state provider – централизованное хранилище, которое хранит информацию о состояниях кластеров.

TCF поддерживает два типа такого хранилища:

etcd: распределенное хранилище типа ключ-значение;
Tarantool-based configuration storage: хранилище, состоящее из набора реплик Tarantool.

Версия: