Для десяти пользователей предлагают две конфигурации. В одной — 8 ядер, 16 ГБ RAM и накопитель на 240 ГБ. В другой — 6–8 ядер, 32 ГБ RAM и диски на 200–500 ГБ.

Обе рекомендации отталкиваются от числа сотрудников. Но база на 20 ГБ без обменов и база на 100 ГБ с фоновыми заданиями нагружают сервер по-разному.

Посчитаем конкретный сценарий: клиент-серверная 1С, 10 одновременных пользователей и одна база на 100 ГБ. СУБД, фоновые задания и обмены работают на том же сервере.

Поставщику можно передать такую спецификацию:

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

Считать нужно нагрузку, а не сотрудников

Число пользователей описывает лишь часть нагрузки. На выбор сервера также влияют размер базы, СУБД, отчёты, обмены и регламентные задания.

Руководство Rack&Roll предлагает считать одновременные сеансы. В расчёт также входят прирост базы, фоновые процессы, терминальный доступ и архитектура системы.

Зафиксируем пять исходных условий:

К расчётным CPU и RAM добавим резерв 25%. Это середина диапазона 20–30%, который ServerMall и GSE рекомендуют для обычного рабочего пика.

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

Процессор: восемь быстрых ядер вместо десятков медленных

Для 5–15 пользователей WCloud указывает 6–8 ядер с частотой от 3,2 ГГц. Наш сценарий включает СУБД, обмены и фоновые задания, поэтому берём верхнюю границу — 8 ядер.

Дополнительные ядра распределят параллельные процессы. Однако низкую скорость отдельного ядра они не исправят.

Проведение документов, часть запросов и логика приложения идут последовательно. Это же ограничение описывает GSE в руководстве по выбору CPU, памяти и дисков для 1С. Поэтому 16 медленных ядер могут откликаться хуже, чем восемь быстрых.

Частота от 3,2 ГГц — нижний ориентир, а не достаточное условие. Сравнивайте процессоры одного поколения и смотрите, какую частоту они держат под длительной нагрузкой.

Максимальная частота из спецификации тоже не даёт полного ответа. Она может действовать для одного ядра и лишь короткое время. Подробный разбор есть в материале о том, как связать параметры CPU с операциями 1С.

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

Память: расчёт даёт 43 ГБ, с резервом — 53,75 ГБ

WCloud приводит такую формулу для ориентировочного расчёта RAM:

пользователи × 1,5 ГБ + 20% размера базы + 8 ГБ

Последние 8 ГБ отводятся под ОС и СУБД. Формула не заменяет замеры работающей системы. Она нужна как отправная точка до покупки сервера.

Подставляем исходные данные:

10 × 1,5 ГБ + 100 ГБ × 20% + 8 ГБ = 43 ГБ

Теперь добавляем резерв 25%:

43 ГБ × 1,25 = 53,75 ГБ

Серверу нужно не менее 53,75 ГБ. Берём 64 ГБ: такой комплект закрывает расчёт и сохраняет заложенный запас.

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

Размер базыРасчёт без резерваС резервом 25%Требование к памяти
50 ГБ15 + 10 + 8 = 33 ГБ41,25 ГБне менее 41,25 ГБ; спецификация на 64 ГБ
100 ГБ15 + 20 + 8 = 43 ГБ53,75 ГБспецификация на 64 ГБ
200 ГБ15 + 40 + 8 = 63 ГБ78,75 ГБне менее 78,75 ГБ; округление по схеме модулей платформы

Вывод: память считают по активным сеансам и размеру базы, а не по штатному расписанию.

Для базы на 200 ГБ комплекта из 64 ГБ уже мало. Полученный объём нужно округлить вверх, не нарушая симметричное заполнение каналов.

GSE рекомендует использовать одинаковые модули и равномерно заполнять каналы. Поэтому сначала проверьте схему памяти платформы, а затем набирайте нужный объём. Случайный набор планок может лишить систему части пропускной способности.

Для Microsoft SQL Server после запуска задайте предел памяти. Rack&Roll советует выбирать его по реальному потреблению. Иначе СУБД может занять RAM, которая нужна ОС, кластеру 1С и служебным процессам.

Диски: 500 ГБ нужны не ради сегодняшних 100 ГБ

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

В материале на Habr средний годовой прирост базы 1С оценён в 20–30%. Для расчёта возьмём середину — 25%.

Через три года получаем:

100 ГБ × 1,25³ ≈ 195 ГБ

Здесь мы предполагаем одинаковый рост каждый год. Если ваша база ежегодно прибавляет 40%, замените коэффициент 1,25 на 1,40.

Два накопителя по 480–500 ГБ в RAID 1 дадут около 480–500 ГБ рабочего пространства до служебных потерь. Этого достаточно для рассчитанного роста базы, ОС, журналов и запаса.

RAID 1 записывает одинаковые данные на два диска. После отказа одного накопителя сервер продолжит работать. Но резервной копией такое зеркало не станет.

Удаление файла, ошибка обмена или шифровальщик затронут оба диска. Храните бэкапы вне рабочего сервера и регулярно проверяйте, что они восстанавливаются.

Под базу нужны серверные SSD или NVMe. Rack&Roll отдельно называет защиту от потери питания и предсказуемый ресурс записи. У потребительского SSD этих свойств может не быть.

Интерфейс выбирают по характеру операций. SATA SSD подходит для умеренной нагрузки. NVMe нужен при большом числе одновременных операций и строгих требованиях к задержке.

СценарийНакопителиRAIDСетьОснование выбора
Умеренная работа, одна базасерверные SATA SSDRAID 11 GbEдесять пользователей, обычные документы и отчёты
Частая запись и фоновые заданиясерверные NVMeRAID 11 GbEменьше задержка при параллельных операциях
Интенсивная запись и несколько базсерверные NVMeRAID 101 или 10 GbE после проверки трафикаRAID 10 лучше подходит для активной записи
Тяжёлые обмены или несколько серверовсерверные NVMeпо профилю записи10 GbEсеть может ограничить обмен и сетевое копирование

Вывод: NVMe и 10 GbE нужны при соответствующей задержке и трафике, а не ради более дорогой строки в счёте.

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

Сеть: для этого сценария хватает 1 GbE

WCloud называет 1 GbE базовым минимумом для сервера 1С. Одной базе и десяти активным пользователям такой скорости достаточно.

Переход на 10 GbE оправдан при тяжёлых обменах, нескольких серверах или более чем 30 активных пользователях. Эти условия также перечисляет WCloud.

Одна сетевая карта на 10 GbE систему не ускорит. Ту же скорость должны поддерживать коммутатор, кабели и принимающая сторона.

Перед покупкой посмотрите загрузку текущего интерфейса в рабочие часы. Если пики далеки от предела 1 GbE, задержку создаёт другой узел.

Где появляется переплата

Первая ошибка — считать ядра и не смотреть на их скорость. Десятки медленных ядер солидно выглядят в коммерческом предложении, но последовательные операции 1С от этого быстрее не станут.

Вторая ошибка — ставить 128 ГБ RAM без расчёта. В нашем сценарии получилось 53,75 ГБ вместе с резервом. Значит, комплект на 64 ГБ закрывает потребность.

Для 128 ГБ нужен другой профиль нагрузки. GSE связывает такой объём с большим числом пользователей, быстрым ростом базы и постоянными регламентными заданиями.

Третья ошибка — добавлять 10 GbE «на будущее». Для десяти пользователей достаточно 1 GbE, что совпадает с рекомендацией WCloud.

Четвёртая ошибка — считать только корпус и комплектующие. К ним добавятся лицензии 1С, ОС, СУБД, настройка и последующее сопровождение.

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

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

Спецификация для поставщика

Для клиент-серверной 1С на десять активных пользователей и базы 100 ГБ передайте поставщику такие требования:

УзелТребованиеПочему так
Процессор8 ядер, частота от 3,2 ГГцверхняя граница ориентира для 5–15 пользователей; важна скорость ядра
Оперативная память64 ГБ ECCрасчёт дал 53,75 ГБ с резервом
Установка памятиодинаковые модули, симметрично по каналамплатформа использует пропускную способность нескольких каналов
Рабочие накопителидва серверных SSD или NVMe по 480–500 ГБбаза может вырасти примерно до 195 ГБ за три года
Дисковый массивRAID 1подходит небольшой системе и переживает отказ одного диска
Сетевой интерфейс1 GbEбазовый уровень для выбранного числа пользователей
Резервное копированиеотдельный носитель или удалённое хранилищеRAID не защищает от удаления и повреждения данных

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

Если нагрузка изменится, пересчитайте три параметра. Для RAM подставьте новое число пользователей и размер базы. Для дисков используйте фактический годовой рост вместо принятых 25%.

Проверяйте необходимость 10 GbE при тяжёлых обменах, нескольких серверах или более чем 30 активных пользователях. Память от 128 ГБ нужна при нескольких базах и постоянных регламентных заданиях.

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

дисковые массивы оперативная память подбор оборудования процессор сервера сервер 1с