← На главную

При работе в многосерверном кластере 1С:Предприятия 8.3 администраторы нередко сталкиваются с ситуацией, когда у пользователей внезапно прерывается работа и появляется сообщение об ошибке: «Не найдено ни одного сервера с размещенным сервисом ServiceName = ClusterConfigService». Ошибка может возникать как в моменты интенсивных операций (чтение файлов, проведение документов, запуск фоновых заданий), так и во время простоя пользовательского сеанса.

Сервис ClusterConfigService отвечает за хранение и предоставление конфигурации самого кластера серверов 1С. Если рабочий процесс или клиентское приложение не может вовремя связаться с менеджером кластера (rmngr), обслуживающим данный сервис, сеанс завершается аварийно. Разберем по шагам ключевые причины возникновения этой неполадки и подробные способы её устранения.

Причина 1. Единая точка отказа и некорректные требования назначения функциональности

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

Для устранения единой точки отказа выполним следующие действия:

1. Откроем консоль Администрирование серверов 1С Предприятия.
2. Перейдем в свойства нашего кластера и проверим параметр Уровень отказоустойчивости (по умолчанию он равен 0). Установим значение 1 или более в зависимости от количества доступных серверов.
3. Откроем ветку Требования назначения функциональности для каждого рабочего сервера.
4. Убедимся, что для сервиса ClusterConfigService настроено резервирование: основной сервер должен иметь приоритет размещения, а резервный сервер — возможность запускать данный сервис при недоступности основного узла.
5. Применим требования назначения функциональности через контекстное меню кластера (пункт Применить требования назначения функциональности).

Причина 2. Сетевые блокировки, брандмауэр и протокол IPv6

В многосерверной инфраструктуре критически важно обеспечить беспрепятственное взаимодействие между всеми узлами. Задержки при маршрутизации пакетов или попытки обращения по протоколу IPv6 часто приводят к таймаутам при обращении к сервисам кластера.

Выполним сетевую диагностику и оптимизацию:

1. Отключение IPv6: В свойствах сетевых адаптеров на всех серверах кластера снимем отметку с компонента IP версии 6 (TCP/IPv6). Это исключит попытки резолвинга локальных адресов в IPv6 и снизит задержки при межсерверных вызовах.
2. Настройка сетевого экрана (Брандмауэра): Добавим полные исключения для исполняемых файлов платформы 1С (ragent.exe, rmngr.exe, rphost.exe) либо откроем диапазоны портов, используемые кластером (по умолчанию 1540, 1541, 1560–1591).
3. Антивирусная защита: Добавим каталоги данных кластера (каталог srvinfo) и процессы 1С в список исключений сканирования в реальном времени, чтобы исключить блокировку файлов реестра и временных сессионных контекстов.
4. Разрешение имен через hosts: Пропишем соответствие IP-адресов и сетевых имен всех участников кластера в системных файлах hosts на каждом рабочем сервере. Это исключит зависимость от нестабильной работы локального DNS-сервера.

Причина 3. Исчерпание пула динамических портов

Если в системе активно выполняются фоновые задания, работают веб-сервисы и COM-соединения, стандартного диапазона портов (1560:1591) может не хватать для создания новых соединений между процессами кластера. В таком случае агент не может выделить свободный порт для связи с ClusterConfigService.

Рассмотрим, как расширить диапазон рабочих портов:

1. Откроем редактор реестра Windows (regedit) или свойства службы 1C:Enterprise 8.3 Server Agent.
2. Найдем параметр запуска службы (ImagePath).
3. Изменим ключ -range, увеличив диапазон доступных портов, например: -range 1560:1691.
4. Выполним аналогичную настройку на всех серверах, входящих в состав кластера, после чего перезапустим службы агента.

Причина 4. Повреждение кэша сессий и реестра кластера

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

Пошаговый регламент очистки кэша кластера:

1. Остановим службу 1C:Enterprise Server Agent на центральном и всех рабочих серверах кластера.
2. Перейдем в каталог данных сервера 1С (по умолчанию C:\Program Files\1cv8\srvinfo или C:\Program Files (x86)\1cv8\srvinfo).
3. Внутри каталога кластера (например, reg_1541) найдем и удалим временные папки контекста сессий вида snccntx*. Файлы реестра информационных баз 1cv8reg.lst и 1cv8wsrv.lst при этом удалять не нужно.
4. Очистим кэш профиля пользователя операционной системы, от имени которого запущена служба 1С (каталоги AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8).
5. Запустим службу агента сервера на всех узлах кластера и проверим стабильность подключения.

Причина 5. Ошибки стабильности релиза платформы

В некоторых сборках платформы 1С:Предприятие 8.3 (включая ветку 8.3.9) наблюдались внутренние ошибки менеджера кластера при интенсивной передаче сериализованных данных между рабочими процессами (например, при вызове объекта ЧтениеФайла в фоновых заданиях). Если вышеперечисленные сетевые и инфраструктурные настройки выполнены, но ошибка периодически повторяется, рекомендуется запланировать обновление платформы 1С:Предприятие на актуальный стабильный релиз.