Система построена по схеме кластера высокой готовности (High – Availability), состоящего из двух контроллеров и общего для них набора дисков. контроллеры связаны друг с другом прямым сетевым соединением, по которому выполняется определение работоспособности соседнего контроллера (Heartbeat) и пересылка данных. В проекте используется микросервисная архитектура. За пересылку сообщений между сервисами отвечает сервис RPC-router. При старте все сервисы регистрируются в RPC-router. После того, как сервис зарегистрировался, он может передавать и принимать сообщения, каждому сообщению назначается идентификатор – action_ID. При передаче сообщений используется протокол JSON-RPC. Обмен сообщениями между контроллерами кластера (нодами) также выполняется через сервисы PRC-router.
Для обмена сообщениями между контроллерами кластера выделен отдельный высокоскоростной сетевой интерфейс – интерконнект, состоящий из двух физических каналов, агрегированных в один логический канал.
На каждом контроллере работают по две независимых файловых системы, одна для быстрых пулов, другая для обычных пулов.
Файловые системы (ФС) контроллеров некластеризованные, то есть дисковые пулы, созданные этими ФС, не могут управляться ими одновременно с разных контроллеров кластера. Контроллер, управляющий пулом (и находящимися на нем томами), называется владельцем пула.
Кластер работает в режиме Active ALUA. Каждый из контроллеров кластера подключен к общему набору дисков (используются двухпортовые накопители SCSI или NVMe, однопортовые накопители и накопители стандарта SATA не поддерживаются) и владеет своими дисковыми пулами. Контроллеры постоянно включены и могут обслуживать клиентов. При этом используется многопутевое подключение (мультипассинг), при котором к каждому клиенту подключены одновременно два контроллера – один по оптимальному пути, второй по неоптимальному. В случае отказа одного контроллера рабочий узел импортирует себе дисковые пулы отказавшего контроллера и переключает рабочую нагрузку с оптимальных путей на неоптимальные, используя протокол ALUA.
ALUA, или Asymmetric Logical Unit Access, это протокол внутри спецификаций SCSI-2 и SCSI-3, позволяющий правильно организовывать доступ к данным, доступным по различным путям с различными характеристиками доступа. Для его использования понимать ALUA должны все участники, как система хранения, так и операционная система хоста.
За обнаружение отказа контроллера-партнера и принятие соответствующих мер для восстановления рабочей нагрузки отвечает сервис Heartbeat. Обнаружение отказа контроллера-партнера выполняется в два этапа: вначале отрабатывается прекращение взаимодействия через Ethernet соединение (интерконнект), далее проверяется отсутствие изменения данных со стороны контроллера-партнера на общих с ним дисковых накопителях (используется запись и чтение в специально выделенную область диска). В случае, если контроллер-партнер изменяет данные на диске (контроллер «жив»), сервис Heartbeat будет ожидать восстановления сетевого соединения через интерконнект, параллельно заблокировав возможность изменения конфигурации системы пользователем. В случае, если работоспособность контроллера-партнера не обнаружена (контроллер «мертв»), сервис Heartbeat инициирует процедуру миграции принадлежащих контроллеру-партнеру ресурсов на себя, импортируя дисковые пулы и переключая пути доступа блочных протоколов (через ALUA), а также поднимая у себя IP адреса сетевых интерфейсов контроллера-партнера для переключения сетевых шар (сетевых папок файловых систем). Информация о своих и чужих ресурсах (ресурсах контроллера-партнера) хранится в общей для кластера базе конфигурации.
Дополнительная проверка работоспособности контроллера-партнера проводится во избежание ситуации, при которой оба контроллера кластера будут использовать одни и те же пулы, вызывая этим порчу данных. Такая ситуация называется split brain.
Конфигурация кластера хранится в синхронизируемой между контроллерами кластера базе конфигурации. За предоставление параметров конфигурации и их обновление отвечает сервис Config Keeper. В качестве хранилища используется БД Sqlite. На каждом контроллере БД конфигурации хранит информацию о конфигурации своего и соседнего контроллеров. При изменении конфигурации своего контроллера сервис Config Keeper реплицирует изменения в БД конфигурации соседнего контроллера, постоянно поддерживая согласованность конфигурации кластера.
Отслеживать