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

Администрирование сервера 1С сводится к пяти задачам: поставить службу агента, закрыть кластер паролем администратора, зарегистрировать информационные базы, следить за сеансами и памятью рабочих процессов и делать резервные копии на уровне СУБД. Всё это делается в консоли «Администрирование серверов 1С Предприятия» или из командной строки утилитой rac.

Ниже речь о платформе 8.3 (релизы 8.3.2x) на Windows Server 2016 и новее. На Linux логика кластера та же, отличаются только управление службой и пути к каталогам.

Как устроен сервер 1С и за что отвечает администратор

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

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

Зона ответственности администратора 1С:

• 🔐 кто может управлять кластером и создавать базы;
• 🗄️ регистрация баз и их связь с базами данных СУБД;
• 📊 контроль сеансов, лицензий, памяти и зависших соединений;
• 🧾 журналы: журнал регистрации баз и технологический журнал;
• 💾 резервные копии и план восстановления после сбоя.

СУБД (MS SQL Server или PostgreSQL) обычно ведёт отдельный специалист, но связка «служба 1С — СУБД» всё равно на вас.

Установка службы агента и первичная настройка кластера

Установка

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

💡 Запускайте службу от отдельной доменной или локальной учётной записи без прав администратора Windows. Ей нужны право «Вход в качестве службы» и полный доступ к каталогу кластера.

Каталог кластера по умолчанию — C:\Program Files\1cv8\srvinfo. Его разумно сразу перенести на быстрый диск с запасом места: там лежат журналы регистрации и сеансовые данные. Каталог задаётся параметром -d в строке запуска службы.

Если служба ставилась вручную, её регистрируют так:

"C:\Program Files\1cv8\8.3.24.1342\bin\ragent.exe" -instsrvc -usr .\USR1CV8 -pwd "Пароль" -regport 1541 -port 1540 -range 1560:1591 -d "D:\srvinfo" -debug

Номер релиза в пути подставьте свой. Ключ -debug включает отладку на сервере; на рабочем сервере его обычно не указывают.

Первичная настройка кластера

При первом старте агент сам создаёт «Локальный кластер» на порту 1541 и рабочий сервер. Дальше:

1. Откройте консоль и добавьте центральный сервер: правой кнопкой по корню «Central 1C:Enterprise 8.3 servers» → новый центральный сервер, имя компьютера, порт 1540.
2. Проверьте свойства рабочего сервера: диапазон портов, число баз и соединений на процесс.
3. Откройте порты 1540, 1541 и 1560–1591 во входящих правилах брандмауэра.

Администраторы кластера, права и создание информационных баз

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

Порядок назначения администраторов

1. В узле центрального сервера откройте ветку «Администраторы» и создайте администратора центрального сервера.
2. В узле кластера откройте его ветку «Администраторы» и создайте администратора кластера.

Сначала заведите администратора центрального сервера, потом кластера. После создания первого администратора консоль сразу начнёт спрашивать пароль. Запишите его в менеджер паролей: восстановить его средствами консоли нельзя.

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

Учётке можно разрешить вход по паролю 1С, через аутентификацию Windows или обоими способами. Для доменной сети удобнее второе.

Создание информационной базы на сервере

В узле кластера: Информационные базы → Создать → Информационная база. Поля, на которых чаще всего ошибаются:

Флажок «Создать базу данных в случае её отсутствия» создаст пустую базу в СУБД. Если база в СУБД уже есть, его не ставят.

⚠️ Для копии рабочей базы, поднятой на тестовом сервере, блокировку регламентных заданий включайте сразу при регистрации. Иначе копия начнёт обмены, рассылки и загрузку банковских выписок от имени боевой базы.

Права пользователей внутри базы (роли, профили) настраиваются уже в самой конфигурации, а не в консоли кластера. Консоль решает только, кто может управлять кластером и базами.

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

Если консоль не открывается

Ярлык консоли есть в меню «Пуск» после установки сервера или клиента с утилитой администрирования. Частая ситуация после обновления платформы: консоль открывается с ошибкой или пустая. Причина — в системе зарегистрирована библиотека от старого релиза. Перерегистрируйте её от имени администратора:

regsvr32 "C:\Program Files\1cv8\8.3.24.1342\bin\radmin.dll"

Версия консоли должна совпадать с версией агента сервера.

Командная строка: ras и rac

Для удалённого и скриптового управления служит связка ras (сервер администрирования, порт 1545) и rac (клиент). Запуск сервера администрирования как службы:

sc create "1C:Enterprise 8.3 Remote Server" binPath= "\"C:\Program Files\1cv8\8.3.24.1342\bin\ras.exe\" cluster --service --port=1545 localhost:1540" start= auto

Базовые команды rac:

rac localhost:1545 cluster list
rac localhost:1545 infobase summary list --cluster=<UUID>
rac localhost:1545 session list --cluster=<UUID>
rac localhost:1545 session list --cluster=<UUID> --licenses

UUID кластера берут из вывода cluster list. Если кластер защищён, добавьте --cluster-user и --cluster-pwd. Остальные параметры смотрите в rac help.

Что смотреть в консоли каждый день

• 👥 Сеансы — кто подключён, к какой базе, с какого компьютера и сколько времени висит.
• 🔒 Блокировки — какие объекты держит сеанс. Полезно, когда пользователь жалуется на ожидание записи.
• ⚙️ Рабочие процессы — занятая память, число соединений, доступная производительность.
• 🪪 Лицензии — какой сеанс какую лицензию взял: клиентскую с ключа или программную с сервера.

Удалить зависший сеанс можно из списка сеансов. Пользователь потеряет несохранённые данные, поэтому сначала свяжитесь с ним.

Журнал регистрации, технологический журнал и аудит

Журнал регистрации

Он пишет действия пользователей: вход и выход, изменение данных, ошибки. Хранится в каталоге кластера, в подпапке с UUID базы, папка 1Cv8Log.

Уровень и срок хранения настраивают в Конфигураторе: Администрирование → Настройка журнала регистрации. Типовые варианты:

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

В пользовательском режиме БП 3.0, ЗУП 3.1 и УТ 11 журнал открывается из раздела Администрирование → Обслуживание. Там же удобно отбирать события по пользователю, базе метаданных и периоду, это и есть основной инструмент аудита: кто удалил документ, кто менял права, кто входил ночью.

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

Он нужен, когда журнала регистрации мало: долгие запросы, взаимоблокировки, падения рабочих процессов. Включается файлом logcfg.xml в каталоге conf платформы. Минимальный пример для сбора исключений и долгих событий:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

history — сколько часов хранить файлы. Сервер подхватывает файл примерно за минуту без перезапуска.

Производительность: память рабочих процессов и регламентные задания

Память и перезапуск процессов

Главная беда сервера 1С — утечки памяти в rphost. Их гасят настройками, а не ночными перезагрузками.

В свойствах кластера:

• «Интервал перезапуска» — плановый перезапуск рабочих процессов, в секундах. Значение 86400 означает раз в сутки.
• «Допустимый объём памяти» и «Интервал превышения допустимого объёма памяти» — процесс, который дольше заданного времени держит память сверх лимита, мягко выводится из работы.
• «Принудительно завершать проблемные процессы» — флажок для процессов, которые не отвечают.

В свойствах рабочего сервера:

• «Критический объём памяти процессов» — при его достижении сервер начинает принудительно обрывать вызовы;
• «Безопасный расход памяти за один вызов» — защищает от одного тяжёлого отчёта, который съедает всю память;
• «Количество ИБ на процесс» и «Количество соединений на процесс» — распределение нагрузки между процессами.

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

Регламентные задания

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

1. Консоль кластера — флажок «Блокировка регламентных заданий включена» в свойствах базы останавливает все задания разом. Нужен для копий и на время обслуживания.
2. Сама конфигурация — в БП, ЗУП и УТ список заданий открывается из Администрирование → Обслуживание → Регламентные операции. Там включают и выключают отдельные задания и меняют расписание.

💡 Тяжёлые задания (полнотекстовый индекс, пересчёт итогов, выгрузки) переносите на ночь, чтобы они не конкурировали с пользователями за рабочие процессы.

Резервное копирование и восстановление сервера 1С

Резервируют две разные вещи: данные баз и настройки самого кластера.

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

Для PostgreSQL ночная копия может выглядеть так:

"C:\Program Files\PostgreSQL\15\bin\pg_dump.exe" -U postgres -Fc -f "E:\backup\buh_%date:~-4%%date:~3,2%%date:~0,2%.backup" buh

Формат даты в имени файла зависит от региональных настроек Windows, проверьте результат на тестовом запуске.

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

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

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

Ошибки, которые чаще всего ломают кластер

• ❌ Разные релизы клиента и сервера. Клиент не подключится. После обновления сервера обновляйте и клиентские места.
• ❌ Открыт только порт 1541. Подключение падает на этапе обращения к рабочему процессу. Нужен весь диапазон из свойств рабочего сервера.
• ❌ Кластер без администраторов. Любой пользователь сети может удалить базу из кластера или завершить чужие сеансы.
• ❌ Копия рабочей базы без блокировки заданий. Тестовая база отправляет документы контрагентам и забирает выписки.
• ❌ Перезагрузка сервера посреди дня «от тормозов». Обрываются все сеансы, а причина остаётся. Сначала посмотрите память процессов и долгие сеансы в консоли.
• ❌ Бэкап на тот же диск, что и база. При отказе диска теряется и то, и другое.

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