RAS и RAC для 1С: безопасное администрирование кластера из командной строки

Консоль администрирования серверов 1С удобна для повседневной работы, но подходит не для всех задач. На сервере может не оказаться графического интерфейса, версии консоли и кластера могут различаться, а повторяющиеся проверки сложно выполнять вручную.

В таких ситуациях используются RAS и RAC. С их помощью администратор может подключаться к кластеру 1С из командной строки, получать сведения о рабочих процессах и пользовательских сеансах, а также выполнять контролируемые административные операции.

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

Поэтому безопасная работа с RAC строится по принципу: сначала получить актуальное состояние, затем точно выбрать объект, выполнить одну операцию и сразу проверить результат.

Как связаны RAS, RAC и кластер 1С

RAS и RAC — два разных компонента одного механизма администрирования.

• RAS (Remote Administration Server) — сервер администрирования. Он принимает административные запросы и взаимодействует с кластером серверов 1С.
• RAC (Remote Administration Client) — консольная утилита, через которую администратор отправляет запросы серверу RAS.

В названиях компонентов используются прописные буквы — RAS и RAC. В командах имена исполняемых файлов записываются так, как они называются в системе: ras, rac, ras.exe или rac.exe.

Схема взаимодействия выглядит так:

Администратор или скрипт
          │
          │ команда rac
          ▼
Сервер администрирования RAS
          │
          │ административный запрос
          ▼
Кластер серверов 1С

RAC можно установить на компьютере администратора, сервере автоматизации или отдельном узле управления. RAS обычно размещают рядом с кластером 1С, обеспечивая ему сетевой доступ к агенту сервера.

Если графическая консоль уже установлена и работает, отказываться от неё не требуется. Инструменты решают разные задачи.

Установка и особенности графического инструмента разобраны отдельно в материале «Консоль администрирования серверов 1С: установка и подключение».

Как подготовить RAS и проверить подключение

Проверьте версию платформы и состав компонентов

RAS и RAC устанавливаются вместе с серверными и административными компонентами платформы 1С. Пути к исполняемым файлам зависят от операционной системы, архитектуры и установленной версии.

Примеры расположения файлов:

C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe
C:\Program Files\1cv8\8.3.xx.xxxx\bin\rac.exe

/opt/1cv8/x86_64/8.3.xx.xxxx/ras
/opt/1cv8/x86_64/8.3.xx.xxxx/rac

Вместо 8.3.xx.xxxx нужно указать фактический каталог платформы.

Желательно использовать RAS и RAC той же версии, что и сервер кластера. При несовпадении версий часть команд или параметров может оказаться недоступной.

Проверить доступные команды установленной утилиты можно так:

rac help

Для отдельной группы объектов:

rac cluster help
rac session help
rac infobase help

В Windows нужно использовать исполняемый файл rac.exe из каталога установленной платформы. Вывод help установленной версии имеет приоритет перед примерами из инструкций: набор команд и параметров платформы со временем может меняться.

Запустите RAS для первичной проверки

Если сервер администрирования ещё не настроен как служба, его можно временно запустить в интерактивном режиме.

Пример для Windows:

& "C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe" cluster --port=1545 localhost:1540

Пример для Linux:

/opt/1cv8/x86_64/8.3.xx.xxxx/ras cluster --port=1545 localhost:1540

В примерах:

• 1545 — порт, на котором RAS принимает административные подключения;
• localhost:1540 — адрес и порт агента сервера 1С;
• cluster — режим администрирования кластера.

Эти значения нужно сверить с фактической конфигурацией. В инфраструктуре могут использоваться нестандартные порты или отдельный адрес агента.

Порты кластера, агента и рабочих процессов не следует путать с портом RAS. Схема сетевого взаимодействия подробнее разобрана в статье «Сетевые порты сервера 1С: назначение и настройка».

Проверьте доступность сервера администрирования

С компьютера, на котором установлен RAC, запросите список кластеров:

rac cluster list RAS_HOST:1545

Замените RAS_HOST на DNS-имя или IP-адрес сервера RAS.

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

1. Запущен ли RAS.
2. Правильно ли указан адрес.
3. Совпадает ли порт с параметрами запуска RAS.
4. Разрешено ли соединение межсетевым экраном.
5. Доступен ли агент кластера с сервера RAS.
6. Совместимы ли версии административных компонентов и платформы.

Для постоянной работы лучше использовать DNS-имя, а не IP-адрес. Это упростит перенос RAS на другой сервер и изменение сетевой конфигурации.

Аутентификация и безопасный доступ

Разделяйте уровни администрирования

В кластере 1С могут использоваться разные учётные данные:

• администратор кластера — для операций на уровне кластера, рабочих серверов, процессов, соединений и сеансов;
• администратор информационной базы — для операций, относящихся к конкретной базе.

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

Типовой запрос с аутентификацией администратора кластера выглядит так:

rac session list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

Здесь и далее значения в верхнем регистре — заполнители. Их нельзя копировать в рабочую команду без замены.

Не публикуйте порт RAS в интернете

RAS относится к административному контуру. Подключение к нему следует разрешать только:

• с рабочего места администратора;
• с выделенного сервера управления;
• из защищённой административной сети;
• с узла автоматизации или мониторинга.

На межсетевом экране нужно ограничить источники подключения. Открывать порт RAS для всех адресов, например правилом 0.0.0.0/0, не следует.

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

Не храните пароль в открытом виде

Параметр --cluster-pwd удобен для разовой проверки, но переданный в командной строке пароль может сохраниться:

• в истории команд;
• в журнале системы автоматизации;
• в выводе диагностического скрипта;
• в списке процессов операционной системы;
• в файле сценария или репозитории.

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

Не включайте полную командную строку с паролем в журнал. При диагностике записывайте имя операции, адрес RAS, идентификатор объекта и код завершения, но не секреты.

Используйте отдельную учётную запись для автоматизации

Не запускайте регулярные сценарии от имени личной учётной записи администратора. Для автоматизации лучше создать отдельную запись и определить:

• какие операции ей разрешены;
• на каких серверах она может использоваться;
• где хранится пароль;
• кто отвечает за его смену;
• какие действия должны попадать в журнал.

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

Как получить состояние кластера через RAC

Перед любой изменяющей операцией следует заново запросить состояние кластера. Это позволяет получить актуальные идентификаторы и убедиться, что команда будет направлена правильному объекту.

Найдите идентификатор кластера

Выполните:

rac cluster list RAS_HOST:1545

В выводе найдите поле cluster. Его значение потребуется для последующих запросов:

cluster : 11111111-2222-3333-4444-555555555555
host    : srv-1c.example.local
port    : 1541
name    : Основной кластер

Не переносите идентификаторы из тестовой среды в рабочую и не полагайтесь на UUID из старого журнала. Перед операцией запрашивайте объект повторно.

Получите список информационных баз

rac infobase summary list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

В сводном списке можно найти нужную информационную базу и её UUID. Перед использованием идентификатора сопоставьте его как минимум с двумя признаками: именем базы и назначением кластера.

Проверьте рабочие процессы

rac process list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

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

• запущены ли процессы;
• на каких рабочих серверах они находятся;
• какие процессы обслуживают кластер;
• не появился ли лишний или недоступный процесс.

Общая архитектура сервера 1С и роли его компонентов рассмотрены в статье «Развёртывание серверной инфраструктуры 1С».

Различайте соединения и сеансы

Для просмотра соединений используется запрос:

rac connection list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

Для просмотра сеансов:

rac session list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

Соединение и сеанс — не одно и то же.

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

Для поиска причины зависаний одного списка RAC может оказаться недостаточно. В таких случаях результаты нужно сопоставлять с технологическим журналом 1С.

Как безопасно выполнять административные операции

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

Безопасная последовательность выглядит так:

1. Получить актуальный список объектов.
2. Найти нужную информационную базу или сеанс.
3. Проверить UUID и дополнительные признаки.
4. Зафиксировать исходное состояние.
5. Выполнить одну точечную операцию.
6. Повторно запросить состояние.
7. Записать результат в журнал работ.

Завершите только выбранный сеанс

Перед завершением получите свежий список:

rac session list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

Убедитесь, что выбранный UUID относится к нужной базе, пользователю и приложению.

После проверки выполните команду:

rac session terminate --cluster=CLUSTER_UUID --session=SESSION_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

Сразу после выполнения повторите запрос списка сеансов:

rac session list --cluster=CLUSTER_UUID --cluster-user=CLUSTER_ADMIN --cluster-pwd=CLUSTER_PASSWORD RAS_HOST:1545

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

Временно запретите новые подключения перед обслуживанием

Для обновления конфигурации, резервного копирования или других регламентных работ может потребоваться запретить новые сеансы и дождаться завершения текущих.

Эта операция выполняется изменением параметров информационной базы. Она требует указания периода блокировки, причины и, при необходимости, кода разрешения.

Синтаксис rac infobase update зависит от версии платформы и набора уже заданных параметров. Перед применением выполните:

rac infobase help

Затем:

1. Получите и сохраните текущие параметры базы.
2. Уточните UUID информационной базы.
3. Задайте понятный текст сообщения пользователям.
4. Установите ограниченный период блокировки.
5. Проверьте, что новые сеансы не создаются.
6. После работ снимите блокировку.
7. Повторно проверьте доступ пользователей.

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

Контролируйте фоновые и регламентные задания

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

Перед изменением режима выполнения заданий:

• уточните, какие операции запущены;
• согласуйте окно обслуживания;
• зафиксируйте исходное состояние;
• предусмотрите время и способ обратного включения;
• после работ проверьте запуск критичных заданий.

Не оставляйте запрет фоновых заданий без конечного времени и ответственного за восстановление. Иначе внешне исправная база может перестать выполнять обмены и регламентные операции.

Не автоматизируйте необратимые действия без защиты

В рабочие скрипты не следует включать без отдельного подтверждения:

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

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

Автоматизация и диагностика ошибок RAC

Начните с безопасного сценария чтения

Первый автоматизированный сценарий лучше ограничить получением состояния. Например, скрипт для Linux может проверять доступность RAS и сохранять список кластеров:

#!/bin/sh
set -eu

RAC="/opt/1cv8/x86_64/8.3.xx.xxxx/rac"
RAS_ENDPOINT="ras-admin.example.local:1545"
LOG_FILE="/var/log/1c/rac-cluster-check.log"

{
  date -u
  "$RAC" cluster list "$RAS_ENDPOINT"
} >> "$LOG_FILE" 2>&1

Перед запуском:

• замените путь к RAC на фактический;
• укажите адрес своего RAS;
• создайте каталог журнала;
• ограничьте права на файл;
• запустите сценарий от отдельной системной учётной записи.

Этот пример не меняет состояние кластера. Его можно использовать как основу для мониторинга доступности административного интерфейса.

Для более сложного сценария проверяйте код завершения команды:

if "$RAC" cluster list "$RAS_ENDPOINT" >/tmp/rac-result.txt 2>/tmp/rac-error.txt; then
  echo "RAS отвечает"
else
  echo "Ошибка подключения к RAS" >&2
  exit 1
fi

Для рабочей эксплуатации временные файлы следует создавать безопасным способом и удалять после обработки. Не записывайте в них пароли и полные командные строки с секретами.

Добавьте защиту перед изменяющими командами

Сценарий, который завершает сеанс или меняет параметры базы, должен дополнительно проверять:

• имя среды: рабочая или тестовая;
• адрес RAS;
• UUID кластера;
• UUID информационной базы;
• UUID конкретного сеанса;
• наличие обязательного подтверждения;
• результат повторного запроса после операции.

Полезно реализовать режим предварительного просмотра, при котором сценарий выводит найденные объекты, но ничего не изменяет. Переход к выполнению должен происходить только после явного параметра, например --apply.

Разбирайте ошибки по уровню возникновения

Если RAC сообщает о неизвестном параметре, не пытайтесь перебирать варианты в рабочей среде. Сначала сравните версии файлов rac, ras и серверной платформы, затем посмотрите справку именно установленной утилиты.

Сопоставляйте RAC с другими источниками диагностики

RAC показывает административное состояние, но не всегда объясняет причину проблемы. Например, наличие сеанса не говорит, почему запрос выполняется долго, а работающий процесс не означает, что внутри него нет блокировок или исключений.

Для полноценной диагностики сведения RAC сопоставляют с:

• технологическим журналом 1С;
• журналом регистрации;
• системными журналами Windows или Linux;
• показателями процессора, памяти и дисковой подсистемы;
• состоянием СУБД;
• сетевыми журналами и правилами межсетевого экрана.

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

Заключение

RAS и RAC дают администратору воспроизводимый интерфейс управления кластером 1С. С их помощью удобно проверять состояние серверов и сеансов, выполнять диагностику без графической консоли и автоматизировать регулярные проверки.

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

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

Что почитать дальше

Для настройки и диагностики инфраструктуры 1С полезно также посмотреть связанные материалы:

• Консоль администрирования серверов 1С — для ручного управления кластером через графический интерфейс.
• Развёртывание серверной инфраструктуры 1С — об устройстве серверной части и распределении компонентов.
• Сетевые порты сервера 1С — для проверки портов агента, кластера, рабочих процессов и административных подключений.
• Технологический журнал 1С — для углублённой диагностики ошибок и проблем производительности.

Когда стоит обратиться к специалистам

Самостоятельной настройки обычно достаточно для подключения RAC, просмотра состояния кластера и создания безопасных сценариев чтения. Помощь специалистов потребуется, если RAS не подключается к кластеру, версии компонентов несовместимы или нужно автоматизировать операции, изменяющие рабочую среду.

IPWAY выполняет поддержку и сопровождение 1С: специалисты помогут проверить кластер, настроить административный контур, диагностировать ошибки и подготовить безопасные сценарии обслуживания.

Если текущей инфраструктуре не хватает ресурсов или требуется отдельная среда для работы пользователей, можно подобрать сервер в аренду для 1С с подходящей конфигурацией процессора, оперативной памяти и дисковой подсистемы.

Кратко

• RAS принимает административные запросы, а RAC отправляет их из командной строки.
• В тексте названия компонентов пишутся как RAS и RAC, а команды — как ras и rac.
• Версии RAS, RAC и серверной платформы должны быть совместимы.
• Порт RAS следует открывать только для доверенных административных узлов.
• Перед изменяющей операцией нужно повторно получить UUID кластера, базы или сеанса.
• Пароли администраторов нельзя хранить в сценариях, истории команд и открытых журналах.
• Автоматизацию лучше начинать с безопасных команд чтения и мониторинга.
• Завершение сеансов, блокировку подключений и другие изменения необходимо выполнять точечно с проверкой результата.