Какие параметры кластера 1С заполнить сразу, а какие оставить по умолчанию

При настройке кластера серверов 1С обязательно указывают четыре вещи: имя и порт центрального сервера (по умолчанию порт агента 1540, менеджера кластера 1541, рабочих процессов — диапазон 1560:1591), администратора кластера, параметры подключения к СУБД для каждой информационной базы и способ выдачи лицензий. Остальное — память процессов, перезапуск, распределение нагрузки — можно включать позже, когда появится статистика по нагрузке.

Материал общий для платформы 1С:Предприятие 8.3 и не зависит от конфигурации: БП, ЗУП, УТ или ERP настраиваются в кластере одинаково. Все параметры задаются в оснастке «Администрирование серверов 1С Предприятия» или утилитой rac.

С чего начинается кластер: сервер, порты и администраторы

После установки сервера 1С служба агента (ragent) сама создаёт кластер по умолчанию с именем «Локальный кластер» и портом 1541. Ваша задача — проверить, что он настроен под вашу сеть, и закрыть его паролем.

Цепочка подключения клиента выглядит так:

1. Клиент обращается к агенту сервера на порт 1540.
2. Агент передаёт его менеджеру кластера на порт 1541.
3. Менеджер выделяет рабочий процесс из диапазона портов, заданного в свойствах рабочего сервера.

Отсюда первое правило: в брандмауэре между клиентами и сервером открывают все три позиции — 1540, 1541 и весь диапазон рабочих процессов. Открыли только 1540 — клиент увидит сервер, но к базе не подключится.

Что заполнить в свойствах кластера:

• 🖥️ Компьютер — сетевое имя сервера, которое резолвится у всех клиентов. Не localhost и не IP, если IP может смениться.
• 🔌 IP-порт — 1541, менять только если на одной машине работает несколько кластеров (тогда второй агент ставят, например, на 2540, а кластер на 2541).
• 🏷️ Имя — произвольное, для удобства в консоли.
• 🔒 Защищённое соединение — «Выключено» для обычной локальной сети; шифрование включают, если трафик идёт через недоверенные сегменты.

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

Служба по умолчанию работает от пользователя USR1CV8. Ему нужны права на каталог srvinfo (там хранятся реестр кластера, журналы регистрации и кэши) и на временные каталоги. Если служба запущена от доменной учётной записи, проверьте, что у неё есть право «Вход в качестве службы».

Рабочие процессы: сколько их нужно и где задаётся

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

Пример расчёта. Сервер с 16 ядрами, две базы по 60 пользователей. Ставим «Количество ИБ на процесс» = 1, соединений на процесс — по умолчанию. Кластер поднимет минимум по процессу на базу и добавит новые по мере роста соединений. Ядра делят процессы между собой, так что 16 ядер не простаивают.

Для серверов с несколькими машинами в кластере пригодятся требования назначения функциональности в свойствах рабочего сервера. Через них, например, отправляют фоновые и регламентные задания на отдельную машину, чтобы они не тормозили пользователей. Это настройка для продвинутых сценариев; на одном сервере её не трогают.

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

Подключение информационной базы к СУБД

Базу в кластере создают либо из окна запуска 1С (кнопка «Добавить» → «Создание новой информационной базы» → «На сервере 1С:Предприятия»), либо в консоли (ветка «Информационные базы» → «Создать»). Поля одинаковые:

• Кластер серверов 1С:Предприятия — имя центрального сервера. Если кластер не на стандартном порту, указывают server:2541.
• Имя информационной базы в кластере — лучше латиницей без пробелов, это имя видят пользователи в строке подключения.
• Защищённое соединение — как в свойствах кластера.
• Тип СУБД, Сервер баз данных, Имя базы данных, Пользователь и Пароль сервера БД.
• Смещение дат — только для MS SQL Server.
• Создать базу данных в случае её отсутствия — если базу в СУБД заранее не создавали.
• Установить блокировку регламентных заданий — ставят, когда загружают копию рабочей базы, чтобы тестовая копия не начала обмены и рассылки.

Как заполнять сервер БД для разных СУБД:

Пользователь СУБД — отдельная учётная запись, а не sa или postgres. Для создания базы ему нужны права на создание БД; для работы — права владельца своей базы.

Сеансы и лицензии: что указать, чтобы пользователи входили

Здесь две разные лицензии, и их часто путают.

Лицензия на сервер 1С нужна самому кластеру. Без неё клиент-серверная база не запустится. Она бывает разных уровней: часть расширенных механизмов кластера — например, счётчики и ограничения потребления ресурсов — работает только с серверной лицензией уровня КОРП.

Клиентские лицензии нужны пользователям. Способов получения два:

• 💻 на компьютере пользователя — программная лицензия активирована локально или стоит аппаратный ключ;
• 🗄️ с сервера — лицензии активированы на сервере 1С, и сеанс получает их оттуда.

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

Проверить, откуда сеанс взял лицензию, можно в консоли в списке сеансов (колонка с типом лицензии) или командой:

rac session list --cluster=<uuid кластера> --licenses

UUID кластера даёт rac cluster list. Утилите rac нужен запущенный сервис администрирования ras.

Ещё два параметра базы касаются сеансов:

• 🚫 Блокировка начала сеансов — с сообщением для пользователей и кодом разрешения. Включают перед обновлением конфигурации; администратор входит с ключом /UC<код>.
• ⏸️ Блокировка выполнения регламентных заданий — для копий баз и на время обслуживания.

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

Эти параметры можно не трогать первые недели. Включайте их, когда в консоли видно, что процессы разрастаются по памяти или сервер «подвисает».

В свойствах кластера:

• 🔄 Интервал перезапуска — плановый перезапуск рабочих процессов, в секундах. Значение 86400 — раз в сутки. Кластер поднимает новый процесс и переводит на него соединения, поэтому при штатной работе пользователи перезапуска обычно не замечают.
• 📈 Допустимый объём памяти и Интервал превышения допустимого объёма памяти — если процесс держит больше заданного дольше интервала, кластер выводит его из работы и поднимает новый.
• ❗ Допустимое отклонение количества ошибок сервера и флажок Принудительно завершать проблемные процессы — защищают от процесса, который сыпет ошибками.
• ⚖️ Режим распределения нагрузки — «Приоритет по производительности» или «Приоритет по памяти». Для серверов, где не хватает ОЗУ, выбирают второе.
• 🛡️ Уровень отказоустойчивости — сколько рабочих серверов может одновременно выйти из строя без остановки кластера. Имеет смысл только при двух и более серверах.

В свойствах рабочего сервера:

• Критический объём памяти процессов — потолок на все рабочие процессы сервера. При его достижении сервер начинает обрывать сеансы, которые запрашивают память, — чтобы не упасть целиком.
• Временно допустимый объём памяти процессов и интервал его превышения — мягкий порог перед критическим.

Пример. Сервер с 64 ГБ ОЗУ, на нём же MS SQL, которому выделили 32 ГБ. На 1С остаётся около 28 ГБ с запасом под ОС. Разумно поставить критический объём около 26 ГБ, временно допустимый — около 22 ГБ, а допустимый объём одного процесса — в зависимости от числа процессов, например 8 ГБ.

💡 Если СУБД стоит на той же машине, ограничьте её память в настройках самой СУБД. MS SQL без лимита забирает всю свободную ОЗУ, и рабочим процессам 1С её не хватает.

Ошибки, из-за которых кластер работает плохо

Ниже — то, что чаще всего всплывает уже в работе, когда базовые параметры вроде бы заполнены.

Отдельно про часовой пояс и дату. Если на сервере 1С неверное время, в документах и журнале регистрации появляется не та дата: время для сеансов берётся с сервера. Синхронизируйте сервер с контроллером домена или NTP.

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

Регулярная проверка и обслуживание кластера

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

Что помогает при разборе проблем:

1. Технологический журнал. Включается файлом logcfg.xml в каталоге conf платформы. Пишет события сервера: исключения, долгие запросы, взаимные блокировки. Журнал быстро занимает гигабайты, поэтому задавайте срок хранения и включайте только нужные события.
2. Журнал регистрации. Для крупных баз переведите его в формат SQLite (файл .lgd) или настройте разделение по периодам — так он не разрастается в один огромный файл.
3. Утилита rac. Позволяет снимать список сеансов и процессов скриптом и складывать в мониторинг. Полный список команд — в rac help.

rem список кластеров и их UUID
rac cluster list
rem сеансы с информацией о лицензиях
rac session list --cluster=<uuid> --licenses

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

Частые вопросы