Централизованное управление кластером 1С Предприятия, состоящим из нескольких рабочих серверов, работающих на платформе GNU/Linux
При эксплуатации крупных информационных систем, в состав которых могут входить десятки серверов 1С Предприятия, зачастую возникают ситуации, требующие однотипных действий на всех серверах кластера 1С Предприятия или на всех серверах контура. В настоящей статье представлен способ централизованного управления серверами 1С Предприятия, работающими на платформе GNU/Linux. Подобный подход может быть использован и для других задач, возникающих в процессе эксплуатации крупных систем, с целью сокращения как временных затрат специалистов, так и времени простоя системы.
0. Общие моменты
В контексте задачи, обозначенной в заголовке статьи, предполагается что управлять серверами кластера 1С Предприятия мы будем из консоли GNU/Linux посредством bash-скрипта. Указанный скрипт, в свою очередь, взаимодействует с серверами кластера по протоколу ssh.
Осуществлять централизованное управление серверами кластера, можно с любого компьютера, работающего под управлением операционной системы GNU/Linux (например, таковым может стать один из центральных серверов кластера 1С Предприятия). Для наглядности излагаемого материала, будем исходить из следующей инфраструктуры: компьютер work — рабочий компьютер администратора, с которого будет осуществляться централизованное управление серверами кластера; сервера server_a, server_b, server_c — сервера из состава кластера серверов 1С Предприятия.
Вместе с тем предполагается, что на компьютере, с которого планируется осуществлять централизованное управление (запуск скрипта), уже существует пользователь (не root) и у него уже созданы ключи для ssh-клиента. Информация о том, как создать пользователя в ОС GNU/Linux и как создать ключи для ssh-клиента не является предметом данной статьи. Подробнее об этом можно узнать из страниц справочного руководства (man 8 useradd и man 1 ssh-keygen).
Все описанное в статье прошло проверку работоспособности на кластере 1С Предприятия, работающем под управлением ОС CentOS 7, но вполне может быть адаптировано под любой имеющийся дистрибутив GNU/Linux. ВАЖНО: Ответственность за любые последствия, возникшие в результате внесения изменений в работающую систему по материалам данной статьи, лежат исключительно на лице, внесшим данные изменения! 1. Подготовка инфраструктуры серверов к централизованному управлению
Предполагается, что на всех серверах кластера (в нашем случае server_a, server_b и server_c) уже существует пользователь операционной системы (не
root), от имени которого будут выполняться удаленные команды. Одним из возможных вариантов, которым мы и воспользуемся, может быть задействование пользователя, созданного при установке серверных пакетов 1С Предприятия — usr1cv8 (имя пользователя может несколько отличаться, в зависимости от используемой версии 1С Предприятия). 1.1. Настройки sudo на рабочих серверах
На всех серверах кластера необходимо наделить выбранного пользователя правами на управление сервисами 1С Предприятия (сам сервер 1С Предприятия и сервер RAS, в случае его использования). Для этого мы создадим файл с именем, соответствующим имени пользователя (однако, имя файла может быть любым), в каталоге /etc/sudoers.d следующего содержания:
usr1cv8 ALL = NOPASSWD: /usr/bin/systemctl start srv1cv83, /usr/bin/systemctl stop srv1cv83 usr1cv8 ALL = NOPASSWD: /usr/bin/systemctl start ras1cv83, /usr/bin/systemctl stop ras1cv83
Текст 1: Содержимое файла /etc/sudoers.d/usr1cv8 Таким образом мы наделили пользователя usr1cv8 возможностью запускать и останавливать сервисы srv1cv83 и ras1cv83 без ввода пароля.
Для более детального изучения структуры конфигурационного файла рекомендуется обратиться к страницам справочного руководства (man 5 sudoers).
Проверить правильность сделанных настроек можно выполнив от имени выбранного пользователя соответствующие команды. В нашем случае, для сервера server_a эти команды будут иметь следующий вид:
[usr1cv8@server_a ~]$ sudo systemctl stop srv1cv83 [usr1cv8@server_a ~]$ sudo systemctl start srv1cv83
Обе команды должны выполниться без запроса пароля и без каких-либо ошибок (дополнительных сообщений). После выполнения первой команды не должно остаться выполняющихся процессов, относящихся к серверу 1С Предприятия (ragent, rmngr и rphost). После выполнения второй команды все указанные процессы должны присутствовать в списке выполняющихся процессов. Информацию о том как посмотреть список рабочих процессов можно почерпнуть в станицах справочного руководства (man 1 ps, man 1 pgrep). 1.2. Настройки ssh на рабочих серверах
Следующим этапом необходимо настроить возможность подключения к серверам кластера по протоколу ssh без необходимости ввода пароля пользователя. Для этого на всех серверах кластера, мы добавляем в домашнем каталоге пользователя usr1cv8 в каталог .ssh файл authorized_keys, в который помещаем публичный ключ пользователя, от имени которого мы будем запускать скрипт управления. В нашем случае это пользователь fedotov на компьютере work:
ssh-rsa AAAA6MakK+xJo9eqjH7TYE7BZP8750/BaThbpc1yjGYrOMvtOQOzMcGlU8KYu9J9KdOPNW6sitboCGugz4L koweymAbgx5/aPwIHJqls1d5cO06sMxRjZIl0CktCHfdjIH/sHFITfRJJ fedotov@work
Текст 2: Примерное содержимое файла /home/usr1cv8/.ssh/authorized_keys ВАЖНО: Права доступа к файлу authorized_keys должны быть не выше чем rw-r—r— (644). В противном случае сервер ssh будет все равно запрашивать пароль, т. к. будет считать что этот файл может быть скомпрометирован. Подробнее о назначении прав доступа можно узнать из страниц справочногоруководства (man 1 chmod). Для проверки корректности сделанных настроек необходимо из терминальной консоли компьютера, с которого планируется запускать скрипт управления, выполнить подключение ко всем серверам кластера командой:
[fedotov@work ~]$ ssh usr1cv8@server_a
Last login: Wed Apr 3 17:48:39 2019 from work [usr1cv8@server_a ~]$
На этом подготовительный этап можно считать завершенным! 2. Работа со скриптом централизованного управления
Скрипт может работать в двух вариантах: «автоматизированном» и «ручном». В «автоматизированном» варианте скрипту в качестве параметра необходимо передать имя одного из центральных серверов кластера 1С Предприятия, на котором развернут сервис RAS.
При выполнении команды останова (перезапуска) серверных процессов 1С Предприятия на серверах кластера скрипт получит необходимый список серверов от RAS:
[fedotov@work ~]$ clstr_ctl.sh stop server_a Останавливаем сервера 1С Предприятия: * Останов сервера 1С Предприятия на server_a [ DONE ] * Останов сервера 1С Предприятия на server_b [ DONE ] * Останов сервера 1С Предприятия на server_c [ DONE ]
При этом будет создан файл server_a.stoped который будет содержать список серверов остановленного кластера. Этот файл необходим для последующего запуска серверов кластера, т. к. при остановленном кластере получить список серверов с RAS уже не удастся. В случае отсутствия данного файла, при попытке запустить сервера кластера, скриптом будет выдана ошибка:
[fedotov@work ~]$ clstr_ctl.sh start server_a ОШИБКА: не найден файл server_a.stoped!
При успешном запуске серверов кластера результат выполнение скрипта долженвыглядеть следующим образом:
[fedotov@work ~]$ clstr_ctl.sh start server_a Запускаем сервера 1С Предприятия: * Запуск сервера 1С Предприятия на server_a [ DONE ] * Запуск сервера 1С Предприятия на server_b [ DONE ] * Запуск сервера 1С Предприятия на server_c [ DONE ]
Файл server_a.stoped при этом будет удален.
В «ручном» варианте в качестве параметра скрипту необходимо указать имя файла, содержащего список серверов, которыми требуется управлять. Запуск скрипта будет выглядеть следующим образом:
[fedotov@work ~]$ clstr_ctl.sh start -f ./servers.list Запускаем сервера 1С Предприятия: * Запуск сервера 1С Предприятия на server_a [ DONE ] * Запуск сервера 1С Предприятия на server_b [FAILED] * Запуск сервера 1С Предприятия на server_c [ DONE ]
В приведенном примере при запуске сервера 1С Предприятия на server_b возникла ошибка, которая требует непосредственного вмешательства
администратора для расследования причин ее возникновения.
#!/bin/bash # # 1C Enterprise 8.3 Cluster Control Script # # (c), 2019, Alexey Y. Fedotov # # Email: fedotov@kaminsoft.ru # USER_NAME="usr1cv8"; SERVICE_1C="srv1cv83"; function print_status < echo -en \\033[60G case $1 in 0) echo "[ DONE ]";; *) echo "[FAILED]";; esac >function parse_parameters < while [[ $1 ]] ; do case $1 in -f) LIST_FILE=$2; shift 2;; -u) USER_NAME=$2; shift 2;; -s) SERVICE_1C=$2; shift 2;; (start|stop|restart) CMD_NAME=$1; shift; if [[ $!= "-" ]]; then SRV_NAME=$; SRV_PORT=$; shift; fi;; *) shift;; esac; done check_parameters; > function check_parameters < [[ -z $|| ( -z $ && -z $ ) ]] && echo "ОШИБКА: Не указаны необходмые параметры!" && exit 1; [[ -z $ && ! -s $ ]] && echo "ОШИБКА: Указанный файл списка серверов не существует или имеет нулевой размер!" && exit 1; [[ -n $ && $ == "start" && ! -s $.stoped ]] && echo "ОШИБКА: Указанный кластер серверов не был остановлен с помощью данного скрипта!" && exit 1; [[ -n $ && ( $ == "stop" || $ == "restart" ) && -s $.stoped ]] && echo "ОШИБКА: Указанный кластер серверов уже остановлен с помощью данного скрипта!" && exit 1; > function clstr_command < if [[ -n $&& $ == "stop" ]]; then SRV_LIST_CMD="G_VER_ARCH=$(grep -m 1 -oP '^G_VER_ARCH=\K(.+)' /etc/init.d/srv1cv83);\ /opt/1C/v8.3/\$/rac server list --cluster=\$(/opt/1C/v8.3/\$/rac cluster list $:$ 2>/dev/null |\ grep -m 1 -oP '^cluster\s+:\s\K(.+)') $:$ 2>/dev/null | tr -d [\ ] |\ grep -oP '((using)|(agent-host:))\K(.+)' | perl -pe '\$_=~s/(^[^:].+)\n/\1/'" SRV_LIST=$(ssh $@$ "$"); else SRV_LIST=$(cat $.stoped); rm -f $.stoped; fi [[ -z $ ]] && echo "ОШИБКА: Пустой список серверов кластера!" && exit 1; for CUR_SRV in $; do if [[ $ == "start" || $ == "stop" ]]; then case $ in start) echo -n "Запуск";; stop) echo -n "Останов";; esac echo -n " сервера 1С Предприятия на $:" ssh $@$ "sudo systemctl $ $"; SSH_RESULT=$?; print_status $SSH_RESULT; [[ $ == "stop" && $ == 0 ]] && echo $ >> $.stoped; [[ $ == "start" && $ != 0 ]] && echo $ >> $.stoped; fi done > parse_parameters $@; if [[ $CMD_NAME == "restart" ]]; then clstr_command stop; clstr_command start; else clstr_command $CMD_NAME; fi