← На главную

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

Проанализируем архитектурные причины такого поведения платформы 1С и разберем по шагам надежные способы устранения неполадки.

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

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

1. Кластер 1С принимает запрос на инициализацию сеанса и передает обслуживание одному из рабочих серверов в соответствии с текущей нагрузкой.
2. Для формирования списка учетных записей процесс rphost выполняет прямое обращение к таблицам базы данных (в частности, к таблице пользователей v8users и служебным параметрам базы) на сервере СУБД (например, MS SQL Server).
3. Если на том рабочем сервере, на который был направлен запрос, отсутствует необходимый драйвер СУБД (SQL Server Native Client или OLE DB Driver), рабочий процесс 1С не может установить соединение с базой данных для считывания актуального списка пользователей.
4. В аварийной ситуации платформа пытается получить данные из локального пользовательского кэша (файл def.usr в каталоге профиля %AppData%\Roaming\1C\1Cv8\...). В результате в диалоговом окне появляется только последний сохраненный в кэше пользователь, а полный список учетных записей остается недоступен.

Именно из-за того, что запросы распределяются балансировщиком случайным образом между сервером с установленным драйвером и серверами без него, ошибка проявляется нестабильно.

Способ 1. Установка драйверов СУБД на все узлы кластера 1С

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

1. Определим разрядность службы сервера 1С на рабочих серверах. Если служба функционирует в 64-битном режиме (процессы ragent, rmngr, rphost имеют разрядность x64), компоненты доступа к базе данных должны быть строго 64-разрядными.
2. Установим требуемый драйвер на каждый рабочий сервер кластера, а не только на тот сервер, где развернут сам MS SQL Server. Исторически платформа использовала SQL Server Native Client (sqlncli), однако в современных версиях платформы 1С:Предприятие 8.3 рекомендуется устанавливать актуальный Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL).
3. Проверим корректность установки компонентов и совпадение версий драйверов на всех серверах группы.

Способ 2. Разделение ролей через требования назначения функциональности

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

1. Откроем ветку «Требования назначения функциональности» для каждого рабочего сервера.
2. Для серверов, на которых драйвер СУБД установлен и настроен, добавим полное обслуживание сервисов работы с данными: для объекта требования Сервис баз данных и Сервис сеансовых данных установим тип требования «Назначать».
3. Для узлов кластера, где драйвер отсутствует (например, выделенные серверы для фоновых заданий без прямого доступа к СУБД), для объекта Сервис баз данных установим тип требования «Не назначать».
4. Выполним полное применение требований назначения функциональности для кластера через контекстное меню.

Способ 3. Очистка кэша сеансовых данных и перезапуск служб

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

1. Остановим службу 1C:Enterprise 8.3 Server Agent на всех узлах кластера.
2. В каталоге данных кластера (по умолчанию C:\Program Files\1cv8\srvinfo\...) найдем и удалим временные папки сеансов snccntx*.
3. Запустим службу агента сервера 1С сначала на центральном сервере, а затем последовательно на всех рабочих узлах.

Рекомендации по доменной авторизации и безопасности

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

1. Настройка доменной аутентификации (SSO): Использование аутентификации операционной системы (Active Directory / Kerberos) или протоколов OpenID позволяет пользователям входить в базу автоматически без необходимости выбирать учетную запись из общего списка.
2. Политика скрытия списка пользователей: В типовых конфигурациях на базе Библиотеки стандартных подсистем (БСП) в целях информационной безопасности список пользователей может быть скрыт намеренно. В этом случае имя учетной записи вводится пользователем вручную, что исключает возможность перебора учетных записей злоумышленниками.