← На главную

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

Причина проблемы: неполная идентичность программного окружения рабочих серверов

Проанализируем архитектуру многосерверного кластера 1С. В отказоустойчивом или распределенном кластере рабочие процессы rphost запускаются на всех входящих в него серверах. Балансировщик кластера автоматически распределяет клиентские подключения и выполнение сервисов между доступными нодами. Каждый процесс rphost должен иметь возможность напрямую обращаться к серверу СУБД (в данном случае — MS SQL Server).

Если на одном из серверов кластера отсутствует драйвер доступа к СУБД (например, SQL Server Native Client или Microsoft OLE DB Driver for SQL Server) либо установлена другая версия/разрядность компонента, возникает следующая цепочка сбоев:

1. Когда клиентское подключение направляется на узел с установленным драйвером, авторизация и работа с базой данных проходят штатно.
2. Когда балансировщик перенаправляет сеанс на сервер, где клиент СУБД не установлен, рабочий процесс rphost не может инициировать соединение с MS SQL Server.
3. Аварийный разрыв или сбой в пуле соединений приводит к нарушению контекста сеанса, сбросу доменной аутентификации (SSO/Kerberos/NTLM) и возврату клиента к окну диалога аутентификации с некорректно заполненными кэшированными данными.

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

Пошаговое решение проблемы

Разберем по шагам, как привести конфигурацию серверов к стабильному состоянию и устранить плавающие ошибки авторизации.

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

   Загрузим и установим дистрибутив SQL Server Native Client (или актуальный Microsoft OLE DB Driver) строго одинаковой версии и разрядности на каждый рабочий сервер, входящий в состав кластера 1С. Разрядность драйвера должна соответствовать разрядности службы 1С (x86 или x64).

2. Проверка сетевой связности и портов:

   Убедимся, что между всеми нодами кластера и сервером СУБД открыты необходимые сетевые порты: основной порт кластера (по умолчанию 1541), порт главного менеджера (1540), диапазон рабочих процессов (1560:1591) и порт экземпляра MS SQL Server (по умолчанию 1433).

3. Синхронизация системного времени:

   Проверим службу времени NTP на всех машинах кластера и контроллерах домена. Рассинхронизация времени более чем на несколько секунд нарушает работу доменной аутентификации и репликацию реестра кластера.

4. Очистка временных файлов и кэша:

   После установки недостающих компонентов остановим службы 1С на всех серверах кластера, очистим локальный кэш сеансов и запустим службы заново.

Как работает признак «Центральный сервер» на нескольких машинах

Рассмотрим подробнее распространенное заблуждение о том, что центральный сервер в кластере может быть только один. В платформе 1С:Предприятие 8.3 установка признака «Центральный сервер» на двух и более машинах является штатным механизмом обеспечения отказоустойчивости кластера.

Выясним, как взаимодействуют между собой несколько центральных серверов:

1. Резервирование сервисов кластера: один из центральных серверов выступает в роли основного (активного), а на втором в фоновом режиме поддерживается актуальная реплика реестра кластера и состояния сеансов.
2. Отсутствие конфликтов нумерации: менеджеры кластера rmngr не дублируют выдачу номеров и блокировок бесконтрольно — синхронизация данных происходит централизованно через механизм кворума и мастер-реплики.
3. Строка подключения на клиентах: для автоматического переключения пользователей в случае отказа одного из серверов в строке соединения на клиентах рекомендуется указывать имена центральных серверов через запятую:

   Srvr="serv1cbp,serv2cbp";Ref="buh_base";

   В такой конфигурации, если serv1cbp станет недоступен, клиентское приложение автоматически подключится через serv2cbp без потери рабочего сеанса.

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