Как правильно настроить параллельную работу нескольких версий сервера 1С:Предприятие на одном компьютере?

← На главную

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

1. Разделение сетевых портов и параметров служб

Каждый экземпляр службы сервера 1С (ragent) по умолчанию использует стандартный диапазон портов: 1540 (главный агент), 1541 (менеджер кластера) и диапазон 1560:1591 (рабочие процессы). Если запустить второй экземпляр без явного указания альтернативных портов, служба завершится с ошибкой сетевого конфликта.

Проанализируем правила распределения портов для нескольких параллельных служб:

Агент кластера (порт -port): для первого экземпляра используем стандартный порт 1540, для второго — 2540, для третьего — 3540.
Главный менеджер кластера (порт -regport): соответственно задаем 1541, 2541, 3541.
Диапазон рабочих процессов (параметр -range): выделяем изолированные интервалы портов, например 1560:1591, 2560:2591, 3560:3591.

При создании дополнительных служб в операционной системе Windows через утилиту sc.exe необходимо сформировать команду с уникальным именем службы и полными параметрами запуска:


sc create "1C:Enterprise 8.3 Server (8.3.9)" binPath= "\"C:\Program Files\1cv8\8.3.9.2170\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\Program Files\1cv8\srvinfo_839\"" start= auto

В операционных системах семейства Linux для каждой версии платформы создаем собственный unit-файл службы в каталоге /etc/systemd/system/, где в секции переменных окружения прописываем индивидуальные значения SRV1CV8_PORT, SRV1CV8_REGPORT, SRV1CV8_RANGE и SRV1CV8_DATA.

2. Изоляция каталогов данных кластера и журнала регистрации

Одной из наиболее критических ошибок при параллельной установке является использование общего системного каталога данных кластера (srvinfo). Если разные версии сервера обратятся к одному и тому же каталогу по умолчанию, файлы настроек кластера 1CV8Clst.lst будут повреждены, что приведет к аварийной остановке служб и потере списка зарегистрированных баз.

Рассмотрим порядок изоляции данных:

Для каждой версии сервера 1С создаем отдельную директорию на диске (например, srvinfo_835, srvinfo_836, srvinfo_839).
Обязательно передаем путь к индивидуальной папке через параметр -d в строке запуска исполняемого файла ragent.exe.
Убеждаемся, что журнал регистрации и файлы блокировок каждой базы создаются строго внутри изолированных подкаталогов соответствующего кластера.

3. Особенности работы COM-соединений и внешних компонент

При одновременном наличии нескольких платформ стандартное создание COM-объекта через конструктор Новый COMОбъект("v83.COMConnector") ссылается на библиотеку comcntr.dll той версии, которая была зарегистрирована в реестре операционной системы последней. Если попытаться подключиться к базе более старой или более новой версии через неподходящий коннектор, возникнет ошибка несоответствия версий клиента и сервера.

Разберем алгоритм настройки параллельной работы COM-коннекторов через службы компонентов Windows:

Открываем оснастку Службы компонентов (Component Services) в операционной системе.
Создаем новое пустое COM+ приложение для конкретной версии платформы (например, 1C_COM_8.3.5).
В созданное приложение добавляем компонент, выбрав файл comcntr.dll из каталога bin соответствующей версии платформы 1С.
Назначаем приложению уникальный идентификатор (ProgID) или обращаемся к нему по идентификатору класса (CLSID).
В исходном коде конфигурации выполняем подключение к созданному компоненту с явным указанием его уникального идентификатора:


// Пример вызова специализированного COM-коннектора конкретной версии
Попытка
    COMКоннектор = Новый COMОбъект("v83_Custom_835.COMConnector");
    Подключение = COMКоннектор.Connect("Srvr=""localhost:2540"";Ref=""trade_base"";Usr=""Admin"";Pwd=""123"";");
Исключение
    Сообщить("Ошибка инициализации соединения: " + ОписаниеОшибки());
КонецПопытки;

4. Администрирование кластеров и консоль MMC

Стандартная консоль администрирования кластера серверов 1С (оснастка MMC) опирается на зарегистрированную в системе библиотеку radmin.dll. Одновременно в системе может быть активна регистрация только одной версии этой библиотеки. При попытке подключиться к кластеру версии 8.3.5 через консоль от 8.3.9 возникнет сообщение о несовместимости версий.

Для решения этой проблемы применим один из следующих подходов:

Пакетные файлы перерегистрации: для каждой версии формируем отдельный .bat-файл, выполняющий тихую регистрацию radmin.dll перед открытием MMC-консоли:
```
regsvr32 /s "C:\Program Files\1cv8\8.3.9.2170\bin\radmin.dll"
start "" "C:\Program Files\1cv8\8.3.9.2170\bin\1CV8Clnt.msc"
```
Использование сервера администрирования RAS: для каждого кластера поднимаем отдельный экземпляр утилиты ras.exe на уникальном порту (например, 1545, 2545) и управляем настройками через утилиту командной строки rac, не зависящую от регистрации системных DLL.

5. Публикация информационных баз на веб-серверах

Если требуется публиковать веб-клиенты или HTTP/SOAP-сервисы для баз, работающих на разных серверах, учитываем архитектурные ограничения веб-серверов:

Веб-сервер Apache: в рамки одного процесса Apache нельзя одновременно загрузить модули расширения wsap24.dll от разных версий 1С. Для разделения потребуется либо поднимать несколько служб Apache на разных сетевых портах, либо использовать виртуализацию и обратный прокси-сервер (Nginx).
Веб-сервер IIS: в IIS публикация баз разных версий платформы возможна на одном сервере. Для этого базы обязательно разносят по разным пулам приложений (Application Pools), а в сопоставлениях обработчиков (Handler Mappings) указывают библиотеку wsisapi.dll из каталога соответствующей версии 1С.

6. Контроль системных ресурсов и альтернативные решения

Параллельная работа нескольких кластеров на одном оборудовании существенно увеличивает потребление оперативной памяти, так как процессы ragent, rmngr и rphost запускаются в нескольких экземплярах. Обязательно настраиваем в свойствах каждого кластера ограничения по объему памяти на процесс и периодичность их автоматического перезапуска.

Если инфраструктура позволяет, вместо установки нескольких версий сервера 1С на одну хостовую операционную систему рекомендуется использовать виртуализацию (Hyper-V, Proxmox) или контейнеризацию (Docker на Linux). Разнесение серверов по изолированным виртуальным машинам или контейнерам полностью устраняет конфликты библиотек, путаницу с портами и сложности с веб-публикациями.