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

Обновление платформы в клиент-серверном варианте сводится к пяти шагам: вывести пользователей, остановить службу агента сервера , поставить новую версию платформы рядом со старой, переключить службу на новый ragent.exe и проверить, что кластер поднялся и клиенты подключаются. Данные при этом не трогаются — платформа ставится в отдельную папку по номеру версии, старая остаётся на диске.

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

Инструкция общая для платформы 8.3 с клиент-серверным кластером (служба «Агент сервера 1С:Предприятия») на Windows Server и на Linux. Пути и имена служб в тексте — для этого варианта; где они зависят от ОС, это указано.

Что проверить до начала работ

До того как что-то останавливать, соберите три факта о текущей среде.

Какая версия платформы стоит сейчас. Посмотрите в Конфигураторе или тонком клиенте: Справка → О программе. Запишите полный номер вида 8.3.24.xxxx — он понадобится для отката.

Какую версию требует конфигурация. Откройте Конфигуратор → Справка → О программе — там указана версия, на которой разрабатывалась база. Правило простое: номер устанавливаемой платформы должен быть не ниже требуемого конфигурацией. Ставить версию ниже нельзя — база не запустится.

Через что лицензируется сервер. Программные лицензии привязаны к оборудованию, а не к номеру платформы, поэтому смена версии их не аннулирует. Аппаратные ключи HASP требуют актуального драйвера — при крупном скачке версий проверьте, что драйвер ключа свежий.

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

Проверьте и окружение сервера. Крупный скачок версий платформы иногда поднимает минимальные требования к СУБД и операционной системе. Если вы перепрыгиваете через несколько релизов, сверьтесь с требованиями новой версии к вашей СУБД (PostgreSQL, MS SQL Server) и к ОС — старую связку новая платформа может уже не поддерживать. На боевом сервере заодно убедитесь, что на системном диске и в каталоге установки хватает свободного места: каждая версия платформы занимает отдельную папку, старые при этом никуда не деваются.

Где взять дистрибутив и как проверить, что он целый

Дистрибутив серверной части берут в личном кабинете сопровождения — там, где у вас оформлена подписка ИТС или лицензия на платформу. Нужен комплект для вашей ОС и разрядности: для боевого кластера это, как правило, 64-битная серверная сборка.

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

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

Get-FileHash setup.exe -Algorithm SHA256

На Linux:

sha256sum server_setup.run

Совпали — файл скачался без повреждений. Не совпали — качайте заново, не ставьте битый дистрибутив на сервер.

Скачивайте дистрибутив заранее, а не в момент начала работ: если архив окажется битым или не той разрядности, вы потеряете время внутри технологического окна, пока пользователи ждут возврата базы. Разрядность серверной сборки должна совпадать с разрядностью установленного кластера — 64-битный сервер обновляют 64-битным дистрибутивом.

Как вывести пользователей и остановить агент сервера

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

1. Запретите новые сеансы. В консоли администрирования серверов (или через rac) включите для каждой базы запрет начала сеансов с понятным сообщением вроде «Идёт обновление, вход закрыт до 20:00». Пользователи, которые попробуют войти, увидят текст и не зайдут.

2. Дайте время завершить работу. Посмотрите активные сеансы — в консоли или командой rac session list. Дождитесь, пока люди сохранятся и выйдут.

3. Завершите оставшиеся сеансы. Кто остался «висеть» — завершите принудительно из консоли или через rac (точные параметры — в справке rac help). Проверьте, что фоновые задания не выполняются.

4. Остановите службу агента сервера. На Windows — через services.msc, служба называется «1C:Enterprise 8.3 Server Agent» или «Агент сервера 1С:Предприятия» (в скобках — номер версии и имя экземпляра). На Linux — через systemctl stop для юнита srv1cv8-8.3.xx.xxxx@default.

После остановки службы убедитесь, что процессы ragent.exe, rmngr.exe и rphost.exe (на Linux — соответствующие процессы) завершились. Если rphost остался — дайте ему закрыться или снимите вручную.

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

Ключевой момент: новая версия ставится в собственную папку и не затирает старую.

На Windows. Запустите setup.exe из распакованного дистрибутива. В списке компонентов отметьте:

• Сервер 1С:Предприятия — сам серверный модуль;
• Администрирование сервера 1С:Предприятия — консоль и утилиты rac/ras;
• при необходимости — Модули расширения веб-сервера, если на этой машине публикуются базы.

Мастер установки предложит зарегистрировать сервер как службу Windows — согласитесь. При этом служба агента будет пересоздана и начнёт указывать на ragent.exe новой версии. Имя экземпляра (default или своё) и порт агента (1540 по умолчанию) оставьте такими же, как были.

Если мастер не предлагает переустановить службу, значит она осталась на старом номере. Тогда службу переключают вручную: удаляют старую регистрацию и регистрируют агент из каталога новой версии (...\1cv8\8.3.xx.xxxx\bin). Делайте это утилитой установки службы из комплекта платформы — не правьте путь службы вслепую.

На Linux. Установите серверные пакеты новой версии из скачанного комплекта (dpkg -i для deb, rpm -U для rpm). Каждая версия регистрирует свой systemd-юнит вида srv1cv8-8.3.xx.xxxx@default. После установки включите и запустите юнит новой версии, а старый остановите и отключите:

systemctl enable --now srv1cv8-8.3.24.xxxx@default
systemctl disable --now srv1cv8-8.3.23.xxxx@default

Так старая версия остаётся в системе — к ней можно вернуться, не переустанавливая.

Переключение кластера на новую версию и первая проверка

Запустите службу агента новой версии и убедитесь, что кластер поднялся на правильном номере.

Проверьте список кластеров и баз через администрирование:

rac cluster list
rac infobase summary list --cluster=<идентификатор>

Команда rac cluster list покажет кластер и его параметры; версия платформы в ответе должна соответствовать только что установленной. Порты остаются прежними: агент — 1540, менеджер кластера — 1541, рабочие процессы — из диапазона, заданного в свойствах рабочего сервера (по умолчанию 1560–1591).

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

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

Если публиковали базы на веб-сервере (тонкий клиент через браузер или веб-клиент), переопубликуйте их из новой версии платформы — модуль расширения веб-сервера привязан к номеру платформы. Разрядность модуля должна совпадать с разрядностью веб-сервера: 64-битному Apache или IIS нужен 64-битный модуль. После переопубликации перезапустите веб-сервер, иначе он продолжит держать старую версию модуля в памяти.

Проверка работоспособности и ввод в эксплуатацию

Пока вход для пользователей ещё закрыт, проверьте всё сами.

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

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

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

Что делать, если кластер не поднялся

Откат здесь быстрый, потому что старая версия никуда не делась.

Сам откат на Windows: остановите службу, переключите её регистрацию обратно на ragent.exe старой версии, запустите. На Linux — остановите юнит новой версии, запустите юнит старой (systemctl start srv1cv8-<старый номер>@default). Данные кластера общие, так что база откроется как раньше.

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

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