Почему в консоли серверов 1С каждый сеанс отображается двумя строками?

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

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

Архитектурная причина: репликация сеансовых данных

Основная причина появления парных записей кроется в настройках отказоустойчивости кластера серверов. Разберем механизм репликации подробнее:

1. Уровень отказоустойчивости кластера: Если в свойствах кластера параметр Уровень отказоустойчивости установлен в значение 1 или выше, платформа переходит в режим резервирования состояния работающих пользователей.
2. Служба сеансовых данных: Сервис сеансовых данных кластера (Session Data Service) начинает автоматически реплицировать контекст и состояние каждого активного сеанса с основного центрального сервера на резервный.
3. Отображение в утилитах администрирования: Консоль серверов опрашивает менеджеры кластера (rmngr) на всех доступных центральных серверах. В ряде версий платформы утилита выводит в единый список как основной рабочий экземпляр сеанса, так и его теневую реплику, ожидающую на резервном узле. Это штатное поведение отказоустойчивого контура, а не ошибка в базе данных.

Вопрос лицензирования при задвоении строк

Рассмотрим, как дублирование строк сеансов влияет на подсчет лицензий:

1. Клиентские лицензии: Теневая реплика сеанса на резервном сервере не расходует дополнительную клиентскую лицензию. Клиентская лицензия привязывается к уникальному клиентскому рабочему месту и сетевому подключению.
2. Серверные лицензии: Каждый рабочий сервер, входящий в состав отказоустойчивого кластера 1С, обязан иметь собственную активированную серверную лицензию.
3. Редакция КОРП: Расширенные механизмы отказоустойчивости кластера, гибкое управление памятью рабочих процессов и требования назначения функциональности регламентируются лицензиями уровня КОРП.

Особенности топологии: проблема двух центральных серверов

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

1. Отсутствие кворума: Для корректной работы отказоустойчивого механизма с уровнем N платформе требуется минимум 2N + 1 центральных серверов. Для уровня отказоустойчивости 1 необходимо не менее трех центральных серверов.
2. Нестабильность при сетевых задержках: В схеме из двух центральных серверов невозможно сформировать кворум менеджеров кластера. Это приводит к рассинхронизации сеансовых контекстов, появлению «зависших» блокировок и сложностям при монопольном обновлении конфигурации.

Способы решения и стабилизации работы кластера

Разберем по шагам регламентные действия и варианты конфигурации кластера.

Вариант 1. Очистка кэша сеансовых данных при зависании дублей

Если в консоли остаются неудаляемые фантомные сеансы, которые мигрируют между серверами и не дают выполнить монопольные операции, выполним полную очистку контекста:

1. Остановим службу 1C:Enterprise Server Agent на всех серверах, входящих в кластер.
2. Перейдем в каталог данных кластера на каждом сервере: srvinfo\reg_1541\snccntx\ (номер порта соответствует рабочему порту кластера).
3. Удалим все вложенные файлы из каталога snccntx. Базы данных и настройки кластера при этом не пострадают, но временная таблица активных сеансов будет очищена.
4. Запустим службы сервера 1С на всех узлах. Таблица сеансов сформируется заново при подключении пользователей.

Вариант 2. Настройка требований назначения функциональности

Чтобы исключить конфликты синхронизации между процессами rmngr, оптимизируем распределение сервисов:

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

Вариант 3. Перевод отказоустойчивости на уровень инфраструктуры

Если в распоряжении есть только два физических или виртуальных сервера 1С, надежнее отключить внутреннюю репликацию сеансов:

1. В свойствах кластера установим параметр Уровень отказоустойчивости равным 0.
2. Назначим центральным только один основной сервер, переведя второй в режим обычного рабочего сервера для распределения нагрузки рабочих процессов rphost.
3. Задачи высокой доступности и аварийного переключения в таком случае реализуем на уровне гипервизора виртуализации или средствами отказоустойчивого хранилища данных.