Что такое vStack Center
vStack Center — плоскость управления кластером «Гиперконвергентная инфраструктура vStack» (далее — vStack HCP). Через него администратор создаёт виртуальные центры обработки данных (ВЦОД), сети и виртуальные машины (ВМ), выдаёт роли, смотрит журнал событий безопасности и метрики. Сами ВМ выполняет гипервизор на узлах кластера. vStack Center держит эталонное состояние кластера и решает, что и где должно работать.
vStack HCP — зонтичный продукт из двух частей: vStack Center отвечает за управление, vStack OS — за операционную систему узлов с гипервизором и слоем хранения. vStack Center не трогает узлы напрямую. Он передаёт задание компоненту Cluster Manager, а тот доводит его до узлов. Разделение видно в поведении API: операция над ВМ — это не одна запись в базу, а обмен между vStack Center и агентами на узлах.
Кластер под управлением vStack Center работает самостоятельно. Отдельный продукт GI собирает несколько кластеров в федерацию и проксирует к ним запросы, но кластер об этом не знает: набор методов и правила доступа остаются теми же.
Два компонента
vStack Center собран из двух служб. Одна принимает запросы снаружи, вторая их исполняет.
| Компонент | Что делает | С чем работает |
|---|---|---|
cluster-endpoint | HTTPS-endpoint кластера. Принимает HTTP POST с телом JSON-RPC 2.0, кладёт запрос в очередь, ждёт ответ и отдаёт его клиенту. Держит cookie-сессии. Проксирует WebSocket к консоли ВМ | RabbitMQ, браузер клиента |
dispatcher-cluster | Ядро vStack Center. Читает запросы из очереди, проверяет права, ведёт учёт сущностей и асинхронных операций, маршрутизирует работу к агентам | PostgreSQL, SQLite, InfluxDB, Cluster Manager через ZMQ |
Клиент видит только первый компонент — один HTTPS-адрес и один формат тела. Всё остальное скрыто за очередью.
Путь запроса
Клиент → cluster-endpoint (HTTPS) → RabbitMQ → dispatcher-cluster → PostgreSQL / SQLite / InfluxDB
│ ZMQ
└→ Cluster Manager → узлы кластера (AMQP)
Клиент → cluster-endpoint (WSS) → VNC-сервер ВМ
Из схемы следуют два практических вывода. Первый: cluster-endpoint
не хранит состояние прикладных операций, поэтому его можно перезапускать
и масштабировать отдельно от ядра. Второй: трафик консоли ВМ идёт мимо очереди —
по WebSocket, напрямую через endpoint к VNC-серверу машины.
Один протокол на всё
vStack Center говорит только на JSON-RPC 2.0: у каждой операции есть имя, свой набор аргументов и однородный ответ. Веб-панель ходит тем же путём, что и собственный клиент, — отдельного интерфейса «для панели» в vStack Center нет. Отсюда следствие: то, что администратор делает мышью, воспроизводимо и программно, поэтому у пошаговых страниц этой документации в конце перечислены методы API для тех же операций.
Ответ на операцию устроен одинаково для всех методов. Успех приходит с полезной нагрузкой конкретной операции — объектом, массивом или одним значением. Отказ приходит с числовым кодом; коды сгруппированы по методам, поэтому по номеру видно, где именно запрос остановился. Формат запроса и ответа описан в справочнике — «Обзор API».
Сессия
Диспетчер не берёт личность вызывающего из транспорта. Он опознаёт его по токену
сессии: веб-панель получает токен при входе и предъявляет его при каждой
операции, собственный клиент делает то же сам. Запрос без токена диспетчер
отклоняет до прикладной логики, с кодом -9494 («No session token»).
Отдельная ветка — принудительная смена пароля. Пользователю с таким признаком вместо обычной сессии выдаётся одноразовый доступ на 5 минут, и до смены пароля работают только она сама и чтение политики паролей. Поэтому панель сразу показывает форму нового пароля, а остальные разделы открываются после неё. Формат токенов и поля ответов описаны в справочнике — «Аутентификация».
Кто что видит
Права в vStack Center описываются ролью и её областью — кластер или конкретный ВЦОД. Секции методов формулируют доступ в этих же терминах: «Cluster master — любая ВМ кластера», «обычный пользователь — только ВМ из ВЦОД, к которым назначены роли».
| id | Роль | Область |
|---|---|---|
| 1 | Cluster Master | Полный доступ ко всему кластеру |
| 2 | vDC Admin | Администратор ВЦОД |
| 3 | vDC User | Пользователь ВЦОД |
| 4 | vDC Viewer | Наблюдатель ВЦОД |
| 5 | Resource Viewer | Просмотр ресурсов кластера |
| 6 | Security Admin | Уровень кластера: журнал безопасности и аудит |
| 7 | VM Developer | Уровень ВЦОД: создание и настройка виртуальных машин |
Управляющие операции над ВЦОД, то есть создание, изменение и удаление, доступны
только Cluster Master. Работа внутри ВЦОД раздаётся ролями 2–4 и 7. Роли 6 и 7
появились в 3.0.3.
Синхронные и асинхронные методы
Часть методов отвечает сразу, потому что читает или пишет только базу. Так
работает, например, vm-console: он выдаёт данные подключения без обращения
к узлу. Другая часть методов отвечает после того, как работу подтвердит агент.
vms-create проходит длинную цепочку: валидация параметров, выбор пула,
запись в базу, передача Storage-агенту для создания zvol-ов, затем передача
VM-агенту для регистрации. Клиент получает ответ после двухфазной обработки
callback-ов, и в ответе лежит полное описание созданной ВМ. vms-start
устроен так же: метод отправляет команду агенту, а финальный ответ приходит
через callback и содержит data.node_id — узел, на котором ВМ запустилась.
Практический вывод: клиент должен уметь ждать. Таймаут запроса нужно считать не от скорости базы, а от времени реальной операции на узле.
Что важно знать заранее
Запрос без токена сессии не будет обработан. Причина: диспетчер определяет
вызывающего только по токену сессии, транспортные заголовки для этого
не используются. Обход: предъявляйте токен в каждом прикладном вызове, иначе
ответ придёт с кодом -9494.
Часть операций завершается позже, чем возвращается ответ. Причина: работу выполняют агенты на узлах, диспетчер лишь дожидается их callback-ов. Обход: ориентируйтесь на финальный ответ метода, а не на первый, и держите таймаут клиента с запасом.
Невидимый образ ОС отвечает «не найден», а не «доступ запрещён». Причина:
существование приватного образа чужого ВЦОД не подтверждается — при попытке
выбрать его vms-create возвращает -256. Обход: берите общекластерный образ
(is_cluster_shared) или запросите для своего ВЦОД грант видимости на нужный.
Что дальше
Сквозной путь от входа до работающей ВМ собран в быстром старте: создание ВЦОД, назначение сети, создание и запуск машины, подключение к консоли.