Сколько виртуальных машин, ядер, памяти и дисков нужно под вашу инсталляцию: приложение, СУБД, хранилище тел документов, поиск, мониторинг, копии. На виртуальных машинах или в Kubernetes, с отказоустойчивостью или без, с тестовым и предпродуктивным контурами.
Калькулятор не знает ваших интеграций, пиковых сценариев и требований по RPO/RTO. Пришлите ссылку на расчёт, за 30 минут созвона скажем, где он завышен, где занижен и что не учтено. Бесплатно.
Это оценка для планирования бюджета и раздела ТЗ, а не замена сайзингу по профилю нагрузки. Коэффициенты подобраны по опыту эксплуатации контуров разного размера и округлены в большую сторону. Лицензии ОС, СУБД и самой системы в расчёт не входят.
Модель простая и открытая: несколько коэффициентов на активного пользователя и на объём документов, минимальные размеры узлов и правила разнесения по ролям. Все допущения здесь, чтобы вы могли поспорить с любым из них.
Если не указали, берём 30% от общего числа. Нагрузку создают те, кто работает в системе одновременно, а не все, у кого есть учётная запись.
Три ядра и десять гигабайт базово, дальше по ядру на 45 активных пользователей и по гигабайту на 18. Узел не больше 12 ядер и 40 ГБ, дальше добавляем узлы. При отказоустойчивости узлов на один больше, чем нужно для нагрузки.
Ядро на 50 активных пользователей, память по активным пользователям и размеру базы, не меньше 4 ядер и 8 ГБ. Диск под данные вдвое больше базы, отдельный том под WAL. Реплика того же размера.
Документов в год × размер × горизонт, плюс архив, плюс 20% на версии. S3 в отказоустойчивом варианте: четыре узла, сырой объём вдвое больше полезного.
Индекс равен десятой части объёма документов. Память узла по размеру индекса, куча JVM не больше половины памяти.
До 300 активных пользователей брокер живёт на узле приложения. При отказоустойчивости кластер из трёх узлов и пара балансировщиков с плавающим адресом.
Квота неймспейса это сумма requests по сервисам RX и брокеру с запасом в полтора раза на limits. Кластер целиком: рабочие узлы по 8/32 или 16/64 с запасом 25% и на потерю одного узла, управляющие отдельно. На каждом рабочем узле вычитаем системный резерв и агенты.
Когда кластер считаем целиком, в него входят ingress, cert-manager, Flux, Prometheus с Alertmanager и Grafana, kube-state-metrics, metrics-server, CoreDNS, а на каждом узле Vector, Longhorn, node-exporter и CNI. Longhorn держит три реплики каждого тома, поэтому локальные диски узлов считаем от утроенного объёма томов.
Приложение даёт около 0,4 ГБ журналов в день на 100 активных пользователей при обычном уровне логирования, плюс 0,1 ГБ на каждую машину и журнал СУБД. Срок хранения выбираете, на индексы добавляем 30%. Метрики: 30 дней, около 50 МБ в день на машину. Журналы тестового и препрода тоже приезжают на этот узел.
Тест: пятая часть пользователей, десятая часть данных, без отказоустойчивости. Препрод: данные как в проде, отказоустойчивость по выбору. Мониторинг один на все контуры.
Три объёма базы плюс один объём тел документов, на другом хранилище. Регламент восстановления в расчёт не входит, но без него копия это просто занятый диск.
Чего здесь нет: интеграций с внешними системами, нагрузочных пиков вроде массовых рассылок заданий, специфики прикладной разработки, требований ИБ к сегментации сети. Всё это меняет цифры и учитывается в сайзинге под договор.
Что значит «8 ядер и 32 ГБ» в требованиях и как посчитать диски под документы и копии. Разбор в блоге