Вывод узла из кластера серверов 1С:Предприятия 8.3 без остановки работы пользователей

Рабочий сервер удаляют из кластера 1С в консоли «Администрирование серверов 1С:Предприятия»: откройте кластер, ветку Рабочие серверы, выделите нужный узел и выполните в контекстном меню Удалить. Из командной строки то же самое делает rac server remove. Перед этим узел нужно разгрузить, иначе пользователи, чьи сеансы обслуживает его рабочий процесс, получат обрыв соединения.

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

Всё описанное относится к платформе 8.3 и одинаково работает для любых конфигураций: кластер ничего не знает о том, БП в базе или ЗУП.

Что проверить до удаления узла из кластера 1С

Удаление из кластера необратимо в том смысле, что настройки узла (диапазон портов, лимиты памяти, требования назначения функциональности) пропадут. Вернуть сервер можно, но параметры придётся вводить заново. Поэтому сначала соберите картину.

📋 Что выяснить:

• 🖥️ Роль сервера. Откройте свойства рабочего сервера и посмотрите флажок «Центральный сервер». Если это сервер, на котором создавали кластер и где работает главный менеджер кластера, штатно удалить его нельзя: это уже перенос кластера на другую машину, отдельная задача.
• 🔑 Лицензии. Проверьте, не лежит ли на этом сервере программная лицензия на сервер 1С или клиентские лицензии, которые раздаёт кластер. После удаления узла они перестанут выдаваться, и пользователи увидят ошибку получения лицензии.
• 📌 Требования назначения функциональности. Ветка с требованиями есть у каждого рабочего сервера. Если там закреплены базы или фоновые задания («этот обмен выполнять только на сервере 2»), после удаления эти правила исчезнут вместе с узлом. Перенесите нужные на оставшийся сервер.
• 🔌 Адрес подключения. Если пользователи в списке баз прописали имя удаляемой машины (Srvr="server2";Ref="buh";), после удаления они не подключатся. Строки нужно заменить на адрес центрального сервера.
• 💾 Резервная копия реестра кластера. Скопируйте каталог srvinfo с центрального сервера целиком. Это главная страховка на случай, если что-то пойдёт не так.

Сами информационные базы удаление узла не затрагивает. Данные лежат в СУБД, рабочий сервер их только обрабатывает.

Разгрузка сервера перед удалением

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

Самый мягкий способ — требование назначения функциональности:

1. В консоли раскройте удаляемый рабочий сервер → Требования назначения функциональности.
2. Создайте новое требование: объект требования «Любой объект требования», тип требования «Не назначать».
3. Сохраните. Кластер перестанет назначать на этот сервер новые соединения и сервисы.
4. Откройте ветку Рабочие процессы кластера и следите за процессами, которые запущены на этом сервере. Число соединений будет падать по мере того, как пользователи закрывают 1С.

Обычно хватает конца рабочего дня. Утром все войдут уже на оставшиеся серверы.

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

Удаление рабочего сервера через консоль администрирования

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

1. Запустите «Администрирование серверов 1С:Предприятия».
2. Раскройте центральный сервер → Кластеры → нужный кластер → Рабочие серверы.
3. Если у кластера заданы администраторы, консоль запросит логин и пароль администратора кластера.
4. Щёлкните правой кнопкой по удаляемому серверу и выберите Удалить. Подтвердите.
5. Обновите дерево (F5). Сервера в списке быть не должно, а в ветке Рабочие процессы не должно остаться процессов с его именем.

Если консоль не открывается или ругается на версию, проверьте, что версия консоли совпадает с версией платформы на сервере. Частая причина — незарегистрированная библиотека консоли после обновления. Её регистрируют от имени администратора:

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

Номер версии в пути подставьте свой: это каталог той платформы, что установлена на сервере.

Удаление через rac

На Linux и на серверах без графики удобнее командная строка. rac работает через сервер администрирования ras, поэтому ras должен быть запущен (по умолчанию слушает порт 1545).

rac cluster list
rac server list --cluster=<id_кластера> --cluster-user=admin --cluster-pwd=***
rac server remove --cluster=<id_кластера> --server=<id_сервера> --cluster-user=admin --cluster-pwd=***

Первая команда покажет идентификатор кластера, вторая — идентификаторы рабочих серверов с их именами. Скопируйте server нужного узла и подставьте в третью. Если администраторов кластера нет, параметры --cluster-user и --cluster-pwd не указывайте. Полный список параметров для вашей версии смотрите в rac help server.

Проверить результат можно теми же командами. rac server list больше не должен показывать удалённый узел, а rac process list --cluster=<id_кластера> — процессы на нём. Если процессы ещё висят, подождите пару минут: кластер завершает их не мгновенно.

Зачистка удалённой машины: служба, srvinfo, сеансовые данные

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

На удалённом сервере:

1. Остановите службу агента. В Windows — через services.msc или командой sc stop с именем службы. В Linux имя юнита зависит от версии, найдите его: systemctl list-units | grep 1cv8.
2. Отключите автозапуск, чтобы служба не поднялась после перезагрузки.
3. Если машину больше не используют под 1С, удалите платформу через «Программы и компоненты» или пакетный менеджер, а затем каталог srvinfo.
4. Если сервер планируют использовать под другой кластер, каталог srvinfo лучше очистить полностью: старый реестр с чужими базами там не нужен.

На оставшихся серверах кластера иногда стоит очистить сеансовые данные. Они лежат в подкаталогах snccntx* внутри srvinfo\reg_1541 (номер в имени reg_ — порт менеджера кластера). Это делают, если после удаления узла сеансы ведут себя странно: висят «мёртвые» соединения, пользователи не могут зайти, консоль показывает сеансы с несуществующего сервера.

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

Порядок:

1. Остановите службу агента на центральном сервере.
2. Удалите папки snccntx* в каталоге reg_1541. Файлы *.lst не трогайте.
3. Запустите службу и проверьте подключение к базе.

Если штатное удаление не сработало: реестр кластера

Бывает, что консоль не даёт удалить сервер, зависает или узел после удаления снова появляется в списке. Обычно это значит, что реестр кластера на центральных серверах рассинхронизировался.

Реестр хранится в двух файлах:

Рабочие серверы описаны в 1CV8Clst.lst. Править его руками можно, но это крайняя мера: файл имеет строгую скобочную структуру, и одна лишняя запятая делает кластер нерабочим.

Если всё же решили:

1. Остановите службу агента на всех центральных серверах кластера.
2. Сделайте копию 1CV8Clst.lst рядом с оригиналом.
3. Найдите в файле блок, где фигурирует имя удаляемого сервера и его порты, и аккуратно удалите его целиком, соблюдая парность скобок.
4. Запустите службу и подключитесь консолью.
5. Если кластер не поднялся, остановите службу и верните копию файла.

Как перераспределить нагрузку на оставшиеся серверы

Удалённый узел обслуживал часть пользователей. Теперь их сеансы ляжут на оставшиеся серверы, и это нужно учесть заранее, а не после жалоб «1С тормозит».

Что посмотреть в свойствах оставшихся рабочих серверов:

• ⚙️ Диапазон IP-портов рабочих процессов (по умолчанию 1560:1591). Если процессов станет больше, портов должно хватить.
• 🧠 Лимиты памяти рабочих процессов. Раньше каждый сервер держал половину нагрузки, теперь один держит всю. Пересчитайте лимиты под реальный объём оперативной памяти.
• 🔢 Количество ИБ на процесс и соединений с ИБ на процесс. Определяют, когда кластер запустит новый рабочий процесс.
• 📌 Требования назначения функциональности. Перенесите сюда правила, которые раньше были у удалённого узла, и проверьте, что нигде не осталось ссылок на его имя.

В свойствах самого кластера есть режим распределения нагрузки (приоритет по производительности или по памяти) и уровень отказоустойчивости. Если после удаления остался один центральный сервер, резервирования у кластера больше нет, какое бы значение ни стояло.

Пример: было два сервера по 32 ГБ, на каждом в пике около 60 пользователей. После удаления одного все 120 пользователей окажутся на втором. Если раньше пиковое потребление процессов на сервер было около 20 ГБ, теперь оно будет около 40 ГБ, и 32 ГБ уже не хватит. Такой узел до удаления нужно либо доукомплектовать памятью, либо не выводить вовсе.

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

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

Если ни один пункт не подошёл, включите технологический журнал на центральном сервере и воспроизведите ошибку. События EXCP и CONN покажут, к какому узлу пытается обратиться кластер.

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