Расчёт ресурсов¶

Это оценки, а не результаты измерений

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

Что определяет нагрузку¶

Потребление ресурсов Hub определяется не числом пользователей, а потоком находок:

Фактор	На что влияет
Объём и частота загружаемых отчётов	Пиковая память worker, нагрузка на базу при разборе
Общее число накопленных находок	Размер базы, скорость выборок и дашбордов
Срок хранения отчётов	Объём файлового хранилища
Включён ли разбор языковой моделью	Внешний трафик и время обработки, не CPU
Размер обследуемого периметра	Ресурсы DomainScope и сканеров, не Hub

Разбор отчёта — самая ресурсоёмкая операция: файл читается целиком в память. Именно поэтому worker в чарте получает вдвое больший лимит памяти, чем backend.

Значения из поставляемых чартов¶

Hub¶

Компонент	CPU запрос	CPU лимит	Память запрос	Память лимит
`backend`	250m	1000m	256 Mi	1 Gi
`worker`	500m	2000m	512 Mi	2 Gi
`frontend`	50m	200m	64 Mi	256 Mi

Постоянные тома, задаваемые чартом:

Том	Размер по умолчанию	Что хранит
Данные PostgreSQL	10 Gi	Находки, отчёты, очередь задач, журнал действий
Хранилище отчётов	5 Gi	Загруженные файлы отчётов
Журналы	2 Gi	Файлы журналов, если файловый вывод включён

PostgreSQL в чарте разворачивается одним экземпляром без ресурсных ограничений — при переходе в промышленную эксплуатацию имеет смысл вынести базу во внешний управляемый экземпляр.

DomainScope¶

Компонент	CPU запрос	CPU лимит	Память запрос	Память лимит
`domain-scope`	500m	4000m	512 Mi	4 Gi

Тома: 5 Gi под данные PostgreSQL и 500 Mi под рабочие файлы. Широкий разброс между запросом и лимитом не случаен: сканирование портов и запуск проверок идут всплесками, между циклами процесс почти ничего не потребляет.

OpenVAS¶

Самый требовательный компонент решения — из-за размера баз описаний уязвимостей:

Составляющая	CPU запрос	Память запрос	Память лимит
Управляющий демон	500m	1 Gi	4 Gi
Сканирующий демон	300m	512 Mi	2 Gi
Своя PostgreSQL	250m	512 Mi	2 Gi
Веб-интерфейс	50m	64 Mi	256 Mi
Внутреннее хранилище состояния	50m	64 Mi	512 Mi

Тома под базы описаний в сумме — около 31 Gi: из них 15 Gi под описания проверок, по 5 Gi под данные PostgreSQL и справочник уязвимостей, остальное — конфигурации и сертификаты.

Внутреннее хранилище OpenVAS

OpenVAS поднимает собственное быстрое хранилище состояния для обмена между своими процессами. К Hub оно отношения не имеет — Hub брокера сообщений и внешнего кеша не использует.

OWASP ZAP¶

CPU запрос	CPU лимит	Память запрос	Память лимит	Том
500m	4000m	1 Gi	4 Gi	10 Gi

Ориентировочные конфигурации¶

Пилот и ознакомление¶

Один узел, всё в одном месте. Достаточно для проверки сценариев и небольшой команды.

Что	Значение
Ядер	4
Памяти	8 Gi
Диска	60 Gi

Сюда входят Hub целиком и DomainScope без OpenVAS и OWASP ZAP. С OpenVAS добавьте 2 ядра, 6 Gi памяти и 40 Gi диска, с OWASP ZAP — 1 ядро, 2 Gi памяти и 10 Gi диска.

Промышленная эксплуатация¶

Компонент	Ядер	Памяти	Диска
`backend`, две реплики	2	2 Gi	—
`worker`, две реплики	4	4 Gi	—
`frontend`, две реплики	0.5	0.5 Gi	—
PostgreSQL (Hub)	4	8 Gi	100 Gi, желательно SSD
Хранилище отчётов	—	—	50 Gi
Итого без периметра	~11	~15 Gi	~150 Gi

Провайдер SSO, если разворачивается рядом, — отдельно; типично ещё 2 ядра и 2 Gi памяти на экземпляр плюс своя база.

Как масштабировать¶

Больше отчётов и находок — увеличивайте число реплик worker и лимит памяти на реплику. Разбор отчёта не распараллеливается внутри одного файла, поэтому очень крупные отчёты упираются в память одной реплики, а не в их количество.

Медленные списки и дашборды — это нагрузка на PostgreSQL: сначала ресурсы базы, затем сроки хранения. Отчёты, которые уже разобраны, места в базе почти не занимают, а вот журнал действий и сами находки растут постоянно.

Заканчивается место в хранилище отчётов — уменьшите сроки хранения (CLEANUP_RETENTION_*). Переполнение этого тома останавливает приём новых отчётов: файл не сохраняется, и загрузка завершается ошибкой.

Больше пользователей — реплики backend. Это самый дешёвый вид роста: интерфейс отдаётся статикой, а сам backend состояния между запросами не хранит.

Настройки, влияющие на потребление¶

Переменная	Значение по умолчанию	На что влияет
`DB_MAX_OPEN_CONNS`	25	Верхний предел соединений с базой на процесс. Каждая реплика backend и worker открывает свой пул — при большом числе реплик сверяйтесь с `max_connections` базы
`DB_MAX_IDLE_CONNS`	5	Сколько соединений держать открытыми в простое
`CLEANUP_BATCH_SIZE`	размер по умолчанию в коде	Размер порции при очистке отчётов. Определяет память на одну порцию
`MAX_UPLOAD_SIZE_MB`	500	Предел размера загружаемого файла
`LLM_WORKERS`	5	Одновременных обращений к языковой модели

Полный перечень: Hub — backend и worker.