Развертывание производительной инфраструктуры под нужды 1С — это всегда компромисс между бюджетом, надежностью и быстродействием. Особенно остро этот вопрос встает в организациях среднего масштаба, где количество активных пользователей приближается к 50, а в распоряжении администратора имеется всего один физический сервер. В этой статье мы подробно проанализируем реальный кейс: сервер на базе двух процессоров Intel Xeon E5-2680v2 со 128 ГБ оперативной памяти, на котором необходимо запустить связку из сервера 1С, СУБД MS SQL и терминального сервера (RDP) для работы конфигураций «Бухгалтерия предприятия 3.0» (БП) и «Управление торговлей 11» (УТ).
Рассмотрим детально, стоит ли объединять все службы в рамках одной операционной системы, безопасно ли делить сервер на виртуальные машины и как правильно организовать работу пользователей без потери производительности. Выясним скрытые технические нюансы, которые часто упускают из виду при проектировании подобных систем.
Вариант 1. Всё на одной физической системе (All-in-One)
Этот подход предполагает установку операционной системы Windows Server непосредственно на «железо» и развертывание на ней роли RDS (Remote Desktop Services), сервера приложений 1С:Предприятие и СУБД MS SQL. Рассмотрим основные преимущества и недостатки такой схемы.
Преимущества:
Максимальная производительность СУБД и 1С: При расположении сервера приложений 1С и MS SQL в рамках одной операционной системы они могут взаимодействовать по протоколу Shared Memory (общая память). Это исключает сетевые задержки и накладные расходы на упаковку/распаковку TCP-пакетов, что дает прирост скорости обмена данными до 15–20% по сравнению с сетевым протоколом TCP/IP.
Отсутствие накладных расходов на виртуализацию: Нет потерь процессорного времени и оперативной памяти на работу гипервизора и дополнительных гостевых ОС.
Недостатки:
Уязвимость системы безопасности: Пользователи терминала (RDP) работают в той же операционной системе, где запущены критически важные службы СУБД и сервер 1С. Любая уязвимость нулевого дня или неосторожные действия пользователя с правами на запись в системные папки могут привести к компрометации баз данных.
Конкуренция за ресурсы: Терминальные сессии пользователей непредсказуемы. Если один из пользователей запустит тяжелый отчет или ресурсоемкое локальное приложение, операционная система может забрать кванты процессорного времени у критически важных процессов rphost (1С) и sqlservr (SQL). Это приведет к микрофризам у всех остальных сотрудников.
Сложность администрирования: Обновление платформы 1С, операционной системы или перезагрузка терминального сервера для применения обновлений потребует полной остановки всей работы предприятия.
Вариант 2. Разделение на две виртуальные машины (Hyper-V / VMware)
Второй сценарий предполагает установку гипервизора (например, Microsoft Hyper-V или VMware ESXi) на физический сервер и создание двух гостевых виртуальных машин (ВМ):
ВМ 1: Сервер СУБД MS SQL + Сервер приложений 1С:Предприятие.
ВМ 2: Терминальный сервер (RDP) для работы пользователей с тонкими клиентами 1С.
Проанализируем этот вариант с точки зрения распределения ресурсов и производительности.
Преимущества:
Изоляция сред: Пользователи терминала изолированы от баз данных. В случае сбоя или зависания терминальной службы СУБД и сервер 1С продолжат работать в штатном режиме.
Простота обслуживания: Терминальную виртуальную машину можно перезагружать, обслуживать и обновлять независимо от сервера баз данных. Вы можете легко делать резервные копии (снапшоты) терминального сервера перед установкой обновлений ПО.
Гибкое распределение ресурсов: Средства гипервизора позволяют жестко ограничить лимиты процессорного времени и оперативной памяти для терминального сервера, предотвращая монополизацию ресурсов одной службой.
Недостатки:
Потеря протокола Shared Memory: Поскольку 1С и SQL остаются в одной виртуалке, внутри нее протокол Shared Memory продолжит работать. Однако взаимодействие между терминальной виртуалкой (где запущены тонкие клиенты) и сервером 1С будет происходить исключительно по виртуальной сети через TCP/IP, что вносит небольшие задержки.
Дефицит оперативной памяти: Это критический фактор для рассматриваемой конфигурации. Давайте произведем детальный расчет распределения оперативной памяти, чтобы понять масштаб проблемы.
Реальный баланс оперативной памяти: почему 128 ГБ — это впритык
Разберем детально, как будут расходоваться 128 ГБ оперативной памяти при делении сервера на две виртуальные машины:
Потребление терминального сервера (RDP): Для комфортной работы одной сессии пользователя в конфигурациях на управляемых формах (БП 3.0, УТ 11) требуется в среднем 1.5 ГБ оперативной памяти. На 50 активных пользователей получаем:
50 пользователей * 1.5 ГБ = 75 ГБ ОЗУ
Потребление MS SQL Server: Чтобы базы данных объемом в несколько десятков гигабайт работали быстро, СУБД должна кэшировать наиболее часто используемые таблицы в оперативной памяти. Для 50 активных пользователей СУБД необходимо выделить как минимум:
32 ГБ ОЗУ
Потребление Сервера 1С: Рабочие процессы сервера приложений rphost под нагрузкой от 50 пользователей потребуют не менее:
16 ГБ ОЗУ
Накладные расходы операционных систем: На работу хостовой ОС (гипервизора) и двух гостевых операционных систем Windows Server потребуется суммарно около:
Как видим, суммарная потребность превышает физически доступный объем памяти сервера (128 ГБ). При попытке запустить такую конфигурацию система неизбежно столкнется с нехваткой памяти, что приведет к активному использованию файла подкачки (свопингу) на жестких дисках. Свопинг мгновенно парализует работу 1С, вызывая задержки при проведении документов и формировании отчетов.
Вариант 3. Оптимальное решение — отказ от терминального сервера в пользу локальных тонких клиентов
Проанализировав все ограничения, рассмотрим наиболее надежную и производительную архитектуру, которая позволит выжать максимум из имеющегося оборудования:
Физический сервер: Напрямую на операционной системе хоста разворачиваются сервер 1С:Предприятие и СУБД MS SQL. Никакой виртуализации для тяжелых служб СУБД не используется.
Клиентские машины: Тонкие клиенты 1С устанавливаются и запускаются непосредственно на локальных компьютерах пользователей. Терминальный сервер (RDP) полностью исключается из цепочки.
Почему эта схема является наилучшей:
Разгрузка оперативной памяти: Перенос 50 клиентских приложений на локальные ПК высвобождает около 75 ГБ оперативной памяти на сервере. Эти освободившиеся ресурсы можно отдать под кэш MS SQL Server (увеличив его лимит до 64 ГБ или более) и под рабочие процессы 1С. Это кардинально ускорит выполнение всех операций в базах данных.
Безопасность: Пользователи больше не имеют прямого доступа к серверной операционной системе. Весь обмен данными идет по безопасному протоколу 1С.
Использование Shared Memory: Связка «1С + SQL» работает на максимальной скорости внутри одной физической ОС.
Как решить проблему администрирования локальных клиентов без прав пользователей?
Основной аргумент противников локальной установки клиентов — сложность их обновления, особенно если у конечных пользователей нет прав администратора на компьютерах. Рассмотрим проверенную схему автоматизации этого процесса с использованием групповых политик Active Directory (GPO) или общего сетевого ресурса.
Разберем по шагам алгоритм настройки централизованного запуска и обновления тонких клиентов через общую сетевую папку (DFS):
Создадим на сервере общую сетевую папку (например, \\server\1C_Distr\) и предоставим пользователям права на ее чтение.
Поместим в эту папку дистрибутивы новых версий тонкого клиента 1С.
Настроим общий файл конфигурации запуска 1cestart.cfg. На локальных компьютерах пользователей ярлык запуска 1С должен указывать не на конкретную версию платформы, а на общий исполняемый файл запуска:
"C:\Program Files (x86)\1cv8\common\1cestart.exe"
В локальном или сетевом файле 1cestart.cfg пропишем параметр DistributiveLocation, указывающий на нашу общую папку:
При таком подходе, когда на сервере обновится версия платформы 1С, локальный загрузчик 1cestart.exe на компьютере пользователя автоматически обнаружит несоответствие версий, обратится к сетевой папке \\server\1C_Distr\, незаметно для пользователя скопирует и установит новую версию тонкого клиента (для этого не требуются права локального администратора, так как установка инициируется самим механизмом запуска 1С во временную папку пользователя), после чего запустит сеанс.
Критические настройки оборудования для обеспечения максимального быстродействия
Вне зависимости от выбранного варианта развертывания, сервер на базе старых процессоров Xeon E5-2680v2 (базовая частота всего 2.8 ГГц) требует тонкой технической настройки. Если упустить эти детали, производительность 1С будет крайне низкой.
1. Архитектура NUMA (Non-Uniform Memory Access)
Процессоры Xeon E5-2680v2 установлены в двухсокетную материнскую плату. Это означает, что оперативная память разделена на два независимых NUMA-узла (по 64 ГБ на каждый процессор). Процессор 1 может быстро работать только со своей памятью, доступ к памяти Процессора 2 осуществляется через медленную шину QPI.
Что нужно сделать:
Если вы используете виртуализацию, никогда не создавайте виртуальную машину, ресурсы которой пересекают границы одного NUMA-узла (не выделяйте одной ВМ более 10 ядер и более 64 ГБ оперативной памяти). Выход за эти рамки (NUMA-crossing) приведет к падению скорости работы с памятью на 30–40%.
Если вы работаете на физическом сервере, убедитесь, что в настройках СУБД MS SQL включена поддержка NUMA, а распределение памяти настроено корректно.
2. Энергосбережение в BIOS (Power Management)
По умолчанию серверные процессоры пытаются экономить электроэнергию, снижая тактовую частоту ядер в моменты простоя. Из-за специфики работы 1С (высокая однопоточная нагрузка короткими импульсами) процессоры просто не успевают поднимать частоту, из-за чего проведение документов может работать в 2–3 раза медленнее, чем на обычном игровом ПК.
Что нужно сделать:
Зайдите в BIOS сервера и полностью отключите технологии энергосбережения: C-States, Intel SpeedStep (EIST).
Выставьте режим электропитания в положение Maximum Performance (Максимальная производительность). Это заставит процессоры постоянно работать на максимальной частоте Turbo Boost.
3. Настройки дисковой подсистемы
Работа 50 пользователей в конфигурациях УТ 11 и БП 3.0 создает колоссальную нагрузку на дисковую подсистему в режиме случайной записи и чтения (IOPS).
Использование обычных HDD или дешевых потребительских SATA SSD категорически запрещено.
Используйте только корпоративные NVMe SSD с аппаратной защитой от потери питания (PLP — Power Loss Protection). Без PLP скорость записи базы данных MS SQL будет искусственно ограничиваться для предотвращения повреждения данных при внезапном отключении электричества.
Разделяйте дисковые массивы: операционная система и файлы профилей пользователей должны находиться на одном физическом массиве, файлы баз данных MDF — на втором, а системная база TempDB и файлы транзакций LDF — на третьем (желательно на сверхбыстром NVMe накопителе).
4. Специфика настройки Hyper-V под SQL и 1С
Если требования бизнеса всё же обязывают вас использовать виртуализацию Hyper-V, обязательно примените следующие настройки:
Запрещено использовать Dynamic Memory (Динамическую память): Для виртуальной машины с MS SQL Server память должна быть выделена строго статически. СУБД определяет доступный объем кэша при старте; динамическое изменение объема памяти приводит к непредсказуемым задержкам и утечкам ресурсов.
Отключение митигаций Spectre/Meltdown: Процессоры семейства Ivy Bridge (к которым относится Xeon E5 v2) теряют до 20–30% производительности при работе программных заплаток против уязвимостей Spectre и Meltdown. Если ваш сервер находится в защищенном локальном контуре, эти патчи в операционной системе хоста рекомендуется отключить с помощью утилиты Inspectre для возврата исходной вычислительной мощности процессора.
Подводя итог, отметим, что для конфигурации с 50 пользователями на базе одного сервера со 128 ГБ ОЗУ оптимальным архитектурным решением является размещение связки «1С + MS SQL» на физическом хосте с организацией работы пользователей через локальные тонкие клиенты. Это позволит избежать дефицита оперативной памяти, задействовать протокол Shared Memory и обеспечить максимальную производительность без дополнительных затрат на новое оборудование.