← Документация и информация о ПО

Требования к техническим средствам и организации хранения данных

Программное обеспечение: XK Server Management Platform (XKSM)
Версия: 2.64.0
Правообладатель: ООО «ХК СЕРВ»
Дата документа: 10.09.2026

1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

1.1 Назначение документа

Документ определяет требования к техническим средствам, необходимым для эксплуатации программного обеспечения XK Server Management Platform (XKSM), и описывает принятую в платформе организацию хранения данных: состав хранилищ, размещение данных по хранилищам, структуру каталогов и томов, политики хранения и порядок резервного копирования.

Документ предназначен для системных администраторов и ИТ-служб, планирующих развёртывание платформы, а также для служб, отвечающих за ёмкость и сохранность данных на этапе эксплуатации.

1.2 Область применения

Требования распространяются на сервер (или группу серверов), на котором разворачивается платформа XKSM. Требования к управляемому оборудованию (серверы, BMC, коммутаторы, внешние системы хранения) настоящим документом не устанавливаются: платформа взаимодействует с ним по стандартным протоколам и не предъявляет к нему требований по ёмкости хранения.

1.3 Связанные документы


2. ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ

2.1 Требования к серверу платформы

Компонент Минимальные требования Рекомендуемые
CPU 4 ядра, x86-64 8+ ядер
RAM 8 ГБ 16–32 ГБ
Дисковое пространство 50 ГБ свободного места 200+ ГБ SSD
Сетевой интерфейс 1 Гбит/с 10 Гбит/с

2.2 Требования к программной среде

Компонент Версия Примечание
ОС Linux (64-bit) Debian 12, Ubuntu 22.04, РЕД ОС 7.3+, Astra Linux 1.7
Docker Engine 24.0+ Официальный пакет от Docker Inc.
Docker Compose v2.20+ Входит в Docker Desktop или устанавливается отдельно
Python 3.12+ Только для dev-режима без Docker

2.3 Требования к дисковой подсистеме

Дисковая подсистема — определяющий фактор производительности платформы: три из четырёх хранилищ (PostgreSQL, ClickHouse, Qdrant) обращаются к диску постоянно, а поток телеметрии носит характер непрерывной вставки.

2.4 Сетевые требования

Входящие подключения к серверу платформы:

Порт Протокол Назначение
443 TCP (HTTPS) Веб-интерфейс
80 TCP (HTTP) Редирект на HTTPS
8099 TCP API-сервер (опционально, если не за reverse proxy)

Исходящие подключения к управляемому оборудованию:

Порт Протокол Назначение
443 TCP Redfish API (HTTPS)
80 TCP Redfish API (HTTP, legacy)
623 UDP/TCP IPMI
22 TCP SSH (сбор OS-логов, опционально)

Пропускная способность сетевого интерфейса — не менее 1 Гбит/с, рекомендуется 10 Гбит/с. Требование 10 Гбит/с существенно для установок, опрашивающих большие парки оборудования, а также для выгрузки резервных копий на внешние хранилища.


3. ОРГАНИЗАЦИЯ ХРАНЕНИЯ ДАННЫХ

3.1 Состав хранилищ

Платформа использует четыре специализированных хранилища. Каждое обслуживает свой класс данных; совмещение классов в одном хранилище не предусмотрено.

Хранилище Версия Класс данных
PostgreSQL 16 Конфигурация платформы, метаданные, справочники
ClickHouse 24.8 Телеметрия, метрики, архив журналов событий
Redis 7 Кэш, очереди фоновых задач, сессии
Qdrant 1.9 Векторные индексы

3.2 Размещение данных по хранилищам

PostgreSQL 16 — основное хранилище состояния платформы:

ClickHouse 24.8 — хранилище данных временных рядов и архива:

Данные в ClickHouse хранятся в сжатом виде: коэффициент сжатия исторических данных относительно PostgreSQL составляет от 30 до 326 раз в зависимости от класса данных. Именно это позволяет удерживать многолетний архив в пределах объёмов, указанных в разделе 4.

Redis 7 — данные с ограниченным временем жизни:

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

Qdrant 1.9 — векторные индексы, используемые функциями поиска и анализа.

3.3 Структура каталогов и томов

Все данные платформы размещаются в едином дереве каталогов установки. Тома Docker сопоставлены с подкаталогами data/, что позволяет резервировать и переносить установку целиком.

/opt/xksm/
├── .env                    — основные настройки (пароли, ключи)
├── docker-compose.yml      — описание сервисов
├── nginx/
│   └── nginx.conf          — конфигурация Nginx (reverse proxy)
├── data/
│   ├── postgres/           — данные PostgreSQL
│   ├── redis/              — данные Redis
│   ├── clickhouse/         — данные ClickHouse
│   └── qdrant/             — векторная БД Qdrant
└── backups/                — резервные копии

Каталог data/ содержит все изменяемые данные и подлежит резервированию. Каталог backups/ содержит резервные копии и, по возможности, должен размещаться вне того же физического носителя, что и data/.


4. ОБЪЁМЫ И ПЛАНИРОВАНИЕ ЁМКОСТИ

4.1 Исходные характеристики

Планирование ёмкости опирается на следующие подтверждённые характеристики платформы:

Параметр Значение
Максимальное количество управляемых серверов 10 000+
Вставка событий в ClickHouse 86 млн событий/день
Хранение телеметрии за 1 год ~1–2 ТБ
Сжатие исторических данных vs PostgreSQL 30–326x
Дисковое пространство (минимум / рекомендуемое) 50 ГБ / 200 ГБ SSD

Значение «~1–2 ТБ телеметрии за 1 год» относится к установке максимального масштаба (парк порядка 10 000 серверов при полном наборе собираемых датчиков).

4.2 Ориентировочный расчёт по масштабу установки

Объём телеметрии растёт практически линейно с числом управляемых серверов и частотой опроса. Приведённая ниже таблица получена линейным пересчётом характеристики из п. 4.1 и предназначена для предварительного планирования; для конкретной установки объём следует уточнять по фактическому заполнению за первый месяц эксплуатации.

Парк серверов Телеметрия за год (оценка) Рекомендуемый том данных
до 100 ~10–20 ГБ 200 ГБ SSD (рекомендуемая конфигурация)
до 1 000 ~100–200 ГБ 500 ГБ SSD
до 10 000 ~1–2 ТБ 2–4 ТБ SSD (с запасом на 1–2 года хранения)

Пояснения к таблице:

4.3 Контроль заполнения

Заполнение хранилищ контролируется штатными средствами платформы: Analytics API предоставляет статус и размеры таблиц ClickHouse, что позволяет отслеживать динамику роста архива и планировать расширение тома заблаговременно.


5. ПОЛИТИКИ ХРАНЕНИЯ И РЕТЕНЦИЯ

5.1 Сроки хранения

Класс данных Хранилище Срок хранения
Конфигурация, устройства, пользователи PostgreSQL Бессрочно (до изменения администратором)
Журналы событий (архив) ClickHouse 1–2 года
Телеметрия и метрики ClickHouse 1–2 года (совместно с журналами)
Кэш, очереди, сессии Redis Время жизни записи (без долговременного хранения)
Резервные копии Файловая система / внешнее хранилище Последние N копий или N дней (настраивается)

5.2 Архивирование журналов

Журналы событий BMC и операционных систем собираются платформой и архивируются в ClickHouse со сжатием до 326 раз. Перед очисткой журналов на стороне BMC платформа автоматически сохраняет их содержимое в собственное хранилище — таким образом штатная операция очистки журналов оборудования не приводит к потере истории.

5.3 Ротация и очистка

При установке платформы в информационных системах, к которым предъявляются требования по срокам хранения событий безопасности, срок хранения следует задавать в соответствии с этими требованиями, увеличив ёмкость тома данных пропорционально выбранному сроку.


6. РЕЗЕРВНОЕ КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ

6.1 Состав резервной копии

Компонент Содержимое
PostgreSQL Полный дамп базы (устройства, пользователи, RBAC, журнал аудита, IPAM)
Конфигурация Файл .env, конфигурации Nginx, сертификаты
Хранилище прошивок Каталог загруженных файлов прошивок
ClickHouse Снимок телеметрии (опционально)
Лицензия Файл лицензии

Дополнительно платформа выполняет экспорт конфигураций управляемых серверов (BIOS, BMC, RAID) — эти данные хранятся в PostgreSQL и попадают в резервную копию вместе с ним.

6.2 Целевые хранилища резервных копий

Тип Описание
Local Локальная файловая система (каталог backups/)
SFTP Удалённый сервер по SFTP
S3 S3-совместимые хранилища, включая Yandex Object Storage, VK Cloud Hotbox, MinIO
NFS Сетевая файловая система
WebDAV Любое WebDAV-совместимое хранилище

Хранение резервных копий исключительно на том же носителе, где расположен каталог data/, не рекомендуется: отказ носителя приведёт к одновременной потере данных и копий.

6.3 Расписание и ретенция копий

6.4 Порядок восстановления

  1. Остановить сервисы платформы.
  2. Восстановить дамп PostgreSQL.
  3. Восстановить файлы конфигурации (.env, конфигурации Nginx, сертификаты).
  4. Запустить платформу — миграции схемы БД проверяются автоматически при старте.

Восстановление из веб-интерфейса выполняется в разделе «Резервирование» выбором нужной копии. Операция перезаписывает текущие настройки, поэтому перед восстановлением рекомендуется создать актуальную резервную копию.

6.5 Контроль показателей восстановления

Платформа поддерживает определение и контроль SLA резервного копирования: задаются целевые показатели RPO (допустимая потеря данных по времени) и RTO (допустимое время восстановления), выполнение которых отслеживается по времени последней успешной копии; при нарушении показателей формируется алерт.


7. ПОДДЕРЖИВАЕМЫЕ СИСТЕМЫ ХРАНЕНИЯ И УПРАВЛЕНИЕ СХД

Помимо собственных требований к хранению, платформа выступает средством управления внешними системами хранения данных, входящими в обслуживаемую инфраструктуру.

7.1 Поддерживаемые системы хранения данных

Производитель Линейки / Модели Протокол интеграции
TATLIN (YADRO) Unified REST API
АЭРОДИСК ENGINE REST API
NetApp ONTAP REST API
Dell EMC PowerStore, Unity REST API
HPE 3PAR, Primera, Alletra REST API
Pure Storage FlashArray REST API

7.2 Функции управления СХД

7.3 Дисковые подсистемы управляемых серверов

Локальные дисковые подсистемы серверов управляются отдельным механизмом — через RAID-контроллеры по Redfish Storage API и вендорным OEM-расширениям. Доступны просмотр контроллеров, логических и физических дисков, создание и удаление томов уровней RAID 0/1/5/6/10/50/60, восстановление деградированных массивов, назначение диска горячей замены, профилактическое фоновое сканирование дисков и криптографическое стирание при выводе носителя из эксплуатации.

7.4 Размещение данных платформы на внешней СХД

Каталог установки, включая data/ и backups/, может размещаться на томе, предоставленном внешней системой хранения (по блочному протоколу либо через NFS). В этом случае требования раздела 2.3 к отказоустойчивости и производительности носителя относятся к предоставленному тому.


8. ТРЕБОВАНИЯ К РАЗМЕЩЕНИЮ

8.1 Поддерживаемые российские операционные системы

ОС Версия Статус поддержки
РЕД ОС 7.3 / 8.0 Поддерживается
Astra Linux Special Edition 1.7 Voronezh Поддерживается
ALT Linux 10 Поддерживается
Базальт СПО 10 Поддерживается
ОС «Ред Виртуализация» 7.3+ Поддерживается

Платформа разворачивается в Docker Compose, что обеспечивает совместимость с любым Linux-дистрибутивом, поддерживающим Docker 24+.

8.2 Автономность размещения

Платформа работает без доступа к сети Интернет: все компоненты разворачиваются из локального архива образов, внешние сервисы, сторонние облачные хранилища и внешние службы аналитики для работы не требуются. Данные платформы не покидают контур размещения, если администратор явно не настроил выгрузку резервных копий на внешнее хранилище.

8.3 Импортозамещение технических средств

Все используемые платформой хранилища — PostgreSQL, ClickHouse, Redis, Qdrant — распространяются под свободными лицензиями и разворачиваются локально, без привязки к проприетарным или зарубежным управляемым сервисам. Аппаратная платформа — серверы архитектуры x86-64, в том числе российского производства из числа поддерживаемых платформой; требований к оборудованию конкретного производителя не предъявляется.

8.4 Режим высокой доступности

Для установок, к которым предъявляются требования по непрерывности, платформа поддерживает развёртывание в режиме высокой доступности (HA). Порядок развёртывания и состав компонентов описаны в Инструкции по установке программного обеспечения.