При развитии информационных систем на базе 1С многие компании сталкиваются с пределом производительности одного физического или виртуального сервера. Когда вертикальное масштабирование (увеличение ресурсов процессора и памяти на одной машине) становится невозможным или экономически нецелесообразным, мы переходим к горизонтальному масштабированию — добавлению новых рабочих серверов в существующий кластер 1С. В данной статье мы подробно разберем, как правильно организовать взаимодействие между узлами кластера и почему вопрос сетевых доступов является критическим для стабильной работы системы.
Разберем базовый принцип работы кластера. В многосерверной конфигурации у нас выделяется Центральный сервер (на котором запущен менеджер кластера rmngr) и один или несколько Рабочих серверов. Важно понимать, что менеджер кластера динамически распределяет нагрузку. Это означает, что любое клиентское соединение или фоновое задание может быть запущено на любом из серверов, входящих в состав кластера, если не настроены жесткие ограничения.
Проанализируем ситуацию: если на сервере выполняется код, который обращается к внешнему миру (например, чтение почты, выгрузка файлов в сетевую папку или запрос к REST API), этот код будет исполняться в контексте рабочего процесса rphost того сервера, которому кластер поручил данную задачу. Из этого следует фундаментальный вывод: все серверы в составе кластера должны иметь идентичные права доступа и сетевые разрешения. Если Сервер №1 имеет доступ к брокеру сообщений, а Сервер №2 — нет, то при попытке выполнить регламентное задание на втором сервере система выдаст ошибку доступа.
Рассмотрим по шагам, что именно необходимо настроить на новом рабочем сервере перед его включением в рабочий контур:
ragent на всех серверах кластера должны запускаться от имени одной и той же доменной учетной записи. Это критически важно для работы с сетевыми ресурсами по UNC-путям (например, \\Server-FS\1C_Exchange). Если использовать локальные учетные записи, доступ к общим папкам будет невозможен.Если у вас имеется лицензия уровня КОРП, мы можем подойти к распределению нагрузки более гибко. ТНФ позволяют нам четко определить, какие задачи на каких серверах должны выполняться. Это помогает избежать необходимости открывать все доступы всем серверам, если мы можем гарантировать локализацию определенных задач.
Выясним, как можно ограничить выполнение тяжелых заданий на конкретном сервере. В консоли администрирования кластеров мы можем создать правила. Например, мы хотим, чтобы все фоновые задания выполнялись только на втором сервере, чтобы не мешать интерактивной работе пользователей на первом:
В этом случае именно на Сервере №2 нам нужно будет настроить максимальные доступы к внешним ресурсам, тогда как Сервер №1 сможет работать в более «закрытом» режиме. Однако помните, что такая схема лишает систему отказоустойчивости: если Сервер №2 выйдет из строя, фоновые задания не смогут автоматически переехать на Сервер №1, так как им запрещено там исполняться правилами ТНФ.
Проанализируем ситуацию с нехваткой памяти, упомянутую в обсуждении. Часто горизонтальное масштабирование выбирается как способ обойти лимиты виртуализации (например, когда нельзя выдать одной виртуалке более 64 Гб памяти). В кластере 1С мы можем эффективно управлять потреблением ресурсов через настройки рабочего сервера:
Безопасный расход памяти за один вызов — этот параметр позволяет принудительно прерывать выполнение кода, если один серверный вызов начинает потреблять аномально много оперативной памяти. Это защищает сервер от падения всего процесса rphost. Рассмотрим пример настройки:
Параметр: "Безопасный расход памяти за один вызов"
Значение: 4 000 000 (около 4 Гб)
Действие: Прерывать сеанс при превышении
При использовании двух серверов по 64 Гб мы фактически получаем 128 Гб на кластер. Чтобы распределение было равномерным, убедитесь, что параметр Коэффициент производительности на обоих серверах установлен одинаковым (по умолчанию 10). Если один сервер мощнее другого, коэффициент можно подкорректировать.
Разберем еще один неочевидный момент. По умолчанию журнал регистрации хранится в файлах на каждом сервере локально. В многосерверном кластере это приводит к тому, что история действий пользователей «размазывается» по двум машинам. Чтобы проанализировать события, вам придется собирать файлы с обоих серверов.
Рекомендация: Рассмотрите возможность перевода журнала регистрации в формат SQLite (новое решение в 1С) или использования внешних систем сбора логов. Также обратите внимание на работу с временными файлами. Если ваш код пишет файл в локальную папку C:\Temp, а другой сервер пытается его прочитать — это приведет к ошибке. Всегда используйте общие сетевые хранилища для передачи файлов между вызовами, которые могут произойти на разных узлах кластера.
Подводя итог, можно сказать: добавление второго сервера в кластер 1С — это эффективный шаг для масштабирования, но он требует тщательной подготовки инфраструктуры. Синхронизация прав доступа, сетевых разрешений и настроек безопасности — это обязательное условие. Использование лицензий КОРП дает дополнительные инструменты управления (ТНФ), но даже с ними системный администратор должен стремиться к идентичности конфигураций всех узлов кластера для обеспечения максимальной надежности и предсказуемости системы.