Общая структура кластера

Компоненты

cluster

  • 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 или без).

  1. Имеется запущенный кластер рантайма, где все узлы имеют старую версию. Лучшая стратегия - "канареечные" обновления, когда единовременно обновляется только часть кластера.
  2. Выбираем узлы для остановки. Помещаем на них бинарные файлы новой версии рантайма.
  3. Посылаем им команду POST /managment/update, указывая в параметрах путь к обновленной версии рантайма.
  4. Выбранные узлы перестают принимать новые задачи. Когда все задачи выполняются, runtime node запускает специальный процесс-updater и останавливает все свои процессы. Как только процесс-updater фиксирует полную остановку старой версии рантайма, он запускает новую, после чего завершается.
  5. Следить за ходом выполнения сего действа можно через GET /managment/status (указывается нужный nodeid).
  6. Ноды новых версий могут автоматически соединится с нодами старых версий (если адреса не поменялись), но почти никак не будут взаимодействовать если произошли изменения в протоколе. В Runtime нет такого понятия как "версия протокола", вместо этого есть автоматические "snapshot"-ы протокола rpc-интерфейсов (фича ajrpc2). Ноды не выясняют кто из них новее или старше, а просто детектируют частичную или полную несовместимость (неэквивалентность снапшотов) и отказываются взаимодейтсвовать. Это позволяет не поддерживать совместимость всех протоколов рантайма, и ломать схему взаимодействия при каждом обновлении без каких-либо последствий.
  7. Новые ноды рантайма гарантировано вступают в работу как только появляется хотя бы один AppServer новой версии.