Как настроить администрирование серверов 1С

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

Основной инструмент администратора — консоль управления кластером серверов (в Windows это оснастка «Администрирование серверов 1С Предприятия», в Linux — утилиты rac/ras или кроссплатформенная консоль). Через неё создаются базы, назначаются администраторы, настраиваются требования назначения функциональности и ограничения ресурсов. Часть задач удобнее выполнять из конфигуратора или скриптами через RAS.

Ниже разобран практический порядок настройки: от установки агента сервера до мониторинга и резервного копирования. Материал ориентирован на администратора, который впервые разворачивает кластер или приводит в порядок уже работающий.

Что понадобится перед началом настройки

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

Проверьте сетевую доступность: агент сервера по умолчанию использует порт 1540, рабочие процессы — диапазон 1560–1591, сервер администрирования RAS — порт 1545. Эти порты должны быть открыты между клиентами, сервером 1С и сервером СУБД. Учётная запись, под которой работает служба агента (по умолчанию USR1CV8 в Windows), должна иметь права на каталоги служебных файлов кластера и доступ к серверу СУБД.

Установка агента сервера и первичная регистрация кластера

При установке дистрибутива выберите компонент «Сервер 1С:Предприятия» и «Администрирование сервера». В Windows служба «Агент сервера 1С:Предприятия» регистрируется автоматически и запускается от имени созданной учётной записи. В Linux агент запускается скриптом srv1cv8 с указанием каталога данных кластера и диапазона портов.

После запуска агента откройте консоль кластера и зарегистрируйте в ней свой сервер: «Кластеры» → «Добавить», укажите имя сервера и порт агента. Внутри появится локальный кластер с рабочим процессом. Если консоль не видит сервер, проверьте, запущена ли служба агента и не блокирует ли брандмауэр порт 1540.

1. 1
   Установите дистрибутив сервера той же версии, что и платформа клиентов
2. 2
   Убедитесь, что служба агента запущена и слушает порт 1540
3. 3
   Зарегистрируйте сервер в консоли кластера
4. 4
   Создайте информационную базу или зарегистрируйте существующую
5. 5
   Назначьте администраторов кластера и базы
6. 6
   Настройте резервное копирование на уровне СУБД

Настройка рабочих процессов и требований функциональности

Каждый рабочий процесс rphost потребляет оперативную память пропорционально активности пользователей. На одном сервере по умолчанию работает один процесс; для баз с десятками одновременных сеансов рекомендуется увеличить их число — это повышает отказоустойчивость: при аварийном завершении одного процесса сеансы перераспределяются между оставшимися.

Количество процессов настраивается в свойствах рабочего сервера: параметр «Количество ИБ на процесс» и «Количество соединений на процесс» ограничивают нагрузку на один rphost. Требования назначения функциональности позволяют выделить отдельный сервер под регламентные задания или сервисы, чтобы фоновая нагрузка не мешала интерактивной работе пользователей.

Ограничение объёма памяти рабочих процессов (параметры «Допустимый объём памяти» и «Интервал превышения» в свойствах кластера) защищает сервер от полного исчерпания RAM: при превышении лимита кластер перезапускает процессы, сохраняя сеансы пользователей.

Разграничение прав: администраторы кластера, сервера и баз

В архитектуре 1С существуют три независимых уровня администраторов. Администраторы агента сервера управляют списком кластеров и рабочими серверами. Администраторы кластера создают и удаляют информационные базы, управляют сеансами и блокировками. Администраторы информационной базы работают внутри конкретной базы: заводят пользователей, назначают роли.

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

Управление сеансами, блокировками и регламентными заданиями

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

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

Автоматизация через RAS и rac

Сервер администрирования (RAS) вместе с консольной утилитой rac позволяет выполнять все операции консоли кластера из командной строки: создавать базы, управлять сеансами, блокировками, администраторами. Это основа для скриптов обслуживания — например, ночной блокировки базы, выгрузки и снятия блокировки.

RAS запускается как служба или приложение и подключается к агенту сервера. Утилита rac входит в состав дистрибутива платформы. Пример получения списка сеансов кластера:

rac session list --cluster=<ID_кластера> --cluster-user=Администратор --cluster-pwd=***

Скрипты на rac удобно интегрировать с планировщиком задач, но храните пароли администраторов не в теле скрипта, а в защищённом хранилище или переменных среды с ограниченным доступом.

Резервное копирование и журнал регистрации

Резервное копирование клиент-серверных баз выполняется средствами СУБД (MS SQL, PostgreSQL, Oracle), а не выгрузкой в dt: только так обеспечивается восстановление на произвольный момент времени и консистентность при активной работе пользователей. Выгрузка в dt подходит как дополнительная мера перед обновлением конфигурации.

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

Мониторинг и типовые проблемы

Следите за тремя группами показателей: память и загрузка рабочих процессов, длительность запросов к СУБД, дисковое пространство под журналы и временные файлы. Резкий рост памяти одного rphost обычно означает утечку в прикладном коде или тяжёлый отчёт; рост времени ответа СУБД — нехватку индексов или блокировки.

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

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