IT Camp: управление жизненным циклом приложений

В докладе Александра Шаповала рассматриваются вопросы развертывания и обновления приложений на основе System Center 2012 Virtual Machine Manager, а также мониторинг приложений с помощью System Center 2012 Operations Manager.

Для того чтобы применять единый подход к развертыванию мониторингу, обновлению приложений в рамках private или tablet cloud, нам нужно каким-то единым образом эти приложения развертывать в нашей инфраструктуре. И вот, собственно, концепция, которую мы здесь предлагаем – она, в первую очередь, и направлена на то, чтобы постараться абстрагировать приложения от операционной системы. Сделать так, чтобы мы могли поднять виртуалку, установить в ней нужную ОС и накатить виртуализационный пакет, который поднимется в этой виртуальной машине и предложение тем самым готово для использования. Да, у нас остается по-прежнему стандартный вариант развертывания приложений. Когда у нас есть дистрибутив, мы подняли виртуальную машину, написали какие-то скрипты, которые запустятся с нужным тактом, ключами, параметрами, подставят какой-нибудь файлик ответа и ответит на все вопросы установщик – это все возможно, но такой вариант развертывания обладает целым рядом ограничений. И с точки зрения создания этих ответов, и для некоторых приложений этого нельзя сделать и для того, чтобы обновить это приложение нужно писать очередной скрипт и так далее. Возможность абстрагирования приложений с помощью технологии виртуализации приводит нас к тому, что у нас есть виртуальная машина, у нас есть операционная система, у нас есть приложения и в принципе, поскольку эти уровни абстрагированы друг от друга, если нам нужно обновить приложение, мы подготовили виртуализационный пакет, который содержит новую версию, и заменили его в виртуальной машине. Если нам нужно обновить операционную систему, мы этот пакет запустили на другой виртуальной машине, выключили эту, поменяли ОС, впустили и вернули приложение обратно. Абстракция здесь как раз помогает существенным образом придать гораздо большей динамики работы с приложениями в рамках System Center. Эта абстракция в System Center 2012 реализуется инструментом Server App-v, который является virtual mashing manager 2012 и позволяет создать виртуализационный пакет приложений, который включает все бинарные файлы этого приложения, нужные ветки реестра, состояния приложения и так далее.

Для того чтобы осуществлять развертывания приложений по выверенной проверенной процедуре, нам нужно понимать, какое состояние приложений является целостностным, согласованным. Если приложения многоуровневые, которые затрагивают базу данных, которые затрагивают веб, интерфейс и мы хотим это приложение развернуть в нашем центре обработки данных, то запуская одну машину, запуская вторую и третью машину, мы должны убедиться, что все слои поднялись, они нормально друг с другом соединились, нет никаких проблем и только после этого можно считать, что приложение готово и может быть, доступным для наших заказчиков. Не имея подхода, который мы уже упоминали с помощью сервисного шаблона, сделать это гораздо тяжелее. Имея сервисный шаблон, VMM как бы видит шаблон сервиса картинку, понимает, из каких частей приложение состоит и можно проверить, что каждое из этих частей запущено и отработано.

Мониторинг. После того как приложение запущено хотелось бы осуществлять достаточно детальный мониторинг работы этого приложения и это можно сделать средствами operations manager. Если это приложение является приложением dot net, то новые модули в рамках operation manager 2012 позволяют мониторинг осуществлять очень глубокий. Не только мониторинг того, что все в порядке с операционной системой, где запущено приложение, все в порядке с виртуальной машиной, в которой эта операционная система запущена и что происходит в самом приложении. Если она тормозит, то она тормозит почему? Потому что мы видим, что появились сиквельные запросы к базе данных, которые это приложение использует. А сиквелы это отмечают медленно. Мы видим это при мониторинге приложений и тогда нам понятно, что корень зла находится где-то там, в сиквельной базе. Хотя с точки зрения сиквела, так какового, все в порядке, как работал, так и работает.

И, наконец, контроль. Раз у нас есть стандартный способ развертывания приложений, мы, естественно, не хотим прийти к ситуации, когда кто угодно взял шаблон сервиса и на его основе развернул виртуальную машину. Мы должны контролировать, кто конкретно, на основе каких шаблонов, какие виртуалки может и не может запускать, что он с ними может делать. И для этого также есть инструмент, который называется add controller. В одной из предыдущих презентаций, мы смотрели, как мы делегируем полномочия и потом этими полномочиями пользуемся средствами самого VMM 2012, это возможно. Но add controller предоставляет гораздо более спектр возможностей, в том смысле, что вы можете получать доступ, развертывать приложения, копировать ресурсы, как в вашем частном облаке, так и в публичном облаке. И мы по этим пунктам сейчас с вами сейчас пройдемся. Но для того, чтобы разбирать все эти компоненты, давайте посмотрим, как выглядит жизненный цикл приложения в нашей схеме, в нашей концепции.

Мы начинаем со спецификации приложения, понимая, какие требования для этого приложения существуют, какие операционные настройки необходимы, компоненты Windows для того, чтобы это приложение нормально функционировало. Проанализировав эту информацию, можем сформировать шаблон, тот самый шаблон сервиса, в котором можем описать, как выглядит модель этого приложения, какие ресурсы, какую конфигурацию можно запустить для того, чтобы приложение нормально функционировало. После того, как этот шаблон создан он публикуется и становится доступным, в том числе и через тот самый application controller и, соответственно, владельцы предложений с соответствующими полномочиями, зайдя на application controller, могут запустить развертывание приложений на основе одного из имеющихся шаблонов. После того, как мы настроили развертывание шаблона, мы запустили развертывание этого сервиса VMM и после того, как это приложение начинает работать, нам нужно осуществлять его мониторинг, во-вторых, с течением времени видимо обновлять, применять к нему фиксы, если это необходимо, обновлять до новой версии и так далее. И этот цикл может повторяться сколько угодно раз.

И давайте по шагам по этому циклу пройдемся. Начнем мы с описания приложения с помощью шаблонов сервиса. В рамках шаблона мы можем указать, из каких слоев, если их там много состоит наше приложение и что с точки зрения инфраструктуры, с точки зрения VMM в каждом из этих уровней, в каждом из этих слоев должно быть. Описав, создав такой шаблон, мы публикуем его в библиотеке VMM. И, как я уже сказал, определенный компонент этого шаблона, как, например, профили ОС и профили оборудования – это достаточно понятные шаблоны, в которых указываются те или иные настройки, связанные с оборудованием виртуальной машины и настройками ОС. И есть профили приложения, которые требуют более детального рассмотрения, более подробного описания.

Давайте посмотрим, структура профиля приложения. Что в профиле приложения VMM 2010 указывается? Первое – это совместимость, наиболее, наверное, простой вариант конфигураций настройки. В профили приложения VMM вы указываете, какие ОС вашем приложением поддерживаются для того, чтобы, когда это приложение вы пытаетесь развернуть, VMM четко понимал, что виртуальную машину, которую нужно создать и запустить для этого приложения внутрь нужно развернуть ОС, вернее поднять виртуальную машину с ОС такой-то и такой-то. Например, поддерживается Windows 8, не поддерживается Windows 2003. Дальше в профили приложения мы указываем конфигурационную информацию. Конфигурационную информацию для самой ОС. Если в ОС нужно поднять какие-то роли, добавить какие-то компоненты, стандартные в профиль необходимые, то указать. Если приложение требует подключения к сиквельной базе, мы должны указать в профиле приложения, каким образом это подключение к базе осуществляется и там же в структуре профиля задаются различные параметры, как ключ продукта, если нужно развернуть какое-то приложение, пароль администратора и так далее. И еще одна часть профиля приложения – это скрипты. Pre скрипты, post скрипты. То есть, то, что нужно сделать до развертывания приложения внутри этой виртуальной машины и то, что нужно сделать после того, как мы это приложение туда развернули. Вся эта информация и составляет наполнение профиля приложения, и структура этого профиля приложения немного отличается в зависимости от того, для какого уровня, для какого слоя мы этот профиль создаем. Это сиквельная база, это уровень на котором будет сиквел запущен, это бизнес логики или это веб-сервер.

С точки зрения сиквела. Если это профиль приложения для виртуальной машины, в которой будет разворачиваться сиквел сервер. Здесь задаются все необходимые конфигурационные данные для того, чтобы должным образом сконфигурировать сиквел сервер, начиная с требуемой конфигурации – это дефолтовая инсталляция сиквела или это какой-то новый экземпляр, редакция, ключ продукта. Дистрибутивные файлы, режим безопасности сиквела, конфигурация сетей и так далее. Режим аутентификации, смешанное или Windows аутентификация сиквела. Целый набор параметров, включая учетные записи подключения, включая самой службы сервера. Вот эту информацию в рамках шаблона приложений вы можете задать и использовать с дальнейшим при развертывании своих сервисов, своих приложений. Причем мы можем столкнуться с ситуацией, когда подготовив те или иные компоненты для запуска приложений, как то профили, которые мы с вами сформировали, шаблоны сервисов, сервисные шаблоны и vhd файлы. Нам необходимо использовать эти ресурсы в различных точках. Например, в удаленном офисе. В идеале на другой площадке и так далее. Такая возможность также предоставляется средствами System Center 2012, и она может быть реализована, на двух уровнях. Во-первых, администратор может настроить синхронизацию между экземплярами VMM в центральной студии или в какой-нибудь филиальной площадки. Используя стандартные средства синхронизации, которые доступны в Windows. Это может быть dfs, скрипты, это может быть оркестратор в составе System Center 2012, где мы создаем процедуру round book, которая с определенной периодичностью синхронизирует содержание library в шар конкретных на VMM. Но, кроме того, в System Center 2012 синхронизацию ресурсов, если вы, таким образом, эти полномочия раздадите и настроите, может осуществлять сам владелец приложения. Если он понимает, что приложения подобного типа нужно будет разворачивать не только здесь, но и на удаленные площадки, то, соответственно, есть возможность через add controller, просто в режиме copy past сказать: «Я хочу, чтобы все компоненты вот этого шаблона или приложения были также доступны на втором, третьем другом экземпляре VMM». При этом веб-контроллер, пользователь просто использует copy-past, но, а за сценой, что называется VMM, передает эту информацию в нужную библиотеку и при этом может поступать достаточно интеллектуально. Например, если в библиотеке VMM уже содержатся vhd файлы с образами виртуальной машины такие, которые нужны этому приложению, то нет смысла копировать этот vhd файл с одного экземпляра VMM на другой. И при копировании пользователь просто увидит окно, в котором мы скажем: «Вот эта компонента на сервере назначения уже присутствует, давайте мы просто сделаем ремакинг». И при копировании VMM изменит шаблон приложения сам для того, чтобы указать ему, что этот vhd файл или вот этот виртуализационный пакет приложения нужно брать из этого пути.

Я постараюсь сейчас кратко проиллюстрировать этот процесс. И заодно мы с вами посмотрим лишний раз на application controller. Перед вами консоль компонентов System Center 2012, которые называются System Center add controller. Это silver light приложение. Красивое и интересное. Здесь можно видеть под каким логином вы подключились к ресурсам. Что самое важное хотел бы здесь отметить, уже на этом дашдборде вы видите, что add controller предоставляет вам доступ, как к ресурсу частных облаков. И здесь конкретный пользователь увидит, что ему доступны два облака вот с таким количеством ресурсов в терминах виртуальных машин, процессоров и так делает. Также вы видите, что есть три подписки на подключение к публичным сервисам, доступ к которым также имеет этот пользователь и с этого единого портала, с этого приложения он может управлять, как ресурсами частного облака в рамках тех полномочий, которые ему предоставлены. Наша с вами задача – переместится в библиотеку и опять же здесь пользователь увидит ровно те компоненты библиотеки, на которые у него есть полномочия, в соответствии с сервисными шаблонами и с помощью add controller мы можем выполнять операции копирования, как в публичном облаке, так и в рамках нашей инфраструктуры центра обработки данных. Например, мы можем с вами увидеть, что здесь есть два файла. Это конфигурационные файлы приложения Windows Azure, мы можем, чтобы они подготовлены были, например, в отделе разработки организаций, пользователь может теперь скопировать их непосредственно в публичное облако Windows Azure подписку продакшн. Соответственно, эти файлы передаются Windows Azure и располагаются там в соответственном хранилище Windows Azure и все готово для того, чтобы на основе этих конфигурационных файлов развернуть новое приложение в публичном облаке. Примерно похожим образом может поступать потребитель наших сервисов и с ресурсами частного облака. В частности в разделе template, на сервере VMM 01 Крис имеет доступ вот к этим сервисным шаблонам. В частности здесь вы видите шаблон приложение 3d сервис версии 1,5 и то, что может сделать он – это просто скопировать данный шаблон, перенести на второй экземпляр сервера VMM и выполнить операцию paste. Но VMM выполняет ту операцию копирования в контексте, он прекрасно понимает, что речь идет не просто о копировании файла шаблона, а копировании всех ресурсов, которые связаны с этим приложением, иначе это приложение на другом экземпляре это приложение просто не поднять. И поэтому перед нами структура данного приложения для того, чтобы мы смогли оценить, какие компоненты мы уже на сервере получателя присутствуют и копировать их нет смысла, какие компоненты нам в рамках этого приложения, тем не менее, надо копировать и, соответственно, для каждого из них мы можем выбрать копирование или mapping, сопоставление с новым расположением в рамках VMM. И после того как мы по всем этим пунктам прошлись, мы получаем mapping. Мы получаем полностью готовую картину для копирования, нажимаем OK и соответственно VMM выполняет перенос копирования или remapping тех ресурсов приложения, которые нам необходимы. После чего на втором VMM сервере мы получаем все необходимые ресурсы нашего приложения, включая профиль оборудования, профили приложения, необходимые vhd файлы для запуска виртуальных машин.

Далее. Посмотрим, как с помощью add controller и VMM может выглядеть развертывание приложений, как в частном, так и в публичном облаке. Для того чтобы получить максимум от System Center 2012 в плане развертывания установки приложений, мы предлагаем механизм виртуализации приложений Server App-v, которые является частью VMM 2012. С помощью App-v вы фактически полностью создаете виртуализационный пакет приложения, который в дальнейшем необходимо развернуть. Те из вас, кто работал с App-v клиентской частью, представляет, как это выглядит. Для тех, кто ни разу не сталкивался, поясню, как эта виртуализация приложения работает. Для этого необходима машина с чистой ОС, с установленной windows, на которой нет ничего лишнего. На эту машину помещается компонента App-v, вы запускаете так называемую компоненту, которая будет смотреть, что происходит в момент установки приложения: куда она пишет реестр, какие бинарные файлы, в какую папку она вкладывает, то есть, каждый шаг по установке этого приложения она отслеживает. Затем после того как установка завершена и сиквенсер, та самая компонента App-v, собрала необходимую информацию, она попросит запустить приложение, для того чтобы проанализировать, что делает приложение в момент запуска, что он там развертывает, меняет ли она что-то при этом в реестре для запуска и так далее. И собирая эту информацию, сиквенсер формирует некий файл, в который включены бинарные составляющие этого приложения, те ключи реестра, которые меняются в процессе установки – вся информация, которая нужна для работы этого приложения и мы получаем вот этот виртуализационный пакет, который теперь мы можем просто развернуть на другой машине с этой операционной системой, и приложение просто стартует. Нам не нужно инсталлировать ее в привычном понимании на эту операционную систему, мы просто туда развернули этот пакет, потому что, когда это приложение запускается – все, что ей необходимо для работы: и бинарные файлы, и ключи реестра, и соответствующие службы Windows – присутствует здесь, внутри этого пакета. Вот в таком виртуальном режиме приложение совершенно легко разворачивается внутри виртуальной машины и, как следствие, вы понимаете, если нам нужно сделать обновление этого приложения, мы просто запустили сиквенсер, запустили новую версию, получили новый бинарный пакет и можем его переместить в нужную виртуальную машину. Подготовив такой виртуализационный пакет Sever App-v нам необходимо сформировать шаблон сервиса, задать в нем необходимые настройки, указать, какой пакет App-v нам нужно использовать, где он лежит. Он, естественно, помещается в библиотеку VMM. И если в процессе эксплуатации нам нужно это приложение обновить или применить какие-то сервис паки, совсем необязательно это делать на ходу в приложении, которое внутри виртуальной машины запущено. Нам нужно развернуть это приложение на тестовой эталонной системе, применить этот packs, сиквенсер отследит, какие изменения произошли и мы получим новую версию виртуализационного пакета, который просто-напросто внедряем в виртуальную машину.

Если при этом наше приложение является многоуровневым и написано таким образом, что умет работать с несколькими экземплярами мы можем прийти к ситуации, когда приложение обновляется вообще без какого-либо простоя. Если нам нужно обновить, например, ОС, на которой запущена веб-служба и таких экземпляров виртуальных машин с веб-сервером, принимающих запрос от клиента у нас запущено, как минимум два, то мы можем одну из этих виртуальных машин выключить, приложение продолжает функционировать за счет оставшегося экземпляра. При этом нагрузка на эту виртуальную машину сейчас возрастет, но приложение продолжает работать. Один экземпляр мы выключили, заменили ОС или установили систему с service pack, поместили туда нужный пакет, но мы его подняли. Вопрос был, чем отличается от кластера? Принципиальное отличие заключается в том, что вот этот же вариант вы можете приводить самим приложением не только с ОС, которая запущена внутри виртуальной машины, но и самим вашим application. И постепенно обновляя нужные виртуализационные пакеты на всех виртуальных машинах, которые составляют приложение, вы динамически приходите к новой версии этого приложения. Вот таким образом этот апдейт и реализуется, без shut down всего приложения и прерывания сервиса. Можно так это назвать, как portable soft. Можем ли мы при помощи server App-v создать виртуализационный пакет этого приложения? Если да, мы идем по этой схеме. Как узнать, можно или нельзя? Если add приложение Microsoft, где мы говорим, что exchange не виртуализируется App-v. Если это офис, то легко виртуализируется, и вы внедряете этот офис с различными конфигурациями. Если это приложение не Microsoft, но оно вам нужно, вы берете этот сиквенсер и проверяете, какой виртуализационный пакет он создаст. Этот пакет работает корректно или нет. Если да, вы протестировали и убедились, что все работает, вы его получили и используете. Если речь идет об организации вот такого развертывания каких-то стандартных сервисов ОС для того App-v не нужен. Вы просто поднимаете виртуальную машину с windows и включаете нужный сервис. И, как я уже говорил, в шаблоне, в профиле ОС вы можете просто теперь сказать: «Мне нужны вот эти компоненты windows». Вам VMM сам их даже поднимет, когда это произойдет. Эта технология, прежде всего, затрагивает приложения, а будет ли оно работать с помощью App-v, есть единственный способ – это проверить. Будут ли теряться специальные настройки при обновлении приложения? Здесь идея такая, если эти настройки, грубо говоря, привязаны к этому экземпляру приложения, она сохранила в этой ОС, то да, они пропадают. Тут чудес не будет. Мы получим свежую инсталляцию новой версии, если в этих терминах говорить, но просто мы тут упираемся в вопрос, что это приложение делает. Если это приложение, к которому подключаются пользователи и настройки этих профилей пользователей сохраняются на сервере, и мы обновили виртуализационный пакет, то мы можем их потерять, хотя, на самом деле, здесь тоже может быть и да и нет. Потому что виртуализационный пакет, если он настроен правильным образом, когда поднимается новая версия, он может сохранять новые версии состоянием этого приложения и их отрабатывать. То есть, произойдет это или нет, это сильно зависит от приложения от того, что в этих профилях и папках сохраняет и как надо потом это использовать, и поэтому может быть так, а может быть не так. Если, например, это приложение, к которому обращаются пользователи, задают какие-то настройки этого приложения, но эти настройки сохраняются не на серверной стороне, а на клиентской, то это вообще не проблема. Оно там обновилось, ваши настройки профиля подгрузились, как только появилась новая версия.

С точки зрения виртуализации приложений сервер App-v вот это к ответу на вопрос – что помещается в виртуализационный пакет, что мы можем виртуализировать средствами App-v. Мы можем виртуализировать службы ОС. Это означает, что, если вы запускаете какое-то приложение и ему нужно для работы тот или иной сервис Windows, все бинарники этого сервиса попадают в виртуализационный пакет App-v. Иными словами, когда вы поднимаете голую виртуальную машину, на которой есть чистая, нетронутая ОС Windows, но вы туда накатываете пакет App-v, в котором все есть. То есть, эта служба там появится сама, потому что ее исходники она возьмет из своего виртуализационного пакета. Точно также это относится и для ES. Все типы учетных записей приложений пользовательских были настроены каким-то образом, мы используем те или иные встроенные или учетные записи, они все помещаются в виртуализационный пакет, их не нужно специальным образом настраивать и поднимать и в только что виртуальной машине, они из App-v пакета будут доступны в этом приложении. Кроме того, в виртуализационный пакет помещаются различные ресурсы. Кроме файла самого приложения различные конфигурационные файлы в текстовом формате, в виде записей в ветке реестра, в виде настроек каких-нибудь провайдеров, которые приложение используют - вся эта информация также включается в виртуализационный пакет, включая локальных пользователей группы, которые вы создали на машине запуска приложений. Естественно, что это не относится к доменным записям. Как вы понимаете, это сделать невозможно, но локальные юзера будут работать. И, наконец, это различные компоненты ОС и не только ОС. Как я уже сказал, ключи и ветки реестра, которые необходимы для работы приложения Java-приложений, которые устанавливаются при развертывании приложения, dot net компоненты, frame work компонент, который нужен, но он отсутствует на только что установленной Windows на виртуальной машине – вся эта информация есть в пакете App-v. И вот в этом, в том числе преимущество этой технологии виртуализации. Мы доставляем приложение на любую совместимую ОС Windows и все, что нужно для этого приложения есть вместе с ним, оно просто запускается и работает.

Более того, после того, как вы создали виртуализационный пакет средствами App-v, вы один этот пакет можете использовать для создания различных профилей приложения с теми или иными нюансами. Потому что в процессе развертывания конкретного экземпляра приложения с помощью VMM, мы можем задать параметры, которые уникальным образом сконфигурируют этот экземпляр, и этот вариант приложения будет работать с такими, а не с другими параметрами. В консоли управления выглядит это следующим образом. Перед вами это как раз и есть профиль приложения. И когда вы создаете сервисный шаблон, вот по этим шагам мы с вами проходим, и вы выбираете нужный профиль ОС и вот здесь, в частности, если это уровень бизнес логики, где вы применяете как раз виртуализационный пакет, вы просто указываете, где этот пакет лежит, вы знаете какие-то переменные, которые инициализируются в процессе развертывания приложения этого экземпляра и можете снабдить этот профиль различными скриптами, которые должны запуститься до или после установки этого приложения. Все, что вы видите – это скриншоты VMM, потому что повторюсь, сервер App-v – это часть VMM, поэтому все, что нужно с инфраструктурной точки зрения для работы этой компоненты, есть в самом VMM. Если у вас есть VMM, у вас есть сервер App-v. Это просто компонента продукта, это не какая-то отдельная добавка к нему. В том числе, кстати говоря, если вы в рамках этих параметров указываете, какую-то конфиденциальную информацию, внутри профиля приложения эта информация будет храниться в зашифрованном виде для конфиденциальности. Клиентский App-v может использовать, а может не использовать инфраструктуру configuration manager. И насколько я знаю, в этом смысле ничего не меняется. Но поскольку эта технология не является частью VMM, она никоем образом не опирается на configuration manager. Можно ли ее заставить использовать configuration manager для этого – я не скажу. Чем отличается App-v от configuration manager. App-v – это пакет, который не имеет прямого отношения к configuration manager, который может при этом опираться на инфраструктуру configuration manager. Отличие, во-первых, в том, что сервер App-v является частью VMM и для работы ничего кроме VMM ничего вам не нужно. Второе – сервер App-v позволяет вам виртуализировать приложения только для серверных операционных систем. Он не предназначен для развертывания пакета на клиентские машины и подготовить пакет, который вы потом развернете, вы здесь не сможете. С точки зрения функционала это определенный шаг вперед достаточно серьезный. Будет ли этими всеми возможностями наделен клиентский App-v – будем считать, что вы меня об этом не спрашивали. Я просто не знаю.

Мы с вами подготовили инфраструктуру, мы создали шаблон сервиса, мы виртуализировали с помощью App-v необходимые приложения и соответственно теперь все готово для того, чтобы потребители могли эти приложения на основе шаблона развертывать. Причем, если пользователь пытается развернуть некоторое приложение, он это сможет сделать в рамках консоли VMM, может сделать с помощью add controller, что гораздо проще и легче, ему нужен просто браузер, который подключается к контролеру. При этом System Center 2012 осуществляет контроль развертывания приложений. Иными словами, если пользователю дан доступ только на ресурсы облака номер один. И на текущий момент в этом облаке не достаточно ресурсов для развертывания приложений из 12 виртуальных машин, add controller сразу об этом скажет. То есть, вы не столкнетесь с ситуацией, когда он стал пытаться виртуальной машиной разворачивать, а они кончились, потому что закончилась квота. Эта ситуация предотвращается на этапе нажатия кнопки deploy – вы тут же получите сообщение, что ресурсов недостаточно. Кроме того, какие конкретно сервисные шаблоны вам доступны, какие приложения вы можете развернуть в рамках вашего частного облака – это тоже зависит от того, к какому полю пользователь принадлежит. И, наконец, мы получаем, что с помощью add controller при развертывании приложений для нас не играет роли, это приложение мы хотим развернуть на инфраструктуре обработке нашего центра данных или в рамках Windows Azure. И как я вам показывал, соответственно, вы можете внедрить приложение, используя private cloud, или можете сказать: «Я хочу развернуть приложение в рамках Windows Azure». Отличаться будут только те параметры, которые от вас add controller попросит, если для развертывания приложений в частном облаке он может попросить с вас дополнительные параметры для этих виртуальных машин, в рамках Windows Azure он попросит у вас только количество экземпляров, виртуальная машина каким объемом будет запущена.

И последний этап, о котором хотелось бы поговорить с точки зрения жизни приложения – это мониторинг. В рамках System Center есть компонент, который называется operation manager 2012 и он представляет из себя готовое решение по мониторингу всей вашей инфраструктуры от нижнего уровня железа, свичи, маршрутизаторы, через физические серверы виртуальной машины вплоть до конкретных приложений компонент, который внутри этой машины запущены. В System Сenter operation 2012 появилось возможность осуществления мониторинга dot net приложения. Любые dot net приложения могут мониториться достаточно глубоко. Если возникает проблема и в консоли operation manager по традиции возникает alert, который говорит, что производитель с этого приложения ниже установленного порога, а вы устанавливаете этот порог, то ops manager может показать вплоть до какого вызова в сиквел сервере приводит к этим тормозам или обращение к какому веб-сервису этого приложения обеспечивает вот такое время оклика вместо положенных пятисот миллисекунд. Но еще раз подчеркну, вот этот дипмониторинг глубокий сейчас доступен для dot net приложений. Приложения другого типа как, насколько мы можем мониторит, мы получим состояние о том, что все в порядке с виртуальной машиной, все в порядке с операционной системой внутри виртуальной машины, но если производитель, поставщик этого программного обеспечения выпускает со своим приложением management pack для своего приложения, то и для этого приложения вы получите детальную информацию. Этот мониторинг вы можете настроить, включить, вы можете его отключить. Сильно ли он снижает производительность? Я не смогу вам сказать в процентах сколько. Какие-то затраты на этот мониторинг существуют, но они не настольно велики, чтобы привести к падению производительности виртуальных машин. Этот мониторинг вы можете включать, но действительно на те периоды анализа ситуации, что с ним происходит, когда вам это необходимо. Поэтому это полностью контролируемо и тут от вас зависит, сколько ресурсов на этот мониторинг вы съедите с вашей инфраструктурой. Что очень важно – вот эта возможность мониторинга приложений может быть реализована с двух точек зрения. На стороне сервера, который вы задаете в configuration manager и вот эти настройки отслеживают выполнение самого кода приложения и есть так называемые клиентские настройки, для того чтобы operation manager предоставил вам информацию о том, как в работе его приложение выглядит с точки зрения пользователя. То есть, если это приложение, которое крутится на сервере и имеет там веб-интерфейс, и мы к нему обращаемся, то здесь вы можете увидеть, что все в порядке. Все код-приложения выполняются нормально, все хорошо и с этой точки зрения ops manager говорит, что приложение работает идеально. А вот эта настройка покажет вам, что у вас есть жуткие тормоза с откликом дефолтовые страницы вашего приложения. И дальше нужно анализировать, почему эти тормоза возникли, потому что, действительно, с приложением что-то не так или с сетью что-то происходит. Вот два взгляда на то, что с приложением происходит. И, кроме того, operation manager предлагает механизм синтетических тестов, которые позволяют ваше приложение периодически проверять для того чтобы анализировать его производительность с течением времени. Информацию вы можете получать в виде отчетов и принимать решение о здоровье вашего приложения или каких-то контрмерах. С точки зрения настройки, в operation manager 2012 вы можете без всякого программирования создать свои менеджмент паки для мониторинга этого приложения. Это делается с помощью графического мастера и все, что вам необходимо – это выбрать приложение, которое вы хотите мониторить вот на этом этапе. Ops manager покажет вам их, потому что, если это развернутое дотное приложение, он умеет его детектить и выдать в виде списка приложения, которые у нас сейчас запущены. Если они запущены на узлах, подвержены мониторингу. Затем мы выбираем конкретное приложение и указываем вот те самые настройки со стороны сервера, включаем мониторинг производительности и устанавливаем пороги производительности, например, с вашей точки зрения нормальной работы приложения, когда отклик не превышает 600 мс. Точно также вы можете задать дополнительные настройки и на вот эти закладки клиентской конфигурации, скорость отклика, загрузки страницы приложения, скорость отработки скриптов этого приложения и, соответственно, получить полную всестороннюю информацию о работе этого приложения. В рамках лабораторных работ как раз такой сценарий можно было попробовать непосредственно на operation manager, на рабочей инфраструктуре.

Как осуществляется мониторинг со стороны клиента, если клиент находится где-нибудь в удаленной точке? Возможная ситуация, когда клиенты находятся в удаленных точках и у одного проблемы с приложением есть, и у другого проблемы с приложением нет. В данном случае проблему ops manager не даст вам такую картину работать с приложением. Суть clients configuration заключается в том, что он сам пытается протестировать это приложение, потому что он знает, что оно находится вот здесь на этом сервере и получить какую-то картину. В вашей ситуации нужно будет тестирование проводить, скажем, наверно более развернутое и ручное для того чтобы понять в чем проблема.

Последнее на чем бы я хотел остановиться – настроив мониторинг приложения в operation manager, вы можете легко и изящно настроить собственные панели мониторинга. Делается с помощью соответствующего мастера. Выбираете папку в иерархии объектов в ops manager, где бы вы хотели эту панель расположить. Таким образом, запускается мастер, на основе которого вы выбираете шаблон этой панели, как она должна выглядеть, сколько в ней должно быть ячеек, как они должны располагаться и после этого начинаете выбранную вами форму панели наполнять так называемыми виджетами. То есть, тех объектов мониторинга, состояние которых вы хотели бы отображать на панели. В данном случае мы выбираем группу объектов для приложения vinner now, которое запущено в нашей инфраструктуре и располагаем этот дашборд в нужной иерархии, говорим, кто этим дашбордом может воспользоваться для анализа, и получаем картинку мониторинга. Здесь будет график счетчиков производительности процессора, здесь обращение к диску, здесь отклик клиентской стороны и так далее.

Подводим краткие итоги, начиная с определения того, какие ресурсы веб-приложению требуются, предоставляем эти ресурсы, помещаем их в библиотеку VMM. Затем мы создаем с помощью template designer шаблон, указываем, какие профили ОС аппаратуры приложения в этот шаблон необходимо вставить. Затем мы в процессе деплоймента выбираем шаблон на этом этапе. VMM говорит: «Сейчас мы планируем развернуть приложение, которое будет состоять из вот этих пяти виртуальных машин. Текущая нагрузка на среду вот такая и поэтому оптимально расположить виртуальную машину, эту здесь, эту здесь». С чем вы можете согласиться или скорректировать поведение VMM. И вот выбрав эти подходящие параметры, вы нажимаете кнопку deploy, после чего развертывается, поднимаются нужные виртуальные машины и поднимается при необходимости мониторинг этого приложения. И, соответственно, когда вам необходимо приложения обновить, вы можете подготовить новую версию шаблона, в котором указать, что теперь на средний уровень мы должны поместить обновленный вариант пакета, например, опубликовать его в библиотеке, выбрав затем с помощью add controller. И, соответственно, это приложение будет обновлено до следующей версии.

Краткие итоги. Мы с вами посмотрели на концепцию предоставлении IT, как сервиса в рамках System Center 2012. Эта концепция включает в себя средства самообслуживания, с помощью которого пользователи могут выразить свои пожелания, оформить свои заявки на предоставления тех или иных услуг с точки зрения IT. Поскольку, так или иначе, речь пойдет о запуске каких-нибудь приложений, по крайней мере, в контексте частного облака, эти приложения запускаются, формируются на основе некой сервисной модели. Средствами сервис менеджера, средствами оркестратора мы можем настроить процесс формирования обработки заявки и реакции на появлении запроса в System Center 2012 после чего, если все критерии выполнены, заявка утверждена, System Center 2012 разворачивает необходимые виртуальные машины, запускает приложение, и мы в дальнейшем осуществляем мониторинг этих приложений. Те компоненты, который участвуют в процессе, мы посмотрели на некоторые из них с упором на VMM. И разделить реализацию этого сервиса можно на три больших блока, подготовка инфраструктур, организация и предоставление услуг приложений в виде сервисов и управление приложениями с помощью тех или иных компонент System Center 2012.

Вот три составляющих применения System Center 2012 для оптимизации – это эффективная инфраструктура. Мы посмотрели, как это можно реализовать при помощи конкретных инструментов, это предсказуемое предложение. И вот эта предсказуемость реализуется на шаблонах, и мы видели, как System Center 2012 позволяет вам использовать и запускать ваши приложения не только в частном облаке, но и в публичном и целостную картинку, с точки зрения потребителя приложения предоставлять. Ресурсы, которые вы уже видели перед вами и я думаю.

Про лицензирование System Center 2012. Происходят изменения. Они направлены в сторону упрощения лицензирования. Первая новость – теперь не нужно лицензировать консоль управления. Вторая новость – можно сиквел использовать бесплатно для множества управления. Третья – теперь в System Center 2012 можно купить только, как единый продукт: System Center 2012 в рамках которого вы получаете все продукты. Можно с этим разобраться так же, как с Windows server. Вы когда покупаете Windows server, вы покупаете файл сервера и веб и все остальное. За каждую консоль вы получаете лицензию, за каждую существующую лицензию индивидуального продукта, вы получаете все лицензии. Остается всего две лицензии System Center - System Center для серверного управления System Center 2012 standard edition и System Center 2012 data center edition. Примерно так же, как с Windows сервером первая для низко виртуализированных средств или для физических средства, а вторая для высоковиртуализированных с неограниченным количеством покрытых управлением виртуальных машин. Сейчас мы рекомендуем, если вы строите частное облако, то вы не хотите задуматься по поводу лицензирования инфраструктуры, вы хотите создавать виртуальные машины, ими управлять без ограничений каких-то, для этого, как раз есть вот эта линейка data center с отсутствием ограничений и System Center data center, бесконечное количество виртуальных машин. Теперь в System Center входит антивирус.