Сервер для 1С на 10–50 пользователей: где нужна мощность, а где начинается переплата

Сервер для 1С часто покупают по принципу «возьмём помощнее, чтобы не возвращаться к вопросу». В итоге часть бюджета уходит в лишние ядра, дорогие накопители не там, где они нужны, или в запас оперативной памяти, который годами не используется. Обратная ошибка — собрать «офисный» сервер, а потом удивляться, почему отчёты тормозят в конце месяца. Ниже — честный buyer guide для сценария 10–50 пользователей: как думать про CPU, ECC память, дисковую подсистему и виртуализацию, чтобы не покупать железо вслепую.

Сначала неудобный вопрос: какая у вас 1С, а не сколько пользователей

Число пользователей — плохая единственная метрика. 20 сотрудников в базе могут создавать разную нагрузку:

• 20 кассиров или операторов, которые вносят документы небольшими порциями;
• 20 бухгалтеров, которые закрывают месяц, формируют тяжёлые отчёты и активно работают с регламентными заданиями;
• 20 пользователей через RDP на том же сервере, где крутится SQL;
• 20 пользователей в терминале плюс обмены, выгрузки, ЭДО, фоновые обработки и резервное копирование в рабочее время.

Перед выбором железа нужно зафиксировать минимум четыре вещи:

1. Архитектура 1С: файловая база или клиент-серверный вариант с SQL. Для 10–50 пользователей обычно уже рассматривают SQL, особенно если база растёт и есть регулярные тяжёлые операции. 2. Где работают пользователи: локальные клиенты, тонкий клиент, веб, RDP/терминальный сервер. RDP резко меняет требования к CPU и памяти. 3. Размер и динамика базы: база 30 ГБ и база 500 ГБ — это разные истории по дискам, резервному копированию и обслуживанию. 4. Критичные периоды: закрытие месяца, массовые обмены, загрузки прайсов, расчёт зарплаты, выгрузки в BI или отчётность.

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

Процессор: не гонитесь только за количеством ядер

Для 1С важны не только ядра. Во многих операциях критична производительность одного потока: частота, архитектура CPU, размер кэша, поведение под длительной нагрузкой. SQL, фоновые задания, RDP-сессии и несколько одновременных тяжёлых отчётов уже требуют большего числа ядер, но «много медленных ядер» не всегда лучше, чем умеренное количество быстрых.

Практичные ориентиры для физического сервера или выделенной ВМ под 1С:

Где начинается переплата:

• брать двухпроцессорную систему только потому, что «сервер должен быть двухпроцессорным»;
• покупать максимальное число ядер при низкой частоте, если основная боль — долгие интерактивные операции;
• закладывать CPU под будущую нагрузку без плана роста базы, пользователей и ролей;
• смешивать на одном сервере 1С, SQL, RDP, файловую шару, резервное копирование и ещё пару сервисов, а потом пытаться лечить это процессором.

Если сервер одновременно будет выполнять роль узла виртуализации, логика другая: нужно считать не только 1С, но и остальные ВМ. Тут уже важны суммарные vCPU, резерв под гипервизор и пики нагрузки. Официальные материалы Microsoft по Hyper-V и документация Proxmox VE полезны именно как напоминание: виртуализация — это не бесплатный слой, она требует планирования ресурсов.

Оперативная память: запас нужен, но он должен быть объяснимым

Для сервера под 1С лучше сразу рассматривать ECC память. Не потому что она «ускоряет» работу — не ускоряет. Её задача другая: снижать риск ошибок памяти, которые на сервере с базами данных могут обойтись дороже, чем разница в цене между обычными модулями и ECC. Для бизнес-критичных баз это не роскошь, а нормальная инженерная практика.

Ориентиры по объёму:

• 10–15 пользователей: обычно от 32 ГБ, если SQL, 1С и ОС находятся на одном сервере и нет тяжёлого RDP.
• 20–30 пользователей: чаще разумнее смотреть на 64 ГБ, особенно если база активно растёт и SQL должен держать кэш.
• 40–50 пользователей: 96–128 ГБ и выше — в зависимости от SQL, терминальных сессий, фоновых обработок и других ролей.

Простой способ прикинуть память:

ОС и служебные процессы: 6–10 ГБ
SQL-кэш: зависит от размера активной части базы, часто десятки ГБ
Сервер 1С и фоновые задания: по нагрузке
RDP-сессии: условно 0,5–1,5+ ГБ на пользователя, зависит от приложений
Резерв: 20–30%, чтобы сервер не жил на пределе

Пример. Есть 25 пользователей, SQL и 1С на одном сервере, RDP нет. База около 120 ГБ, активная часть заметная, отчёты регулярные. 32 ГБ может работать, но быстро станет тесно: SQL будет хуже кэшировать данные, диски получат лишнюю нагрузку. 64 ГБ выглядит более спокойным стартом. 128 ГБ можно рассматривать, если база быстро растёт, есть тяжёлые отчёты, обмены и план расширения, но без этих условий это уже не обязательный первый шаг.

Важно проверить тип памяти, поддерживаемый платформой: ECC UDIMM, RDIMM, LRDIMM — это разные классы, их нельзя произвольно смешивать. Если конфигурация собирается на серверной платформе HUANANZHI, совместимость модулей лучше проверять до покупки, а не после установки.

Диски: для 1С важнее задержки и схема хранения, чем просто терабайты

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

Что обычно стоит разделять:

• системный диск ОС;
• том под базы SQL;
• том под журналы SQL;
• временные файлы и tempdb, если используется Microsoft SQL Server;
• резервные копии — желательно не на тот же массив, где рабочая база.

NVMe SSD дают низкие задержки и хорошую производительность на случайных операциях, но их нужно выбирать не только по «максимальным МБ/с». Для сервера важны ресурс записи, охлаждение, поведение при длительной нагрузке и наличие резервирования. SATA SSD могут быть приемлемы для умеренных сценариев, но на 30–50 активных пользователей с тяжёлыми отчётами и SQL они часто становятся компромиссом.

Типовая практичная схема для 20–30 пользователей:

• 2 SSD/NVMe под ОС и службы, зеркалирование;
• отдельный зеркальный или RAID-массив под SQL-базы;
• отдельный том под журналы и tempdb, если нагрузка это оправдывает;
• отдельное хранилище под бэкапы: другой сервер, NAS, облачный контур или внешняя площадка.

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

Физический сервер или сервер виртуализации: когда есть смысл разделять роли

Для 10–50 пользователей можно идти двумя путями: отдельный физический сервер под 1С или сервер виртуализации, на котором 1С живёт в одной или нескольких ВМ. Оба варианта рабочие, если они правильно спроектированы.

Физический сервер проще:

• меньше слоёв и потенциальных ошибок настройки;
• проще объяснить, куда ушли ресурсы;
• удобно для небольшой инфраструктуры, где 1С — главный сервис.

Виртуализация удобнее, если:

• кроме 1С нужны AD, файловые сервисы, мониторинг, тестовая база, шлюзы, небольшие Linux-сервисы;
• требуется быстро переносить ВМ, делать снапшоты перед обновлениями, гибко выделять ресурсы;
• есть администратор, который понимает Hyper-V, Proxmox VE или другую платформу и умеет следить за дисками, памятью, overcommit и бэкапами ВМ.

Но есть важное ограничение: виртуализация не должна становиться способом «упаковать всё на один сервер без запаса». Если на одном узле одновременно работают SQL, 1С, RDP на 40 пользователей, файловый сервер, видеонаблюдение и резервное копирование, то проблема не в выборе гипервизора. Проблема в плотности нагрузки.

Отдельно про GPU сервер. Для 1С сам по себе GPU обычно не нужен. Видеокарты могут быть оправданы, если на той же инфраструктуре есть VDI с графикой, локальные ИИ-задачи, обработка видео или другие вычисления. Покупать GPU «на всякий случай для 1С» — почти всегда лишняя статья бюджета. Если такие задачи действительно есть, их лучше считать отдельно и не смешивать с базовой конфигурацией бухгалтерского сервера.

Практический пример: 30 пользователей, SQL, без лишнего героизма

Допустим, у компании 30 сотрудников в 1С. Из них 20 работают активно каждый день, 5–7 формируют отчёты, есть обмены с внешними системами, база около 150 ГБ, рост — 5–10 ГБ в месяц. Пользователи подключаются с рабочих мест, RDP для всех не нужен. Требуется нормальная работа в течение дня и предсказуемое закрытие месяца, но без задачи строить кластер высокой доступности.

Разумная отправная точка может выглядеть так:

• CPU: 8–12 производительных ядер с хорошей частотой, без погони за максимальным числом потоков;
• RAM: 64 ГБ ECC как базовый вариант, 128 ГБ — если есть тяжёлые отчёты, быстрый рост базы или план добавить ВМ;
• диски: SSD/NVMe с зеркалированием, отдельное внимание к SQL data/logs/tempdb;
• сеть: 1 Гбит/с минимум, 10 Гбит/с имеет смысл при активной виртуализации, бэкапах и работе с крупными файлами;
• резервное копирование: отдельный контур, регулярная проверка восстановления, а не просто «копии где-то лежат».

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

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

Чек-лист перед покупкой: что проверить, чтобы не переплатить

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

1. Роли сервера

• Только 1С и SQL?
• Будет ли RDP для пользователей?
• Планируются ли дополнительные ВМ?
• Нужны ли файловые сервисы, видеонаблюдение, резервное копирование на том же железе?

2. Пользователи и пики

• Сколько пользователей всего и сколько одновременно активны?
• Кто формирует тяжёлые отчёты?
• Когда идут обмены и регламентные задания?
• Что происходит в закрытие месяца?

3. База и SQL

• Текущий размер базы?
• Темп роста?
• Какая СУБД используется?
• Настроены ли обслуживание индексов, планы обслуживания, регламентные операции?

4. CPU

• Достаточно ли производительности на ядро?
• Не покупаются ли лишние медленные ядра вместо более сбалансированного процессора?
• Есть ли запас под фоновые задачи и обновления?

5. RAM

• Используется ли ECC память?
• Есть ли запас 20–30% после расчёта SQL, ОС, 1С и RDP?
• Оставлены ли свободные слоты для расширения?

6. Диски

• Разделены ли ОС, базы, журналы и бэкапы?
• Есть ли зеркалирование или другой отказоустойчивый массив?
• Подходит ли ресурс SSD под характер записи?
• Проверяется ли восстановление из резервных копий?

7. Типичные ошибки

• выбирать сервер только по числу пользователей;
• экономить на дисках, покупая мощный CPU;
• ставить 1С, SQL, RDP и бэкапы на один перегруженный том;
• считать RAID полноценным бэкапом;
• покупать GPU для 1С без реальной задачи под видеокарты;
• закладывать виртуализацию без администратора, который будет её сопровождать;
• брать конфигурацию «с запасом на всё», но без понятного сценария роста.

Главная мысль простая: хороший сервер для 1С — не самый дорогой и не самый «многоядерный». Это сбалансированная конфигурация под вашу базу, ваших пользователей и ваши пики нагрузки.

Ещё по теме на huananzhi.ru

• Серверы под 1С
• Память для серверов (ECC)

Читайте также

• Рабочая станция для CAD и рендера: где нужны ядра, где решает GPU, а где достаточно памяти
• Сервер видеонаблюдения без сюрпризов: как посчитать камеры, диски и реальный срок архива
• Тихий сервер на Xeon для дома и офиса: как выбрать охлаждение, корпус и вентиляторы без серверного гула

Автор статьи