← На главную

Рассмотрим весьма распространенную и неприятную ситуацию, с которой сталкиваются системные администраторы при масштабировании инфраструктуры 1С. Допустим, мы перевели высоконагруженную базу (например, 1С:Комплексная автоматизация) на кластер серверов, состоящий из нескольких физических машин (например, четырех серверов Windows: sql-001, sql-002, sql-003, sql-004). Неожиданно мы замечаем «сюрприз»: фоновые задания начинают запускаться параллельно сразу под всеми физическими именами серверов. При этом количество активных сеансов может многократно превышать число реальных пользователей — например, 319 сеансов на 65 живых пользователей.

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

Природа огромного количества сеансов в кластере

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

1. Синхронизация реестра кластера. Кластер постоянно обменивается данными между центральным сервером и рабочими узлами для поддержания актуального состояния.
2. Фоновая подготовка новых рабочих процессов. Когда старый рабочий процесс rphost потребляет слишком много оперативной памяти, кластер заранее, в фоновом режиме, создает новый процесс. С помощью системных заданий он загружает в него контекст баз данных и кэш. Это делается для того, чтобы переключение пользователей на новый процесс прошло без задержек и «тормозов».

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

Почему кластер «живет своей жизнью» и дублирует задания

На первый взгляд кажется, что кластер просто игнорирует настройки, которые мы задаем в консоли администрирования. Задания, которые должны выполняться в одном экземпляре, дублируются. Рассмотрим подробнее архитектуру отказоустойчивости 1С.

Главная цель менеджера кластера — сохранить работоспособность системы любой ценой. Если мы жестко назначаем выполнение сервиса заданий на один конкретный сервер, но этот сервер начинает испытывать проблемы с сетью, перегружен или перестает отвечать, главный менеджер принудительно поднимет этот сервис на других доступных узлах (sql-002, sql-003 и т.д.). Визуально это выглядит так, будто кластер игнорирует наши пожелания и сервисы начинают хаотично «гулять» по узлам.

Критичность синхронизации времени

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

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

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

Как правильно настроить требования назначения функциональности

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

1. Выберем один конкретный рабочий сервер, который мы выделяем под фоновые задачи (например, sql-001).
2. В свойствах этого сервера добавим требование для объекта СервисЗаданий со значением Назначать.
3. Критический шаг: на всех остальных рабочих серверах кластера (sql-002, sql-003, sql-004) мы должны явно прописать правило для объекта СервисЗаданий со значением НеНазначать.

Только при наличии запрещающих правил на остальных узлах менеджер кластера перестанет распределять эту специфическую нагрузку по всем доступным серверам.

Альтернативное решение: Разделение кластеров 1С

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

Оптимальным выходом (Best Practice) для высоконагруженных систем часто является отказ от единого кластера 1С в пользу независимых серверов:

1. Разделим серверы 1С на независимые службы (установим их как отдельные кластеры, не объединяя через центральный сервер 1С).
2. Жестко распределим информационные базы между этими серверами (например, бухгалтерские базы на одном сервере, управленческие — на другом).
3. При этом кластер СУБД (например, MS SQL Server) оставим общим и отказоустойчивым.

Такой подход полностью исключает проблему «блуждающих» сервисов и дублирования фоновых заданий, так как каждый сервер 1С обслуживает только свои базы и полностью контролирует свои планировщики.

Правильная работа с зависшими фоновыми заданиями

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

1. Откроем консоль серверов 1С и найдем конкретный рабочий процесс rphost, в котором зависло проблемное задание.
2. Зайдем в свойства этого процесса и снимем галочку Использовать.
3. Применим настройки. Кластер автоматически перестанет назначать новые соединения на этот процесс и бесшовно переведет всех «живых» пользователей на другие доступные процессы rphost.
4. В отключенном процессе останутся только зависшие фоновые задания.
5. После того как реальные пользователи покинут процесс, мы можем безопасно завершить его через диспетчер задач Windows, найдя его по номеру PID.

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