• Интеграция SCOM 2012 R2 и SCDPM 2012 R2 со сторонней системой ServiceDesk с помощью SCOrch 2012 R2

    Так уж получилось что в нашей компании используется система ServiceDesk не из состава System Center (я говорю о Service Manager). Возник вопрос об интеграции этого продукта с используемыми продуктами System Center, а конкретно с System Center 2012 R2 Data Protection Manager и System Center 2012 R2 Operations Manager. Первая задача по интеграции была следующая – необходимо отслеживать инциденты, возникающие в процессе резервного копирования, и регистрировать их в системе ServiceDesk.

    Первым делом были рассмотрены возможности нашей системы ServiceDesk – у нее обнаружился удобный REST API для взаимодействия. Общей шиной для взаимодействия был выбран System Center Orchestrator и именно этот выбор побудил меня написать эту статью (а может и цикл статей, посвященный Orchestrator, так как по нему не очень много статей на русском, да и вообще).

    Алгоритм работы процесса такой:

    1. Operations Manager собирает информацию обо всех алертах Data Protection Manager

    2. Orchestrator запускает каждые два часа RunBook в котором считывает все новые алерты из Operations Manager и создает на их основе инциденты в ServiceDesk, после чего обновляет алерты вписывая им номера инцидентов (TicketID) и меняя статус (ResolutionState).

    Итак, имея все исходные данные и алгоритм работы, остается только реализовать его в виде RunBook в System Center Orchestrator.

    Читать далее...

  • Перенос БД System Center 2012 Orchestrator на другой сервер

    imageРассмотрим ситуацию, когда все компоненты работающего экземпляра System Center 2012 Orchestrator (SCORCH) развернуты на одном виртуальном сервере под управлением Windows Server 2012 Standard с локальным экземпляром БД SQL Server 2012 Standard и возникла необходимость переместить базу данных SCORCH на отдельный кластеризованный экземпляр SQL Server. По мере эксплуатации сервера SCORCH стало очевидно что размер БД весьма мал и держать отдельный локальный экземпляр SQL Server на этом сервере несколько расточительно, особенно учитывая тот факт, что размер потребляемой оперативной памяти процессом SQL Server чуть ли не в 30 раз превышает размер файла единственной обслуживаемой этим процессом БД. В ходе обдумывания поставленной задачи стало понятно что в нашем случае для переноса БД воспользоваться инструкцией описанной в статье Migrate Orchestrator Between Environments не получится, так как она подразумевает перенос SQL Master Key с исходного SQL сервера на целевой, что в нашем случае невозможно, так как на этом экземпляре уже работает некоторое количество других БД по некоторым предположениям использующих уже имеющийся Master Key. Поэтому было решено отработать альтернативный сценарий переноса БД с использованием функций Экспорта/Импорта консоли Runbook Designer с проведением ряда дополнительных манипуляций для успешного решения поставленной задачи. 

    Читать далее...

  • SC 2012 Orchestrator – Ротация текстовых логов

    imageВстречаются приложения, которые генерируют определённое количество текстовых логов, но при этом не имеют встроенной функциональности для их ротации. Могут возникнуть проблемы с производительностью файловой системы и/или нехваткой свободного места если запись в лог-файл ведётся достаточно интенсивно и его размер вырастает до неприличных величин. Здесь я опишу пример создания рабочего процесса (Runbook) в System Center 2012 Orchestrator (SCO) для систематической ротации логов на удалённом сервере.

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

    • Ротации должны подвергаться файлы DBLog.txt, AppLog.txt, ErrorLog.txt
    • Процесс ротации должен выполняться 1 раз в сутки в 07:00
    • При условии что любой из указанных файлов становиться больше 100 MB, он должен быть переименован и заархивирован в отдельный каталог (подразумевается что приложение способно самостоятельно создавать свежий лог файл)
    • Архивы логов не должны накапливаться и храниться более года

    Результативный рабочий процесс будет выглядеть следующим образом:

    image

    Далее опишем свойства каждого этапа, то есть каждой активности рабочего процесса.

    1. Monitor Date/Time

    Создана из стандартной активности (Activity) Scheduling - Monitor Date/Time. Из настроек имеет лишь время суток в которое запускается рабочий процесс

    image

    2. Log File Paths

    Создана из стандартной активности System - Run .Net Script. В этой активности с помощью PowerShell мы задаём локальные переменные отвечающие входным параметрам нашей задачи. В нашем примере вводится три переменные:

    • $ArchiveNameSuffix – суффикс (с текущей датой и временем) который будет добавляться к имени лог-файла при переименовании
    • $ArchiveFolderPath – путь к каталогу в котором будут сохраняться заархивированные логи
    • $FullPathLogFilesArray – массив строк состоящий из полных имён лог-файлов которые мы будем подвергать ротации.

    image

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

    image

    Все последующие активности будут выполняться для каждого файла прописанного в массиве $FullPathLogFilesArray

    3. Get Log File

    Создана из стандартной активности File Management – Get File Status. В свойствах этой активности мы получаем подробные сведения о лог-файлах (размер, атрибуты). В качестве входного параметра File используем созданный нами ранее выходной параметр Full path log files array из предыдущей активности. Как я уже сказал, этот параметр будет содержать массив строк с полными путями к лог-файлам.

    image

    4. Log Size more than 100 MB

    Создана из стандартной активности Utilities – Compare Values. В свойствах этой активности на закладке General указываем тип сравнения – Compare Numeric Values

    image

    На закладке Details указываем, что значение входящего параметра File size (bytes) из активности Get Log File должно быть больше 104857600 байт.

    image

    То есть дальнейшая обработка рабочего процесса заканчивается, если не удалось найти ни одного файла размером более 100 MB

    5. Rename Log

    Создана из стандартной активности File Management – Rename File
    Если по результатам предыдущей активности найден хоть один файл больше указанного размера, то в этой активности мы переименовываем этот файл, добавляя к концу его имени суффикс который мы задали ранее. В поле Folder (папка в которой будут переименовываться файлы) используем значение выходного параметра File folder из активности Get Log File 

    image

    В таблицу правил переименования добавляем одно правило, которое значит то, что будет искаться файл с именем File name из активности Get Log File и переименовываться с добавлением суффикса. То есть например файл DBLog.txt будет переименован в DBLog.txt.2012-08-17_15-01-15.log

    image

    6.Compress Renamed Log

    Создана из стандартной активности File Management – Compress File. Активность предназначена для создания архива из переименованного лог-файла в предыдущей активности.

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

    В поле Folder (полный путь к файлу который будет архивироваться) указываем параметр Name and path of the destination file из предыдущей активности Rename Log

    image

    В поле File (полный путь к создаваемому архиву) указываем значение, сложенное из двух параметров разных предыдущих активностей:

    image 

    В результате этой активности файл вида DBLog.txt.2012-08-17_15-01-15.log будет заархивирован в файл DBLog.txt.2012-08-17_15-01-15.log.zip 

    7. Delete Renamed Log

    Создана из стандартной активности File Management – Delete File. Активность удаляет переименованный лог-файл после его успешной архивации на предыдущем этапе.

    В свойствах этой активности в поле Path (полный путь к удаляемому файлу) указываем ссылку на параметр Name and path of the destination file из предыдущей активности Rename Log

    image

    8. Delete Old Log Archives

    Создана из стандартной активности File Management – Delete File. Активность отвечает за удаление устаревших архивов.

    Указываем то что удалению подвергаются файлы с датой создания старше 365 дней.

    image

    В поле Path (полный путь к удаляемому файлу) используем два параметра из разных активностей для того чтобы составить маску имени удаляемых файлов в следующем виде:

    image

    Запускаем Runbook и проверяем результат.

    Такой Runbook можно считать универсальным, так как он подойдёт для ротации любых текстовых логов расположенных на разных серверах. Для адаптации к конкретной среде достаточно изменить значения входных переменных в активности Log File Paths.

    Только когда дописал заметку до конца, подумал, что значение максимального размера лог-файла и количество дней хранения тоже можно включить в список входных переменных PowerShell Улыбка