Что писать в кластер серверов 1С: настройка параметров

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

Кластер серверов 1С — это группа процессов на одном или нескольких компьютерах, обеспечивающая выполнение запросов клиентов к информационным базам. Основные настройки задаются в оснастке «Администрирование серверов 1С Предприятия» (файл 1CV8 Servers.msc) через контекстное меню кластера или окно его свойств.

Базовые поля кластера: имя, компьютер и порт

Первые три поля, которые запрашивает консоль при создании кластера, — самые простые, но именно здесь чаще всего допускают ошибки. Поле «Кластер» — это произвольное отображаемое имя. Пишите осмысленное название, например «Основной кластер» или «Кластер ERP», чтобы при наличии нескольких кластеров не путать их в списке.

Поле «Компьютер» — это имя или IP-адрес центрального сервера кластера, на котором работает агент сервера. Если кластер локальный, допустимо указать localhost, но для отказоустойчивых конфигураций лучше писать реальное DNS-имя сервера: при переносе роли центрального сервера на другую машину настройки останутся корректными.

Поле «IP-порт» — порт главного менеджера кластера, по умолчанию 1541. Менять его имеет смысл только если на одном сервере работает несколько кластеров или порт занят другим приложением. Помните, что агент сервера слушает порт 1540, менеджер кластера — 1541, а диапазон рабочих процессов по умолчанию 1560–1591: все эти порты должны быть открыты в брандмауэрах между серверами и клиентами.

Уровень отказоустойчивости и резервирование

Поле «Уровень отказоустойчивости» определяет, сколько рабочих серверов кластера может выйти из строя без прерывания обслуживания. Значение 0 означает, что резервирование не используется — это нормально для кластера из одного сервера. Если серверов несколько, обычно ставят 1: кластер переживёт отказ одной машины, сеансы переназначатся на оставшиеся.

Не стоит бездумно ставить высокие значения. Каждый уровень резервирования требует дополнительных ресурсов: система заранее резервирует мощности под возможный отказ. Значение должно быть меньше количества рабочих серверов в кластере, иначе резервирование лишается смысла.

Дополнительно доступна опция «Режим распределения нагрузки» с вариантами «Приоритет по производительности» и «Приоритет по памяти». Первый режим распределяет соединения так, чтобы выровнять загрузку серверов по производительности, второй — минимизирует потребление памяти, концентрируя сеансы на меньшем числе процессов. Для большинства внедрений подходит приоритет по производительности.

Настройка рабочих процессов и ограничения памяти

Один из самых критичных блоков — параметры, управляющие рабочими процессами (rphost). Именно здесь решается, сколько процессов будет запущено и когда они будут перезапускаться. Ключевые поля:

• Количество ИБ на процесс — сколько информационных баз обслуживает один рабочий процесс. Значение 8–10 снижает расход памяти, но при падении процесса пострадают пользователи всех этих баз. Для крупных баз часто ставят 1.
• Количество соединений на процесс — ограничивает число клиентских соединений в одном rphost. Типичные значения 50–128 в зависимости от объёма памяти сервера.
• Допустимый объем памяти рабочих процессов — суммарный лимит памяти для всех rphost на сервере. Задавайте его с запасом под ОС и агента, иначе сервер уйдёт в своп.
• Безопасный расход памяти за один вызов — защита от «взрывающихся» запросов: если один вызов превысит порог, сеанс будет аварийно завершён.

Также полезны параметры «Интервал перезапуска» и «Выключенные процессы останавливать через». Периодический перезапуск рабочих процессов (например, раз в сутки) помогает освобождать накопленную память и снижает влияние утечек. Перезапуск выполняется плавно: процесс сначала перестаёт принимать новые соединения, а старые завершаются штатно.

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

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

Каждое требование содержит: объект требования (например, «Сервис сеансовых данных», «Сервис фоновых заданий», «Клиентское соединение с ИБ» или «Любой объект требования»), тип требования («Назначать», «Не назначать», «Авто») и дополнительные параметры, включая привязку к конкретной информационной базе.

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

Защищённое соединение и профили безопасности

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

Для информационных баз внутри кластера дополнительно настраиваются профили безопасности: они ограничивают доступ к файловой системе сервера, COM-объектам, внешним компонентам и запуску внешних приложений из кода конфигурации. Это важный элемент защиты, особенно если в кластере работают базы с недоверенными расширениями.

Проверка результата после настройки

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

Контрольные точки

Как проверить результат

Список рабочих процессов в консоли

Норма

Число rphost соответствует заданным лимитам, процессы распределены по серверам

Тревожный признак

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

Подключение клиента к базе

Норма

База открывается, сеанс виден в консоли кластера

Тревожный признак

Ошибка соединения или «нет доступных рабочих процессов»

Загрузка памяти сервера

Норма

Суммарное потребление rphost в пределах заданного лимита, есть резерв под ОС

Тревожный признак

Память исчерпана, активно используется файл подкачки

Фоновые задания

Норма

Выполняются на выделенном сервере согласно ТНФ

Тревожный признак

Задания не выполняются или работают на сервере интерактивных сеансов

Для диагностики используйте технологический журнал: включите сбор событий подключений и ошибок на время проверки. Он покажет, какой процесс обслужил соединение и не было ли отказов из-за требований назначения функциональности.

1. 1
   Откройте консоль «Администрирование серверов 1С Предприятия» и разверните узел нужного центрального сервера
2. 2
   В контекстном меню узла «Кластеры» выберите «Создать — Кластер»
3. 3
   Укажите имя кластера, имя компьютера центрального сервера и порт (по умолчанию 1541)
4. 4
   Задайте уровень отказоустойчивости и режим распределения нагрузки
5. 5
   Настройте ограничения памяти и количество соединений на процесс под ресурсы сервера
6. 6
   При необходимости добавьте требования назначения функциональности, завершив список правилом «Авто»
7. 7
   Проверьте подключение клиента и состояние рабочих процессов в консоли

Частые вопросы по настройке кластера

Можно ли менять параметры кластера без перезапуска службы?

Большинство параметров (лимиты памяти, количество соединений, требования назначения функциональности) применяются на лету. Смена порта кластера или имени центрального сервера может потребовать переподключения клиентов и обновления строк подключения, поэтому такие изменения планируйте на время минимальной нагрузки.

Сколько рабочих процессов должно быть в кластере?

Количество определяется косвенно — через лимиты «соединений на процесс» и «ИБ на процесс». Ориентируйтесь на доступную память: каждый rphost резервирует заметный объём ОЗУ, поэтому лучше меньше процессов с большим числом соединений, чем десятки мелких процессов, съедающих память накладными расходами.

Что делать, если после настройки ТНФ пользователи не могут подключиться?

Проверьте, что в списке требований есть итоговое правило с типом «Авто» для объекта «Любой объект требования». Без него объекты, не попавшие под явные правила, остаются неназначенными, и кластер отказывает в обслуживании. Также проверьте порядок правил — они применяются сверху вниз.

Нужен ли уровень отказоустойчивости для кластера из одного сервера?

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

Как выделить отдельный сервер под фоновые задания?

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