Второй рабочий сервер для 1С 8.3: от установки службы до балансировки нагрузки

Чтобы добавить сервер в кластер 1С, на новую машину ставят серверную часть платформы той же версии до последней цифры, запускают агента как службу, а затем в консоли центрального сервера открывают Кластеры → <ваш кластер> → Рабочие серверы и через контекстное меню создают рабочий сервер с именем новой машины и портом 1540. Дальше кластер сам начинает запускать на новом узле рабочие процессы rphost и раздавать им сеансы.

Есть два пути. Через оснастку «Администрирование серверов 1С Предприятия» удобно, когда серверов два-три и администратор работает в Windows. Через утилиту rac — когда узлы на Linux или добавление нужно встроить в скрипт. Логика одна: агент нового сервера должен быть доступен по сети, а центральный сервер должен знать его по имени.

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

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

1. Версия платформы. Номер сборки на новом сервере должен совпадать с центральным полностью, например 8.3.24.1548 и 8.3.24.1548. Кластер с узлами разных сборок не работает : агенты просто не договорятся.

2. Разрешение имён. Кластер обращается к серверам по именам, а не по IP. Новый узел должен находить центральный сервер по имени, и наоборот. Если в сети нет нормального DNS, пропишите оба имени в файл hosts на каждой машине и на терминальных серверах, откуда работают пользователи:

192.168.10.11   srv1c-01
192.168.10.12   srv1c-02

3. Порты. Откройте во входящих правилах межсетевого экрана на обоих серверах:

Диапазон 1560:1591 — значение по умолчанию. Его задают в свойствах рабочего сервера, и если вы его меняли на центральном, повторите то же на новом узле и в правилах брандмауэра.

4. Доступ к СУБД. Рабочие процессы сами ходят в базу данных. Значит, на новом сервере нужны клиентские компоненты вашей СУБД (для MS SQL — драйвер OLE DB или Native Client нужной версии), а сервер СУБД должен пускать подключения с этого адреса.

Установка серверной части и службы агента на новом узле

Windows

1. Запустите установщик технологической платформы той же сборки.
2. В составе компонентов отметьте Сервер 1С:Предприятия 8 и Администрирование сервера 1С:Предприятия. Клиент на сервере не обязателен.
3. На шаге с режимом запуска выберите установку как сервиса Windows.
4. Укажите учётную запись службы. По умолчанию установщик создаёт локального пользователя USR1CV8. В домене удобнее заранее завести доменную учётку: у неё проще настроить доступ к СУБД и сетевым папкам.
5. Ключ защиты HASP на этом шаге установщик предлагает поставить отдельным драйвером — нужен, только если серверная лицензия на аппаратном ключе.

После установки проверьте в оснастке служб, что служба агента сервера 1С:Предприятия 8.3 запущена, тип запуска — автоматический. Командой ниже убедитесь, что порты открыты локально:

netstat -ano | findstr ":1540 :1541"

Linux

Ставятся пакеты сервера той же сборки, после чего запускается служба агента. Имя systemd-юнита зависит от версии платформы и способа установки, поэтому найдите его поиском, а не по памяти:

systemctl list-unit-files | grep -i 1c
ss -tlnp | grep -E ':154[01]'

Служба работает от пользователя usr1cv8. Каталог реестра кластера по умолчанию лежит в его домашней папке, в подкаталоге .1cv8/1C/1cv8.

Регистрация рабочего сервера в кластере через консоль

Работаем из консоли, подключённой к центральному серверу, а не к новому.

1. Откройте оснастку «Администрирование серверов 1С Предприятия». Если она пустая или выдаёт ошибку загрузки, зарегистрируйте библиотеку консоли от имени администратора:

regsvr32 "C:\Program Files\1cv8\8.3.24.1548\bin\radmin.dll"

Путь подставьте под свою сборку. Регистрировать нужно radmin.dll той же версии, что и сервер.

2. Разверните центральный сервер → Кластеры → нужный кластер → Рабочие серверы.
3. Правой кнопкой по узлу Рабочие серверы → Создать → Рабочий сервер.
4. Заполните карточку:
   • Описание — понятное имя, например «Сервер 2, бухгалтерия»;
   • Имя компьютера — сетевое имя нового узла, ровно как оно резолвится (srv1c-02);
   • IP-порт — 1540, если агент слушает порт по умолчанию;
   • Диапазон IP портов — 1560:1591 или ваш диапазон.
5. Отметку Центральный сервер пока не ставьте. Сначала убедитесь, что узел работает как рабочий.
6. Нажмите ОК. Если связи нет, консоль сразу выдаст ошибку соединения.

Через несколько секунд раскройте у нового сервера ветку Рабочие процессы. Там должен появиться хотя бы один rphost, а в списке Менеджеры кластера — служба менеджера на новом узле, если вы её включили.

То же через rac

На любой машине должен работать сервер администрирования ras. Сначала узнайте идентификатор кластера:

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

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

Рабочие процессы и распределение нагрузки между серверами

Сам по себе второй сервер начнёт получать часть сеансов. Чтобы распределение было предсказуемым, настройте три уровня.

Свойства рабочего сервера

В карточке рабочего сервера задаются лимиты для его rphost:

• 🔢 Количество ИБ на процесс — сколько баз обслуживает один рабочий процесс. 0 — без ограничения. Для тяжёлых баз часто ставят 1, чтобы каждая база жила в своём процессе.
• 👥 Количество соединений на процесс — после превышения кластер поднимает ещё один rphost.
• 🧠 Критический объём памяти процессов и временно допустимый объём памяти — пороги, после которых кластер перезапускает рабочие процессы. Ставьте их с учётом реальной памяти именно этой машины, а не копируйте с центрального сервера.
• ⚙️ Менеджер под каждый сервис — выносит службы кластера в отдельные процессы rmngr. Полезно на загруженных кластерах.

Свойства кластера

В карточке кластера есть Режим распределения нагрузки: приоритет по производительности или по памяти. Кластер оценивает рабочие процессы по показателю «Доступная производительность» и отдаёт новые соединения тем, кто отвечает быстрее. Если серверы разные по мощности, слабый будет получать меньше сеансов автоматически.

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

ТНФ — главный инструмент, когда нужно не «поровну», а «по смыслу». Они настраиваются в узле Требования назначения функциональности у конкретного рабочего сервера. Каждое правило — это объект, тип требования и, при необходимости, имя базы.

Применяются требования к новым соединениям. Чтобы уже работающие сеансы переехали по новым правилам, кластеру нужна команда применить требования. В консоли она доступна в контекстном меню узла ТНФ: частичное применение переносит сеансы без разрыва, полное — с завершением соединений, которые нарушают правило. Полное применение делайте вне рабочего времени.

Отказоустойчивость

Когда новый узел стабильно отработал несколько дней, можно отметить у него флажок Центральный сервер и в свойствах кластера поднять Уровень отказоустойчивости до 1. Тогда при падении одного центрального сервера кластер продолжит работу на другом. Без второго центрального сервера отказоустойчивость не повышается: второй рабочий узел добавляет мощность, а не резерв.

Лицензии и ключи защиты на нескольких узлах

Тут ошибаются чаще всего, поэтому по пунктам.

• 🖥 Серверная лицензия нужна на каждый рабочий сервер, где запускаются рабочие процессы. Программная лицензия привязывается к железу конкретной машины, перенести её с центрального сервера нельзя. Аппаратный серверный ключ HASP вставляется в ту машину, где он должен работать, либо раздаётся менеджером лицензий HASP по сети.
• 👥 Клиентские лицензии получает кластер, а не отдельный узел. Программные клиентские лицензии можно активировать на одном из серверов кластера, и их увидят сеансы на всех узлах. Какой сервер выдаёт клиентские лицензии, задаётся тем же механизмом ТНФ — объектом «Клиентская лицензия».
• 📁 Программные лицензии на Windows лежат в C:\ProgramData\1C\licenses. Файлы привязаны к оборудованию, копировать их на другой сервер бесполезно.
• 🏢 Часть возможностей тонкой настройки кластера относится к редакции сервера уровня КОРП. Если пункты ТНФ или служб у вас недоступны, проверьте, какая серверная лицензия куплена.

Проверка, мониторинг и отладка нового узла

Сразу после регистрации проверьте узел в такой последовательности:

1. В консоли у нового сервера видны рабочие процессы со статусом «Включён».
2. Колонки «Память» и «Доступная производительность» у его rphost заполняются, а не стоят на нуле.
3. Откройте базу с клиентского компьютера, затем в консоли в узле Сеансы посмотрите, на каком рабочем процессе сеанс. Повторите несколько входов — часть должна уйти на новый сервер.
4. Запустите регламентное задание или фоновую операцию и проверьте, где оно выполняется, особенно если настраивали ТНФ для фоновых заданий.

Где искать причину сбоя

• Журнал регистрации базы — ошибки на уровне прикладной логики и входа.
• Технологический журнал — подробная запись событий платформы. Включается файлом logcfg.xml в каталоге conf платформы на каждом сервере отдельно. Для начала достаточно событий EXCP и CONN, чтобы увидеть исключения и проблемы соединений. Журнал быстро растёт, задавайте history и следите за диском.
• Журнал событий Windows или journalctl на Linux — падения самой службы агента.
• Каталог реестра кластера (srvinfo на Windows) — по его содержимому видно, что узел получил настройки кластера.

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