← На главную

Разберем типичную дилемму системного администратора: в распоряжении имеется мощный двухпроцессорный сервер (например, 2x Intel Xeon E5-2683 v3, 128 Гб RAM, контроллер Smart Array P440 с кэшем FBWC), лицензия Windows Server Datacenter, а парк пользовательских станций сильно устарел. Встает вопрос: стоит ли строить ферму виртуализации с доставкой приложений (RemoteApp, Citrix XenApp) или эффективнее использовать классическую клиент-серверную архитектуру 1С?

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

1. Организация клиентского доступа: нужен ли терминальный сервер или Citrix?

Первое побуждение при наличии слабых рабочих станций — развернуть виртуальные машины и организовать доставку приложений через Citrix XenApp или ферму Microsoft RDS (RemoteApp). Однако в среде 1С:Предприятие 8.3 это далеко не всегда оправдано.

1. Режим работы клиента 1С: Выясним причину жалоб на низкую скорость локальных машин. Если пользователи запускают базы в режиме толстого клиента, рабочая станция самостоятельно выполняет ресурсоемкие операции по формированию форм и обработке данных. Если же перевести базы на тонкий клиент (для конфигураций на управляемых формах), нагрузка на процессор и оперативную память клиентского ПК становится минимальной. Тонкий клиент лишь отображает готовый интерфейс, передаваемый сервером 1С.
2. Публикация через веб-сервер: Отличной альтернативой терминалам является публикация информационной базы на веб-сервере (Apache или IIS). Тонкий клиент подключается к серверу по протоколу HTTP/HTTPS. Такой вариант снижает требования к клиентским компьютерам до базового минимума, обеспечивает стабильную работу даже на слабых каналах связи и не требует сложной инфраструктуры доставки окон.
3. Лицензионные ограничения Windows Server Datacenter: Наличие лицензии Datacenter позволяет развернуть неограниченное количество виртуальных машин под управлением Windows Server на данном физическом хосте. Однако она не включает клиентские терминальные лицензии. Для работы RDS или RemoteApp потребуется отдельно докупать клиентские лицензии доступа (RDS CAL) на каждого пользователя или устройство, что приводит к существенным финансовым затратам.

2. Виртуализация: подводные камни для 1С и СУБД

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

Если принято решение разворачивать виртуальные машины, обязательно выполним следующие требования:

1. Отказ от динамического выделения ресурсов: Ни в коем случае нельзя использовать динамическую оперативную память (Dynamic Memory) или переподписку процессоров (vCPU overcommit). Серверу СУБД и серверу 1С память и ядра должны выделяться статически с жестким закреплением.
2. Прямой доступ к накопителям: Использование виртуальных дисков с динамическим расширением недопустимо. Требуются фиксированные диски либо передача контроллера/томов в режиме прямого доступа (Pass-through / RDM).
3. Тестирование производительности: После развертывания виртуальной машины обязательно замерим производительность с помощью теста Гилева (TPC-1C). Если показатели однопоточной производительности падают более чем на 10–15% по сравнению с физическим хостом, виртуализация в данной связке нецелесообразна.

Для конфигурации с PostgreSQL на Linux оптимальным решением часто является установка системы непосредственно на «железо» (Bare Metal) без гипервизора, что исключает просадку скорости вычислений.

3. Настройка двухпроцессорного сервера на базе HPE ProLiant Gen9

Используемые процессоры Intel Xeon E5-2683 v3 имеют 14 ядер на сокет, но низкую базовую тактовую частоту — 2.00 ГГц. В 1С подавляющее большинство критичных блокирующих операций (проведение документов, закрытие месяца, расчет себестоимости) выполняется в один поток. Следовательно, производительность каждого отдельного ядра имеет первостепенное значение.

Разберем по шагам оптимизацию хоста:

1. Настройка BIOS/UEFI сервера:

   По умолчанию серверные платформы HPE настроены на экономию электроэнергии, что приводит к переходу ядер в энергосберегающие состояния (C-States) и резкому росту задержек при смене нагрузки. В BIOS необходимо включить профиль электропитания High Performance / Maximum Performance, отключить режимы C-States и C1E, а также активировать режим Turbo Boost на максимальной планке частоты.

2. Учет архитектуры NUMA:

   В двухпроцессорной системе оперативная память разделена между сокетами. Обращение одного процессора к памяти, подключенной к соседнему сокету, увеличивает время ожидания. Для оптимизации связки 1С и СУБД под Linux рекомендуется привязывать процессы к конкретным узлам NUMA с помощью утилиты numactl, либо разносить процессы ragent/rphost и демон postgres по разным сокетам.

3. Обеспечение отказоустойчивости дисковой подсистемы:

   Хранить рабочие базы данных на одиночных SSD без объединения в RAID-массив недопустимо, так как внезапный отказ диска приведет к остановке предприятия и потере данных. Имеющийся контроллер HPE Smart Array P440 с энергонезависимой памятью FBWC (2 Гб) позволяет собрать надежный массив RAID 10. При этом необходимо убедиться, что на контроллере активирован режим кэширования записи (Write-Back / Accelerator). В случае использования SSD потребительского класса контроллер может отключать внутренний кэш, поэтому для баз данных 1С следует применять серверные накопители (Enterprise SSD).

4. Тонкая настройка кластера 1С и PostgreSQL

Так как суммарно сервер имеет 28 физических ядер (56 потоков Hyper-Threading), стандартная конфигурация 1С с одним рабочим процессором не сможет эффективно утилизировать ресурсы.

1. Настройка рабочих процессов кластера: В консоли администрирования серверов 1С:Предприятия создадим несколько рабочих процессов (rphost). Рекомендуется настроить распределение соединений так, чтобы на один процесс rphost приходилось от 20 до 30 сеансов пользователей. Это защитит систему от утечек памяти в рамках одного процесса и позволит полноценно нагрузить многоядерный процессор.
2. Параметры PostgreSQL: При работе СУБД на быстрых твердотельных накопителях скорректируем ключевые параметры в файле postgresql.conf:

   Параметр random_page_cost уменьшим до значений 1.1–1.5 (дефолтное значение 4.0 ориентировано на медленные шпиндельные HDD). Это позволит планировщику запросов эффективнее использовать индексы.

   Параметр effective_io_concurrency для SSD поднимем до 100–200. На уровне ядра Linux настроим выделение больших страниц памяти (HugePages) для ускорения обращений СУБД к кэшу shared_buffers.

Итоговая рекомендация: Не усложняйте инфраструктуру терминальными службами и доставкой приложений, требующими покупки дорогих лицензий RDS CAL. Разверните связку Linux + PostgreSQL + Сервер 1С на физическом сервере без гипервизора, переведите дисковую подсистему в отказоустойчивый RAID-массив, а пользователей подключите через тонкий клиент или веб-публикацию. Это обеспечит максимальную производительность базы данных и комфортную работу даже на старых рабочих станциях.