Общая структура кластера¶
Компоненты¶
- Aeron MediaDriver - локальный брокер сообщений (UDP, SHM)
- CPVM node - компонент Runtime, основной связующий элемент системы. Каждый узел Runtime может выполнять 2 функции:
- Application Server (AppServer) - реализация внешнего HTTP API
- CPVM module - основная бизнес-логика системы: планировщик задач, управление воркерами, балансировка нагрузки, устранение кофнликтов TVM итд
- CPVM worker - компонент Runtime, отвечающий за исполнение фрагментов
- TVM - Transation Value Manager. "In memory" хранилище с определением "конфликтов" параллельного доступа. Инстансы TVM нужно размещать как можно ближе к нодам CPVM, т.к. между ними происходит синхронный (в пределах исполнения фрагмента) обмен данными. Задержки обмена сообщениями между CPVM и TVM - основная причина низкой производительности "транзакционных" фрагментов.
- IO_service - слой stateless сервисов, вспомогательная система для TVM, которая выполняет IO операции. Выделен в отдельную сущность для масштабирования.
- FragSeq (FragmentSequence) - обрабатывает отчеты TVM об обнаруженных зависимостях и формирует ЯПФ/LPF (ярусно-параллельная форма).
- A_Storage - основное хранилище данных и метаинформации системы. Выполняет функции:
- хранилище кода, фрагментов (CB - Code Base).
- хранилище метаинформации для PTS
- хранилище логов выполнения
- хранилище структуры данных системы FragSeq - ЯПФ/LPF
- хранилище информации для биллинга (PaaS).
- информация фронтенда, требуемая LK (в личном кабинете)
- Сonsul node - координация вышеперечисленных сервисов
Структура кластера Runtime¶
Кластер CPVM состоит из множества "CPVM node", попарно соединенных в произвольную топологию.
Ограничений на количество связей между узлами нет, топология может и, скорее всего, должна быть полносвязной (балансировка
нагрузки лучше всего работает в полносвязной топологии).
Узлы CPVM не имеют четко обозначеных "ролей", каждый узел может выполнять любой функционал из арсенала достпных модулей.
![cpvm master_quorum](/galleries/page_images/cpvm master_quorum.png)
Zero-downtime обновление кластера Runtime (vm5)¶
Требования: Reverse-proxy для группы AppServer как минимум один запущенный AppServer и еще одна произволная нода (c AppServer или без).
- Имеется запущенный кластер рантайма, где все узлы имеют старую версию. Лучшая стратегия - "канареечные" обновления, когда единовременно обновляется только часть кластера.
- Выбираем узлы для остановки. Помещаем на них бинарные файлы новой версии рантайма.
- Посылаем им команду
POST /managment/update
, указывая в параметрах путь к обновленной версии рантайма. - Выбранные узлы перестают принимать новые задачи. Когда все задачи выполняются, runtime node запускает специальный процесс-updater и останавливает все свои процессы. Как только процесс-updater фиксирует полную остановку старой версии рантайма, он запускает новую, после чего завершается.
- Следить за ходом выполнения сего действа можно через
GET /managment/status
(указывается нужный nodeid). - Ноды новых версий могут автоматически соединится с нодами старых версий (если адреса не поменялись), но почти никак не будут взаимодействовать если произошли изменения в протоколе. В Runtime нет такого понятия как "версия протокола", вместо этого есть автоматические "snapshot"-ы протокола rpc-интерфейсов (фича ajrpc2). Ноды не выясняют кто из них новее или старше, а просто детектируют частичную или полную несовместимость (неэквивалентность снапшотов) и отказываются взаимодейтсвовать. Это позволяет не поддерживать совместимость всех протоколов рантайма, и ломать схему взаимодействия при каждом обновлении без каких-либо последствий.
- Новые ноды рантайма гарантировано вступают в работу как только появляется хотя бы один AppServer новой версии.