• ИТ Вестник №06/07.2016

    imageПредставляем вашему вниманию очередной обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере. В связи с отпускной порой "вне зоны доступа" мне не удалось вовремя опубликовать Июньский обзор, поэтому данный обзор содержит в себе обновления сразу за два прошедших месяца – Июнь и Июль.

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

  • Интеграция 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.

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

  • Бесплатная книга Designing Orchestrator Runbooks

    image

    Стала доступна для скачивания новая бесплатная книга от Microsoft Press:
    Microsoft System Center - Designing Orchestrator Runbooks под авторством David Ziembicki, Aaron Cushner, Andreas Rynes.
    Книга содержит большое количество примеров применения Runbooks с обилием PowerShell-кода.
    Загрузить книгу на английском языке в электронном виде в разных форматах можно по ссылке
    Free ebook: System Center: Designing Orchestrator Runbooks

    Для читателей нашего блога копия книги доступна для загрузки также по ссылке.

  • Перенос БД 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 SP1 Orchestrator & SCOM IP - Failed to get Monitor…

    imageПосле обновления System Center 2012 Orchestrator до уровня Service Pack 1 заметил что перестала корректно работать задача, описанная в заметке SC 2012 Orchestrator – Режим обслуживания SCOM по расписанию. На этапе выполнения активности Start Maintenance Mode для каждого объекта полученного из SQL запроса к БД SCOM возникала ошибка:

    Failed to get Monitor. The exception was "An object of class MonitoringObject with ID 00000000-0000-0000-0000-000000000000 was not found.".

    image

    После изучения ситуации стало понятно, что в обновлённой версии Orchestrator изменилось представление объектов возвращаемых из SCOM для подстановки в поле Monitor для активности Start Maintenance Mode. Например если ранее значение выглядело так..

    Microsoft.Windows.Computer:KOM-AD01-RDS03.holding.com

    ..то после обновления оно стало выглядеть так..

    KOM-AD01-RDS03 : Microsoft.Windows.Computer:KOM-AD01-RDS03.holding.com

    Таким образом, для того чтобы описанная в ранее указанной заметке задача заработала, пришлось несколько изменить SQL запрос к БД SCOM:

    SELECT (TargetObjectDisplayName + ' : ' + TargetObjectFullName)

    FROM RelationshipGenericView

    WHERE isDeleted=0 AND SourceObjectDisplayName like 'KOM RDS Servers (VMs with App-V Client)'

  • System Center 2012 Orchestrator SP1

    imageСовсем недавно стал доступен Service Pack 1 (SP1) для линейки продуктов Microsoft System Center 2012. Попробую рассмотреть процесс обновления тех продуктов линейки, с которыми у меня есть возможность работать.

    Из документа Upgrade Sequencing for System Center 2012 SP1 можно понять, что в средах, где используется несколько продуктов линейки System Center 2012 важна правильная последовательность обновления этих продуктов до уровня SP1, а именно есть рекомендация соблюдать следующий порядок обновления:

    1. Orchestrator
    2. Service Manager
    3. Data Protection Manager
    4. Operations Manager
    5. Configuration Manager
    6. Virtual Machine Manager
    7. App Controller

    В этой заметке мы рассмотрим первый пункт этой последовательности – обновление System Center 2012 Orchestrator (SCO) до уровня SP1.

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

  • 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 Улыбка

  • SC 2012 Orchestrator - Режим обслуживания SCOM по расписанию

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

    Итак, жила-была ферма Remote Desktop (RD) Connection Broker состоящая из трёх виртуальных серверов RD Session Host на базе Hyper-V, которые обслуживали пользователей в рабочее время и без каких-либо проблем подвергались резервному копированию с помощью System Center 2012 DPM в нерабочее время. И всё бы ничего если бы не возникшая необходимость начать использовать на этих виртуальных серверах клиента Application Virtualization Client (App-V) for Remote Desktop Services. Клиент то конечно установился и прекрасно справляется со своей задачей – виртуализацией в многопользовательской среде весьма специфических приложений, требующих от пользователей расширенных привилегий в системе. Но вот незадача…сразу после начала использования клиента App-V я заметил две вещи: во первых - на DPM пропала возможность нативно на горячую с помощью метода Backup Using Child Partition Snapshot бэкапить виртуальные сервера фермы полноценно используя VSS (осталась доступной лишь возможность бэкапа с помощью Backup Using Saved State), а во вторых – при бэкапе в режиме Save State каждую ночь фиерично разваливался кластерный экземпляр службы RD Connection Broker. По сути вторая проблема является прямым следствием первой. Но это стало ясно позже...А пока я взялся за изучение проблемы систематично разваливающегося кластера RDS…

    Резервное копирование виртуальных серверов (нод кластера) выполнялось в 3.00 каждую ночь и как раз в это время происходил развал кластера. При этом в логе серверов фиксировалось довольно занятное событие:

    Event ID:10 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' disconnected.

    …и затем буквально через пару минут…

    Event ID: 9 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' connected.

    image_thumb2

    Стало очевидно что в процессе создания резервной копии виртуального сервера методом Save State происходит фактически его кратковременное “замораживание”, что влечёт за собой кратковременную потерю сетевого соединения, и как следствие, приводит к коллапсу службы кластера…Ох уж мне этот Save State… Но почему же исчезла возможность бэкапа на горячую с помощью снапшотов?… Колупание недр интернета привело к мысли о том, что в такой “неполноценности” с точки зрения DPM, виноват виртуальный диск который создаётся в системе для нужд клиента App-V.

    image_thumb1

    Натолкнувшись на заметки Deutscher App-V Blog - App-V und VSS–Backup oder kein Backup… и Gridmetric Blog - Enabling (service) process access to App-V virtual environment пришёл к выводу о том, что между VSS и виртуальным диском App-V какая то давняя врождённая нелюбовь, вызванная, на мой взгляд, аскетичностью архитектуры последнего. Обнаружил на своих виртуальных серверах то, что vssadmin действительно не может получить полный список томов

    image_thumb

    Воспользовался рецептом описанным в немецком блоге, разрешив провайдеру VSS доступ к виртуальному тому App-V c помощью ключа реестра:

    [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5ClientAppFSServiceInclusions]

    "VSS"="swprv" (STRING)

    swprv в данном случае это имя процесса Microsoft Volume Shadow Copy Service software provider. После изменения реестра и перезагрузки виртуальных серверов стало понятно, что ошибка с vssadmin исчезла, но он всё равно не воспринимает виртуальный том App-V как что-то съедобное, и причиной того вероятно является тип файловой системы этого самого тома…

    Надеясь поставить точку в этом вопросе, создал обращение в тех.поддержку MS, изложив всю фактуру происходящего и расписав все проделанные манипуляции в попытках самостоятельно разобраться с проблемой. Результатом стал удручающий ответ с европейского саппорта, подтверждающий мои предположения и не имеющий решения (инцидент был закрыт без списания). Ну что-ж…будем ждать следующей версии App-V и надеяться на то, что ситуация в дальнейшем измениться к лучшему… А пока как-то надо работать дальше и что-то делать с пачкой алертов приходящих от Operations Manager (SCOM) в почту каждое утро после очередного ночного краха кластера.

    Логичным решением подавления генерации алертов SCOM конечно является перевод ресурсов кластера в режим обслуживания (Maintenance Mode) на время выполнения резервной копии. Но штатными средствами SCOM не позволяет выполнять запланированный перевод в режим обслуживания (в будущем времени). Поиск нештатных способов привёл к инструменту Maintenance Mode Scheduling Tool разработанному под SCOM 2007. Сразу смутили попадающиеся в интернете сообщения о глючности данной тулзы, и такие “особенности” как неперевариваемость non-EN локали. И несмотря на утверждения, встречающиеся на формах TechNet, о том, что утилита работает с SCOM 2012, у меня так и не получилось добиться от неё адекватного поведения.

    Далее виделся один путь – использовать командлеты Powershell от SCOM в связке с планировщиком заданий Windows Scheduler. На глаза попадались решения типа OpsMgr 2012: Group Maintenance Mode via PowerShell (the way it should be) но хотелось сделать что-то своё – более гибкое и универсальное, и тут я вспомнил про то, что недавно читал какой-то обзорный материал про возможность управления объектами SCOM из System Center 2012 Orchestrator (в прошлой жизни Opalis). Стало понятно что пора знакомится с этим продуктом Улыбка

    В общем-то здесь и кончается предыстория и начинается история использования Orchestrator.

    Заострять большого внимания на развертывании сервера Orchestrator со всеми необходимыми компонентами, в том числе SQL Server, наверно особого смысла нет, так как эта процедура не должна вызвать особых сложностей. Собственно системные требования к серверу можно найти здесь TechNet Library - System Center 2012 – Orchestrator. Единственное, что вызвало у меня затруднения - это выбор редакции SQL Server, так как в текущем варианте документации есть информация лишь о требовании к версии (Microsoft SQL Server 2008 R2) и Collation (SQL_Latin1_General_CP1_CI_AS). Требование к редакции удалось найти только в документации к Opalis, где сказано что редакция SQL Express не поддерживается и необходима как минимум редакция SQL Standard. Итак, был развёрнут отдельный виртуальный сервер на котором было выполнено:

    • Установка SQL Server 2008 R2 Standard с набором компонент: 
      - Database Engine
      - Client Tools Connectivity
      - Management Tools - Complete
      Порядок сортировки -
      SQL_Latin1_General_CP1_CI_AS
    • Установка System Center 2012 Orchestrator с настройками по умолчанию с полным набором компонент:
      - Management Server
      - Runbook Designer
      - Runbook Server
      - Web Features

    После установки открываем консоль Orchestrator Deployment Manager и сначала импортируем загруженные пакеты интеграции System Center 2012 – Orchestrator Component Add-ons and Extensions (System_Center_2012_Orchestrator_Integration_Packs.EXE), а затем в этой же консоли выполняем Deploy этих пакетов, чтобы они стали нам доступны в консоли Runbook Designer

    Возможно вам окажется полезной пошаговая инструкция от Кевина Холмана Orchestrator 2012: a quickstart deployment guide

    Для нашей задачи важно чтобы был загружен пакет интеграции SCO для SCOM. После его загрузки в консоли Runbook Designer нам станет доступ набор активностей (Activities) этого пакета. Перед началом использования этих активностей при построении нужных нам цепочек Runbook, необходимо настроить глобальные параметры подключения SCO к экземпляру SCOM. Сделать это можно через меню Options > SC 2012 Operations Manager

    image

    Для того чтобы успешно произвести настройку параметров подключения к SCOM необходимо установить на сервер SCO консоль Operations Manager (не забываем также прикрутить к ней последний CU/RU). Задаём имя сервера SCOM и учётные данные пользователя входящего в роль администраторов Operations Manager (я создал для этих целей специальную сервисную учетную запись). После установки параметров проверяем подключение и если оно прошло успешно, то можно приступать к процессу создания Runbook

    image

    В нашем примере Runbook будет состоять из довольно простой цепочки активностей.

    image

    На первом этапе мы ждём кода наступит определённое время суток. Используем для этого активность Monitor Date/Time из раздела Scheduling. В настройках этой активности задаём только один параметр – время запуска.

    image

    На втором этапе выполняется запрос параметров из базы данных SCOM с помощью активности Query Database из раздела Utilities. В свойствах активности на закладке Details укажем содержимое SQL запроса:

    SELECT TargetObjectFullName

    FROM RelationshipGenericView

    WHERE isDeleted=0

    AND SourceObjectDisplayName like 'RDS Servers (VMs with App-V Client)'

    ORDER BY TargetObjectFullName

    image

    Запрос выполняет выборку объектов включённых в специально созданную группу SCOM по имени этой самой группы. В эту группу по правилу явного членства (Explicit Members) включены три ноды кластера (как объекты класса Microsoft.Windows.Computer) и кластерные группы страдающие при распаде кластера (объекты класса  Microsoft.Windows.Cluster.Group)

    image

    Вернёмся к свойствам активности Query Database. На закладке Connection указываем тип базы данных, тип аутентификации, имя сервера и имя БД SCOM (по умолчанию используется OperationsManager)

    image

    На закладке Security определяемся с тем от имени какой учетной записи  будет происходить подключение к БД SCOM. Можно использовать учетную запись службы SCO или же специально созданную сервисную учетную запись, которая, как вы понимаете, должна входить в группу роли администраторов SCOM

    image

    Связываем между собой первую и втору активность с помощью соединителя (Link) с помощью мыши:

    image

    Далее создаём третью активность Start Maintenance Mode из раздела SC 2012 Operations Manager. И сразу создаём соединитель с предыдущей активностью

    image

    В свойствах последней активности на закладке Details с помощью кнопки обзора выбираем ранее созданное глобальное подключение к серверу SCOM. В поле Reason с помощью кнопки обзора выбираем причину перевода объектов в режим обслуживания. В полях Duration и Comment соответственно указываем продолжительность активации режима обслуживания и произвольный комментарий.image

    Подробней остановимся на поле Monitor в котором собственно и нужно указать тот объект/объекты для которых будет включаться режим обслуживания. Если пользоваться кнопкой обзора для этого поля, то откроется не очень удобное окно выбора среди всех полученных из SCOM объектов. Нас эта кнопка не интересует и мы воспользуемся механизмом передачи параметров между активностями, чтобы вставить в это поле значение SQL запроса полученного в активности Query Database. Для этого, наведя курсор на это окно, откроем контекстное меню и выберем пункт Subscribe > Published Data

    image

    Суть в том, что каждая активность в цепочке имеет свои выходные данные (Published Data) которые можно использовать в последующих активностях цепочки. В нашем случае мы должны выбрать выходные данные SQL запроса и параметр хранящий результат запроса - Full line as string with fields separated by ';'

    image

    После этого можно считать, что наша примитивная логическая цепочка выстроена, и теперь мы можем запустить её на постоянное исполнение, нажав на верхней панели инструментов кнопки Check In а затем Run. После этого мы можем наблюдать за результатом выполнения каждой активности в цепочке с помощью окна Log History

    image

    Удалённо можно управлять Runbook и просматривать результаты выполнения с помощью веб-консоли SCO, опубликованной в конфигурации по умолчанию на порту 82

    image

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