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, решающих повседневные задачи администрирования.

Добавить комментарий