Как устроен рабочий сервер в кластере 1С:Предприятия 8.3
Содержание
Рабочий сервер 1С — это компьютер, включённый в кластер серверов
1С:Предприятия 8.3, на котором запущен агент сервера и выполняются рабочие процессы rphost. Именно они исполняют серверный код конфигурации и отправляют запросы в СУБД. Настраивают его в консоли администрирования: ветка кластера → Рабочие серверы → свойства нужного сервера.
В небольшой установке кластер состоит из одного компьютера, и он же — центральный рабочий сервер. Когда пользователей становится 100–200 и больше, в кластер добавляют второй и третий сервер, а нагрузку между ними делит менеджер кластера. От того, как заданы порты, лимиты памяти и число процессов на каждом сервере, зависит, будет ли база работать ровно или падать в часы пик.
Место рабочего сервера в кластере 1С
Кластер — это логическая единица. Физически он состоит из одного или нескольких рабочих серверов. Каждый рабочий сервер — это запись в консоли, которая привязана к конкретному компьютеру по имени и порту агента.
Рабочие серверы бывают двух видов:
- 🏛️ Центральный. Хранит реестр кластера (список баз, администраторов, настроек), на нём работает основной менеджер кластера. В свойствах сервера включён флажок
Центральный сервер. - ⚙️ Обычный рабочий. Принимает рабочие процессы и, при настройке, дополнительные сервисы кластера. Реестр хранит у себя копию только при отказоустойчивой конфигурации.
Центральных серверов в кластере может быть несколько — так строят резервирование. Если один центральный сервер выходит из строя, второй продолжает обслуживать клиентов.
Как клиент находит рабочий процесс
Путь подключения толстого или тонкого клиента в клиент-серверном режиме выглядит так:
- Клиент обращается к агенту сервера по порту
1540. - Агент передаёт его менеджеру кластера (порт
1541). - Менеджер выбирает рабочий процесс на одном из рабочих серверов и сообщает клиенту его порт из диапазона
1560:1591. - Дальше клиент работает напрямую с этим процессом
rphost.
Отсюда практическое правило для сетевиков: на брандмауэре открывают не только 1540 и 1541, но и весь диапазон портов рабочих процессов. Иначе консоль видит кластер, а пользователи получают ошибку соединения при входе в базу.
Если на одном компьютере работают два кластера (например, рабочий и тестовый на разных версиях платформы), второму обычно назначают порты 2540, 2541 и диапазон 2560:2591. Главное — чтобы диапазоны не пересекались.
Процессы ragent, rmngr и rphost: кто чем занят
В диспетчере задач сервера 1С видно три главных процесса. Путают их часто, хотя роли у них разные.
ragent — агент сервера. Работает как служба Windows («Агент сервера 1С:Предприятия 8.3») или демон в Linux. Запускает остальные процессы, следит за ними и перезапускает при падении. Сам по себе почти не потребляет ресурсов.
rmngr — менеджер кластера. Отвечает за сервисы кластера: сеансы, управляемые блокировки, лицензии, журнал регистрации, полнотекстовый поиск, регламентные задания. По умолчанию один процесс на центральном сервере. Если включить Менеджер под каждый сервис, сервисы разнесутся по отдельным процессам rmngr.
rphost — рабочий процесс. Выполняет серверные процедуры, проводит документы, строит отчёты, общается с СУБД. На одном рабочем сервере обычно работает несколько rphost.
Рядом иногда видно ещё два процесса:
- 🛠️
ras— сервер администрирования, через него работает утилитаrac(порт по умолчанию1545); - 📋
rac— сама утилита командной строки для управления кластером.
Как процессы связаны с базами
Один rphost обслуживает соединения сразу нескольких информационных баз. Сколько именно — задают два параметра рабочего сервера, о них ниже. Когда лимит исчерпан, агент запускает на этом сервере новый рабочий процесс.
Из-за этого в диспетчере задач на нагруженном сервере легко увидеть 6–10 процессов rphost. Это не утечка и не сбой, а штатная работа.
Сводная таблица процессов кластера
| Процесс | Роль | Порт по умолчанию | Где работает | Что будет, если упадёт |
|---|---|---|---|---|
ragent | Агент, запуск и контроль процессов | 1540 | На каждом рабочем сервере | Сервер выпадает из кластера |
rmngr | Менеджер кластера и его сервисы | 1541 | На центральном сервере (и других по настройке) | Нет новых сеансов, блокировки и журнал недоступны |
rphost | Исполнение серверного кода | 1560–1591 | На рабочих серверах | Разрываются сеансы, которые он обслуживал |
ras | Сервер администрирования | 1545 | Где запущен вручную или службой | Не работает rac, консоль при этом живёт |
Порты в таблице — значения по умолчанию. В конкретной установке их могут переопределить при регистрации службы.
Свойства рабочего сервера: что и зачем менять
Откройте консоль администрирования серверов 1С, разверните кластер, затем ветку Рабочие серверы. Двойной щелчок по серверу открывает его свойства. Ниже — параметры, которые реально влияют на работу.
Порты и роль
- Имя и Компьютер — сетевое имя или IP-адрес. Лучше имя, которое резолвится одинаково на всех клиентах.
- IP-порт — порт агента на этом сервере, по умолчанию 1540.
- Диапазоны IP-портов — откуда брать порты для
rphost. Значение по умолчанию1560:1591. - Центральный сервер — делает сервер центральным.
- Менеджер под каждый сервис — запускает отдельный
rmngrна каждый сервис кластера. Полезно при сотнях сеансов: падение одного сервиса не тянет за собой остальные.
Сколько баз и соединений на процесс
- Количество ИБ на процесс — по умолчанию 8.
- Количество соединений на процесс — по умолчанию 128.
Если на сервере 30 баз и вы хотите изолировать тяжёлую учётную базу от мелких, уменьшите первый параметр. Тогда процессов станет больше, и проблема в одной базе реже задевает другие. Обратная сторона — растёт расход памяти: каждый процесс держит свой кеш метаданных.
Лимиты памяти
Здесь собраны самые важные для стабильности настройки (в разных версиях платформы формулировки могут немного отличаться):
- Временно допустимый объём памяти процессов — общий объём памяти всех
rphostсервера, превышать который можно не дольше заданного интервала. - Интервал превышения допустимого объёма памяти — сколько секунд сервер терпит превышение (по умолчанию 300). После этого самый «тяжёлый» процесс помечается к перезапуску: он перестаёт принимать новые соединения, а текущие переводятся на другие процессы.
- Критический объём памяти процессов — аварийная граница. Если её перешли, кластер принудительно разгружает сервер, прерывая тяжёлые вызовы.
- Безопасный расход памяти за один вызов — лимит для одного серверного вызова. Вызов, который съел больше, прерывается с ошибкой у пользователя, а не роняет весь процесс.
Пример расчёта для сервера с 64 ГБ оперативной памяти, на котором стоит и СУБД:
| Параметр | Значение | Логика |
|---|---|---|
| Память сервера | 64 ГБ | — |
| Резерв под СУБД и ОС | 32 ГБ | половина под PostgreSQL или MS SQL и систему |
| Временно допустимый объём | 24 ГБ | оставшиеся 32 ГБ минус запас 8 ГБ |
| Критический объём | 30 ГБ | чуть ниже доступных 32 ГБ |
| Безопасный расход за вызов | 4 ГБ | один отчёт не должен съесть больше |
Цифры — отправная точка. Через неделю работы посмотрите реальный пик памяти rphost и подстройте.
Нулевое значение в полях памяти обычно означает «без ограничения». На сервере, где рядом работает СУБД, оставлять так рискованно: один кривой отчёт вытеснит кеш базы данных, и встанут все пользователи.
Лицензия на рабочий сервер
Каждому компьютеру, на котором работают rphost, нужна своя лицензия на сервер 1С:Предприятия: 32-разрядная, 64-разрядная или КОРП. Без неё рабочие процессы на этом сервере не стартуют.
Часть возможностей распределённого кластера — например, тонкие требования назначения функциональности и расширенная отказоустойчивость — рассчитана на лицензию КОРП. Перед покупкой второго сервера проверьте, какой редакции хватит под задачу.
Как кластер делит нагрузку между рабочими серверами
Новое соединение получает тот рабочий процесс, у которого лучше всего показатель доступной производительности. Его кластер считает сам: замеряет время эталонных вызовов в каждом rphost. В консоли этот показатель виден в списке рабочих процессов.
Режим распределения нагрузки
В свойствах кластера есть параметр Режим распределения нагрузки с двумя вариантами:
- 🚀 Приоритет по производительности — соединение идёт в самый быстрый процесс, даже если на этом сервере уже занято много памяти;
- 🧠 Приоритет по памяти — сначала учитывается свободная память, потом скорость.
Первый вариант подходит, когда серверы одинаковые. Второй — когда один сервер заметно слабее по оперативной памяти.
Требования назначения функциональности
Это главный инструмент, когда серверов два и больше. В свойствах рабочего сервера есть вкладка (или ветка) с требованиями. Каждое требование говорит: «этот тип объектов назначать или не назначать на этот сервер».
Типичная схема для двух серверов:
- Сервер А — только клиентские соединения пользователей.
- Сервер Б — фоновые и регламентные задания, сервис полнотекстового поиска, журнал регистрации.
Требование можно сузить до конкретной базы. Например, обмены с сайтом в одной базе уводят на отдельный сервер, чтобы ночная выгрузка не тормозила дневную работу бухгалтерии.
После изменения требований нажмите в консоли команду применения требований к рабочим процессам. Иначе новые правила подхватятся только для новых соединений, а старые сеансы останутся на прежних серверах.
Отказоустойчивость
У кластера задаётся уровень отказоустойчивости — сколько рабочих серверов может одновременно выйти из строя без остановки работы. При уровне 1 и двух центральных серверах падение одного не прерывает работу: сеансы переподключаются к оставшемуся.
Резервирование стоит памяти и сетевого трафика: сервисы кластера держат копии данных на нескольких серверах. На одном компьютере этот параметр бессмыслен.
Диагностика рабочего сервера и поиск узких мест
Когда база тормозит, проверяйте сверху вниз: сначала сервер в целом, потом процессы, потом конкретные вызовы.
Что смотреть в консоли
- 📉 Доступная производительность процессов. Если у одного
rphostона резко ниже остальных, в нём застрял тяжёлый вызов или процесс разросся по памяти. - 💾 Память процессов. Процесс, который растёт день ото дня и не сбрасывается, — кандидат на перезапуск.
- 👥 Сеансы и соединения. Сеанс с огромным временем вызова и десятками ожидающих блокировок — источник очереди.
Команды rac для удалённой проверки
Если консоль на Windows недоступна, тот же список видно через rac. Сначала запустите ras на сервере, затем:
rac cluster list
rac server list --cluster=<id_кластера>
rac process list --cluster=<id_кластера>
rac session list --cluster=<id_кластера>
Идентификатор кластера берётся из вывода первой команды. Остальные параметры и фильтры смотрите в справке rac help.
Технологический журнал
Для разбора долгих вызовов и взаимоблокировок включают технологический журнал. Его настраивают файлом logcfg.xml в каталоге conf платформы. Записывайте только нужные события (например, длинные вызовы и ожидания на блокировках) и ограничивайте время хранения: полный журнал за сутки на нагруженном сервере занимает десятки гигабайт.
Каталог данных кластера
Реестр кластера хранится в файле 1CV8Clst.lst в каталоге srvinfo, внутри папки вида reg_1541. Там же лежат кеши сеансовых данных (папки snccntx…).
Перед любыми действиями с каталогом srvinfo сделайте копию файла реестра 1CV8Clst.lst. Без него кластер «забывает» все зарегистрированные базы.
Очистка сеансовых данных помогает при странных ошибках входа, но требует остановки службы агента. Все пользователи будут отключены, несохранённые документы потеряются. Делайте это вне рабочего времени и после предупреждения пользователей.
Когда второй рабочий сервер не нужен
Добавить сервер в кластер просто, но это не лечит любые тормоза. Сначала проверьте, где реальное узкое место.
Второй рабочий сервер не поможет, если:
- ⛔ медленно работает СУБД — запросы упираются в диск или индексы базы данных;
- ⛔ тормоза из-за управляемых блокировок — пользователи ждут друг друга, а не процессор;
- ⛔ виноват конкретный отчёт или обработка с неоптимальным запросом;
- ⛔ проблема в сети между клиентами и сервером.
Второй рабочий сервер поможет, если:
- ✅ процессоры текущего сервера стабильно загружены на 80–90% процессами
rphost; - ✅ памяти не хватает даже после настройки лимитов;
- ✅ нужно развести пользователей и фоновые задачи физически;
- ✅ требуется отказоустойчивость: простой базы стоит дороже второго сервера.
Ориентир по железу: один современный сервер с 16–24 ядрами и 64–128 ГБ памяти обычно тянет несколько сотен пользователей типовых конфигураций, если СУБД вынесена отдельно. Точную цифру даёт только нагрузочный тест на ваших данных.