Схема компонентов¶
Компоненты кластера¶
Кластер TCS может включать в себя следующие компоненты:
Узлы Storage – для хранения данных и обработки запросов на чтение/запись
Узлы Scheduler – для маршрутизации запросов на экземпляры Storage
Узлы Coordinator – для управления переключением в случае сбоя экземпляров Storage
etcd – для хранения и управления конфигурацией кластера
Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером
Состав кластера TCS зависит от режима работы кластера: проксированный или шардированный.
В проксированном режиме типовой кластер TCS состоит из следующих компонентов:
Storage: один набор реплик из нескольких узлов (1 мастер-экземпляр + 1 или больше экземпляров-реплик), развернутый на 1 или более серверах – для хранения данных и обработки запросов на чтение/запись
Scheduler: (необязательно без шардирования) один набор реплик из 1 и более узлов – для маршрутизации запросов на экземпляры Storage
Coordinator: (необязательно) по 1 экземпляру на каждый сервер с развернутыми экземплярами Storage – для управления переключением в случае сбоя экземпляров Storage
(необязательно) etcd – для хранения и управления конфигурацией кластера
(необязательно) Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером
В шардированном режиме кластер TCS состоит из аналогичных компонентов, но со следующими отличиями:
в кластере может быть больше одного набора реплик с узлами типа Storage
наличие набора реплик с узлами типа Scheduler становится обязательным
Наборы реплик TCS¶
Наборов реплик с экземплярами Scheduler и Storage может быть несколько.
Любой набор реплик TCS можно разворачивать как на одном сервере, так и на нескольких серверах.
Клиентское приложение может устанавливать соединение с любым экземпляром в наборе реплик (Scheduler или Storage), по любому поддерживаемому TCS протоколу (HTTP, JDBC/ADBC). Однако тип экземпляров, доступных клиентам для прямого подключения, зависит от режима работы кластера TCS:
в режиме проксирования – Scheduler (если они присутствуют в кластере) и Storage
в режиме шардирования – только Scheduler
Все запросы принимаются в формате SQL.
Для обработки запросов на экземплярах Storage используется одинаковая логика. Конвейер обработки запроса включает в себя:
парсер SQL-запросов
кеш физических планов (для аналитических расчетов)
планировщик с оптимизатором
исполнитель плана запроса
В режиме шардирования тот же конвейер обработки действует также на экземплярах Scheduler.
Наборы реплик Storage¶
В набор реплик Storage входят экземпляры двух видов:
мастер-экземпляр (может быть только один)
экземпляры-реплики (любое количество от 0 до 30)
Все экземпляры Storage в наборе реплик работают с одинаковым набором данных, поскольку все экземпляры-реплики связаны процессом непрерывной репликации с мастер-экземпляром. Других видов движения данных, кроме репликации, между экземплярами нет.
Запросы на чтение данных могут обрабатываться на всех экземплярах. Запросы на запись/изменение данных – только на мастер-экземпляре. Поэтому при установлении прямого соединения с экземпляром Storage из клиентского приложения следует явно выбирать экземпляр Storage, на котором будут выполняться запросы в рамках сессии. Если для обработки запроса на чтение/модификацию данных выбран экземпляр-реплика, то в ответ вернется ошибка.
Внимание
Во избежание ошибок, в режиме шардирования прямое подключение к экземплярам Storage должно быть запрещено в конфигурации.
Наборы реплик Scheduler¶
Экземпляры Scheduler осуществляют автоматическую маршрутизацию запросов на экземпляры Storage.
Экземпляры Scheduler являются stateless-компонентами, т.е. хранение данных на экземплярах Scheduler не осуществляется.
В одном наборе реплик может быть любое количество узлов типа Scheduler (от 1 до 31).
Наборы реплик Coordinator¶
Для отказоустойчивости в кластер TCS рекомендуется добавлять координаторы обработки сбоев (failover coordinator) из расчета 1 экземпляр Coordinator на каждый сервер с развернутыми экземплярами Storage. Один координатор должен быть активным, остальные – пассивными.
Координаторы следят за состоянием всего кластера Storage, получая информацию об узлах хранилищ по прямому запросу состояния к экземплярам Storage. В случае сбоя активный координатор осуществляет аварийное переключение, выбирая один из экземпляров-реплик Storage и переводя его в режим RW. Переключение может настроено в ручном или автоматическом режиме.
Между собой координаторы связаны через etcd, получая мета-информацию об активном координаторе.
etcd¶
etcd позволяет централизованно хранить конфигурацию кластера и управлять ей.
На основе etcd построено управление кластером с помощью ATE и TCM.
Рекомендованный вариант установки TCS – с файлом конфигурации, хранящимся в etcd.
См. подробнее Первичная установка системы.
Для тестовых целей возможна установка кластера TCS с локальным файлом конфигурации.
TCM¶
TCM предоставляет веб-инерфейс, который позволяет отслеживать состояние набора реплик TCS,
а также управлять конфигурацией кластера (как альтернатива etcd).
Взаимодействие TCM с конфигурацией кластера TCS идет только через etcd.
См. подробнее Управление кластером с помощью TCM.