Компоненты платформы необходимо развертывать на физических серверах (bare-metal).

Установка на виртуальные машины допустима только в демонстрационных целях, но при этом должна быть включена вложенная виртуализация (nested virtualization). Если платформа развернута на виртуальных машинах, техническая поддержка не предоставляется.

Возможности масштабирования платформы

Платформа поддерживает следующую конфигурацию:

  • Максимальное количество узлов: 1000.
  • Максимальное количество виртуальных машин: 50000.

Минимальные требования к платформе

В зависимости от архитектуры, для корректной работы платформы требуются следующие минимальные ресурсы:

Архитектура Запуск нагрузки Master-узел Worker-узел Системный узел Frontend-узел
Одноузловая платформа
(Single Node / Edge)		 На одном узле 3 vCPU
10 ГБ ОЗУ		 — — —
Многоузловая платформа
(1 master-узел + worker-узлы)		 На всех узлах 6 vCPU
6 ГБ ОЗУ		 2 vCPU
4 ГБ ОЗУ		 — —
Трёхузловая платформа
(3 master-узла, High Availability)		 На всех узлах 6 vCPU
14 ГБ ОЗУ		 — — —
Платформа с выделенными worker-узлами
(3 master-узла + worker-узлы)		 Только на worker-узлах 5 vCPU
11 ГБ ОЗУ		 2 vCPU
5 ГБ ОЗУ		 — —
Распределённая архитектура Только на worker-узлах 4 vCPU
9 ГБ ОЗУ		 1 vCPU
2 ГБ ОЗУ		 4 vCPU
10 ГБ ОЗУ		 1 vCPU
2 ГБ ОЗУ

Выбор архитектуры платформы подробно описан в разделе Архитектурные решения.

Требования к аппаратному обеспечению

Deckhouse Virtualization Platform не накладывает дополнительных ограничений и совместима с любым оборудованием, поддерживаемым операционными системами, на которые она может быть установлена.

Требования к программному и аппаратному обеспечению

Требования к аппаратному обеспечению для Deckhouse Virtualization Platform совпадают с требованиями, предъявляемыми к Deckhouse Kubernetes Platform, с дополнительным требованием поддержки виртуализации CPU на хостах, где будут запускаться виртуальные машины.

Дополнительные требования для поддержки виртуализации

На всех узлах кластера, где планируется запуск виртуальных машин, необходимо обеспечить поддержку аппаратной виртуализации:

  • CPU — поддержка инструкций Intel-VT (VMX) или AMD-V (SVM);
  • BIOS/UEFI — включена поддержка аппаратной виртуализации в настройках BIOS/UEFI.

Обеспечение стабильной работы механизмов живой миграции требует использования идентичной версии ядра Linux на всех узлах кластера.

Это связано с тем, что различия в версиях ядра могут привести к несовместимости интерфейсов, системных вызовов и особенностей работы с ресурсами, что может нарушить процесс миграции виртуальных машин.

Поддерживаемые гостевые ОС

Платформа виртуализации поддерживает операционные системы, работающие на архитектурах x86 и x86_64, в качестве гостевых ОС. Для корректной работы в режиме паравиртуализации необходимо установить драйверы VirtIO, обеспечивающие эффективное взаимодействие между виртуальной машиной и гипервизором.

Успешный запуск операционной системы определяется следующими критериями:

  • корректная установка и загрузка ОС;
  • бесперебойная работа основных компонентов, таких как сеть и хранилище;
  • отсутствие сбоев или ошибок в процессе работы.

Для операционных систем семейства Linux рекомендуется использовать образы гостевых ОС с поддержкой cloud-init, что позволяет выполнять инициализацию виртуальных машин после их создания.

Для операционных систем семейства Windows платформа autounattend установки.

Поддерживаемые конфигурации виртуальных машин

  • Максимальное число поддерживаемых ядер: 248.
  • Максимальный объем оперативной памяти: 1024 Гб.
  • Максимальное количество подключаемых блочных устройств: 16.

Поддерживаемые хранилища

Диски виртуальных машин создаются на основе ресурсов PersistentVolume. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть развернуто одно или несколько поддерживаемых хранилищ:

Хранилище Расположение дисков
sds-local-volume Локальное
sds-replicated-volume Реплики на узлах кластера
Ceph-кластер Внешнее хранилище
NFS (Network File System) Внешнее хранилище
TATLIN.UNIFIED (Yadro) Внешнее хранилище
Huawei Dorado Внешнее хранилище
HPE 3par Внешнее хранилище
NetApp Внешнее хранилище

Распределение компонентов по узлам кластера

Распределение компонентов по узлам кластера зависит от его конфигурации. Например, в кластере могут присутствовать:

  • только master-узлы, для запуска компонент плоскости управления и нагрузки;
  • только master-узлы и worker-узлы;
  • master-узлы, system-узлы и worker-узлы;
  • другие комбинации (в зависимости от архитектуры).

Под worker-узлами понимаются узлы, на которых нет ограничений (taints), мешающих запуску обычной рабочей нагрузки (подов, виртуальных машин).

В таблице приведены основные компоненты control plane модуля virtualization и узлы, на которых они могут быть размещены. Компоненты распределяются по приоритету — если в кластере есть подходящий тип узлов, компонент будет размещён на нём.

Название компонента Группа узлов Комментарий
cdi-operator-* system/worker  
cdi-apiserver-* master  
cdi-deployment-* system/worker  
virt-api-* master  
virt-controller-* system/worker  
virt-operator-* system/worker  
virtualization-api-* master  
virtualization-controller-* master  
virtualization-audit-* system/worker  
dvcr-* system/worker На узле должно быть доступно хранилище
virt-handler-* Все узлы кластера  
vm-route-forge-* Все узлы кластера  

Компоненты для создания и загрузки (импорта) образов или дисков виртуальных машин (они запускаются только на время создания или загрузки):

Название компонента Группа узлов Комментарий
importer-* system/worker  
uploader-* system/worker