← На главную

Переход со старого серверного оборудования на новое — всегда ответственный шаг для системного администратора. Ситуация усложняется, когда бюджет ограничен, а на одном физическом сервере планируется объединить сразу несколько критически важных ролей: сервер терминалов (RDS), сервер СУБД (MS SQL или PostgreSQL), сервер приложений 1С и файловое хранилище. Рассмотрим подробно, как правильно подобрать комплектующие для такой системы, избежать классических ошибок с производительностью и настроить сервер для максимального быстродействия.

Анализ исходной задачи и инфраструктурных ограничений

В нашем сценарии развертывания исходные данные следующие:

1. Количество пользователей: до 30 терминальных подключений (активно работают одновременно около 10–15 пользователей).
2. Базы данных: УПП (Управление производственным предприятием) объемом около 9 ГБ и ЗУП (Зарплата и управление персоналом) объемом 2 ГБ.
3. Текущее состояние: базы работают в файловом режиме на старом сервере с выходящим из строя дисковым контроллером.
4. Планируемый стек: переход на клиент-серверный вариант (СУБД + сервер 1С) совмещенный с терминальным сервером на одной физической машине.

Прежде всего выясним причину, почему файловый режим работы при 30 пользователях — это крайне опасная практика. В файловом режиме блокировки происходят на уровне таблиц, а не отдельных записей. При одновременной работе более 5–7 пользователей неизбежно возникают микрозависания, а при аварийном завершении сессии (например, из-за сетевого сбоя или отключения питания) велик риск физического повреждения базы данных. Переход на полноценную СУБД полностью решает эту проблему.

Процессор для 1С: почему много ядер вредит производительности?

Разберем по шагам логику выбора центрального процессора. Это самый важный компонент сервера 1С, и именно здесь чаще всего совершают дорогостоящие ошибки. Руководство или поставщики часто предлагают купить многопроцессорные системы на базе младших линеек Intel Xeon Bronze или Silver (например, 12-16 ядер с частотой 2.1–2.4 ГГц).

Для 1С это решение будет катастрофически медленным!

Бизнес-логика платформы 1С:Предприятие устроена так, что большинство операций (проведение документов, расчет себестоимости, формирование отчетов) выполняются в один поток. Соответственно, производительность системы напрямую зависит от скорости работы одного ядра (показатель Single-Core Performance), то есть от тактовой частоты процессора и его архитектуры (IPC). Многоядерность важна для параллельной работы множества пользователей, но частота каждого ядра должна быть максимально возможной.

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

• Intel Xeon E-2146G / E-2246G: Отличный выбор для небольшого сервера. Имеет 6 ядер, 12 потоков и базовую частоту 3.5 ГГц (с возможностью авторазгона Turbo Boost до 4.5 ГГц). Поддерживает серверную память с коррекцией ошибок ECC.
• Intel Core i7-8700K / i9-9900K (или современные аналоги серии i7-13700 / i7-14700): Обладают колоссальной производительностью на одно ядро (частота более 5 ГГц). Однако десктопные процессоры не поддерживают ECC-память и специализированные серверные материнские платы с удаленным управлением (IPMI).
• Линейка Intel Xeon E-2300 (например, Xeon E-2388G): Современная альтернатива серии 2100/2200 с улучшенной архитектурой и более высокой производительностью на такт.

Для стабильной работы сервера 1С в BIOS обязательно нужно отключить все функции энергосбережения (C-States, Intel SpeedStep) и перевести профиль электропитания в режим Maximum Performance. Это заставит процессор всегда работать на максимальной тактовой частоте, исключая задержки на «разогрев» ядер при поступлении запроса от пользователя.

Оперативная память: расчет реальных потребностей

Автор исходной темы планирует установить 32 ГБ оперативной памяти. Проверим, хватит ли этого объема для совмещенного сервера.

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

1. Операционная система (Windows Server): требует для стабильной работы около 3–4 ГБ.
2. СУБД (MS SQL Server / PostgreSQL): для эффективной работы базы данных СУБД должна кэшировать таблицы в оперативной памяти. Для баз УПП (9 ГБ) и ЗУП (2 ГБ) желательно выделить СУБД не менее 8–10 ГБ.
3. Сервер приложений 1С: рабочий процесс rphost при активной работе пользователей потребляет в среднем от 3 до 6 ГБ памяти (при формировании тяжелых отчетов потребление может кратковременно вырастать).
4. Терминальный сервер (RDS): на каждого пользователя 1С в терминальном режиме уходит в среднем 700–1000 МБ памяти (с учетом запущенного тонкого/толстого клиента, операционной системы сессии и минимального набора офисных программ). Для 30 пользователей потребуется от 20 до 30 ГБ.

Сложим полученные показатели: 4 ГБ (ОС) + 10 ГБ (SQL) + 6 ГБ (1С) + 25 ГБ (RDS) = 45 ГБ.

Очевидно, что 32 ГБ памяти для такой совмещенной конфигурации — это критический минимум. Система будет постоянно сбрасывать данные в файл подкачки на диски, что сведет на нет все преимущества быстрых процессоров. Рекомендуемый объем памяти для данного сервера — 64 ГБ ECC DDR4/DDR5 двумя или четырьмя модулями для обеспечения многоканального режима работы.

Дисковая подсистема: потребительские SSD против серверных

В обсуждении упоминается использование четырех потребительских дисков Samsung 860 Pro в RAID-массиве. Посмотрим на технические риски такого решения.

Главное отличие серверных SSD от потребительских (Consumer) — это наличие технологии PLP (Power Loss Protection). Серверные накопители оснащены блоком конденсаторов. В случае внезапного отключения электроэнергии накопленного заряда хватает для того, чтобы контроллер успел сбросить данные из быстрого кэша диска в энергонезависимую память.

У потребительских накопителей (таких как Samsung Evo/Pro) защиты PLP нет. При отключении питания данные из кэша диска теряются, что при работе с базой данных СУБД гарантированно приводит к логическому разрушению базы (corruption) или потере транзакций СУБД. Поэтому для баз данных крайне рекомендуется использовать специализированные серверные SSD начального уровня (например, серии Samsung PM893 или аналоги от Intel/Solidigm).

Также важно уделить внимание дисковому контроллеру и RAID. Если вы используете встроенный в материнскую плату RAID-контроллер (чипсетный Intel RSTe), помните, что он не имеет собственной кэш-памяти и батарейки резервного питания (BBU/TFM). Чтобы защитить данные, контроллер может автоматически отключить кэширование записи накопителей, из-за чего скорость записи упадет в десятки раз (до 20–30 МБ/с).

Рассмотрим два варианта решения проблемы:

1. Программный RAID (Software RAID): Средствами операционной системы (динамические диски в Windows Server или ZFS/mdadm в Linux). Программный RAID-1 на SSD работает очень быстро, не требует дорогостоящих контроллеров и легко переносится на другое железо в случае аварии.
2. Отказ от RAID в пользу частых бэкапов: Для небольших баз данных отличной стратегией является использование двух независимых быстрых NVMe SSD (один под ОС и базы, второй — под бэкапы и логи), дополненное ежечасным резервным копированием на внешний сетевой диск (NAS).

Тонкая настройка SQL Server и 1С при совместном размещении

Когда сервер 1С и СУБД MS SQL работают на одной физической машине, обязательно нужно настроить их локальное взаимодействие. По умолчанию обмен данными идет по сетевому протоколу TCP/IP, даже если программы находятся на одном компьютере. Это создает лишнюю нагрузку на сетевой стек ОС.

Посмотрим, как оптимизировать эту связку:

1. Протокол Shared Memory (Общая память): Включите использование общей памяти в настройках SQL Server Configuration Manager (раздел Client Protocols). Это позволит серверу 1С напрямую читать и писать данные в память SQL Server минуя сетевую карту, что ускоряет выполнение запросов на 10–15%.
2. Ограничение памяти для SQL Server: По умолчанию MS SQL стремится занять всю доступную оперативную память сервера. В свойствах сервера СУБД в среде SQL Server Management Studio (SSMS) жестко ограничьте параметр Max Server Memory. Например, если на сервере установлено 64 ГБ, выделите под SQL не более 16–20 ГБ, оставив остальное под терминалы и сервер 1С.
3. Настройка TempDB: Системная база данных TempDB активно используется платформой 1С для временных таблиц. Разместите файлы TempDB на самом быстром SSD (в идеале NVMe). Разделите TempDB на несколько файлов данных (количество файлов должно быть равно числу физических ядер процессора, но не более 8).

Виртуализация — современный стандарт развертывания

Установка операционной системы Windows Server прямо на «голое железо» (Bare Metal) в современных реалиях не рекомендуется. Гораздо эффективнее развернуть бесплатный гипервизор (например, Proxmox VE, VMware ESXi или Microsoft Hyper-V Server) и запустить сервер 1С и СУБД внутри виртуальной машины.

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

• Быстрое резервное копирование: Вы можете делать моментальные снимки (снапшоты) всей виртуальной машины перед обновлением конфигураций или платформы 1С.
• Независимость от железа: В случае выхода из строя физического сервера, виртуальную машину с настроенной 1С и пользователями можно запустить на любом другом компьютере за несколько минут.
• Разделение ресурсов: При необходимости вы можете легко выделить терминальный сервер в отдельную виртуальную машину, изолировав его от базы данных СУБД.

Итоговая оптимальная спецификация оборудования

Исходя из нашего анализа, соберем сбалансированную и надежную спецификацию сервера 1С под нагрузку до 30 пользователей в рамках разумного бюджета:

• Процессор: Intel Xeon E-2388G (8 ядер, 16 потоков, базовая частота 3.2 ГГц, Turbo Boost до 5.1 ГГц). Это идеальный баланс между высокой частотой на одно ядро и достаточным количеством потоков для терминалов.
• Материнская плата: Серверная плата Supermicro (например, на чипсете Intel C256) с поддержкой IPMI (удаленного администрирования).
• Оперативная память: 64 ГБ (2 x 32GB) DDR4 ECC Unbuffered 3200MHz.
• Дисковая подсистема:
  • 2 x SSD SATA Enterprise (например, Samsung PM893 480GB) в программном зеркале (RAID-1) под операционную систему, СУБД и базы 1С.
  • 1 x NVMe SSD (например, Samsung 980 Pro / PM9A1) под базу TempDB и файлы кэша.
  • 1 x HDD или недорогой SSD большого объема под локальные резервные копии (бэкапы также обязательно должны дублироваться на внешнее сетевое устройство или в облако).
• Блок питания: Отказоустойчивый блок питания с возможностью горячей замены (Redundant Power Supply 1+1). Один блок питания подключаем к обычному источнику, второй — через надежный ИБП (источник бесперебойного питания).

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