При администрировании серверов 1С:Предприятие через консольные утилиты rac (Remote Administration Client) и ras (Remote Administration Service) администраторы иногда сталкиваются с парадоксальной ситуацией: вы запрашиваете список кластеров или информационных баз для одного сервера, а в ответ получаете данные совершенно другого хоста. Такая путаница может привести к критическим ошибкам, например, к случайному удалению или изменению баз данных на рабочем (production) сервере вместо тестового.
В этой статье мы подробно разберем, почему возникает подобное поведение систем утилит администрирования, проанализируем внутренние механизмы взаимодействия компонентов 1С, исправим синтаксические ошибки и научимся правильно регистрировать службу ras как в операционной системе Windows, так и в Linux.
Прежде чем перейти к исправлению ошибок, давайте детально разберем архитектурную схему управления кластером 1С. Это поможет понять, на каком именно этапе происходит подмена адресов.
Взаимодействие компонентов администрирования выглядит следующим образом:
1540). Он запускает и контролирует другие процессы кластера.1541).ras не знает, какие базы запущены на сервере. При запуске ей необходимо жестко указать, к какому агенту сервера (ragent) она должна привязаться для трансляции команд. Порт по умолчанию для самого ras — 1545.ras (1545), которая, в свою очередь, передает их агенту ragent (1540).Если на каком-то из этих этапов допущена ошибка в адресации или синтаксисе, вся цепочка начинает работать некорректно, отправляя запросы не на тот физический сервер.
Рассмотрим классическую ошибку, с которой часто начинают системные администраторы при работе с консольным клиентом. Попытка вызвать команду в следующем формате:
rac cluster list Server2
При таком вызове утилита возвращает данные локального сервера или вообще другого хоста, игнорируя указанный в конце Server2. Почему так происходит? Выясним причину, обратившись к официальной документации по синтаксису утилиты rac.
Согласно спецификации 1С, адрес целевого сервера администрирования ras должен указываться в самом начале командной строки, сразу после вызова исполняемого файла rac, а не в конце строки параметров. Полный шаблон вызова выглядит так:
rac [адрес_сервера_ras[:порт_ras]] режим [команда] [параметры]
Когда мы пишем имя сервера в конце, парсер утилиты rac не может сопоставить его ни с одним известным параметром команды cluster list, просто отбрасывает его и обращается по адресу по умолчанию — к локальному хосту (localhost:1545).
Правильное решение: для опроса удаленного сервера администрирования необходимо перенести имя хоста в начало команды:
rac Server2:1545 cluster list
Если порт службы ras на удаленном сервере стандартный (1545), его можно опустить:
rac Server2 cluster list
Что делать, если синтаксис команды вызова rac абсолютно верен, но при обращении к локальной службе ras на сервере Server2 вы все равно получаете идентификаторы кластеров и базы данных с сервера Server1?
Проанализируем ситуацию: это означает, что служба ras, запущенная на физическом сервере Server2, настроена на работу с агентом сервера (ragent), расположенным на Server1. При создании службы была допущена опечатка в параметрах подключения.
Давайте разберем по шагам, как исправить эту проблему в операционной системе Windows.
По умолчанию при установке платформы 1С:Предприятие служба сервера администрирования ras не регистрируется автоматически в системных службах Windows. Администраторы создают её вручную с помощью утилиты командной строки sc.
Важное системное правило утилиты sc: при написании параметров создания или изменения служб в Windows после знака равенства (например, binPath=, start=) обязательно должен стоять пробел. Если пробел не указать, операционная система вернет синтаксическую ошибку.
Если служба уже создана некорректно, нам не обязательно удалять её и создавать заново. Мы можем обновить конфигурацию существующей службы. Выполним следующие шаги:
1C_RAS):
net stop "1C_RAS"
localhost:1540 вместо ошибочного удаленного сервера):
sc config "1C_RAS" binPath= "\"C:\Program Files\1cv8\8.3.22.1709\bin\ras.exe\" cluster --port=1545 localhost:1540"
net start "1C_RAS"
Если вы предпочитаете использовать графический интерфейс или утилиту sc config использовать неудобно из-за экранирования кавычек, исправление можно внести напрямую через реестр Windows:
regedit и нажмите Enter.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C_RAS (или найдите ветку с именем вашей службы администрирования 1С).ImagePath.localhost:1540 или 127.0.0.1:1540.services.msc.Для создания новой, заведомо правильной службы с нуля, используйте следующий шаблон команды:
sc create "1C_RAS" binPath= "\"C:\Program Files\1cv8\8.3.22.1709\bin\ras.exe\" cluster --port=1545 localhost:1540" start= auto
Поскольку серверные решения 1С все чаще разворачиваются на операционных системах семейства Linux (Ubuntu, Astra Linux, RedOS), рассмотрим особенности конфигурирования службы администрирования в этой среде.
В Linux запуск сервера администрирования может выполняться как вручную в фоновом режиме (демон), так и через подсистему инициализации systemd.
Если требуется запустить службу в фоновом режиме вручную для быстрого теста, выполните в терминале команду:
/opt/1cv8/x86_64/current/ras --daemon cluster localhost:1540
Для постоянной работы службы используется юнит-файл systemd. Обычно он поставляется вместе с дистрибутивом платформы. Разберем, как проверить и исправить его конфигурацию:
srv1cv8-ras.service):
sudo nano /lib/systemd/system/srv1cv83-ras.service
ExecStart). Она должна выглядеть следующим образом:
ExecStart=/opt/1cv8/x86_64/current/ras cluster --port=1545 localhost:1540
Если там указан сторонний сервер вместо localhost, исправьте значение.
systemd, чтобы применить изменения:
sudo systemctl daemon-reload
sudo systemctl restart srv1cv83-ras.service
Ошибки администрирования и путаница часто возникают из-за непонимания назначения стандартных портов платформы. Давайте систематизируем эти знания, чтобы вы всегда точно знали, какой порт указывать в командах:
ras при старте. Если вы указываете адрес хоста в параметрах утилиты ras, используйте именно этот порт (например, localhost:1540).rac вы увидите этот порт в выводе информации о кластере в поле port. Сюда подключаются клиентские приложения 1С. Подключать напрямую службу ras к этому порту нельзя.rac при отправке команд. Его необходимо указывать в команде rac (например, rac Server2:1545 ...).rphost), которые выделяются динамически для работы сеансов пользователей с информационными базами.После того как мы исправили конфигурацию служб и синтаксис команд, рассмотрим несколько полезных практических примеров работы с утилитой rac, которые помогут вам убедиться в правильности настроек и автоматизировать повседневные задачи администрирования.
Шаг 1. Получение списка кластеров с удаленного сервера:
Выполним запрос к серверу администрирования на хосте Server2:
rac Server2:1545 cluster list
В результате мы должны получить корректный вывод, содержащий уникальный идентификатор (UUID) кластера именно этого сервера:
cluster : 12345678-abcd-12ef-34gh-567890abcdef
host : Server2
port : 1541
name : "Локальный кластер Server2"
Шаг 2. Получение списка информационных баз для конкретного кластера:
Используя полученный на предыдущем шаге clusterID (в примере: 12345678-abcd-12ef-34gh-567890abcdef), запросим список всех информационных баз, зарегистрированных в данном кластере:
rac Server2:1545 infobase --cluster=12345678-abcd-12ef-34gh-567890abcdef summary list
Вывод покажет краткую информацию по каждой информационной базе (имя, описание), подтверждая, что мы работаем с нужным физическим сервером.
Шаг 3. Завершение зависших сеансов пользователей:
Если вам необходимо программно отключить пользователей перед выполнением регламентных работ (например, резервного копирования), вы можете получить список активных сеансов командой:
rac Server2:1545 session --cluster=12345678-abcd-12ef-34gh-567890abcdef list
И затем завершить конкретный сеанс по его идентификатору:
rac Server2:1545 session --cluster=12345678-abcd-12ef-34gh-567890abcdef terminate --session=session-uuid
Благодаря правильной настройке адресации в утилите ras, вы можете быть абсолютно уверены, что все эти команды будут выполнены именно на целевом сервере Server2, не затрагивая другие серверные мощности вашей компании.