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

Страница для того, кто разворачивает Alatyr и должен назвать цифры: сколько процессора, памяти и диска просить под сервер, базу и Vault. Для настройки целей она не нужна.

Числа ниже разделены на три вида, и это разделение существенно:

• Замерено — снято на работающей установке, указано чем и при каком объёме данных.
• Посчитано — выведено из замеров арифметикой, метод показан.
• Зависит от установки — величина, которую задаёт ваша политика (частота продления, глубина хранения журнала), и подставить её можем только вы.

Ресурсы — не лицензионный лимит

Расчёт ресурсов не отменяет ограничения из действующей лицензии. Лимитов два: по числу устройств (базовая лицензия — 50, платная — max_devices) и, если лицензия их несёт, по числу машин на каждую цель отдельно. Железо, рассчитанное на 600 машин, само по себе не даёт права их обслуживать. См. Лицензирование.

Потребление в покое (замерено)

Демо-состав docker-compose.demo.yml целиком, четыре компонента, после инициализации и засева демо-данными. Три пробы docker stats с интервалом 5 с:

Компонент	CPU	Память
PostgreSQL	0,02–0,05 %	30 МиБ
Сервер	0,00–0,24 %	21 МиБ
Веб-интерфейс (nginx)	0,00 %	18 МиБ
Vault (dev-режим)	0,78–24,6 %	51 МиБ
Итого	менее 0,3 % ядра в среднем	около 120 МиБ

Всплеск CPU у Vault — периодическая внутренняя работа, не реакция на запросы: установка в этот момент не обслуживала никого.

Подъём с нуля — 110 секунд до состояния, когда API отвечает 200 на /health: сборка образов, миграции, инициализация PKI, засев.

Размеры образов: сервер 141 МБ, веб-интерфейс 84 МБ, PostgreSQL 417 МБ (alpine) или 633 МБ, Vault 740 МБ.

Профиль: пилот (до ~200 устройств)

Одна реплика на компонент, без отказоустойчивости. Значения requests разумно брать вдвое выше замеренного покоя — запас на выпуск и на пики опроса:

Компонент	CPU (request / limit)	Память (request / limit)
Сервер	100m / 500m	64Mi / 256Mi
PostgreSQL	100m / 500m	128Mi / 512Mi
Vault	100m / 500m	128Mi / 512Mi
Веб-интерфейс	25m / 100m	32Mi / 64Mi

Прежние значения на этой странице были завышены по памяти втрое-вчетверо: они задавались оценкой, а не замером.

Профиль: 600 машин, 5–6 целей на машину

Типичный корпоративный парк: 600 устройств, на каждом 5–6 целей (Wi-Fi, проводной 802.1X, вход по карте, mTLS, SSH, Kubernetes) — около 3300 действующих сертификатов.

Диск: как считалось

Замер: таблица заявок занимает 488 кБ при 766 строках, включая индексы, — 652 байта на строку. Но в демо-данных поля csr_pem и cert_pem заполнены заглушками (82 и 63 байта), а не настоящими PEM.

Настоящие размеры сняты выпуском сертификата тем же профилем, которым пользуется продукт:

Поле	Замерено
CSR (PEM, RSA-2048)	911 байт
Сертификат (PEM)	1358 байт

Отсюда настоящая строка заявки: 652 − 145 + 2269 ≈ 2776 байт.

Величина	Значение	Вид
Таблица заявок, 3300 действующих	8,7 МБ	посчитано
То же за 3 года при ежегодном продлении	26 МБ	посчитано
Таблица устройств, 600 строк	1,1 МБ	посчитано (замер: 1959 Б/строка)
Журнал аудита	18–70 МБ в год	зависит от установки (замер: 1117 Б/строка)

Разброс по журналу — это 5 и 20 событий на сертификат в год: выпуск, продление, отзыв, вход, проверка. Глубину хранения задаёте вы.

Итого по диску: десятки мегабайт данных в год. Том PostgreSQL на 5–10 ГБ закрывает такой парк с многократным запасом; узким местом станет не объём, а резервное копирование и глубина хранения журнала.

Процессор и память

Сам по себе парк в 600 машин нагрузки почти не создаёт: обращения редки и коротки — заявка на выпуск раз в год на цель, периодическая отметка присутствия. Значения профиля «пилот» подходят и здесь; удваивать их стоит, если вы разворачиваете парк одномоментно.

Что НЕ замерено

Одновременная первичная регистрация всех 600 машин. При массовой раскатке агенты стартуют пачкой, и пик приходится не на установившийся режим, а на первый час. Агент разносит старт случайной задержкой (--tick-jitter, по умолчанию 120 с), но при 600 машинах планируйте раскатку волнами и следите за очередью заявок в веб-интерфейсе.

Профиль: тысячи устройств

Для тысяч устройств топология демо-чарта — не отправная точка, а только источник соотношений между компонентами. На таком масштабе потребуется платная лицензия с соответствующим max_devices. Развёртывание потребует:

• нескольких реплик сервера за load balancer'ом — но прежде чем размещать N реплик API-сервера, посмотрите страницу Отказоустойчивость: там описаны ограничения, специфичные для SCEP-поллинга, которые влияют на то, как масштабировать сервер горизонтально;
• production-режима Vault (не -dev): постоянный storage backend (Raft/Consul), ручной или auto-unseal через KMS, в идеале — HA-кластер Vault (нечётное число узлов), что выходит далеко за рамки одноподового демо-чарта;
• PostgreSQL с ресурсами, пропорциональными реальному датасету, и отдельным планом на бэкапы/репликацию (демо-чарт даёт один под без реплики и без задачи резервного копирования).

Компонент	CPU (request / limit)	Memory (request / limit)	Почему
Server (на реплику)	250–500m / 1 vCPU	128–256Mi / 512Mi	Тот же лёгкий Go-бинарь; на тысячах устройств значение имеет число реплик (см. Отказоустойчивость) и частота /enroll/checkin-трафика, а не размер одного пода
PostgreSQL	500m–1 vCPU / 2 vCPU	512Mi–1Gi / 2Gi	Датасет и WAL-нагрузка растут с числом устройств и историей заявок на выпуск и журнала аудита; на этом масштабе также рассмотрите read-реплику под отчётность
Vault (production, на узел HA-кластера)	250m–1 vCPU / 2 vCPU	256Mi–1Gi / 2Gi	Требуемые ресурсы сильно зависят от выбранного storage backend (Raft/Consul) и числа узлов кластера (обычно 3+ для HA) — это оценка на узел, не на весь кластер
Frontend (на реплику)	10–25m / 100m	16–32Mi / 64Mi	Статика; масштабируется по объёму HTTP-запросов от админки, не по числу устройств

Диск. На тысячах устройств 5Gi из демо-чарта, скорее всего, будет мало — рост журнала аудита и заявок на выпуск пропорционален числу операций выпуска/отзыва/проверки, что зависит от политики ротации сертификатов и retention-политики аудита у конкретного заказчика. Ориентируйтесь не на фиксированное число ГБ, а на мониторинг занятости тома с алертом задолго до заполнения, плюс план на расширение тома (storageClassName с поддержкой online-resize) или архивацию старых записей журнала аудита.