Программирование без программирования — System Center 2012 Orchestrator

Пост от Алексей Леготин | в категории System Center 2012 | добавлен 17-06-2012

1

 Orchestrator – это один из компонентов, который появился в новой версии System Center (2012). Он позволяет автоматизировать задачи, связанные с инфраструктурой сети, частного облака и т.п. Причем, как я отметил в заголовке, знания программирования для этого не потребуется.

Вообще говоря, автоматизация каких-либо рутинных процессов – это одна из задач системных администраторов (особенно "правильных", т.е. ленивых). Но часто админа написание чего-либо более серьезного, чем, скажем, нескольких команд PowerShell, повергает в уныние и стойкое нежелание это делать, ведь это получается программированием заниматься. Помочь справиться с этой "фобией", а также наиболее эффективно автоматизировать задачи в совокупности с другими компонентами System Center 2012, и призван Orchestrator.

Orchestrator (ранее, кстати говоря, он назывался Opalis) состоит из нескольких компонентов.

Основной из них – это Management Server – сервер управления. Системные требования достаточно скромные по нынешним меркам: Windows Server 2008 R2, RAM 1Gb (рекомендуется 2Гб и более), 200Мб на HDD и двухъядерный процессор Intel с частотой от 2,1ГГц. Также необходим установленный экземпляр Microsoft SQL Server 2008 R2 для хранения конфигураций Orchestrator.

Такие же требования предъявляются к Runbook Server – сервер выполняемых заданий (Runbooks). Вообще говоря, все компоненты Orchestrator чаще всего устанавливаются на один сервер, но некоторые компоненты, в частности, Runbook Designer, может быть установлен как на Windows Server 2008 R2, так и на Windows 7 (32 или 64-разрядную). Orchestrator web service устанавливается тоже только на Windows Server 2008 R2 и требует еще включенной роли Internet Information Services (IIS) 7.0.

Основной инструмент админа – это, конечно же, Runbook Designer. Именно в нем создаются наборы заданий, точнее даже, как бы собираются из "кубиков". Набор возможных операций разделен на группы. Посмотрим, как выглядит главное окно:

clip_image002

Рисунок 1. Runbook Designer – основное окно. Системные задания.

Группы показаны в правой части. Как видим, есть Activities (задания, или действия) – базовые операции, "кирпичики", из которых и может состоять целое задание (в терминах OrchestratorRunbook). В системной группе, как видим, есть действия по завершению какого-либо процесса, перезагрузке системы, запуску и остановке служб, запуску программ или сценариев .NET, и т.п.

В группе Scheduling (расписание) всего пара действий: мониторинг даты-времени и проверка расписания.

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

clip_image004

Рисунок 2. Runbook Designer – основное окно. Задания мониторинга.

В группе File Management, разумеется, находятся всяческие операции, которые можно проделывать с файлами: копировать, перемещать, даже производить зашифровку/расшифровку или печатать:

clip_image006

Рисунок 3. Runbook Designer – основное окно. Задания управления файлами.

В группе Email присутствует единственная операция – Send Email – отправить сообщение электронной почты получателю. 😉 Также группа Notification не слишком богата разнообразием – там находятся действия по уведомлениям – отправка системных сообщений или запись в системный журнал.

А вот в группе Utilities операций значительно больше, и разного плана. Наверное, потому и объединили таким общим словом. clip_image008

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

clip_image010

Завершают список групп, входящих в стандартный набор Orchestrator, действия по управлению заданиями (Runbook Control):

clip_image012

Как вы могли заметить на скриншотах, есть еще несколько групп, относящихся к компонентам System Center 2012. Сразу после установки Orchestrator их нет. Для их появления надо скачивать так называемые пакеты интеграции для Orchestrator. И туда входят не только все компоненты System Center, как свежей, так и более старых версий, но и пакеты интеграции для продуктов других разработчиков, не только Microsoft: IBM, HP, VMware… Описание существующих пакетов интеграции можно увидеть здесь: http://technet.microsoft.com/en-us/library/hh295851.aspx.

Более того, Orchestrator поставляется  с инструментом Quick Integration Kit (QIK), с помощью которого можно самостоятельно, на базе утилит командной строки или командлетов PowerShell, создавать свои наборы действий и пакеты интеграции.

Кстати говоря, методом тыка встроить в Orchestrator внешние пакеты интеграции у меня не получилось. Пришлось читать документацию. 😉 Оказалось не очень тривиально, для этой цели предназначен Deployment Manager, с помощью которого надо сначала зарегистрировать пакет интеграции на сервере управления (management server), а потом произвести развертывание (deployment) пакета интеграции на Runbook server:

clip_image014

Пакеты интеграции очень сильно увеличивают возможности Orchestrator, ведь с их помощью можно использовать в своих конструируемых заданиях все возможности других программ. Например, пакет интеграции с System Center 2012 Virtual Machine Manager позволит осуществить конструирование всевозможных операций с виртуальными машинами и хостами:

clip_image016

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

Запускаем Runbook Designer. Выбираем правой кнопкой мыши строчку Runbooks и делаем "New Runbook". Начинаем, как говорится, с чистого листа!

В панели Activities, в группе операций File Management находим задание Monitor File и перетаскиваем его на рабочее поле. Двойным кликом открываем свойства задания, в поле In Folder, выбираем путь к папке C:\Drop. Добавляем фильтр, в котором указываем, что соответствие — по имени файла и маска файла — *.txt.

clip_image018

Далее перейдем в окне свойств на пункт Triggers и ставим там галочку Created, что будет обозначать, что включится триггер создания файла, когда текстовый файл появится в папке C:\Drop.

clip_image020

Кликаем Finish.

Далее из группы File Management перетащим задание Copy File, А из группы Text File Management – задание Read Line. Создадим связь от Monitor File к Copy Line, "потянув" за соответствующую стрелочку. Аналогично создадим связь от Monitor File к Read Line.

clip_image022

Таким образом, мы создали последовательность (workflow).

Зайдем теперь в свойства Copy File. В разделе Source, в поле File кликнем правой кнопкой мыши и выберем Subscribe, затем Published Data:

clip_image024

Далее в колонке Name выберем Name and path of the file, что будет означать, что источником для Copy File будут имя и путь к файлу из задания Monitor File. В разделе Destination пропишем путь C:\Copy.

clip_image026

Кликаем Finish. Задание Copy File теперь сконфигурировано для копирования из папки в папку.

Теперь зайдем в свойства Read Line, аналогично в поле File правой кнопкой мыши выберем Subscribe и Published Data. И тоже выбираем Name and path of the file. В поле File Encoding выбираем Auto. В поле Line numbers пишем 1-END.

clip_image028

Кликаем Finish. Задание Read Line теперь тоже настроено.

В группе Text File Management находим операцию Append Line и тащим ее на рабочее поле. Затем образуем связь от Read Line к Append Line. В результате получится следующая картинка:

clip_image030

Далее заходим в свойства Append Line. В поле File пишем C:\Copy\Masterlog.txt. В поле File Encoding выбираем Auto. В поле Text жмем правой кнопкой и выбираем Subscribe и Published Data. В колонке Name выбираем Line text.

clip_image032

Задание Append Line теперь настроено на добавление строчек в файл C:\Copy\Masterlog.txt.

Теперь в панели Activities, раскрываем группу Runbook Control и перетаскиваем Junction на рабочее поле.  Создаем связи от Copy File и от Append Line к Junction.

clip_image034

Заходим в свойства Junction. В поле Return Data from выбираем Copy File. Таким образом, мы настраиваем данное задание возвращать те же данные, что и Copy File.

Ну и, наконец, вытащим из группы File Management операцию Delete File. Создадим связь от Junction к Delete File. Зайдем в свойства Delete File, в поле Path правой кнопкой и Subscribe, затем Published Data. В списке Activity выберем Copy File. В колонке Name выберем Name and path of the origin file.

В результате у нас получилась готовая конфигурация заданий:

clip_image036

Осталось только протестировать получившуюся конфигурацию. Кликаем кнопку Runbook Tester.

clip_image038

Устанавливаем точку прерывания на Monitor File и запускаем (Run). Задание Monitor File ожидает появления файла. Открываем Блокнот, набираем несколько строк и сохраняем в папку C:\Drop. После некоторого времени выполнения мы увидим нечто похожее на следующий скриншот:

clip_image040

В журнале (Log) показаны все выполненные задания, можно подробно посмотреть каждое задание, кликнув Show Details. Будет показываться нечто такое:

clip_image042

Ну и теперь нам остается только убедиться, что папка C:\Drop теперь пустая, а в папке C:\Copy теперь есть копия исходного файла и файл MasterLog.txt, в котором содержатся строчки из исходного файла.

Вот такой пример нехитрого скрипта, сделанного визуально. На самом деле сначала немного непривычно, но с опытом, я думаю, скорость "написания" определенных задач может существенно возрасти (по сравнению, скажем, с написанием решения подобной задачи на PowerShell). Так что остается только изучать Orchestrator далее и пробовать автоматизировать необходимые задачи. Да и даже выполнение некоторых действий, например, в Data Protection Manager, можно ускорить, например, создав Runbook, в котором производится создание группы защиты для сервера, в которую включаются все источники данных со всех томов сервера, состояние системы и существующие базы данных, а затем запускается создание точек восстановления. Выполнить такой Runbook (набор операций) в дальнейшем будет гораздо быстрее, чем производить все те же действия из родной консоли Data Protection Manager.

В общем, Orchestrator показался мне очень интересным продуктом, достойным дальнейшего изучения и использования. Чего и вам желаю! 😉

Полезные ссылки:

1) http://technet.microsoft.com/enus/library/hh237242.aspx – документация на Technet по System Center 2012 Orchestrator.

2) http://technet.microsoft.com/enus/library/hh295851.aspx – пакеты интеграции для Orchestrator.

3) http://www.microsoft.com/ruru/servercloud/systemcenter/orchestrator.aspx – официальная страница System Center 2012 Orchestrator на сайте Microsoft.



Комментарии (1)

Несомненно, оркестратор великая вещь. Однако есть у неё ряд недостатков:
1. Не все компоненты работают так как предпологается, например, Monitor Internet Application — не возвращает полностью страницу, каждый компонент нужно тестировать, благо есть тестировщик :).
2. Не каждый компонент имеет необходимое количество параметров.
3. Организация циклов и переменных просто ужасна!!!

Написать комментарий