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

Приложение¶

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

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

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

Для определения состояния кластера можно использовать следующие способы:

• отправить HTTP-запрос к любому из узлов кластера на заданный адрес обработчика запроса (endpoint);

• просмотреть состояние кластера в веб-интерфейсе Cartridge на вкладке TCF.

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

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

• Cluster A: активный кластер Tarantool, на который перенаправляются запросы от приложения.

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

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

TCF-координатор¶

За автоматическое переключение состояния отвечает отдельная роль в каждом кластере – TCF-координатор. Чтобы обеспечить отказоустойчивость, в каждом кластере должно быть запущено два и более экземпляра Tarantool с этой ролью.

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

Данные с активного на пассивный кластер реплицируются по протоколу 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).

• TCF Gateway (B->A) и TCF Destination (B->A): Gateway и Destination, которые начинают реплицировать данные на Cluster A если Cluster B стал активным.

В каждый момент времени репликация может идти только в одном направлении.

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

etcd: распределенное хранилище, которое хранит информацию о состояниях кластеров и позволяет оповестить внешний балансировщик о смене активного кластера.

Ручная смена состояния¶

Ручная смена состояния кластера позволяет проводить технические работы и изменения логики работы приложения без простоя. Например, вы можете выполнить HTTP POST-запрос на адрес /tcf/toggle любого TCF-координатора, чтобы поменять состояния кластеров на противоположные.

Автоматическая смена состояния¶

Автоматическая смена состояния кластеров позволяет минимизировать негативные последствия при различных инцидентах.