Сайзинг Directum RX: что значит «8 ядер и 32 ГБ» и как посчитать серверы и диски

Коротко. Сайзинг это расчёт ресурсов под нагрузку и срок: сколько машин, процессоров, памяти и дисков. «8 ядер, 32 ГБ» обычно описывает один сервер одной роли и часто только минимум. Процессоры и память считают от одновременно работающих, это около 30% учётных записей. Диски считают от документооборота за горизонт, плюс база, поиск, журналы и копии на другом хранилище. На 300 пользователей и 60 000 документов в год выходит пять машин, 22 vCPU и 780 ГБ дисков без копий.

Под новую систему ИТ-службе нужно выделить серверы, и первый вопрос звучит просто: сколько. Интегратор присылает таблицу, где у сервера приложений написано «8 ядер, 32 ГБ», у базы примерно то же, а про диски одна строка «от 500 ГБ». Откуда эти цифры, хватит ли их через три года и как они ложатся на виртуализацию, обычно никто не объясняет. Разбираем, как устроен такой расчёт, как проверить его самим и где он чаще всего ошибается.

Как это называется

Расчёт ресурсов под систему называют сайзингом, от английского sizing. В документах встречаются и другие названия: расчёт аппаратных требований, планирование мощностей (capacity planning), раздел «Требования к техническому обеспечению» в техническом задании. Речь везде об одном: сколько серверов, процессоров, памяти и дисков нужно под заданную нагрузку и на какой срок.

Хороший сайзинг отвечает на три вопроса: сколько ресурсов нужно на старте, сколько понадобится к концу горизонта планирования (обычно от трёх до пяти лет) и какие допущения за этим стоят. Если допущений в документе нет, проверить его нельзя, и через год спорить будет не о чем.

Что значит «8 ядер и 32 ГБ»

Такая строка почти всегда описывает один сервер одной роли, а не систему целиком. «Сервер приложений: 8 ядер, 32 ГБ памяти» означает одну машину с этими ресурсами. Если ролей пять, машин тоже пять, и считать их надо по отдельности.

Дальше стоит уточнить, какие ядра имеются в виду. Виртуальной машине выдают виртуальные процессоры (vCPU), и один vCPU обычно соответствует одному аппаратному потоку хоста, то есть половине физического ядра при включённой гиперпоточности. Поэтому «8 ядер» из требований и «8 vCPU» на виртуалке по производительности не одно и то же. Разница растёт, если на хосте виртуальных процессоров выдано больше, чем у него есть потоков.

Наконец, стоит понять, нижняя это граница или расчёт под вашу нагрузку. Минимальные требования говорят, при каких ресурсах система вообще запустится. Сколько нужно именно вам, зависит от числа людей, которые работают одновременно, и от объёма документов, а этого в минимальных требованиях нет.

Из чего складывается расчёт

Directum RX состоит из нескольких ролей, и у каждой своя зависимость от нагрузки. Ниже правила, по которым считает наш открытый калькулятор сайзинга. С любым из них можно поспорить, для этого они и выписаны.

Активные пользователи, а не учётные записи. Нагрузку создают люди, которые работают в системе одновременно. Если точной цифры нет, берём 30% от общего числа. Ошибка здесь самая дорогая: расчёт по всем учётным записям даёт железо примерно втрое больше нужного.

Сервер приложений. Три ядра и десять гигабайт памяти базово, дальше по ядру на 45 активных пользователей и по гигабайту на 18. Один узел не больше 12 ядер и 40 ГБ, при большей нагрузке добавляются узлы. Для отказоустойчивости узлов на один больше, чем нужно по нагрузке.

СУБД. Ядро на 50 активных пользователей, память по числу активных и размеру базы, не меньше 4 ядер и 8 ГБ. Диск под данные вдвое больше самой базы: место нужно на рост, обслуживание и временные файлы. Журнал предзаписи на отдельном томе.

Хранилище тел документов. Сами файлы документов лежат отдельно от базы, в объектном хранилище S3 или в файловом. Их объём считается от документооборота, об этом ниже.

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

Брокер сообщений. До 300 активных пользователей RabbitMQ живёт на узле приложения. Для отказоустойчивости нужен кластер из трёх узлов и пара балансировщиков.

Мониторинг и журналы. Отдельная машина на все контуры. Про неё забывают чаще всего.

Диски считают отдельно

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

Тела документов: документов в год × средний размер × горизонт в годах, плюс архив, который переносится из старой системы, плюс 20% на версии. При 60 000 документов в год по 500 КБ за пять лет выходит 150 ГБ, с версиями 180 ГБ.

База: растёт вместе с документооборотом, а под данные закладывается вдвое больше её размера. Отдельно том под журнал предзаписи.

Поиск: десятая часть от тел документов.

Журналы и метрики: около 0,4 ГБ журналов приложения в день на 100 активных пользователей при обычном уровне логирования, плюс по 0,1 ГБ на каждую машину и журнал СУБД. Метрики примерно 50 МБ в день на машину. Сколько дней хранить, решаете вы, от этого срока и зависит объём.

Резервные копии: три объёма базы и один объём тел документов, обязательно на другом хранилище. Копия на том же диске, что и база, пропадёт вместе с ней.

Тестовый контур: примерно пятая часть пользователей и десятая часть данных, без отказоустойчивости. Если нужен препрод, данные в нём как в проде.

Пример на 300 пользователей

Возьмём небольшую компанию: 300 учётных записей, 60 000 документов в год по 500 КБ, горизонт пять лет, Linux и PostgreSQL, приложение на виртуальных машинах, документы в S3. Калькулятор даёт такой продуктивный контур:

Итого 5 машин, 22 vCPU, 52 ГБ памяти и 780 ГБ дисков, копии ещё 450 ГБ на отдельном хранилище. Из 300 пользователей активными считаются 90, тела документов за пять лет займут 180 ГБ, база около 70 ГБ, журналов в проде будет около 1,1 ГБ в день. Вместе с тестовым контуром выходит 9 машин и 38 vCPU.

По примеру видно, где ошибается строка «8 ядер, 32 ГБ на всё». Процессоры и память у такой системы скромные, основная часть ресурсов уходит на диски, а копии и мониторинг занимают больше трети всего места. В коротких таблицах этих строк обычно нет.

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

Чего не считает ни один калькулятор

Расчёт по коэффициентам хорош для старта и для технического задания, но у него есть границы. В него не входят:

• интеграции с внешними системами, которые иногда нагружают сильнее всех пользователей вместе;
• пики вроде массовой рассылки заданий или закрытия отчётного периода;
• скорость дисков: объём посчитать можно, а задержки и число операций в секунду нужно мерить на вашей системе хранения;
• требования безопасности к разделению сетей и отдельным контурам;
• цены. Лицензии операционной системы, СУБД и самой системы в расчёт не входят, стоимость зависит от вашего договора с вендором и партнёром.

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

Что сделать

1. Узнать число одновременно работающих. Если старая система есть, посмотреть пиковое число сессий. Если нет, взять 30% от учётных записей и записать это как допущение.
2. Посчитать документооборот. Сколько документов в год, какой средний размер файла, будет ли перенос архива.
3. Выбрать горизонт. Для дисков разумно пять лет: документы накапливаются и никуда не исчезают.
4. Расписать ресурсы по ролям, а не одной строкой на систему, и отдельно тестовый контур.
5. Заложить копии на другом хранилище и срок хранения журналов.
6. Проверить диски на скорость, особенно под базу.
7. Записать допущения в документ. Через год по ним будет видно, где расчёт разошёлся с жизнью.

Чего не делать

• Не считать по числу учётных записей. Нагрузку дают одновременно работающие, по нашему допущению это около трети.
• Не принимать минимальные требования за сайзинг. Минимум говорит, что система запустится, и ничего не говорит о том, хватит ли ей ресурсов.
• Не держать базу и документы на одном томе без плана роста. Документы обычно растут быстрее, и когда диск заполнится, остановится база.
• Не забывать мониторинг, журналы и копии. В примере выше это больше трети всех дисков.
• Не приравнивать vCPU к физическим ядрам на хосте, где виртуальных процессоров выдано больше, чем есть потоков.