В практике системного администрирования 1С часто возникает ситуация, когда на одном физическом или виртуальном сервере необходимо запустить сразу несколько версий платформы. Это может быть связано с необходимостью плавного перехода на новый релиз (например, с 8.3.11 на 8.3.15), тестированием баз на новой платформе или поддержкой специфических конфигураций, которые еще не адаптированы под последние обновления. Разберем подробно, как реализовать этот сценарий, обеспечив стабильную работу обеих служб.
Для того чтобы две разные версии платформы 1С бесконфликтно работали на одной операционной системе, нам необходимо разграничить их ресурсы. Основная причина конфликтов — использование одинаковых сетевых портов и одних и тех же каталогов для хранения настроек кластера. Проанализируем ключевые параметры, которые нам придется изменить для второй (дополнительной) службы сервера:
Рассмотрим наиболее простой и удобный вариант — использование готовых инструментов, которые автоматизируют создание служб Windows. Программисты часто рекомендуют использовать утилиту Управление службами серверов 1С. Рассмотрим алгоритм действий при ее использовании:
ragent.exe новой версии платформы (например, в папке 8.3.15.хххх\bin).C:\ProgramData\1C\server_8_3_15.Такой подход минимизирует риск ошибок в командной строке и позволяет быстро переключаться между консолями администрирования разных версий. В качестве альтернативы стандартным инструментам можно использовать кроссплатформенную мультиверсионную консоль администрирования кластера 1С.
Если вы предпочитаете полный контроль или не хотите использовать стороннее ПО, проанализируем процесс ручного создания службы с помощью стандартной команды Windows sc create. Выясним причину, по которой это решение считается максимально надежным для опытных администраторов.
Для создания второй службы нам понадобится выполнить команду в командной строке (CMD) от имени администратора. Пример команды выглядит следующим образом:
sc create "1C:Enterprise 8.3.15 Server" binPath= "\"C:\Program Files\1cv8\8.3.15.1830\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\ProgramData\1C\server_8_3_15\"" start= auto obj= "NT AUTHORITY\NetworkService"
Разберем параметры этой команды подробнее:
binPath — полный путь к исполняемому файлу новой платформы. Обратите внимание на использование кавычек и экранирование.-srvc — указывает, что программа запускается как служба.-agent — запуск в режиме агента сервера.-regport и -port — наши новые порты (2541 и 2540).-range — новый диапазон портов для рабочих процессов.-d — путь к новой директории реестра кластера. Убедитесь, что у пользователя, под которым запускается служба, есть права на запись в эту папку.Для повышения стабильности работы рассмотрим вариант запуска служб под разными пользователями. Если обе службы (8.3.11 и 8.3.15) запущены под стандартным пользователем USR1CV8, они могут конфликтовать при доступе к временным файлам в профиле пользователя. Посмотрим, как это предотвратить:
USR1CV8_15.-d).После того как обе службы запущены, нам нужно научить клиентские приложения подключаться к правильному экземпляру сервера. Если при использовании стандартного сервера мы просто пишем имя хоста (например, 1C-Main-Server), то для подключения к серверу с нестандартными портами необходимо явно указывать порт агента.
В строке соединения или в поле «Сервер предприятия» при добавлении базы в список указываем:
1C-Main-Server:2540
Если мы попытаемся запустить базу на новой платформе, не указав порт, система по умолчанию обратится к порту 1540 и попытается найти базу в реестре старого кластера (8.3.11), что приведет к ошибке «Информационная база не обнаружена» или ошибке соответствия версий клиента и сервера.
Проанализируем ситуацию с консолью администрирования. Оснастка MMC (1cv8.msc) обычно регистрируется для последней установленной версии. Если вам нужно одновременно управлять обоими кластерами, выполним следующие шаги:
ras (сервер администрирования). Запустите для каждой версии свой экземпляр ras на разных портах, и тогда вы сможете подключаться к ним через универсальные средства управления.Важно помнить, что в реестре Windows может быть зарегистрирована только одна версия COM-соединителя (comcntlev.dll). Если ваши базы обмениваются данными через COM, они будут использовать ту версию, которая была установлена или зарегистрирована последней. Рассмотрим решение: если требуется работа разных версий COM, используйте механизм запуска COM-объекта в отдельном процессе через «Службы компонентов» (COM+), создав там отдельное приложение для каждой версии библиотеки comcntlev.dll.
Таким образом, мы детально разобрали процесс настройки параллельной работы двух платформ. Главное в этой задаче — строгая изоляция портов и каталогов данных кластера, а также внимательное указание портов при подключении пользователей.