Как подобрать конфигурацию сервера для 1С 8.3 на 300 пользователей?

Подбор оборудования для крупного внедрения 1С — это сложная инженерная задача, где цена ошибки может привести к простою бизнеса или неэффективным тратам миллионов рублей. Когда количество пользователей переваливает за 250-300 человек, классический подход «один мощный сервер на всё» перестает работать. В данной статье мы разберем оптимальную архитектуру и конкретные характеристики «железа» для стабильной работы 1С:Предприятие 8.3.

Архитектурный подход: разделяй и властвуй

Для начала проанализируем ситуацию: 300 пользователей в тяжелых конфигурациях вроде 1С:ERP или Зарплата и управление персоналом создают колоссальную нагрузку на все подсистемы. Если мы попытаемся запустить терминальный сервер (RDS), сервер приложений 1С и SQL-сервер на одной физической машине, мы неизбежно столкнемся с конкуренцией за ресурсы. Рассмотрим рекомендуемую трехуровневую схему распределения ролей:

1. Сервер СУБД (SQL): основной потребитель оперативной памяти и дискового I/O.
2. Сервер приложений 1С: требует максимально высокой частоты процессора на одно ядро.
3. Терминальная ферма (RDS Farm): группа серверов для работы пользователей в режиме удаленного рабочего стола.

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

Выбор процессора: частота против количества ядер

Выясним важную особенность платформы 1С: многие внутренние механизмы (например, проведение документов) работают в один поток. Это значит, что процессор с 64 ядрами, но низкой частотой (например, 2.0 ГГц), будет работать медленнее, чем «домашний» процессор с 8 ядрами и частотой 5.0 ГГц.

Проанализируем варианты процессоров:

• Для сервера приложений 1С критически важна частота. Рассмотрим модели вроде Intel Xeon Gold серии 64xx или AMD EPYC с технологией 3D V-Cache. Если бюджет ограничен, системные администраторы часто смотрят в сторону десктопных решений типа Core i9-13900K, однако это лишает систему поддержки ECC памяти и серверной надежности.
• Для сервера СУБД (SQL) важно соблюсти баланс. SQL умеет распараллеливать задачи, поэтому здесь количество ядер имеет значение, но частота не должна падать ниже 3.0 ГГц в базовом режиме.

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

// Пример настройки параметров рабочего сервера в консоли администрирования:
Количество соединений на один процесс: 25
Количество рабочих процессов: авто (или по числу ядер)
Объем памяти на один процесс: 4096 МБ

Оперативная память: расчеты для 300 пользователей

Многие ошибочно полагают, что 64 ГБ или 128 ГБ достаточно для такой нагрузки. Проанализируем реальные цифры. На 300 пользователей в режиме ERP расчет должен быть следующим:

1. Терминальный сервер: в среднем 1.5 ГБ на одного пользователя. Итого: 300 * 1.5 = 450 ГБ. Рекомендуем разделить это на 3 сервера по 160 ГБ RAM.
2. Сервер приложений 1С: требует от 64 до 128 ГБ под кэш и рабочие процессы rphost.
3. SQL-сервер: здесь работает правило «чем больше, тем лучше». Для базы объемом 500 ГБ желательно иметь минимум 256 ГБ RAM, чтобы SQL мог держать наиболее активные таблицы и индексы в памяти (Buffer Pool).

Дисковая подсистема: забудьте про SATA SSD

Для 300 активных пользователей стандартные SSD с интерфейсом SATA станут «бутылочным горлышком». Разберем, почему. Максимальная скорость SATA — около 550 МБ/с, а количество операций ввода-вывода (IOPS) редко превышает 100 000. Рассмотрим современные решения:

Необходимо использовать только NVMe Enterprise накопители. Они подключаются напрямую к шине PCI Express, обеспечивая скорости до 7000-10000 МБ/с и IOPS на уровне 1 000 000+. При выборе дисков обязательно смотрим на параметр DWPD (Drive Writes Per Day). Для баз данных он должен быть не менее 3 (интенсивная запись).

Посмотрим на схему организации дисковых массивов:

• Массив 1 (RAID 1 NVMe): ОС и файлы сервера 1С.
• Массив 2 (RAID 10 NVMe): Файлы базы данных SQL (MDF) и файлы логов (LDF). Разнесение логов и данных на разные физические диски — классическая, но всё еще актуальная рекомендация.
• Массив 3 (RAID 1 SATA/SAS): Резервные копии и временные файлы.

Тонкий клиент и веб-сервер как альтернатива RDP

Если ваши 300 пользователей раскиданы по всей России, работа через классический RDP может быть затруднена из-за задержек в сети (latency). Проанализируем ситуацию: при плохом канале связи картинка в терминале будет «рассыпаться».

В этом случае рассмотрим переход на Тонкий клиент 1С. Он передает только данные, а отрисовка интерфейса происходит на локальной машине пользователя. Это значительно снижает нагрузку на сервер (не нужно держать сотни сессий explorer.exe) и экономит трафик. Для этого потребуется поднять веб-сервер (Apache или IIS) и опубликовать базу.

Пример настройки default.vrd для публикации базы:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/Trade"
       ib="Srvr="MainServer";Ref="TradeDB";">
    <standardOdata enable="true" />
</point>

Итоги и конкретная спецификация

Подведем итог нашего анализа. Для стабильной работы 300 пользователей 1С 8.3 нам потребуется комплексное решение. Разберем примерную спецификацию серверного парка:

1. Сервер СУБД + Приложения (физический мощный сервер или кластер):

• Процессор: 2x Intel Xeon Gold 6434 (8 ядер на сокет, частота 3.7 - 4.1 ГГц).
• Память: 512 ГБ DDR5 ECC.
• Диски: 4x 1.6TB NVMe Enterprise в RAID 10.

2. Терминальная ферма:

• 3 виртуальных или физических сервера.
• Процессор: Минимум 12-16 ядер на каждый.
• Память: 128 - 192 ГБ RAM на каждый сервер.

Важный момент: не забудьте настроить регламентные задания в SQL. Выясним причину тормозов в понедельник утром — часто это отсутствие свежей статистики. Обязательно настройте ежедневное обновление статистик и дефрагментацию индексов. Это позволит оптимизатору SQL строить правильные планы запросов, что критично при больших объемах данных в ERP.

Используя данный системный подход, мы обеспечим не только текущую работу 300 пользователей, но и создадим задел для масштабирования системы в будущем.