Переход на новую версию платформы 1С в серверном варианте

Платформу на сервере обновляют не «поверх» старой, а ставят новую версию рядом: обе лежат в C:\Program Files\1cv8\<номер версии> и не мешают друг другу. Чтобы сервер начал работать на новой, достаточно переключить на неё службу агента Агент сервера 1С:Предприятия. Сами информационные базы при этом не трогаются — они хранятся в СУБД, а реестр кластера в папке srvinfo не зависит от номера платформы.

Частое заблуждение: обновить платформу 1С на сервере можно прямо из программы, как конфигурацию. Нет. Конфигурация обновляется в режиме «1С:Предприятие» или «Конфигуратор», а платформа — это служба Windows, её меняют на уровне операционной системы, остановив сервер и завершив сеансы. Ниже — весь порядок: что готовить, как переключить службу, что делать с кластером и чем проверить результат.

Что именно меняется, когда вы ставите новую версию

Серверная часть 1С — это три процесса: агент ragent, менеджер кластера rmngr и рабочие процессы rphost. Все они запускаются из каталога конкретной версии. Агент зарегистрирован как служба Windows, и в пути к службе прописан ragent.exe именно той версии, на которой сейчас работает сервер.

Когда вы устанавливаете новый дистрибутив, появляется второй каталог версии со своими ragent.exe, rmngr.exe, rphost.exe. Старая служба продолжает указывать на прежний каталог. Переход на новую версию — это переназначение службы на новый ragent.exe. Пока вы этого не сделали, сервер работает по-старому.

Важное следствие: все серверы одного кластера должны работать на одной версии платформы. Смешать в кластере разные номера нельзя, поэтому «плавное» обновление с нулевым простоем в рамках одного кластера не выйдет — нужно техническое окно.

Посмотреть, на какой версии сейчас работает сервер, можно двумя способами: в клиенте через пункт меню «О программе» (там видна версия платформы подключённого сеанса) и в пути к службе агента — номер версии прямо присутствует в строке запуска ragent.exe. Запишите текущий номер перед обновлением: он понадобится, если решите откатиться.

Подготовка: копии, окно и завершение сеансов

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

Перед остановкой службы сделайте резервные копии — это единственная гарантия отката:

• 🗄️ резервная копия баз данных средствами СУБД (для MS SQL — полный бэкап, для PostgreSQL — pg_dump или физическая копия);
• 📁 копия каталога srvinfo целиком (это реестр кластера: список баз, настройки, администраторы);
• 📦 при желании — выгрузка критичных баз в .dt через Конфигуратор (долго, но даёт независимый от СУБД файл).

Дальше гасим активность. Сделать это грубо (остановить службу на работающих пользователях) можно, но тогда оборвутся незакоммиченные операции. Правильный порядок:

1. Заблокируйте начало новых сеансов и регламентные задания — через консоль администрирования кластера или утилитой rac (установка блокировки сеансов в свойствах базы).
2. Дайте пользователям выйти, посмотрите остаток в списке сеансов: rac session list.
3. Завершите задержавшиеся сеансы: rac session terminate --session=<идентификатор>.
4. Убедитесь, что фоновые и регламентные задания завершились.

Чек-лист для окна обновления:

Способы обновления и как переключить службу на новую версию

Устанавливать новую версию можно при остановленной службе. Остановите Агент сервера 1С:Предприятия в оснастке Службы Windows (services.msc) и дождитесь, пока из диспетчера задач исчезнут процессы ragent, rmngr, rphost.

Дальше запускайте установку. Способов перевести сервер на новую версию два.

Способ 1. Через штатный установщик (рекомендуется). Запустите setup.exe из дистрибутива, выберите установку серверных компонентов. На шаге настройки установщик предложит зарегистрировать агент сервера как службу Windows — согласитесь. Он пропишет службе путь к новому ragent.exe с теми же портами и тем же каталогом srvinfo. Это самый безопасный вариант: ничего руками править не нужно.

Способ 2. Переключить службу вручную (для тех, кто знает, что делает). Если новая платформа уже установлена, можно не трогать регистрацию, а изменить путь в существующей службе — заменить номер версии в пути к ragent.exe. Параметры запуска (порты, каталог данных) при этом сохраняются. Способ быстрый, но при опечатке в пути служба не стартует, поэтому он для администраторов, уверенных в структуре каталогов.

Типичная строка запуска агента выглядит так (порты по умолчанию, диапазон рабочих процессов и каталог данных):

"C:\Program Files\1cv8\8.3.XX.YYYY\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

После установки и регистрации запустите службу агента. В диспетчере задач должны появиться ragent, затем rmngr и rphost.

На Linux принцип тот же: пакет новой версии ставится рядом, а демон (srv1cv8 / ragent) перенастраивается на новый каталог; управление — через systemctl и тот же rac.

Совместимость: платформа, конфигурация, клиенты, ОС

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

Платформа и конфигурация. У каждой конфигурации есть минимальная требуемая версия платформы. Если вы заодно обновляете конфигурацию, сверьтесь: новый релиз может требовать платформу не ниже определённого номера. Сравнивайте версии строго по номеру («не ниже 8.3.XX»), а не на глаз. Если и платформа, и конфигурация идут на повышение — сначала ставьте платформу, потом грузите конфигурацию.

Клиенты. Версия клиента и версия сервера должны совпадать. Старый тонкий клиент к обновлённому серверу не подключится и выдаст сообщение о несовместимости версий. Поэтому план обновления всегда включает клиентские рабочие места.

Операционная система и СУБД. Свежие релизы платформы перестают поддерживать устаревшие ОС. Ориентируйтесь на Windows Server 2016 и новее. Версию СУБД (MS SQL или PostgreSQL) тоже сверьте с заявленной поддержкой — платформа работает не с любой сборкой.

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

Обновление кластера из нескольких серверов

Если кластер состоит из нескольких рабочих серверов, помните главное правило: на всех серверах кластера должна быть одна и та же версия платформы. Нельзя обновить один сервер и оставить второй на старой — кластер такую пару не соберёт.

Порядок для многосерверного кластера:

1. В техническое окно остановите агенты на всех рабочих серверах кластера.
2. Установите новую платформу на каждом сервере.
3. Переключите службы агента на новую версию (способом из раздела выше).
4. Сначала поднимите центральный сервер (тот, где лежит реестр кластера srvinfo), затем остальные рабочие серверы.
5. Проверьте в консоли, что все рабочие серверы снова в кластере, а рабочие процессы rphost запустились.

Напомню про порты, чтобы не искать проблему не там: клиент сначала обращается к агенту (порт 1540), затем к менеджеру кластера (1541) и к рабочим процессам. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера, там же — требования назначения функциональности и параметры отказоустойчивости. Если после обновления сервер «не виден», первым делом смотрите, не закрылись ли эти порты файрволом и совпадают ли они с теми, что были до обновления.

Проверки после обновления

Запустили службу — не расходитесь, пока не убедились, что всё живо. Минимальный набор проверок:

• ✅ служба Агент сервера 1С:Предприятия в состоянии «Выполняется», процессы ragent, rmngr, rphost присутствуют;
• ✅ все информационные базы видны в консоли администрирования и открываются;
• ✅ тонкий клиент новой версии подключается и заходит в базу под обычным пользователем;
• ✅ выдаются лицензии — и программные, и аппаратные (HASP): зайдите в базу, проверьте, что не просит ключ;
• ✅ регламентные задания разблокированы и отрабатывают по расписанию;
• ✅ в технологическом журнале нет новых ошибок уровня EXCP.

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

Проверить, кто и с какими лицензиями уже подключился, удобно так:

rac session list --licenses

Частые ошибки и что с ними делать

Отдельно про откат. Если новая версия ведёт себя плохо, не спешите удалять её. Остановите службу, переключите агент обратно на прежний каталог версии, запустите службу — сервер вернётся в исходное состояние. Базы и srvinfo вы не трогали, поэтому откат безопасен. Удалять неудачную версию можно потом, спокойно.

Автоматизация: тихая установка и обновление клиентов

Когда серверов и рабочих мест много, обновлять руками долго. Два направления автоматизации.

Тихая установка платформы. Дистрибутив разворачивается без диалогов через msiexec с ключом /qn. Набор устанавливаемых компонентов (сервер, клиент, администрирование) задаётся свойствами пакета — точные имена свойств смотрите в документации к вашему дистрибутиву, не подбирайте наугад. Остальное оборачивается в простой bat-сценарий по шагам: остановить службу → поставить версию → переключить службу → запустить.

Централизованное обновление клиентов. Самый удобный способ не обходить рабочие места ногами — опубликовать базу на веб-сервере и включить автоматическое обновление тонкого клиента . Тогда при подключении клиент сам скачивает нужную версию. Это снимает большую часть ручной работы по клиентам.

Удалённое управление кластером из скриптов. Для автоматизации окна подойдёт связка ras + rac: через неё скрипт заблокирует сеансы, дождётся их завершения и снимет блокировку после обновления. Уверенно используйте базовые команды — rac cluster list, rac session list, rac session terminate; полный список подкоманд и параметров смотрите в rac help, не выдумывайте ключи.

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