В практике системного администрирования часто возникает ситуация, когда аппаратные мощности сервера значительно превосходят возможности имеющихся лицензий 1С. Одной из самых распространенных проблем является ограничение лицензии 1С:Предприятие 8.3 ПРОФ, которая позволяет использовать не более 12 ядер (логических процессоров) на один инстанс сервера. Если у вас в распоряжении мощный 24-ядерный сервер и две лицензии ПРОФ, встает вопрос: как эффективно объединить их ресурсы? Разберем эту ситуацию подробно, проанализируем технические нюансы и выстроим оптимальную архитектуру решения.
Рассмотрим стандартную логику работы системы защиты 1С. Когда запускается служба ragent.exe, платформа обращается к операционной системе для получения списка доступных вычислительных ресурсов. В случае лицензии ПРОФ, платформа жестко ограничивает потребление ресурсов первыми 12 логическими процессорами (ядрами), которые перечислила ОС.
Проанализируем попытку запуска второй службы на той же ОС с использованием другой лицензии. Даже если вы назначите второму инстансу другой сетевой порт (например, 1640 вместо 1540), алгоритм лицензионной проверки останется прежним. Вторая служба также увидит тот же самый список процессоров и, согласно заложенной логике, попытается задействовать те же самые первые 12 ядер. В результате мы получим ситуацию, когда две службы 1С конкурируют за одни и те же вычислительные мощности, в то время как оставшиеся 12 ядер простаивают. Использование средств ОС для привязки процессов к конкретным ядрам (так называемый CPU Affinity) в данном случае не помогает обмануть систему лицензирования 1С: она проверяет именно общее ограничение в рамках доступной среды исполнения.
Выясним, какой путь будет единственно верным для задействования всех 24 ядер. Оптимальным решением является разделение ресурсов физического сервера на две виртуальные машины (ВМ), на каждой из которых будет развернута своя операционная система и свой сервер 1С. Рассмотрим пошагово, как это реализовать:
Разберем критически важные настройки гипервизора, без которых работа 1С в виртуальной среде может быть нестабильной или медленной. Проанализируем ситуацию с точки зрения топологии NUMA.
Конфигурация vCPU и NUMA-узлов. Современные многоядерные процессоры физически разделены на узлы со своей локальной памятью. Если мы выделяем 12 ядер виртуальной машине, крайне важно, чтобы эти ядра помещались в один физический процессорный сокет (один физический NUMA-узел). Если гипервизор «размажет» эти 12 ядер между двумя физическими процессорами, возникнут огромные задержки при обращении к оперативной памяти (Remote Memory Access), что критично для производительности 1С. Для автоматической оптимизации распределения рабочих процессов по узлам можно использовать балансировщик процессов и потоков по группам NUMA.
Резервирование оперативной памяти (Memory Reservation). Для сервера 1С недопустимо использование механизмов динамического распределения памяти гипервизором (например, Memory Ballooning). Необходимо использовать опцию Reserve all guest memory в настройках ВМ. Это гарантирует, что выделенная память всегда будет физически находиться в ОЗУ, а не в файле подкачки хоста.
Latency Sensitivity. В настройках виртуальной машины на ESXi рекомендуется установить параметр Latency Sensitivity в значение High. Это заставит планировщик гипервизора выделять физические ядра эксклюзивно для потоков этой ВМ, минимизируя время ожидания в очереди на выполнение.
После того как две виртуальные машины запущены, нам нужно настроить их совместную работу. Рассмотрим, как распределить нагрузку в консоли администрирования кластеров 1С. Для этого используются Требования назначения функциональных объектов. Для удобного управления параметрами и узлами кластера можно использовать альтернативную консоль администрирования кластера серверов 1С.
Посмотрим на пример логики распределения:
Для равномерного распределения нагрузки между двумя 12-ядерными узлами, проанализируем настройки рабочих процессов. В свойствах кластера рекомендуется задать параметры:
Количество соединений на рабочий процесс — установка этого лимита заставит систему создавать новые процессы при росте нагрузки, распределяя их по доступным серверам кластера.Объем памяти на рабочий процесс — помогает избежать утечек памяти и распределить потребление ресурсов более предсказуемо.Разберем ситуацию, когда MS SQL Server вынесен на отдельный хост, как это часто бывает в крупных инсталляциях. В такой архитектуре узким местом становится сеть. При работе кластера из двух ВМ нагрузка на сеть возрастает, так как оба узла 1С будут активно обмениваться данными с SQL-сервером.
Если SQL-сервер находится на том же физическом хосте, что и ВМ с 1С, рекомендуется использовать внутренний виртуальный коммутатор (vSwitch) без выхода на физические сетевые адаптеры. Это позволит передавать данные между 1С и SQL со скоростью оперативной памяти. Если же SQL-сервер вынесен на другой физический сервер, необходимо обеспечить канал не менее 10 Гбит/с и минимизировать количество сетевых переходов (хопов).
Что касается дисков, то создание двух ВМ позволяет нам гибко распределить нагрузку. Мы можем вынести кэш сервера 1С каждой машины на разные физические SSD или использовать общий высокоскоростной NVMe накопитель. Проанализируем использование временных файлов: 1С активно пишет временные данные. Рекомендуется использовать RAM-диск внутри каждой ВМ для папки временных файлов пользователя, под которым запускается служба 1С. Это значительно ускорит работу тяжелых отчетов.
Выясним, в каких случаях создание кластера из двух ВМ может быть неоправданным. Если сложность администрирования двух ОС и настройки балансировки нагрузки в кластере становится слишком высокой, стоит рассмотреть переход на лицензии уровня КОРП.
Преимущества лицензии КОРП:
Однако, если бюджет ограничен и две лицензии ПРОФ уже куплены, вариант с двумя ВМ остается наиболее экономически оправданным и технически реализуемым способом задействовать все аппаратные ресурсы сервера.
Подводя итог, проанализируем итоговую схему. Мы имеем один физический сервер с 24 ядрами. На нем развернуты две ВМ по 12 ядер каждая. На каждой ВМ установлена ОС, сервер 1С и активирована лицензия ПРОФ. Эти два сервера объединены в один кластер 1С. Такая конфигурация позволяет полностью утилизировать процессорную мощность сервера, соблюдая при этом лицензионные ограничения платформы 1С:Предприятие.