gifts2017

Управление сервером приложений 1С с помощью PowerShell

Опубликовал Марат Биккин (squad) в раздел Администрирование - Системное

Примеры скриптов PowerShell для управления сервером 1С с помощью  менеджера COM-соединений
"Выгонялка" пользователей 1С, которая умеет:
1) устанавливать блокировку соединений ИБ
2) отсоединять сессии пользователей выбранной ИБ или выбранного кластера
3) перезапускать рабочие процессы выбранного кластера, если п.2 не помогает
4) рестартовать сервис агента 1С

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

В реальном мире перед администратором сервера приложений сразу же встает большое количество задач, решить которое можно только используя продвинутые методы интеграции. Такие как например менеджер COM-соединений сервера приложений. Описание его свойств и методом доступно в (страшно сказать) Синтакс-помощнике, в ветке Средства интеграции и администрирования -> Менеджер COM –соединений.

В то же время любимым продуктом администраторов серверов Windows для автоматизации различных рутинных процессов является PowerShell, который заменил устаревшие WSH\VBScript  скрипты и архаичные BAT-файлы, начиная с Windows Server 2003.

Осталось только объединить возможности двух «подсистем», написав скрипт на PowerShell, который будет управлять сервером приложений 1С, с помощью com-администратора. 

Первая и самая простая задача из «реального мира» – перезапуск сервиса «Агент сервера 1С» по расписанию (вернее стоп-старт с таймаутом, из-за особенностей работы агента сервера). На PowerShell это можно сделать по разному, например так:

Get-service "1C:Enterprise 8.2 Server Agent*" | stop-service

Start-Sleep -s 40

Get-service "1C:Enterprise 8.2 Server Agent*" | start-service

 В расписание, как обычно мы скрипт поставим в шедулере Windows.

Теперь вторая задача из «реального мира», уже посложнее.

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

Для PowerShell это тоже не слишком сложная задача:

# Сценарий разрывает все сессии пользователей во всех ИБ на выбранном кластере сервера приложений 1С
# Если часть сессий остается активными после этого, то он останавливает все рабочие процессы кластера

# Параметры запуска сценария: адрес сервера, основной порт кластера
$SrvAddr = "tcp://y001-ap-01:1640"

$MainPort = "5641"
########################################
$V82Com = New-Object -COMObject "V82.COMConnector"
# Подключение к агенту сервера

$ServerAgent = $V82Com.ConnectAgent($SrvAddr)
$ClusterFound = $FALSE
#Получим массив кластеров сервера

$Clasters = $ServerAgent.GetClusters()
foreach ($Claster in $Clasters)
{

if ($Claster.MainPort -eq $MainPort)
{
$ClusterFound = $TRUE
break
}
}

if (!($ClusterFound))
{
break
}

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

$ServerAgent.Authenticate($Claster,"","")

#получаем список сессий кластера и прерываем их
$Sessions = $ServerAgent.GetSessions($Claster)
write-host "Разрывается" $Sessions.Count "сессий..."
foreach ($Session in $Sessions)
{
$ServerAgent.TerminateSession($Claster,$Session)
}
if (($Sessions.Count -eq 0))
{
break
}

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

# Получаем список рабочих процессов кластера
$WorkingProcesses = $ServerAgent.GetWorkingProcesses($Claster)

foreach ($WorkingProcess in $WorkingProcesses)
{
if ($WorkingProcess.Running -eq 1)
{
write-host "Останавливаем процесс с PID =" $WorkingProcess.PID
#!!!здесь хорошо бы проверить что компьютер с которого запущен сценарий это выбранный в параметрах запуска сервер приложений 1С
Stop-Process $WorkingProcess.PID -Force

}

}

$V82Com = ""

 

Как видите в скрипте мы используем только методы объекта «Соединение с агентом сервера», т.е. работает на уровне кластера, а не на уровне конкретной информационной базы.

Так что следующей задачей будет например такая: поставить блокировку соединений на конкретную информационную базу. Это уже потребует использование объекта «Соединение с рабочим процессом» и аутентификации в конкретную ИБ.

# Сценарий устанавливает блокировку соединений в выбранной ИБ на выбранном кластере сервера приложений 1С

# Параметры запуска сценария: адрес сервера, основной порт кластера, информационная база

$SrvAddr = "tcp://y001-ap-02:1640"

$MainPort = "5641"

$InfoBaseName = "aspb4"

$V82Com = New-Object -COMObject "V82.COMConnector"

 # Подключение к агенту сервера

 $ServerAgent = $V82Com.ConnectAgent($SrvAddr)

$ClusterFound = $FALSE 

$InfoBaseFound = $FALSE              

#Получим массив кластеров сервера

 $Clasters = $ServerAgent.GetClusters()

foreach ($Claster in $Clasters)

{

 

if ($Claster.MainPort -eq $MainPort)

    {

    $ClusterFound = $TRUE    

    break

    }

}

if (!($ClusterFound))

  {

   break

  }

# Аутентификация к выбранному кластеру

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

# можно прописать ниже имя пользователя и пароль администратора кластера

 $ServerAgent.Authenticate($Claster,"","")

 

 # Получаем список рабочих процессов кластера

 $WorkingProcesses = $ServerAgent.GetWorkingProcesses($Claster)

                   

foreach ($WorkingProcess in $WorkingProcesses)

  {                    

    if (!($WorkingProcess.Running -eq 1) )

    {

        continue   

    }

  

   $CWPAddr = "tcp://"+$WorkingProcess.HostName+":"+$WorkingProcess.MainPort  

   $CWP= $V82Com.ConnectWorkingProcess($CWPAddr)

   $CWP.AddAuthentication("", "")

 

    $InfoBases =$CWP.GetInfoBases()

 foreach ($InfoBase in $InfoBases)

   {

   if ($InfoBase.Name -eq $InfoBaseName )

     {

       $InfoBaseFound = $TRUE    

       break

     }

   }

 

  if (!($InfoBaseFound))

  {

   write-host "Не найдена указанная в параметрах запуска ИБ..."

   break

  }

 

 # Устанавливаем блокировку соединений ИБ

 $InfoBase.ConnectDenied = $True

 $CWP.UpdateInfoBase($InfoBase)               

  } 

$V82Com = ""


Вы можете соединить возможности второго и третьего сценария и получить «абсолютное  оружие» для отсоединения пользователей от конкретной ИБ, для проведения каких-либо регламентных работ. 

Вообще обилие свойств и методов COM-администратора позволяет решать совершенно различные задачи,  а не только связанные с «любимой» задачей администраторов «выгнать пользователей» .

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

Или собирать статистику о соединениях на кластере, чтобы ответить на вопрос «куда ушли все свободные лицензии?» (нетривиальная задача в корпоративной системе с кучей терминальных серверов, большим количеством ИБ и клиентов).

 В итоге я надеюсь это статья поможет вам приблизиться к решению вашей «задачи из реального мира».


См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. Марат Биккин (squad) 24.05.12 08:11
Хотел бы добавить пару важных вещей, вроде бы понятных, но в статье это явно не написано:

1) Скрипт можно запускать с любого компьютера на котором установлены компоненты 1С Администрирование сервера.
Важно лишь только чтобы версии платформы на компьютере и на сервере при этом совпадали.
Ну и естественно, ели вы выполняете остановку рабочих процессов с помощью stop-process, то такой cmdlet имеет смысл выполнять только на самом сервере.

2) При установке сервера 1С по умолчанию список администраторов кластера пуст. И любой(!) пользователь может подключиться и использовать методы com-соединения.
Теоретически это дыра в модели безопасности которую может использовать злоумышленник.
Я бы рекомендовал сразу после установки "закрывать" эту дырку назначением администраторов кластера (сквозной аутентификацией к домену желательно чтобы не "потерять" пароль).
2. Александр Капустин (kapustinag) 25.05.12 11:36
...на постоянной основе получать объектные блокировки в конкретной ИБ ...

Актуальная вещь для нас сейчас, в связи с участившимися случаями блокировок при проведении документов.
С помощью каких методов и свойств это можно сделать? Удастся при этом получить метаданные заблокированного объекта, и даже представление объекта - если это конкретный документ, например?
3. Марат Биккин (squad) 25.05.12 12:35
(2) kapustinag,
Посмотрите в синтакс-помощнике свойство объекта Блокировка.
Можно запускать мониторинг этого свойства с небольшим интервалом (не более 5 сек), выгружать в текстовый файл, а потом консолидировать в Excel например и смотреть.
Это не слишком просто получается, проще конечно ЦУП пользоваться, если он есть.

Но вообще конечно поскольку ЦУП сам по себе создает нагрузку на продуктивную систему и не может применяться на постоянной основе, а блокировка вещь кратковременная и поймать её "вручную" сложно, для решения вашей задачи я бы посмотрел статистику по блокировкам на стороне СУБД (она собирается самим сервером, вы её просто используете).

Как это сделать ?
Если у вас MS SQL - почитайте про DMV, если DB2 - почитайте про Admin Routin Views.
4. Александр Капустин (kapustinag) 25.05.12 12:56
(3) squad,

Спасибо. На стороне сервера БД (у нас MS SQL) статистика есть, но там в обозначениях СУБД. Долго добираться до этого объекта в 1С. Попробую через свойства объекта Блокировка.
5. Марат Биккин (squad) 25.05.12 13:00
(4) kapustinag,
Ну что значит долго, существует N-ое количество обработок которые покажут вам структуру таблицы СУБД = метаданные.
Тот же Enterprise Integrator например.
Или эта: http://infostart.ru/public/96424/
6. Александр Капустин (kapustinag) 26.05.12 09:24
(5) squad,
Да, есть у меня одна из таких обработок, с Инфостарта когда-то раньше брал. Не EI. Показывает для объектов метаданных соответствующие объекты MS SQL. С ее помощью можно добраться до объекта, конечно. Хочется, чтобы обработка сразу показывала список заблокированных объектов ИБ, то есть чтобы не приходилось руками с помощью одной или нескольких доп.обработок определять, какой объект ИБ соответствует заблокированному объекту SQL.

По синтакс-помощнику посмотрел; есть надежда, что с помощью Блокировка.Object (выдает строку - Представление идентификатора заблокированного объекта базы данных) удастся получить то, что нужно. Буду пробовать.
8. Denis Zuev (Varies) 19.06.12 15:14
Спасибо. Этот метод выглядит более привлекательно нежели использование скриптов и батов.
9. Sergey Slepen (Slepen) 25.02.13 13:17
10. CHEBURASHKA (cheburashka) 01.10.13 12:27
Спасибо за подробное разъяснение, очень актуально.