Как обновить платформу 1С в клиент-серверном варианте с MS SQL Server
Содержание
Обновление платформы 1С на сервере с SQL сводится к пяти действиям: снять резервную копию базы в MS SQL Server, завершить сеансы пользователей , остановить службу агента сервера , установить новый дистрибутив платформы и снова поднять кластер. Саму СУБД MS SQL Server при этом трогать не нужно — это отдельный продукт со своим циклом обновлений.
Платформа и конфигурация обновляются по-разному. Платформа — это ядро 1cv8 (службы ragent, rmngr, rphost), её номер выглядит как 8.3.xx.xxxx. Конфигурация (Бухгалтерия, ЗУП, УТ) — прикладное решение поверх платформы. Здесь речь только о платформе: меняется версия сервера, прикладное решение в базе остаётся прежним.
Работы ведут в окно обслуживания. На время остановки службы все подключения к базам прервутся, поэтому обновление планируют на вечер или выходной и предупреждают пользователей заранее. На типовой сервер весь цикл с резервной копией и проверками занимает от получаса до двух часов — закладывайте запас на случай отката.
Что меняем, а что остаётся прежним
Частая ошибка — думать, что вместе с платформой придётся переустанавливать базу или обновлять SQL. Нет. Обновление платформы затрагивает только исполняемые файлы сервера 1С и клиентов. Данные в MS SQL Server и каталог кластера остаются на месте.
Чаще всего платформу обновляют не ради самой платформы, а потому что этого требует новая версия конфигурации: прикладные решения выходят с условием «версия платформы не ниже такой-то». Поэтому сначала смотрят, какой минимальный номер платформы нужен обновлению конфигурации, и ставят версию не ниже требуемой.
| Компонент | Обновляем? |
|---|---|
Платформа 1С на сервере (ragent/rmngr/rphost) | Да, ставим новый дистрибутив |
| Клиентская платформа на компьютерах пользователей | Да, версия клиента должна совпадать с сервером |
| Консоль администрирования серверов | Да, до той же версии, что и сервер |
| Конфигурация базы (БП, ЗУП и т. д.) | Нет, это отдельное обновление |
| MS SQL Server | Нет, остаётся как есть |
Если новая платформа требует более свежую версию MS SQL Server, чем у вас стоит, — это два независимых проекта. Сначала по отдельному регламенту обновляют СУБД, и только потом платформу.
Резервные копии: база в SQL и каталог кластера
До любых действий — резервная копия. Без свежего бэкапа базы обновление начинать нельзя. На клиент-серверной базе копию снимают средствами MS SQL Server, а не выгрузкой в .dt: это быстрее и не требует монопольного доступа.
В SQL Server Management Studio: правый клик по базе → Задачи → Создать резервную копию, тип — полная. Или командой T-SQL:
BACKUP DATABASE [ИмяВашейБазы]
TO DISK = N'E:\Backup\base_before_update.bak'
WITH INIT, COPY_ONLY, COMPRESSION;
COPY_ONLY делает копию, не вмешиваясь в цепочку обычных регулярных бэкапов, — удобно для разовой копии перед работами. После завершения копирования убедитесь, что файл .bak действительно создался и читается: пустой или недописанный бэкап при откате не спасёт. Если база в модели восстановления FULL, для точки восстановления между регулярными копиями дополнительно снимают бэкап журнала транзакций.
Кроме базы, сохраните каталог srvinfo — в нём хранится реестр кластера: список баз, настройки, права администраторов. По умолчанию его путь задаётся параметром -d при регистрации службы агента. Копируют каталог при остановленной службе, иначе часть файлов будет занята рабочими процессами.
Храните дистрибутив старой версии рядом. Если после обновления что-то пойдёт не так, откат — это установка прежней платформы обратно; база и SQL при этом не меняются.
Завершение сеансов и остановка службы агента
Сначала закрывают доступ, потом останавливают службу. Если просто выключить агента на работающей базе, незавершённые транзакции пользователей оборвутся.
Порядок:
- В консоли администрирования серверов откройте свойства информационной базы и включите блокировку начала сеансов, задав код разрешения. Новые подключения перестанут приниматься, активные — доучат работу.
- Отключите регламентные задания на время обновления (флажок блокировки в тех же свойствах базы).
- Через список сеансов убедитесь, что активных подключений не осталось, при необходимости завершите «зависшие».
- Остановите службу
Агент сервера 1С:Предприятиячерез оснасткуservices.msc(или командойsc stopпо имени службы). Остановка агента завершает рабочие процессыrphost— кластер гаснет полностью.
Остановка службы агента рвёт все сеансы всех баз этого сервера, а не только обновляемой. Делайте это только в согласованное окно и только после того, как убедились, что пользователи вышли.
Если на сервере поднят отдельно сервис RAS (удалённое администрирование, ras.exe), его тоже останавливают — он привязан к версии платформы.
Установка новой версии платформы на сервере
Запускают дистрибутив новой платформы (setup.exe) от имени администратора.
- В списке компонентов выберите
Сервер 1С:Предприятия(для современных серверов — 64-разрядный). Остальные компоненты ставьте по необходимости: администрирование сервера, модули расширения веб-сервера. - На шаге установки сервиса отметьте установку сервера как службы Windows и укажите ту же учётную запись, под которой служба работала раньше (обычно
USR1CV8или доменный сервисный пользователь). Учётная запись должна совпадать со старой — иначе служба не получит доступ к каталогу srvinfo. - Проверьте, что путь к каталогу кластера (
srvinfo) и порты остались прежними: агент — 1540, менеджер кластера — 1541, диапазон рабочих процессов — 1560:1591 по умолчанию. Менять их при обновлении не нужно. - Дождитесь завершения установки. Платформа 1С допускает параллельную установку нескольких версий — старая остаётся на диске, но активной службой становится новая.
Если установщик не предложил перерегистрировать службу (такое бывает при параллельных версиях), службу агента пересоздают вручную под новую версию ragent.exe, сохранив прежние порты и каталог srvinfo. Точные параметры запуска агента смотрите в документации платформы и в описании уже существующей службы — не меняйте их наугад.
Перед установкой проверьте целостность дистрибутива и временно не мешайте установщику: агрессивный антивирус или блокировка файлов 1cv8 открытым процессом приводят к ошибкам копирования. Если дистрибутив требует перезагрузки сервера — выполните её в том же окне обслуживания, а не откладывайте «на потом».
Если кластер распределён по нескольким рабочим серверам, новую платформу ставят на каждый узел и доводят все узлы до одной версии. Смешанных версий в одном кластере быть не должно.
Запуск кластера и проверка версий
После установки поднимают кластер и проверяют, что всё сошлось по версиям.
- Запустите службу
Агент сервера 1С:Предприятия. В диспетчере задач должны появиться процессыragent,rmngrиrphost. - Обновите консоль администрирования серверов до новой версии. Если оснастка не подключается к кластеру, перерегистрируйте её библиотеку:
regsvr32 "C:\Program Files\1cv8\<номер версии>\bin\radmin.dll". Это типичная причина, по которой консоль «не видит» сервер после обновления. - Подключитесь к кластеру консолью и убедитесь, что база в списке, администраторы на месте, блокировку сеансов можно будет снять.
- Обновите клиентскую платформу на компьютерах пользователей. Версия клиента должна совпадать с версией сервера — при расхождении 1С выдаст сообщение о несовпадении версий и не пустит в базу. Клиенты раздают через общий каталог запуска, групповые политики или ручную установку.
Если клиенты запускаются через 1cestart.exe и настроен каталог шаблонов/дистрибутивов, новую версию кладут туда — тогда клиенты подхватят её автоматически при следующем запуске.
Снимать блокировку начала сеансов и возвращать пользователей стоит только после проверки на одной-двух тестовых учётках.
Лицензии после обновления платформы
Отдельный повод для паники после обновления — «пропали лицензии». Обычно пропадать нечему.
Программные лицензии 1С привязаны к параметрам оборудования сервера, а не к версии платформы. Смена версии сама по себе их не сбрасывает — повторная активация, как правило, не нужна. Файлы лицензий лежат в системном каталоге лицензирования и остаются на месте.
Аппаратные ключи HASP обслуживает менеджер лицензий (HASP License Manager) вместе с драйвером ключа. Ключ при обновлении платформы никуда не девается, но проверьте два момента:
- служба менеджера лицензий запущена, сетевой ключ виден;
- драйвер ключа актуален — на старом драйвере новая платформа иногда не видит ключ.
После запуска кластера загляните в список сеансов: там видно, какие лицензии получены. Из командной строки занятые лицензии показывает rac session list --licenses. Если лицензии не выдаются — проверьте доступность сервера лицензирования и открытые порты между клиентом и сервером.
Если на сервере стоит только серверная лицензия, а клиентские раздаёт отдельный сервер лицензирования или ключ, убедитесь, что после обновления связь с ним не потерялась — иначе пользователи упрутся в сообщение «не найдена лицензия».
Обновление информационных баз и проверка работы
Обновление платформы само по себе не меняет структуру базы. Но при первом открытии базы новой версией конфигуратор может предложить реструктуризацию — это нормально.
- Откройте базу в конфигураторе под новой платформой. Если появится запрос на обновление конфигурации базы данных, выполните его. Эта операция меняет структуру таблиц в SQL и требует монопольного доступа, поэтому её делают в том же окне обслуживания.
- Запустите базу в режиме предприятия на тестовой учётке. Проверьте вход, открытие часто используемых документов и отчётов, проведение документа, фоновые и регламентные задания.
- Проверьте обмены и интеграции: веб-сервисы, HTTP-сервисы, публикации на веб-сервере. После смены версии платформы публикации на IIS или Apache иногда нужно обновить — переопубликовать базу из конфигуратора.
- Снимите блокировку начала сеансов, включите обратно регламентные задания и пустите пользователей.
Если после обновления отдельный клиент ведёт себя странно — не открывает формы, выдаёт ошибки компоновки, — почистите его локальный кэш (каталог профиля пользователя 1cv8) и запустите заново. Серверный кэш пересоздаётся при перезапуске службы автоматически.
Первый рабочий день после обновления держат на контроле: следят за загрузкой процессора рабочими процессами rphost, временем открытия документов и объёмом журнала регистрации. Резкий рост нагрузки или ошибки в журнале — повод разобраться сразу, а не копить до жалоб пользователей.
Монопольный доступ нужен только для обновления структуры базы. Если конфигуратор не просит реструктуризацию, захватывать базу монопольно не требуется.
Частые ошибки при обновлении сервера 1С
Отдельно проверьте журнал регистрации и технологический журнал в первые часы после обновления — там видно ошибки рабочих процессов, которые на экране пользователя не всплывают.