Изучение IBM SmartCloud Application Services

Как создать новый типовой образ виртуального приложения

Специалист по облачным решениям IBM Доминик Вернье считает, что разработчикам, интенсивно использующим виртуальные образы в экспертных облачных системах IBM® PureSystems™, будет полезно узнать, как создать типовой образ ― структуру, которая обеспечивает все необходимые для создания образа компоненты, связи, правила масштабирования и т.д. В этом сборнике эксперт шаг за шагом объясняет, как создать и расширить типовой образ. Автор использует IBM SmartCloud Application Workload Services из семейства SmartCloud Application Services, но результаты применимы также и к системам SmartCloud Enterprise и IBM PureSystems.

Доминик Вернье, ИТ-архитектор, IBM China

Фото Доминика ВерньеДоминик Вернье (Dominique Vernier) в последние годы занимается Java-технологиями и облачной архитектурой. Также работает в сфере информационных технологий, где приобрел широкие знания в области таких технологий и продуктов, как средства обмена сообщениями, базы данных, SOA, EAI, клиент/сервер, C/C++ и существующие инфраструктуры. Обладает обширными знаниями и в таких отраслях, как связь, CRM, материально-техническое обеспечение и страхование. Является автором/соавтором четырех патентов, относящихся к автоматам состояний и управлению ресурсами. В настоящее время отвечает за решения IBM SmartCloud Enterprise в группе IBM GTS Global Team.



25.06.2013

Будучи любознательным ИТ-архитектором и прочитав статью developerWorks Создание и настройка образов виртуальных приложений, я задал себе вопрос: «А трудно ли создать новый типовой образ?» И попытался создать типовой образ для отдельного сервера ― простой проект, который, однако, наглядно демонстрирует концепции, лежащие в основе типового образа.

Эта статья представляет собой путеводитель по этому процессу; его этапы выделены из более полного описания, приведенного в моем блоге. Каждый раздел ― это краткий обзор полной инструкции. Чтобы углубиться в детали, нужно выбирать ссылки и читать либо соответствующий PDF-документ с полным описанием, либо это же описание в моем блоге. PDF – это копии заметок в блоге, которые обновляются лишь периодически; ссылки же на фактические заметки соответствуют текущей версии информации в блоге, где можно найти новые публикации этой серии.

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

Определения, концепции, сценарий и установка

Часть 1 начинается с описания разницы между образом (pattern) и типовым образом (pattern type): типовой образ содержит всё для построения образа: компоненты, ссылки, правила масштабирования и т.д. Для создания типового образа требуется больше усилий, чем для создания образа на основе готового типового образа.

Затем излагается сценарий:

  • типовой образ содержит единственный сервер;
  • у сервера единственный параметр;
  • процесс развертывания выдает сообщение, когда модель развертывания начинает процесс установки;
  • процесс развертывания выдает сообщение в другой момент развертывания.

Представлены три важных концепции:

  1. Типовой образ обычно состоит из одного плагина с определением типового образа и одного или нескольких плагинов с функциональностью этого типового образа — количество плагинов зависит от архитектуры.
  2. Плагин можно разложить на две основных части:
    • модель приложения: определяет различные компоненты и связи для создания образа виртуального приложения.
    • физическая модель: определяет различные виртуальные машины и сценарии, которые нужно запустить в целевом облаке.
  3. Имеется два механизма отображения модели приложения на физическую модель: механизм на основе кода Java™ и механизм на основе образа (предпочтительный и рекомендуемый).

Наконец, приводятся инструкции по настройке для участия в этом упражнении:

  1. Создание рабочей области.
  2. Импорт типового образа и плагинов.
  3. Переименование типового образа.
  4. Редактирование JSON-описания типового образа.
  5. Создание нового проекта Java для разработки плагина.
  6. Создание каталога плагинов.
  7. Копирование в каталог плагинов файлов META-INF, build.plugin.xml и build.properties.
  8. Обновление файла config.json созданного плагина.

Я также буду говорить о следующих вещах и предоставлю соответствующий код:

  • модель приложения: определена в plugin/appmodel/metadata.json. Вы увидите, как спроектировать и проверить ее;
  • физическая модель: состоит из файла образа виртуальной машины, определяющего виртуальный элемент, который следует развернуть, и роли по отношению к модели приложения.

Наконец, демонстрируется заключительный тест, и вы готовы перейти к части 2.

Часть 1-PDF | Часть 1-блог


Создание типового образа "главный-подчиненный"

Следующая задача - создание типового образа "главный-подчиненный" (Master-Slave); он отличается от упражнения из части 1, так как состоит из связи между главным и подчиненным серверами и извлекает некоторую информацию из подчиненного сервера (например, IP-адрес) для настройки главного сервера.

Этапы, рассматриваемые в части 2:

  1. Изучение модели приложения и демонстрация изменений по сравнению с моделью приложения из файл JSON, рассмотренной в части 1. Добавлен элемент типовой связи, указывающий исходный и целевой элементы.
  2. Изучение изменений физической модели, обновление каталога OSGI и реструктуризация компонентов, так чтобы главный зависел от подчиненного.
  3. Демонстрация способа проверки модели и вида правильных результатов.

Часть 2-PDF | часть 2-блог


Добавление в типовой образ статической масштабируемости

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

Сначала мы присоединяем компонент политики к подчиненному компоненту, затем определяем атрибуты этой политики и, наконец, адаптируем образы подчиненной ВМ для импорта информации, собранной в модели приложения. (Эта возможность имеет большое значение, потому что она имеется и в интегрированных экспертных системах IBM PureSystems и в IBM Workload Deployer.)

Часть 3-PDF | Часть 3-блог


Добавление в типовой образ коллектора мониторинга

Конечно, чтобы реализовать динамическую масштабируемость, которая будет реагировать на функцию мониторинга, нужно иметь возможность собирать информацию от сервера. Цель этого упражнения заключается в том, чтобы научиться контролировать количество файлов в заданном каталоге сервера и графически отображать его.

Требуется выполнить следующие шаги:

  1. Определение формата данных, собираемых в файл метаданных. Определение происходит при создании файла.
  2. Создание сценария коллектора, который будет собрать информацию от сервера. Существуют разные способы сбора информации от сервера: HTTP, WCA и т.п.; я выбрал сценарий, потому это проще всего для понимания. Можно также реализовать свой собственный Java-класс путем реализации интерфейса ICollector. Так как все коллекторы должны следовать этому интерфейсу, ответ коллектора должен соответствовать заданному формату.
  3. Создание сценариев загрузки файла метаданных и сценария коллектора на сервер. Для этой роли я адаптировал файл install.py. Существуют и другие способы выполнения этой функции.
  4. Регистрация коллектора. Коллектор регистрируется с помощью команды maestro.monitorAgent.register(). Это делается в файле configure.py.
  5. Предоставление конфигурации в пользовательском интерфейсе для графического представления собранных данных. Для демонстрации графика создается файл monitoring_ui.json. Этот файл помещается рядом с файлом config.json.

Часть 4-PDF | Часть 4-блог


Масштабирование и вывод на основе коллектора мониторинга

Мы добавили простой коллектор, подсчитывающий количество файлов в каталоге; теперь научимся использовать этот коллектор для добавления правил масштабирования вверх и вниз в соответствии с параметрами, предоставляемыми этим коллектором.

Для реализации этого сценария необходимо изменить некоторые файлы, чтобы:

  1. Ввести аргументы правил масштабирования при проектировании образа:
    • каталог файлов, подлежащих мониторингу;
    • мин./макс. пороговые значения количества файлов;
    • мин./макс. количество виртуальных машин, которые нужно развернуть;
    • время реакции.
  2. Отражение этих значений в топологии.
  3. Изменение сценариев для создания каталога мониторинга и передача этого параметра в коллектор.

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

Что касается сценариев, то в предыдущем разделе я жестко запрограммировал в сценарии монитор. Я сделал это в сценарии установки, но теперь, поскольку это параметры роли, его нужно поместить в сценарии ролей, в файл configure.py или start.py. Очевидно, что это конфигурация роли, поэтому мы поместим ее в сценарии конфигурации.

Часть 5-PDF | Часть 5-блог


Добавление связей к операциям

При определении роли в типовом образе ее можно связать с рядом операций, которые нужно запустить после развертывания образа. В этом примере я добавляю к роли операцию «Отправить строку в журнал».

Для осуществления операции нужно добавить дополнительный файл с именем operation.json к файлу metadata.json в каталоге appmodel. Этот файл указывает, какой сценарий нужно запускать и что этот сценарий должен поместить в каталог роли компонента.

В файле operation.json для каждой роли можно определить количество операций; у каждой операции есть идентификатор, метка, описание, категория, сценарий и список атрибутов. Категория используется для соединения ряда операций в пользовательском интерфейсе. Сценарий ― это сценарий Python, и его нужно поместить в каталог сценариев роли компонента. Атрибуты отображаются в пользовательском интерфейсе.

Реализация простейшего сценария. Этот сценарий просто извлекает значение атрибута stringToLog и помещает его в файл журнала. Значение атрибута можно извлечь, используя синтаксисmaestro.operation['parms'][{attributeName}];, где attributeName - имя нужного атрибута. Сценарий нужно поместить в каталог сценариев роли.

Часть 6-PDF | Часть 6-блог


Масштабирование вверх и вниз на основе параметров операционной системы

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

В файле модели приложения необходимо определить политику масштабирования и ввести все аргументы этой политики. Это очень похоже на то, что мы делали при определении политики коллектора мониторинга. Вместо определения количества файлов и каталога в атрибутах мониторинга, определим атрибут cpuUsage, который представляет собой процентное отношение. Определим элемент типовой политики, который применяется к роли сервера. В этой политике две группы: политика статического масштабирования и политика на основе процессора.

Для политики на основе процессора определим три атрибута: cpuUsage, scaleInstanceRange1 и triggerTime1. Имена можно выбрать любые; важно, чтобы они соответствовали идентификатору атрибута в определенном после этого перечне атрибутов. Порядок следования атрибутов в группе определяет порядок их появления в редакторе образа.

Далее, определим каждый атрибут; например для cpuUsage укажем, что это диапазон, он должен отображаться в процентах со значениями по умолчанию от 1 до 100.

В файлы топологии нужно ввести атрибут, полученный в модели приложения для определения правила масштабирования. Это делается в JSON-атрибуте scaling файла ВМ. Для вставки элементов в топологии можно использовать сценарий Velocimacro.

Часть 7-PDF | Часть 7-блог


Расширение существующего типового образа

Клиент задал мне следующий вопрос:

У меня есть своя собственная система журналов событий, и хотелось бы, чтобы все данные из файлов журналов WebSphere® Enterprise Application копировались в эту систему. Я не хочу воссоздавать полный типовой образ WebApp, а только добавить новую функциональность. Как мне использовать существующий типовой образ WebApp и добавить в него только ту функциональность, которая мне нужна?

Ответ прост: расширить типовой образ WebApp, добавив плагин, который делает то, что нужно. И вам повезло: расширить типовой образ очень легко. Нужно лишь помнить, что типовой образ состоит из определения типового образа и набора вложенных плагинов. В определении типового образа указаны его версия, имя и описание. Каждый подключенный плагин определяет связь с определением типового образа с помощью нескольких строк в отдельном файле config.json.

Достаточно создать новый плагин, связанный с целевым типовым образом (в данном случае, WebApp). Добавим новые компоненты в файл metadata.json.

Часть 8-PDF | Часть 8-блог


Добавление возможности настраивать экземпляр виртуального приложения

Операции важны: они обеспечивают возможность выполнять действия в развернутом образе или виртуальном приложении; это такие действия, как установка параметров и манипулирование ситуациями на основе этих параметров. Для этого нужно запустить сценарий, записанный в файле operation.json, созданном в модели приложения. Читайте, как добавить операцию в типовой образ.

Модель операций позволяет запускать сценарии с параметрами в работающем образе, но для этого есть еще один способ: настройка (tweak). Разница в том, что настроенный параметр сохраняется в хранилище и, следовательно, может использоваться в любой момент на протяжении всего жизненного цикла образа.

Настройка обеспечивает ту же функциональность, но с постоянными параметрами в развернутом образе. Настройку параметров можно использовать для восстановления отказавшего сервера и его точной настройки как в предыдущей версии. Примером служит файл WAR/EAR в образе WebApp; при его установке путь к файлу сохраняется в развернутом образе.

Настроенные параметры можно связать с атрибутами компонента.

В модели приложения необходимо создать файл tweak.json и файлы операций. В файле tweak.json определите свои параметры настройки.

Вы можете спросить: «Зачем мне файл операций, если я выполняю настройку?». Файл операций (с идентификатором configuration) нужен для того, чтобы показать настройку в интерфейсе пользователя.

Данные хранятся в файле parameters.json, расположенном в хранилище образа.

В файлах топологии (ВM) ничего особенного делать не должно, если только вы не хотите извлечь значение с помощью функции maestro.parms.

Часть 9-PDF | Часть 9-блог


Добавление дискового пространства к виртуальной машине в SmartCloud Application Services

Мне стало интересно, как добавить дисковое пространство к виртуальной машине, сгенерированной из типового образа, разработанного в SmartCloud Application Workload Service? Это оказалось довольно просто. Достаточно обновить шаблон топологии, чтобы запросить дисковое пространство, а затем указать его в элементе массива vm-templates.

Возьмите простой файл виртуальной машины, добавьте запрос на дисковое пространство, поместив массив storage-templates в файл JSON, добавьте ссылку на этот запрос, поместив элемент массива памяти в элемент vm-templates, а затем постройте плагин и разверните его.

После развертывания образа подключите дисковое пространство и убедитесь, что оно смонтировано с нужным размером.

Да, кстати: SmartCloud Application Workload Service определяет размер своего дискового пространства в гигабайтах (GB); SmartCloud Enterprise позволяет запрашивать его как в GB, так и в терабайтах (TB).

Часть 10-PDF | Часть 10-блог


Заключение

Я надеюсь что это краткое руководство по созданию и настройке типового образа в SmartCloud Application Services послужит вам хорошей отправной точкой для построения типовых образов, конструктивных блоков будущих виртуальных образов. Напомню, что для подробного ознакомления с каждым пунктом достаточно одного щелчка кнопки мыши.

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=935358
ArticleTitle=Изучение IBM SmartCloud Application Services
publish-date=06252013