Настройка кластера серверов 1С 8.3: параметры администрирования

Кластер серверов 1С 8.3 — это связка из нескольких рабочих процессов, которая распределяет нагрузку между пользователями базы данных. Правильная настройка параметров администрирования определяет, насколько стабильно работает система, как быстро обновляются конфигурации и сколько пользователей может одновременно работать без тормозов. В этом руководстве разберём ключевые параметры консоли администрирования кластера, их значения по умолчанию и рекомендуемые настройки для типовых сценариев.

Материал рассчитан на системных администраторов, которые настраивают производственные среды 1С на выделенных серверах. Здесь вы найдёте конкретные значения параметров, пошаговые инструкции и объяснение, как каждая настройка влияет на работу кластера.

Доступ к консоли администрирования кластера

Консоль администрирования кластера 1С — это служебное приложение, которое входит в состав платформы. Через него настраивают рабочие процессы, серверы, базы данных и службы кластера. Консоль работает по протоколу TCP/IP и подключается к менеджеру кластера (процесс ragent.exe в Windows или ragent в Linux) на порту 1540 по умолчанию.

Чтобы открыть консоль, запустите файл 1cv8s.exe (Windows) или 1cv8s (Linux) из каталога установки платформы. При первом запуске введите адрес сервера кластера в формате server-name:1540 или IP-адрес:1540. Если кластер развёрнут локально, используйте localhost:1540. Авторизуйтесь с учётной записью администратора кластера, если защита включена.

После подключения в дереве консоли отобразится структура кластера: центральный сервер, рабочие серверы, рабочие процессы и информационные базы. Настройки кластера находятся в контекстном меню объекта «Кластер» — пункт «Свойства».

Параметры менеджера кластера

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

Порт менеджера кластера

По умолчанию 1540. Изменять имеет смысл, если на сервере работают несколько независимых кластеров или порт занят другим сервисом. После изменения перезапустите службу агента сервера (rphost в Windows, srv1cv8 в Linux). Все клиенты и внешние системы должны будут подключаться к новому порту.

Интервал проверки доступности серверов

Параметр называется Lifetime timeout (время жизни соединения). Значение по умолчанию — 1800 секунд (30 минут). Менеджер кластера каждые 30 минут проверяет, отвечают ли рабочие серверы кластера. Если сервер не отвечает дольше этого времени, он исключается из списка активных.

Для критичных систем рекомендуем сократить до 600-900 секунд (10-15 минут). Это позволит быстрее обнаружить отказ сервера и перераспределить нагрузку на работающие узлы. Но слишком короткий интервал (меньше 300 секунд) может привести к ложным срабатываниям при кратковременных сетевых задержках.

Интервал перезапуска рабочих процессов

Параметр Expiration timeout отвечает за автоматическую перезагрузку рабочих процессов. Значение по умолчанию — 0 (отключено). Если установить, например, 3600 секунд (1 час), каждый рабочий процесс будет автоматически перезапускаться через час работы.

Рекомендуется оставить 0 и перезапускать процессы только вручную или по расписанию в нерабочее время. Автоматический перезапуск прерывает сеансы пользователей, что приводит к потере несохранённых данных. Исключение — тестовые стенды или случаи, когда в рабочих процессах накапливаются утечки памяти из-за некорректной внешней обработки.

Параметры рабочих процессов

Рабочий процесс (rphost.exe в Windows, rphost в Linux) — это исполняемый файл платформы 1С, который обрабатывает запросы клиентов. Один рабочий сервер может запустить несколько рабочих процессов для параллельной обработки подключений. Параметры рабочих процессов определяют, сколько памяти они потребляют, как распределяют соединения и когда отключают неактивных пользователей.

Количество рабочих процессов

Настраивается на уровне рабочего сервера. Откройте в консоли администрирования узел «Рабочий сервер» → «Свойства» → вкладка «Рабочие процессы». По умолчанию количество процессов равно количеству логических ядер процессора минус 1. Например, на сервере с 8 ядрами создаётся 7 рабочих процессов.

Для типовых баз 1С рекомендуется формула: количество ядер × 0,75. На сервере с 16 ядрами оптимально 12 процессов. Для баз с интенсивными запросами к SQL (большие отчёты, регламентные операции) можно уменьшить до количество ядер × 0,5, чтобы снизить конкуренцию за процессорное время между процессами 1С и СУБД.

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

Использование памяти рабочим процессом

Параметр Memory limit ограничивает максимальный объём оперативной памяти, который может занять один рабочий процесс. Значение указывается в мегабайтах. По умолчанию — 0 (без ограничений).

Рекомендуемое значение зависит от объёма ОЗУ сервера и количества процессов. Формула: (Общий объём RAM − 4 ГБ на ОС) / количество процессов × 0,8. Например, сервер с 64 ГБ RAM и 12 рабочими процессами: (64 − 4) / 12 × 0,8 = 4000 МБ. Установите Memory limit = 4000.

Если процесс превышает лимит, платформа принудительно завершает его. Пользователи, подключённые к этому процессу, получат ошибку и потеряют несохранённые данные. Чтобы избежать аварийных завершений, мониторьте потребление памяти через консоль администрирования (пункт меню «Активные пользователи») или системные утилиты (Диспетчер задач, htop).

Количество соединений на рабочий процесс

Параметр Connections определяет, сколько одновременных клиентских подключений может обработать один рабочий процесс. Значение по умолчанию — 128.

Для файл-серверных баз (редко применяется в промышленных системах) это число означает активные сеансы. Для клиент-серверных баз — количество одновременных подключений к базе данных через платформу.

Рекомендуется оставить 128 для большинства сценариев. Если в базе работают менее 50 пользователей, можно снизить до 64, чтобы уменьшить накладные расходы на управление пулом соединений. Для высоконагруженных систем (более 200 одновременных сеансов) увеличивайте не этот параметр, а количество рабочих процессов.

Таймаут неактивного соединения

Параметр Connection idle timeout отключает клиента, который не отправлял запросы к серверу дольше заданного времени. Значение указывается в секундах. По умолчанию — 0 (отключение по таймауту не производится).

Рекомендуемое значение — 3600 секунд (1 час). Это предотвращает накопление «зависших» соединений, когда пользователь ушёл с рабочего места, не закрыв клиент 1С. Такие соединения занимают ресурсы рабочего процесса и лицензии.

Для бухгалтерских баз, где формирование отчётов занимает больше часа, увеличьте до 7200 секунд (2 часа). Для розничных баз (кассы, терминалы сбора данных) можно сократить до 1800 секунд (30 минут).

Параметры информационных баз

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

Блокировка регламентных заданий

Параметр Scheduled jobs deny запрещает выполнение регламентных заданий (резервное копирование, обмен данными, загрузка курсов валют и т.д.). Значение по умолчанию — выключено (регламентные задания работают).

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

Блокировка начала сеансов

Параметр Sessions deny запрещает пользователям подключаться к базе. Действующие сеансы продолжают работать до завершения. Значение по умолчанию — выключено.

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

Можно установить сообщение для пользователей, которое они увидят при попытке подключения. Например: «База обновляется. Доступ откроется в 14:00». Текст задаётся в параметре Denied message.

Разрешение на создание расширений

Параметр Extensions deny запрещает подключение расширений конфигурации. Расширения — это механизм добавления функциональности без изменения типовой конфигурации. Значение по умолчанию — выключено (расширения разрешены).

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

Ведение журнала регистрации

Параметр Log включает запись действий пользователей в технологический журнал. Значение по умолчанию — выключено. Журнал хранится на сервере в каталоге logdir, который настраивается при установке платформы.

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

Параметры безопасности кластера

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

Включение авторизации администраторов кластера

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

Рекомендуется создать минимум двух администраторов — основного и резервного — на случай утери пароля. Храните учётные данные в защищённом хранилище (KeePass, 1Password) или корпоративной системе управления секретами.

Защита информационных баз паролем

Для каждой информационной базы можно задать отдельного администратора базы. Это позволяет разграничить доступ: один сотрудник администрирует кластер, другой — отдельную базу данных. Настройка находится в свойствах информационной базы → вкладка «Администраторы».

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

Типовые конфигурации параметров кластера

Ниже приведены рекомендуемые значения параметров для трёх типовых сценариев: малая компания (до 20 пользователей), средняя компания (50-100 пользователей) и крупная компания (200+ пользователей).

Параметр	Малая (до 20)	Средняя (50-100)	Крупная (200+)
Рабочих процессов	2-4	6-12	16-32
Memory limit, МБ	2000	4000	6000
Connections на процесс	64	128	128
Connection idle timeout, сек	3600	3600	1800
Lifetime timeout, сек	1800	900	600
Журнал регистрации	Ошибки	Ошибки и предупреждения	Ошибки и предупреждения
Авторизация администраторов	Включена	Включена	Включена

Эти значения — отправная точка. После развёртывания кластера мониторьте использование процессора, памяти, длину очередей подключений. Если рабочие процессы стабильно загружены на 80-90%, увеличьте их количество. Если потребление памяти приближается к лимиту, пересмотрите Memory limit или оптимизируйте запросы в конфигурации.

Настройка параметров через консоль администрирования: пошаговая инструкция

Изменение параметров через командную строку

Платформа 1С поддерживает управление кластером через утилиту rac.exe (Windows) или rac (Linux). Это полезно для автоматизации настройки в скриптах или Ansible-плейбуках. Утилита работает в режиме командной строки и возвращает текстовые результаты.

Пример команды для изменения Memory limit у рабочего процесса:

rac process update --cluster=cluster-id --process=process-id --memory-limit=4000 192.168.1.10:1540

Здесь cluster-id и process-id — это идентификаторы кластера и процесса, которые можно получить командами rac cluster list и rac process list. Полная документация по rac доступна в справке 1С (раздел «Администрирование сервера 1С:Предприятия 8»).

Параметры администрирования для обновления конфигурации

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

Подготовка кластера к обновлению

За 15-30 минут до обновления отправьте пользователям предупреждение о плановых работах. Используйте встроенный механизм рассылки сообщений (конфигурация 1С) или корпоративный мессенджер. Укажите точное время начала работ и ожидаемую продолжительность.

За 5 минут до обновления включите блокировку начала сеансов (параметр Sessions deny). В поле Denied message укажите: «Выполняется обновление. База будет доступна в [время]». Пользователи, которые попытаются подключиться, увидят это сообщение вместо ошибки соединения.

Включите блокировку регламентных заданий (Scheduled jobs deny). Это предотвратит запуск фоновых задач во время обновления, которые могут конфликтовать с изменением структуры метаданных.

Дождитесь завершения всех активных сеансов. Если через 10 минут после блокировки остались сеансы, свяжитесь с пользователями и попросите завершить работу. Принудительное отключение (через консоль администрирования → «Прервать») используйте только в крайнем случае — пользователи потеряют несохранённые данные.

Настройка параметров на время обновления

Временно увеличьте Memory limit для рабочих процессов на 20-30%. Обновление конфигурации и перестройка индексов базы данных потребляют больше памяти, чем обычная работа. Например, если рабочий лимит 4000 МБ, установите 5000 МБ.

Отключите Connection idle timeout (установите 0). Это предотвратит разрыв соединения с конфигуратором во время длительной загрузки изменений или обновления базы данных.

Если обновление выполняется удалённо (конфигуратор запущен не на сервере кластера), увеличьте Lifetime timeout до 3600 секунд. Нестабильное сетевое соединение между конфигуратором и кластером может привести к ложному обнаружению «мёртвого» сервера.

Выполнение обновления

Подключитесь к базе в режиме конфигуратора с правами администратора. Загрузите файл обновления (CF или CFU) через меню «Конфигурация» → «Загрузить конфигурацию из файла» или «Сравнить/объединить с конфигурацией из файла». Дождитесь завершения загрузки — время зависит от размера обновления и скорости диска.

Запустите обновление базы данных: меню «Конфигурация» → «Обновить конфигурацию базы данных». Платформа проверит изменения метаданных, перестроит индексы, добавит новые поля в таблицы. Для больших баз (более 100 ГБ) процесс может занять от 30 минут до нескольких часов. Мониторьте прогресс через технологический журнал — там отображаются этапы обновления и возможные ошибки.

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

Возврат параметров в рабочий режим

Верните Memory limit к рабочему значению. Включите Connection idle timeout (например, 3600 секунд). Верните Lifetime timeout к стандартному значению (900-1800 секунд).

Отключите блокировку регламентных заданий (Scheduled jobs deny). Проверьте, что критичные задания запустятся по расписанию — откройте конфигуратор → «Администрирование» → «Регламентные и фоновые задания», убедитесь, что галочка «Блокировка регламентных заданий» снята.

Отключите блокировку начала сеансов (Sessions deny). Сообщите пользователям, что база доступна для работы. Мониторьте подключения в течение первого часа после обновления — возможны жалобы на медленную работу из-за перестройки индексов или статистики SQL.

Мониторинг параметров кластера в процессе эксплуатации

Настройка кластера — не разовая задача. Параметры требуют регулярного пересмотра по мере роста количества пользователей, увеличения объёма данных или изменения бизнес-процессов. Рекомендуется проводить ревизию настроек каждые 3-6 месяцев.

Ключевые метрики для мониторинга

Загрузка процессора рабочих процессов. Если rphost стабильно загружает ядра на 90-100%, добавьте рабочие процессы или распределите нагрузку на дополнительный сервер. Для многосерверных кластеров 1С используйте rack-серверы с высокой плотностью вычислений и расширяемостью.

Потребление памяти. Отслеживайте через консоль администрирования (раздел «Рабочие процессы» → столбец «Память, МБ») или системные утилиты. Если процесс регулярно приближается к Memory limit (более 90%), увеличьте лимит или оптимизируйте запросы в конфигурации.

Длина очереди подключений. Если пользователи получают ошибки «Все рабочие процессы заняты», увеличьте количество процессов или параметр Connections. Очередь можно увидеть через rac: команда rac process list --cluster=cluster-id выводит столбец «Available connections».

Количество активных сеансов. Если число сеансов стабильно превышает 70% от максимально возможного (Connections × количество процессов), готовьтесь к масштабированию кластера. Добавьте рабочий сервер или увеличьте количество процессов на существующих серверах.

Инструменты мониторинга

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

Технологический журнал (logdir) — для анализа производительности и ошибок. Настройте ротацию журнала (автоматическое удаление старых файлов), чтобы логи не заполнили диск. Используйте утилиты разбора журнала (встроенная обработка «АнализЖурналаРегистрации» или сторонние инструменты вроде LogParser).

Системный мониторинг (Zabbix, Prometheus, Grafana). Настройте сбор метрик через SNMP или агенты. Типовые метрики: загрузка CPU, использование RAM, дисковая подсистема (IOPS, задержка), сетевой трафик. Постройте дашборды для визуализации трендов.

Частые ошибки при настройке параметров кластера

Слишком много рабочих процессов

Распространённая ошибка — запустить количество процессов, равное или больше количества логических ядер. Например, на сервере с 8 ядрами создать 8 или 16 процессов. Это приводит к избыточному переключению контекста операционной системы между процессами. Процессор тратит время на управление очередями вместо выполнения полезной работы.

Симптомы: высокая загрузка CPU (80-100%), но низкая пропускная способность (пользователи жалуются на медленную работу). Решение: сократите количество процессов до количество ядер × 0,5-0,75.

Отсутствие Memory limit

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

Симптомы: периодические «зависания» сервера, медленная работа всех баз на кластере, высокое использование диска (swap). Решение: установите Memory limit по формуле из раздела «Параметры рабочих процессов». Оптимизируйте проблемные запросы, чтобы они не загружали все данные в память сразу.

Забыли снять блокировку после обновления

После обновления конфигурации администратор забывает отключить Sessions deny или Scheduled jobs deny. Пользователи не могут подключиться к базе, регламентные задания не выполняются, обмены данными с другими системами останавливаются.

Симптомы: пользователи видят сообщение «Начало сеансов запрещено администратором». Фоновые задания висят в очереди со статусом «Отложено». Решение: откройте свойства информационной базы в консоли администрирования, снимите флажки блокировок, сохраните изменения.

Короткий Connection idle timeout

Установка таймаута менее 1800 секунд (30 минут) приводит к принудительному отключению пользователей во время выполнения длительных операций. Например, бухгалтер запустил формирование годового отчёта, отчёт генерируется 40 минут, но Connection idle timeout = 1800. Через 30 минут платформа разрывает соединение, пользователь получает ошибку, отчёт не сохраняется.

Симптомы: жалобы на «вылеты» из базы во время работы с отчётами или документами. Решение: увеличьте таймаут до 3600-7200 секунд в зависимости от типа операций в базе.

Не настроена авторизация администраторов

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

Симптомы: несанкционированные изменения настроек кластера, внезапные блокировки баз, остановки рабочих процессов без согласования. Решение: создайте минимум одного администратора кластера через консоль администрирования → «Администраторы». После создания авторизация включится автоматически.

Вопросы и ответы