Обзор архитектуры Inscale

Платформа построена как набор слабосвязанных микросервисов поверх распределённого хранилища состояния. Такой подход обеспечивает горизонтальное масштабирование и устойчивость к отказам отдельных узлов.

Три уровня платформы

Уровень вычислений

Гипервизор KVM/QEMU на каждом узле: запуск ВМ, живая миграция, управление ресурсами CPU/RAM.

Control Plane

Микросервисы оркестрации, планировщик размещения и распределённый кворум состояния.

Доставка (VDI)

Брокер сессий и протокол IDP для подключения тонких клиентов к рабочим столам.

Control Plane

Control plane состоит из независимых служб, общающихся через шину событий. Состояние кластера хранится в распределённом хранилище с кворумом по алгоритму Raft. Управление построено по модели event sourcing: каждое изменение фиксируется как событие, что обеспечивает воспроизводимость и аудит.

Служба	Назначение
api-gateway	Единая точка входа REST API, аутентификация и rate-limiting.
scheduler	Планирование размещения ВМ по узлам с учётом ресурсов и политик.
vdi-broker	Балансировка и назначение сессий рабочих столов пользователям.
state-store	Распределённое хранилище желаемого и текущего состояния.

Декларативная модель

Ресурсы платформы описываются декларативно. Контроллеры непрерывно сверяют желаемое состояние с текущим и приводят систему к заданному виду — это называется циклом согласования (reconciliation loop).

// Упрощённый контроллер согласования пула рабочих столов
func (c *PoolController) Reconcile(ctx context.Context, pool Pool) error {
    desired := pool.Spec.Size.Min
    current := c.runningDesktops(pool)

    if current < desired {
        // не хватает рабочих столов — провижионим новые
        return c.provision(ctx, pool, desired-current)
    }
    if current > pool.Spec.Size.Max {
        return c.reclaim(ctx, pool, current-pool.Spec.Size.Max)
    }
    return nil
}

API-first

Веб-консоль не имеет привилегированного доступа к данным — она работает поверх того же REST API, что доступен администраторам. Любой сценарий можно автоматизировать через CLI или REST API.

Поток управления

1. Запрос

   Клиент отправляет декларативный манифест в api-gateway. Запрос проходит аутентификацию и валидацию схемы.

2. Фиксация

   Желаемое состояние записывается в state-store как событие. Событие реплицируется на все узлы кворума.

3. Согласование

   Контроллер обнаруживает расхождение между желаемым и текущим состоянием, планирует действия через scheduler.

4. Исполнение

   Агент узла применяет изменения на гипервизоре, сообщает новый статус обратно в state-store.

Сетевая модель

Inscale использует многоуровневую сетевую архитектуру:

Сеть	Назначение	Рекомендуемая пропускная способность
Управляющая	Control plane, API, метрики	1 Гбит/с
Storage	Репликация хранилища	10 Гбит/с
VDI	Протокол доставки рабочих столов IDP	1 Гбит/с
VM	Трафик виртуальных машин	1–10 Гбит/с

Изолируйте сети

Разделение управляющего и storage-трафика на разные физические интерфейсы значительно повышает производительность при высокой нагрузке на хранилище.

Масштабирование

Платформа поддерживает горизонтальное масштабирование без единой точки отказа:

• Control plane масштабируется до 5 узлов (кворум Raft). Добавление CP-узлов не требует остановки кластера.
• Worker-узлы добавляются онлайн — ВМ автоматически перераспределяются планировщиком.
• Хранилище поддерживает репликацию 2x/3x и striping для увеличения производительности.

Максимальный проверенный масштаб: 512 worker-узлов, 16 000 одновременных ВМ в одном кластере.