В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 специалисты часто сталкиваются с ситуацией, когда стандартный функционал (например, блокировка соединений или регламентные задания через БСП) внезапно перестает работать. Одной из самых коварных проблем является некорректное поведение COM-соединения при попытке получить данные об информационной базе в многосерверном кластере. Мы можем видеть, что соединение устанавливается, но объект ИнформационнаяБаза возвращается практически пустым: заполнено только имя, в то время как DBMS, DBServer и другие свойства остаются пустыми.
Рассмотрим детально, почему это происходит, проанализируем механизмы работы платформы и найдем надежное решение этой задачи.
Представим типовую конфигурацию: кластер из нескольких серверов (например, два центральных и один сервер лицензирования). При выполнении программного кода, который должен получить параметры базы через COM, мы вызываем метод GetInfoBases() объекта IWorkingProcessConnection. Несмотря на то, что мы предварительно вызываем AddAuthentication() с корректными учетными данными администратора ИБ, результат оказывается неудовлетворительным.
Важный технический нюанс: Согласно документации 1С, метод GetInfoBases() может выполняться без аутентификации. В этом случае он возвращает только свойства Name и Descr. Если же нам нужны данные о сервере СУБД или типе базы, аутентификация обязательна. Если после вызова AddAuthentication() данные все равно не подтягиваются, значит, рабочий процесс, к которому мы обратились, по какой-то причине "не узнает" или не хочет авторизовывать наши учетные данные для конкретной базы.
Выясним основную причину: в многосерверном кластере база может быть распределена по разным рабочим процессам (rphost) на разных физических серверах. Если мы подключаемся к первому попавшемуся рабочему процессу, он может знать о существовании базы (ее имя), но не являться ее текущим "обслуживающим" процессом. В этом случае он не сможет выдать полные метаданные, даже если пароль верный.
Проанализируем программную ошибку, которая часто встречается в старых версиях БСП и самописных модулях. Обычно разработчик берет первый доступный рабочий процесс и пытается работать через него. Для стабильной работы в кластере нам необходимо изменить логику: мы должны перебирать все рабочие процессы до тех пор, пока не найдем тот, который успешно вернет нам полные данные базы.
Рассмотрим правильный алгоритм реализации на языке 1С:
// Устанавливаем соединение с агентом сервера
Соединитель = Новый COMОбъект("V83.COMConnector");
СоединениеСАгентом = Соединитель.ConnectAgent(ИмяСервераКластера);
// Получаем список кластеров и выбираем нужный
Кластеры = СоединениеСАгентом.GetClusters();
Для Каждого ТекущийКластер Из Кластеры Цикл
Если ТекущийКластер.HostName = НужныйХост И ТекущийКластер.MainPort = НужныйПорт Тогда
СоединениеСАгентом.Authenticate(ТекущийКластер, "", "");
// Получаем ВСЕ рабочие процессы кластера
РабочиеПроцессы = СоединениеСАгентом.GetWorkingProcesses(ТекущийКластер);
Для Каждого Процесс Из РабочиеПроцессы Цикл
// Пропускаем неактивные процессы
Если Процесс.Running <> 1 Тогда Продолжить; КонецЕсли;
Попытка
// Подключаемся к конкретному рабочему процессу
СтрокаСоединенияПроцесса = Процесс.HostName + ":" + Формат(Процесс.MainPort, "ЧГ=0");
СоединениеСПроцессом = Соединитель.ConnectWorkingProcess(СтрокаСоединенияПроцесса);
// Добавляем аутентификацию администратора ИБ
СоединениеСПроцессом.AddAuthentication(ИмяАдминаИБ, ПарольАдминаИБ);
// Ищем нашу базу среди баз данного процесса
СписокИБ = СоединениеСПроцессом.GetInfoBases();
Для Каждого ТекИБ Из СписокИБ Цикл
Если НРег(ТекИБ.Name) = НРег(ИмяИБ) Тогда
// ПРОВЕРКА: заполнено ли ключевое поле?
Если ЗначениеЗаполнено(ТекИБ.DBMS) Тогда
// УРА! Мы нашли процесс, который "знает" параметры базы
РезультатПараметры = ТекИБ;
Прервать;
КонецЕсли;
КонецЕсли;
КонецЦикла;
Исключение
// Если процесс недоступен или ошибка прав, пробуем следующий
Продолжить;
КонецПопытки;
Если РезультатПараметры <> Неопределено Тогда Прервать; КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
Этот подход гарантирует, что даже если база "спит" или закреплена за определенным сервером в рамках требований назначений, мы в конечном итоге достучимся до нужного контекста.
Разберем ситуацию, когда программный код верен, но система внезапно "сломалась" после обновлений ОС. Это часто связано с ужесточением требований безопасности DCOM (уязвимость CVE-2021-26414). Microsoft внедрила обязательное повышение уровня аутентификации для RPC-соединений.
Если сервер 1С и клиент (откуда запускается COM) находятся на разных машинах или работают под разными учетными записями, механизм AddAuthentication внутри 1С может блокироваться на уровне операционной системы. Проанализируем шаги для исправления:
1C:Enterprise 8.3 Server Agent, имеет права "Log on as a batch job" и входит в группу "Distributed COM Users".dcomcnfg проверьте свойства "My Computer". На вкладке "Default Properties" уровень "Default Authentication Level" должен быть установлен в "Connect", а "Default Impersonation Level" в "Identify".RequireIntegrityActivationAuthenticationLevel (хотя это не рекомендуется с точки зрения безопасности, это помогает диагностировать проблему).Посмотрим на проблему с точки зрения иерархии прав в 1С. Существует три уровня администраторов:
AddAuthentication.Если в консоли администрирования 1С были созданы администраторы кластера, то анонимное подключение через ConnectAgent может возвращать ограниченный список данных. В таком случае перед вызовом GetWorkingProcesses необходимо обязательно вызвать метод Authenticate для объекта соединения с агентом, передав логин и пароль администратора кластера (не путать с паролем самой базы!).
Выясним причину специфических сбоев на релизах 8.3.17. В этих версиях были замечены ошибки кэширования COM-объектов. Если в информационной базе включен режим "Спящие сеансы" или настроено агрессивное завершение выключенных процессов, COM-соединение может "цепляться" за дескриптор процесса, который уже помечен системой как неактивный.
Рекомендация: При работе с COM в версиях 8.3.17.1496/1549 старайтесь всегда явно освобождать память, устанавливая переменные COM-объектов в значение Неопределено сразу после использования. Также стоит проверить длину пароля администратора ИБ — были зафиксированы случаи, когда спецсимволы в пароле (например, амперсанд или кавычки) приводили к ошибке разбора строки внутри COM-слоя платформы, хотя при обычном входе в 1С:Предприятие проблем не возникало.
Подводя итог, можно сказать, что стабильность работы с кластером через COM напрямую зависит от того, насколько гибко реализован поиск рабочего процесса. Переход от стратегии "взять первый процесс" к стратегии "перебрать все до успеха" — это ключевой шаг к созданию отказоустойчивой системы администрирования 1С.