Аппаратные и программные требования к инфраструктуре

Аппаратные требования

Минимальные требования к аппаратному обеспечению

В данной таблице описаны минимальные требования рекомендуются для применения в стендах PoC, лабораториях по изучению продукта.

Требование	Сервер Control	Сервер Compute-FC	Сервер Compute-SDS	Сервер Compute-FC-SDS
Архитектура CPU	x86_64	x86_64	x86_64	x86_64
Количество CPU	2	2	2	2
Количество ядер одного CPU без учёта мультипоточности	10	2	2	2
Объём RAM, Гб	512	128	128	128
Системные диски	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)
Диски для данных	2x 800GB, Enterprise SSD MixUse (RAID1)	не требуется	не требуется	не требуется
Количество портов 10/25 Gbps Ethernet	4	4	6	6
Количество портов FC SAN (HBA)	2	2	0	2

Рекомендуемые требования для сценария «Классическая платформа виртуализации»

В данной таблице описаны рекомендуемые требования к аппаратному обеспечению для сценария «Классическая платформа виртуализации» при условии что количество гипервизоров не превышает 150 и количество виртуальных машин на одном гипервизоре не превышает 20.

Требование	Сервер Control	Сервер Compute-FC	Сервер Compute-SDS	Сервер Compute-FC-SDS
Архитектура CPU	x86_64	x86_64	x86_64	x86_64
Количество CPU	2	2	2	2
Количество ядер одного CPU без учёта мультипоточности	20	20	20	20
Объём RAM, Гб	1024	1024	1024	1024
Системные диски	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)	2x 480GB, Enterprise SSD MixUse (RAID1)
Диски для данных	2x 1.9TB, Enterprise SSD MixUse (RAID1)	не требуется	не требуется	не требуется
Количество портов 10/25 Gbps Ethernet	4	4	6	6
Количество портов FC SAN (HBA)	2	2	0	2

Примечание

Могут использоваться программные или аппаратные решения. Список поддерживаемых СХД приведён в разделе Драйверы Cinder.

Требования к инфраструктуре LCM

LCM (Lifecycle Manager) поддерживает два варианта установки:

• single-node — на одном узле;

• multi-node — в режиме высокой доступности на трёх Control-узлах, образующих Kubernetes-кластер на базе k0s. Этот режим обеспечивает отказоустойчивость самой системы управления жизненным циклом платформы.

Перед началом установки убедитесь, что инфраструктура подготовлена в соответствии со следующими требованиями:

multi-nodesingle-node

Серверы

Для развёртывания в режиме высокой доступности требуется три LCM-сервера. Минимальные требования к каждому:

• CPU — не менее 32 ядер.

• RAM — не менее 64 ГБ.

• Два SSD-диска (системный и дополнительный), не менее 240 ГБ каждый.

Диски

На каждом LCM-сервере требуется наличие следующих дисков:

• sda — системный диск с заранее установленной ОС.

• sdb — дополнительный диск без разделов; по умолчанию задействуется встроенным CSI (Ceph OSD).

  Предупреждение

  Дополнительный диск не должен быть локальным и не должен использовать Ceph в качестве бэкенда.

Сеть

Должны быть настроены сетевые интерфейсы: IP-адреса, маски подсети, маршруты на каждом сервере.

В DNS должны быть зарегистрированы следующие записи:

• vault.<lcm_name>.vm.lab.itkey.com

• nexus.<lcm_name>.vm.lab.itkey.com

• docker.<lcm_name>.vm.lab.itkey.com (указывает на nexus_vip)

• netbox.<lcm_name>.vm.lab.itkey.com

• gitlab.<lcm_name>.vm.lab.itkey.com

• grafana.<lcm_name>.vm.lab.itkey.com

• docs.<lcm_name>.vm.lab.itkey.com

• s3.<lcm_name>.vm.lab.itkey.com

• vmauth.<lcm_name>.vm.lab.itkey.com (указывает на grafana_vip)

• <lcm_name>-lcm-01.vm.lab.itkey.com

• <lcm_name>-lcm-02.vm.lab.itkey.com

• <lcm_name>-lcm-03.vm.lab.itkey.com

• ironic.<lcm_name>.vm.lab.itkey.com

DNS-имена внутри зоны могут быть произвольными — главное, чтобы они были заданы. Например, имя для GitLab не обязательно должно быть gitlab.domain.local, оно может быть любым, например ks-lcm.domain.local.

В сети должны быть зарезервированы следующие VIP-адреса (их значения потребуются при настройке lcm-config.yaml):

• mgt_vip_address

• vault_loadbalancer_ip

• nexus_loadbalancer_ip

• netbox_loadbalancer_ip

• gitlab_loadbalancer_ip

• grafana_loadbalancer_ip

• docs_loadbalancer_ip

• s3_loadbalancer_ip

• ironic_ip_address

Пользователь и доступ по SSH

• Требуется наличие непривилегированного пользователя (например, kolla) на каждом сервере.

• На первом LCM-узле должна быть сгенерирована SSH-ключевая пара, с использованием алгоритма шифрования RSA (пример генерации такого ключа ssh-keygen -t rsa); публичный ключ — добавлен в ~/.ssh/authorized_keys на втором и третьем узлах.

• Пользователю должно быть предоставлено право выполнять команды от суперпользователя без пароля (NOPASSWD в sudoers).

Синхронизация времени

На всех серверах должна быть настроена синхронизация времени (NTP). Расхождение времени между узлами может привести к нестабильной работе Kubernetes и Ceph.

Swap

Swap должен быть отключён на всех серверах, поскольку этого требует Kubernetes:

$ sudo swapoff -a
$ sudo sed -i '/swap/d' /etc/fstab

Программные требования

Требование / Тип узла	LCM	Controller	Compute	Network	Storage
Операционная система	Ubuntu 24.04 LTS / SberLinux 9.7.2
Минимальная версия ядра	5.15.0-76
Наличие сетевой связности между узлами	Да
Поддержка виртуализации	Intel VT-x (Virtualization Technology) или AMD-V (AMD Virtualization)

Версии компонентов продукта

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

KeyStack version	HashiCorp Vault	NetBox Community	Sonatype Nexus Community	GitLab Community Edition
2026.1	v1.21.0	v4.3.5	v3.85.0-03	v18.2.8
2026.2.1	v2.0.0	v4.6.0	v3.91.1-04	v18.11.5

Интеграция с внешними сервисами

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

• Vault и продукты на его основе;

• Sonatype Nexus.

Поддерживаемые версии внешних сервисов для каждого релиза приведены в таблице выше.