Два сервера 1С:Предприятие 8.3 разных релизов на одной машине

· 11 мин

Содержание

Две версии 1С на сервере ставят так: первую — обычным установщиком со службой на стандартных портах 1540/1541/1560:1591, вторую — без регистрации службы, а потом вручную регистрируют для неё отдельный агент ragent.exe на других портах, например 2540/2541/2560:2591, и с отдельным каталогом кластера. После этого на одном компьютере работают два независимых кластера, и каждый обслуживает базы своей версии платформы.

Такая схема нужна, когда часть баз уже переведена на новый релиз платформы, а часть ещё нельзя трогать: отраслевая конфигурация не поддерживает новую версию, внешний обмен проверен только на старой, или новый релиз сначала обкатывают на копии. Ниже порядок для Windows Server 2016 и новее; в конце раздела про вторую версию — короткая заметка для Linux.

Что подготовить до установки: дистрибутивы, порты, учётная запись

Начните с плана. Ошибка на этом этапе — пересечение портов — потом выглядит как «служба то стартует, то нет».

📦 Дистрибутивы. Нужен полный дистрибутив технологической платформы для Windows нужной разрядности на каждую версию. Сервер ставьте 64-битный: 32-битный сервер на рабочей машине сегодня не имеет смысла.

🔢 Номера версий. Запишите точные номера обеих версий в формате 8.3.xx.xxxx. Клиент подключится к кластеру только той же версии, что и сервер, — совпадать должны все четыре числа.

🔌 Порты. Распределите их заранее:

ЧтоПервая версияВторая версия
Агент сервера (-port)15402540
Менеджер кластера (-regport)15412541
Рабочие процессы (-range)1560:15912560:2591
Сервер администрирования RAS15452545
Каталог данных кластера (-d)C:\Program Files\1cv8\srvinfoC:\Program Files\1cv8\srvinfo2

Сдвиг на 1000 удобен тем, что номера легко запомнить. Подойдёт и сдвиг на 100 (1640/1641/1660:1691), главное — чтобы диапазоны не пересекались ни друг с другом, ни с другими программами на сервере.

👤 Учётная запись службы. Установщик первой версии создаёт пользователя USR1CV8. Вторую службу удобно запускать от него же. Если по регламенту нужны разные учётные записи, заведите вторую заранее и дайте ей право «Вход в качестве службы».

Проверьте, что выбранные порты свободны, ещё до установки: netstat -ano | findstr ":2540 :2541". Пустой вывод — порты свободны.

Шаг 1. Ставим первую версию как обычно

Первая версия устанавливается стандартно — так же, как единственный сервер.

  1. Запустите setup.exe из дистрибутива первой версии.
  2. В списке компонентов отметьте «Сервер 1С:Предприятия», при необходимости — «Модули расширения веб-сервера» и «Администрирование сервера 1С:Предприятия».
  3. На шаге про службу оставьте галочку установки сервера как сервиса Windows, укажите пользователя USR1CV8 и пароль.
  4. Завершите установку и убедитесь в оснастке services.msc, что служба агента сервера запущена.

Файлы лягут в C:\Program Files\1cv8\8.3.xx.xxxx\, где в имени папки стоит номер версии. Это ключевая деталь: разные версии не перезаписывают друг друга на диске. Конфликт возникает только из-за службы: установщик регистрирует её под одним и тем же именем и на портах по умолчанию.

Откройте свойства службы и посмотрите поле «Исполняемый файл». Там будет строка запуска ragent.exe с ключами -port 1540 -regport 1541 -range 1560:1591 -d "...\srvinfo". Её удобно взять за образец для второй службы.

Шаг 2. Вторая версия без службы и отдельный агент на своих портах

Установка файлов платформы

  1. Запустите setup.exe второй версии.
  2. Отметьте те же компоненты, что и в первый раз.
  3. Снимите галочку установки сервера как сервиса Windows. Иначе установщик перерегистрирует существующую службу на новую версию, и базы первого кластера окажутся под чужим релизом.
  4. Дождитесь окончания. В C:\Program Files\1cv8\ появится вторая папка с номером версии.

Если галочку забыли снять — сразу откройте свойства службы и проверьте путь к ragent.exe. Если он ведёт в папку новой версии, остановите службу в нерабочее время (все сеансы пользователей оборвутся) и исправьте путь обратно через sc config, как показано ниже.

Каталог кластера и права

Создайте папку C:\Program Files\1cv8\srvinfo2. Выдайте пользователю, от которого будет работать служба, полный доступ к ней. Без этого агент не сможет записать реестр кластера и служба остановится сразу после запуска.

Регистрация службы второго агента

Службу создают штатной утилитой Windows sc. Запускайте командную строку от имени администратора. Пробелы после binPath=, start=, obj= и прочих параметров обязательны — такой синтаксис у sc.

sc create "1C Server Agent 2540" binPath= "\"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ragent.exe\" -srvc -agent -port 2540 -regport 2541 -range 2560:2591 -d \"C:\Program Files\1cv8\srvinfo2\"" start= auto obj= ".\USR1CV8" password= "ПарольПользователя" DisplayName= "Агент сервера 1С 8.3.xx (2540)"
sc description "1C Server Agent 2540" "Кластер 1С второй версии, порты 2540/2541"

Подставьте номер второй версии вместо 8.3.xx.xxxx. В отображаемом имени тоже укажите версию и порт: через полгода иначе никто не вспомнит, какая служба что обслуживает.

Если нужно исправить строку запуска у существующей службы, используйте sc config с тем же binPath=. Удалить ошибочно созданную службу можно командой sc delete "1C Server Agent 2540" — предварительно остановив её.

Брандмауэр

Откройте входящие подключения на новые порты. Пример для встроенного брандмауэра Windows:

netsh advfirewall firewall add rule name="1C Server 2 agent and cluster" dir=in action=allow protocol=TCP localport=2540-2541
netsh advfirewall firewall add rule name="1C Server 2 workers" dir=in action=allow protocol=TCP localport=2560-2591

Запустите службу: sc start "1C Server Agent 2540". Через несколько секунд в srvinfo2 должна появиться папка reg_2541 — это признак, что кластер создан.

Заметка для Linux

На Linux версии тоже ставятся рядом: каждая в свой каталог /opt/1cv8/x86_64/8.3.xx.xxxx/. Логика та же. Для второй версии создают отдельную службу systemd со своим именем: берут unit-файл, поставляемый с платформой, и прописывают в строке запуска ragent те же ключи -port, -regport, -range и отдельный каталог -d. Не забудьте права пользователя usr1cv8 на этот каталог и правила файрвола.

Шаг 3. Лицензии и ключи защиты для двух кластеров

Здесь пугаются зря: лицензии от версии платформы 8.3 не зависят.

🔑 Программные лицензии хранятся в общем каталоге C:\ProgramData\1C\licenses и привязаны к параметрам компьютера, а не к релизу. Обе версии платформы видят одни и те же файлы. Повторно активировать лицензию после установки второй версии не нужно.

🔐 Аппаратные ключи HASP обслуживает драйвер и менеджер лицензий, которые общие для всего компьютера. Сетевой ключ на сервере одинаково доступен обоим кластерам.

Где реально бывают сложности:

  • 🧮 Клиентские лицензии. Сеансы в двух кластерах считаются по отдельности, а пул лицензий общий. Если пользователи раньше работали только в одном кластере, а теперь открывают базы в обоих, лицензий может внезапно не хватить. Посмотрите сеансы каждого кластера в консоли или командой rac session list --licenses.
  • 🖥️ Перенос сервера на другую машину. Лицензия привязана к оборудованию, поэтому при переезде её придётся восстанавливать — это уже отдельная процедура.
  • 🧰 Изменение «железа» сервера. Добавили диск или сетевую карту одновременно с установкой второй версии — лицензия может перестать подходить. Не совмещайте эти работы.

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

Шаг 4. Разводим базы, консоль и клиентов по кластерам

Где какая база

Каждый кластер ведёт свой список информационных баз. Одна и та же база данных SQL не должна быть зарегистрирована в двух кластерах одновременно: две версии платформы начнут работать с одними таблицами, и это прямой путь к повреждению данных.

Перенос базы со старого кластера на новый делают так:

  1. Сделайте резервную копию базы средствами СУБД и выгрузку .dt.
  2. В нерабочее время удалите базу из списка старого кластера, выбрав вариант «не удалять базу данных». Удаляется только регистрация, данные в СУБД остаются.
  3. В новом кластере создайте информационную базу с тем же сервером СУБД и тем же именем базы данных.
  4. Откройте её в Конфигураторе новой версии и проверьте работу.

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

Сервер СУБД — PostgreSQL или MS SQL — у двух кластеров может быть один. Просто базы данных у них разные.

Консоль администрирования

Консоль серверов 1С — это оснастка, которая работает через библиотеку radmin.dll. Зарегистрирована может быть только одна её версия, а версия консоли должна совпадать с версией сервера. Перед администрированием второго кластера перерегистрируйте библиотеку нужной версии:

regsvr32 "C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll"

Затем в консоли добавьте центральный сервер с указанием порта агента: имя_сервера:2540. Для возврата к первому кластеру повторите regsvr32 с путём первой версии.

Удобнее работать через RAS и консольный rac, где переключать ничего не нужно. Для второй версии регистрируют свою службу RAS на отдельном порту:

sc create "1C RAS 2545" binPath= "\"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe\" cluster --service --port=2545 localhost:2540" start= auto DisplayName= "Сервер администрирования 1С 8.3.xx (2545)"

После запуска команда rac localhost:2545 cluster list покажет второй кластер. Если rac возвращает ошибку о несовпадении версий, вызывайте его из папки bin той же версии, что и RAS.

Подключение пользователей

В окне запуска 1С при добавлении базы второго кластера в поле с кластером серверов указывайте имя сервера с портом менеджера кластера: srv1c:2541. Для первого кластера порт не нужен — 1541 подставляется по умолчанию.

В строке подключения в файле ibases.v8i это выглядит так:

Connect=Srvr="srv1c:2541";Ref="buh_test";

Чтобы клиент сам выбирал нужную версию, откройте свойства базы в списке и на последней странице заполните поле с версией 1С:Предприятия, например 8.3.xx.xxxx. Тогда 1cestart.exe запустит подходящий клиент. На компьютерах пользователей должны быть установлены клиенты обеих версий.

Диагностика: служба не запускается или клиент не видит кластер

Вторая служба чаще всего не стартует по одной из трёх причин: занят порт, нет прав на каталог -d, ошибка в кавычках binPath. Клиент не подключается — из-за порта в строке подключения или несовпадения версий.

Диагностика: выберите симптом

Технологический журнал для двух версий

Если простые проверки не помогли, включайте технологический журнал. Настройки задают в файле logcfg.xml в каталоге conf. Если положить его в общий каталог C:\Program Files\1cv8\conf\, журнал начнут писать обе версии. Поэтому в параметре location укажите разные папки или фильтруйте события по процессам нужного кластера. Иначе логи смешаются, и разобрать, какой сервер упал, будет трудно.

Минимальный пример для поиска ошибок и падений процессов:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_logs\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь history="24" означает хранение журнала 24 часа. Не оставляйте журнал включённым надолго с широким фильтром — он быстро занимает диск. После диагностики уберите файл или закомментируйте блок.

Заодно полезно заглянуть в каталог srvinfo2\reg_2541: там лежит файл реестра кластера 1CV8Clst.lst. Его наличие и свежая дата изменения подтверждают, что агент второй версии действительно поднял свой кластер, а не упал при старте.

Когда второй сервер на той же машине не нужен

Иногда две версии ставят по привычке, хотя задачу можно решить проще:

  • 🧪 Нужна только проверка нового релиза на копии. Файловая копия базы на рабочей станции администратора проверяется без второго кластера.
  • 🗂️ Базы просто переводят на новую версию. Если все конфигурации её поддерживают, проще обновить единственный сервер в окно обслуживания, чем держать два кластера месяцами.
  • 💾 Мало памяти. Каждый кластер запускает свои рабочие процессы. На сервере с 8–16 ГБ оперативной памяти два нагруженных кластера начнут мешать друг другу. Тогда разумнее вынести второй кластер на отдельную виртуальную машину.

Частые вопросы

Можно ли поставить три и больше версии сервера 1С на один компьютер?
Да. Принцип тот же: каждая следующая версия — без штатной службы, со своим агентом, своим диапазоном портов и своим каталогом кластера. Ограничение — только память и процессор сервера.
Нужно ли удалять старую версию платформы после переноса всех баз?
Сначала остановите и отключите её службу, неделю-две понаблюдайте. Если базы работают на новом кластере без проблем, удалите старую платформу через «Программы и компоненты», а затем службу командой sc delete, если она осталась.
Можно ли запустить второй кластер на стандартных портах, а первый перенести на другие?
Можно, порты не привязаны к версии. Но перенос порта у работающего кластера заставит переписать строки подключения у всех пользователей. Обычно нестандартные порты дают тому кластеру, где меньше баз.
Будет ли веб-публикация работать с базами второго кластера?
Будет. В файле default.vrd публикации строка подключения указывается с портом: Srvr=“srv1c:2541”. Модуль расширения веб-сервера должен быть той же версии, что и сервер этого кластера.
Как понять, какой версией сервера обслуживается конкретная база?
Посмотрите, в каком кластере она зарегистрирована: в консоли или командой rac infobase summary list с параметром –cluster. Версию кластера показывает папка ragent.exe в свойствах соответствующей службы.