Сорок баз помещаются в одной консоли 1С. Из этого не следует, что они поместятся в один сервер.

Допустим, компания переносит 40 баз на новый узел. На действующем сервере десять таких же баз в пик занимают 6 ядер, 24 ГБ у процессов 1С и 36 ГБ у СУБД. За сутки накопители принимают 0,8 ТБ случайной записи. Если нагрузка растёт линейно, расчёт приводит к 32 ядрам, 384 ГБ памяти и корпоративным NVMe.

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

Сорок баз — плохая единица мощности

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

Официальные аппаратные требования 1С задают минимум без учёта прикладных решений. Поэтому нельзя взять требование «4 ГБ» и умножить его на 40: эта цифра относится к запуску платформы, а не к рабочему набору конкретных баз.

1С предлагает другой способ: измерить загрузку модельной системы и линейно перенести результат на целевую. Модель должна повторять приложение, клиент-серверный режим, компоновку компонентов, версии платформы, СУБД и ОС. Работающая система с реальными пользователями даёт наиболее точную модель при наименьших затратах на подготовку — так описывает методику база знаний 1С.

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

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

Память считаем по рабочему набору

В модельной системе процессы 1С занимают 24 ГБ, СУБД — ещё 36 ГБ. Получаем 60 ГБ на десять баз в самый тяжёлый измеренный период.

Переход к сорока базам выглядит так:

(24 + 36) × 40 ÷ 10 = 240 ГБ

К расчётной нагрузке закладываем 25% запаса:

240 × 1,25 = 300 ГБ

Ещё 16 ГБ оставляем ОС и служебным процессам:

300 + 16 = 316 ГБ

Ставить 320 ГБ технически можно, но такая раскладка может мешать симметрично заполнить каналы памяти при следующем апгрейде. Для этой закупки берём 384 ГБ ECC RDIMM и просим поставщика показать схему установки модулей. Заодно проверяем предельный объём памяти и число свободных слотов у выбранной платформы: без этих данных нельзя обещать апгрейд без замены сервера.

Здесь видна цена исходного замера. Если десять баз занимают не 60, а 40 ГБ, получится:

40 × 4 × 1,25 + 16 = 216 ГБ

Тогда хватит 256 ГБ. При модельном потреблении 80 ГБ результат меняется:

80 × 4 × 1,25 + 16 = 416 ГБ

Это уже конфигурация на 512 ГБ. Разница между тремя закупками возникает не из числа баз, а из измеренных 40, 60 или 80 ГБ. Такой же подход разобран в расчёте сервера 1С на 50 пользователей.

Процессор: 24 ядра под нагрузку, 8 — под запас

Модельный сервер потребляет 6 физических ядер в самый тяжёлый профиль. При неизменной нагрузке сорок баз потребуют:

6 × 40 ÷ 10 = 24 ядра

Добавляем те же 25%:

24 × 1,25 = 30 ядер

Для спецификации округляем расчёт до 32 физических ядер. Это проектное значение с запасом, а не единственная допустимая конфигурация. Нужное число ядер можно набрать одним или двумя процессорами, но выбирать конкретную модель только по их количеству нельзя. Методика 1С разделяет расчёт номинального числа ядер и выбор процессора, а среди параметров, влияющих на систему, называет производительность CPU, дискового массива и объём памяти.

Для этой закупки важна производительность одного ядра при суммарных 32 физических ядрах. Она влияет на операции с низкой параллелизацией. Но назвать конкретную модель без теста на той же платформе нельзя: в исходных данных нет сопоставимых замеров процессоров.

Если 30 ядер нужны только при закрытии месяца, а обычный пик занимает 16, сервер всё равно считаем по тяжёлому профилю. Иначе нехватка мощности проявится в день, когда бухгалтерия не может ждать.

NVMe выбираем по записи, а не только по ёмкости

Для расчёта ёмкости примем средний размер базы 50 ГБ:

40 × 50 ГБ = 2 ТБ

Четыре NVMe по 1,92 ТБ в RAID 10 дадут 3,84 ТБ полезной ёмкости. После размещения 2 ТБ останется 1,84 ТБ под рост, служебные данные и операции СУБД. Если резервные копии планируется хранить на этом же массиве, расчёт нужно переделать: текущая спецификация места под них не содержит.

Теперь ресурс записи. Модельные десять баз записывают 0,8 ТБ в сутки. Для сорока получаем:

0,8 × 4 = 3,2 ТБ в сутки

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

3,2 ÷ 2 = 1,6 ТБ в сутки

Для накопителя на 1,92 ТБ это:

1,6 ÷ 1,92 ≈ 0,83 DWPD

Это допущение нужно проверить по фактической записи на каждом диске после запуска: распределение может отличаться от расчётного.

DWPD показывает, сколько полных объёмов накопителя разрешено записывать ежедневно в течение гарантии. Но цифру из паспорта нужно сопоставить с методикой теста. ATP отдельно публикует ресурс для последовательной записи блоками 128 КБ и для случайной корпоративной нагрузки JESD219A: случайная запись сильнее увеличивает внутреннюю перезапись NAND. Для СУБД нужен показатель, рассчитанный на случайной или смешанной нагрузке, а не результат последовательного теста — это следует из разбора методик ресурса SSD от ATP.

Расчётные 0,83 DWPD — нижняя граница при наших исходных данных. Накопитель нужен с большим паспортным ресурсом: объём записи может вырасти, а нагрузка — распределиться неравномерно.

Лицензии считаются отдельно от железа

Из замеров следуют 384 ГБ памяти, 32 физических ядра и требования к накопителям. Но этих данных недостаточно, чтобы выбрать редакцию сервера 1С, определить число разрешённых подключений и рассчитать стоимость лицензий.

В предоставленных материалах нет официальной схемы лицензирования, характеристик ПРОФ и КОРП и действующих цен. Поэтому сумму лицензий в эту смету не добавляем: сначала нужно зафиксировать архитектуру и число одновременных подключений, затем запросить расчёт у правообладателя или партнёра 1С.

В закупке нужна отдельная строка: «Лицензии 1С — по расчёту правообладателя или партнёра для выбранной архитектуры и числа одновременных подключений». До согласования этой строки можно сравнить условия лицензий ПРОФ и КОРП, но переносить цену из чужого сценария в этот расчёт нельзя.

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

Спецификация под задачу

Считаем конфигурацию для 40 баз по модели из десяти одинаковых баз: 6 ядер в пик, 60 ГБ совокупной памяти процессов 1С и СУБД, 0,8 ТБ случайной записи в сутки. Средний объём одной базы принимаем равным 50 ГБ.

Процессор: 32 физических ядра с приоритетом производительности ядра. Расчёт дал 30: 24 под измеренную нагрузку и 6 как запас 25%; до 32 округлили для спецификации.
Память: 384 ГБ ECC RDIMM. Расчёт дал 316 ГБ с запасом и памятью для ОС; оставшиеся 68 ГБ не заняты модельной нагрузкой.
Накопители: четыре корпоративных NVMe по 1,92 ТБ в RAID 10. Полезная ёмкость — 3,84 ТБ при расчётных 2 ТБ данных.
Ресурс накопителей: выше 0,83 DWPD по методике для случайной корпоративной нагрузки. Значение получено из 3,2 ТБ записи в сутки при допущении, что на накопитель приходится 1,6 ТБ.
Сеть: два порта. Их пропускную способность выбираем после замера сетевого трафика: в исходных данных такого замера нет.
Питание: два блока питания с независимым подключением. Это снижает риск простоя из-за отказа одного блока, но не заменяет второй узел.
Корпус: стоечный, со свободными слотами памяти и отсеками ещё под одну группу накопителей. Предельный объём RAM проверяем по спецификации выбранной платформы.

Если расчёт памяти не превышает 256 ГБ и роста не ожидается, можно ограничиться 256 ГБ. Результат от 257 до 384 ГБ ведёт к конфигурации на 384 ГБ. При 385–512 ГБ ставим 512 ГБ либо разделяем роли 1С и СУБД между узлами — выбор зависит от загрузки CPU, дисков и требований к простою.

Эту спецификацию можно отправлять поставщику, но только вместе с исходными замерами. Без строки «6 ядер, 60 ГБ памяти и 0,8 ТБ записи на десять одинаковых баз» числа 32, 384 и 0,83 снова превращаются в догадку.