В 1С одновременно работают 50 человек, база выросла до 200 ГБ, а проведение документов задерживается на несколько секунд. Один поставщик предлагает 64 ГБ памяти, другой — 256 ГБ. Обе конфигурации подписаны одинаково: «сервер на 50 пользователей».

Число учётных записей не объясняет нагрузку. Чтобы заказать сервер и защитить смету перед директором, нужны четыре параметра: одновременные сеансы, размер базы, фоновые задания и требования к простою. Ниже — расчёт для 50 активных пользователей и одной базы около 200 ГБ.

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

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

Перед запросом поставщику зафиксируй:

максимальное число одновременных сеансов;
текущий размер активной базы;
число обменов и тяжёлых регламентных заданий;
прогноз роста на ближайшие 2–3 года.

Запас на 2–3 года позволяет пережить рост базы без внеплановой замены платформы. Но «удвоим всё на всякий случай» — не расчёт. Если сейчас одновременно работают 35 человек, а штат прибавляет по пять человек в год, заложи нагрузку на 45–50 сеансов. Не покупай ресурсы под сто.

Файловый режим для такой установки не подходит. После десяти пользователей его скорость снижается, а эксплуатацию более чем с пятнадцатью пользователями источник называет критической ошибкой. Для пятидесяти сеансов нужна клиент-серверная схема: сервер 1С плюс PostgreSQL или MS SQL.

Теперь можно считать железо.

Процессору нужны быстрые ядра, а не большое число ядер в спецификации

Один пользовательский сеанс 1С в основном зависит от производительности одного ядра. Поэтому частота и IPC влияют на время проведения документа сильнее, чем два десятка медленных ядер.

Для 30–100 пользователей ориентир такой: 8–12 ядер с частотой 3,2–3,8 ГГц. Нижняя граница для процессора 1С — 3 ГГц. Смотри не только на пиковую частоту: сервер должен удерживать высокую частоту под продолжительной нагрузкой, а не показывать её несколько секунд на одном ядре.

Восемь ядер подойдут, если у тебя одна база, умеренные обмены и нет тяжёлых отчётов в рабочее время. Двенадцать дадут запас под параллельные запросы, СУБД и фоновые задания.

Больше ядер нужно не из-за магического порога в 50 пользователей. Конфигурация с 24-ядерным Xeon Gold 6342 рассчитана на диапазон 50–100 пользователей, несколько баз или параллельные фоновые операции. Для одной базы на 50 сеансов такой процессор может оказаться дорогим запасом, который не сократит время отдельной операции.

Между 12 быстрыми и 24 медленными ядрами для этого сценария я бы выбрал 12 быстрых. Исключение — несколько рабочих баз, частые обмены и регламентные задания, которые нельзя вынести за пределы рабочего дня.

Для базы на 200 ГБ рабочая точка — 128 ГБ ECC

Минимальный расчёт памяти для сервера приложений выглядит скромно: 2 ГБ плюс 0,5 ГБ на каждого активного пользователя. Для 50 сеансов получается 27 ГБ. Но эти 27 ГБ не покрывают кэш СУБД, операционную систему и рост базы.

Практические диапазоны дают другую картину:

64 ГБ — для 30–50 пользователей и базы объёмом 50–100 ГБ;
128 ГБ — для 50–100 пользователей и базы объёмом 100–300 ГБ.

При базе около 200 ГБ бери 128 ГБ ECC RDIMM. Память стоит установить так, чтобы сохранить свободные каналы и слоты для расширения до 256 ГБ. Если поставить восемь модулей в восемь доступных слотов, следующий апгрейд потребует выбросить часть комплекта.

Вариант на 64 ГБ оправдан при базе до 100 ГБ, небольшом числе фоновых заданий и подтверждённом пике не выше 30–40 сеансов. Экономия на памяти в базе объёмом 200 ГБ уменьшит кэш СУБД и вернёт чтение на диски.

С другой стороны, 256 ГБ нельзя считать обязательным минимумом. Такой объём имеет смысл при 40–60 активных сеансах с интенсивным обменом, нескольких базах или быстром росте данных. Если этих условий нет, сначала поставь 128 ГБ и сохрани возможность расширения.

Под базу нужны четыре NVMe в RAID 10

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

Для активной базы рекомендуют выделить не меньше 200–300 ГБ. Отдельно нужен запас под журнал транзакций, временные данные, обслуживание и рост: ориентир составляет 3–5 ГБ свободного места на пользователя. Поэтому накопитель нельзя выбирать по размеру текущего файла базы.

Базовая дисковая схема — 4 × 960 ГБ NVMe в RAID 10. После зеркалирования она даст около 1,92 ТБ сырой полезной ёмкости до накладных расходов файловой системы и контроллера. Этого хватит для базы на 200 ГБ, журналов, временных файлов и роста без заполнения массива под завязку.

NVMe обеспечивают от 3000 МБ/с при последовательном чтении и 200–500 тысяч IOPS в зависимости от модели и нагрузки. Для 1С важнее не паспортная скорость чтения, а задержка и число операций со случайным доступом.

RAID 10 переживёт отказ одного диска и не создаст штрафа на запись, характерного для RAID 5. RAID 5 для рабочей базы 1С брать не стоит: пересчёт чётности увеличивает задержку записи, особенно на смешанной нагрузке.

У RAID-контроллера проверь защищённый кэш объёмом от 2 ГБ. Без защиты питания контроллер не должен подтверждать запись до её сохранения на накопителях — иначе ускорение оплачивается риском потерять подтверждённую транзакцию.

Для базы, которая приближается к 300 ГБ и быстро растёт, можно перейти на 4 × 1,92 ТБ NVMe в RAID 10. При интенсивной записи журналов — вынести их на 2 × 960 ГБ NVMe в RAID 1. Такая схема входит в конфигурацию для 50–100 пользователей, но для спокойной базы на 200 ГБ отдельный массив журналов не обязателен.

Один сервер выдержит нагрузку, если бизнес допускает простой

Для одной базы и пятидесяти пользователей можно разместить сервер приложений и СУБД в одном корпусе. Конфигурация на 8–12 быстрых ядер, 128 ГБ ECC и четырёх NVMe в RAID 10 соответствует этой нагрузке.

Виртуализация упростит резервное копирование и разделит роли, но не ускорит 1С. Гипервизор забирает 5–15% производительности, поэтому для установок на 50 и более пользователей физический сервер предпочтительнее виртуальной машины, если изоляция не нужна по другим причинам.

Граница между одним и несколькими серверами проходит не ровно по числу пользователей. Разделять сервер 1С и СУБД стоит, когда выполняется хотя бы одно условие:

активная база превысила 200 ГБ и продолжает быстро расти;
одновременно работают больше 45 пользователей;
бизнес требует работы 24/7 и не принимает простой одного узла.

Для отказоустойчивой схемы понадобятся не просто два одинаковых корпуса. Источник рекомендует два узла приложений, отдельный сервер СУБД с репликацией и сеть 10/25 Гбит/с между ними; гигабитное соединение в такой архитектуре может ограничить обмен.

Это уже другой бюджет и другой результат. Один сервер с резервными блоками питания переживёт отказ БП или диска, но не отказ системной платы. Кластер продолжит работу после потери узла, зато потребует больше оборудования, лицензий и времени на сопровождение.

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

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

Для одной активной базы около 200 ГБ и 50 одновременных пользователей отправь поставщику такую конфигурацию:

один процессор на 8–12 ядер с рабочей частотой 3,2–3,8 ГГц;
128 ГБ ECC RDIMM с расширением до 256 ГБ без замены установленных модулей;
4 × 960 ГБ NVMe с ресурсом записи, подходящим для серверной нагрузки;
RAID 10 и контроллер с защищённым кэшем от 2 ГБ;
минимум два сетевых порта 1 GbE;
два блока питания с горячей заменой;
свободные отсеки под отдельный массив журналов или рост базы.

Попроси поставщика указать точную модель процессора, базовую частоту, схему установки памяти, ресурс записи накопителей, модель RAID-контроллера и число свободных отсеков. Формулировка «аналогичный компонент» здесь не годится: замена процессора или NVMe может изменить поведение всей системы.

Развилка по памяти простая. При базе до 100 ГБ и умеренных фоновых заданиях можно оставить 64 ГБ. Для базы 100–300 ГБ бери 128 ГБ. На 256 ГБ переходи после замеров или при нескольких базах и активных обменах.

Развилка по архитектуре жёстче. Если компания принимает остановку на время ремонта одного сервера, хватит одного корпуса с резервными БП и RAID 10. Если простой останавливает продажи, склад или производство, одной спецификацией сервера задача не закрывается: считай два узла приложений, отдельную СУБД и сеть 10/25 Гбит/с.