Содержание


Автоматическая инициализация ресурсов хранения данных для удовлетворения потребностей приложения с помощью расширений Rational

Применение акселератора IBM Deployment Planning and Automation for the Cloud 2.1.0

Comments

В статье How to reduce deployment time for composite solutions with the integration asset (Как уменьшить время развертывания для составных решений с интеграционным активом) описывается использование акселератора IBM Deployment Planning and Automation for the Cloud для генерации артефактов автоматизации развертывания, основанных на модели топологии приложения, для построения и конфигурирования виртуальных образов, содержащих такие компоненты, как промежуточное программное обеспечение и приложение. (Топология— это разновидность модели, показывающая отношения между ИТ-ресурсами).

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

Актив интеграции описываемого акселератора позволяет архитекторам использовать инструмент моделирования решения Rational Software Architect (RSA) для проектирования топологии приложения и генерации потоков работ для нескольких механизмов развертывания, таких как Tivoli Service Automation Manager (TSAM) и Rational Automation Framework (RAF) — что позволяет обеспечить развертывание всеобъемлющего решения.

Рисунок 1. Сквозная автоматизация всех шагов развертывания
Diagram shows  end-to-end automation of all the deployment                     steps
Diagram shows end-to-end automation of all the deployment steps

Сгенерированные потоки работ включают следующие шаги:

  • Шаги механизма TSAM по инициализации виртуальных машин VMware и логических разделов (LPAR) системы System p®, а также по установке промежуточного программного обеспечения.
  • Шаги механизма RAF по конфигурированию компонентов промежуточного программного обеспечения и по установке приложений.

Акселератор версии V2.1.0 позволяет настраивать элементы систем хранения в виртуальных образах. В качестве примера рассмотрим сценарий развертывания веб-приложения на базе Java™ Enterprise Edition (EAR) в совместно используемой виртуализированной инфраструктуре. Этому приложению требуется бэкенд в виде сервера веб-приложений и сервера баз данных (рис. 2).

Рисунок 2. Пример сценария развертывания
Diagram shows a sample deployment scenario
Diagram shows a sample deployment scenario

В этом сценарии архитектору решения ("Салли") нужно, чтобы сервер приложений и сервер баз данных были установлены на дополнительном жестком диске (т. е. не на том диске, на котором развернута операционная система хоста). Салли хочет, чтобы эти два жестких диска были независимы, что позволит при необходимости расширить систему.

С помощью акселератора Салли может спроектировать требуемую модель топологии развертывания с модулем модели сервера, состоящим из модуля модели веб-сервера (такого как WebSphere® Application Server) и модуля модели сервера баз данных (такого как IBM DB2®). При проектировании модели топологии развертывания акселератор версии V2.1.0 позволяет смоделировать дополнительный жесткий диск в явном виде — как модуль модели дополнительной системы хранения, который будет ассоциирован с модулем модели виртуального образа. На этапе развертывания механизм TSAM находит подходящий кластер VMware или хост CEC (Central Electronic Complex), поддерживающий образы System p, с для развертывания сервера с характеристиками системы хранения, заданными в элементе системы хранения.

Такая модель топологии развертывания позволяет инженеру по развертыванию ("Дуг") предложить стандартизированную модель топологии для развертывания приложений в совместно используемой корпоративной компьютерной инфраструктуре. Применяя эту стандартизированную модель топологии, два архитектора решений ("Салли" и "Сэм") могут независимо друг от друга развернуть две версии JavaEE-приложения в совместно используемой инфраструктуре.

Все это позволяет Дугу, Салли и Сэму развертывать активы решения более эффективно и с меньшим количеством ошибок.

Итак, на этом примере сценария мы рассмотрели способности акселератора в части моделирования автоматизации инициализации системы хранения. Теперь рассмотрим некоторые другие задачи:

  • Установка акселератора
  • Моделирование расширений системы хранения в инструменте Rational System Architect
  • Генерация специальных определений сервиса продукта TSAM и проектов продукта RAF
  • Импорт и запрос специального сервиса в TSAM
  • Установка компонентов приложения и конфигурирование промежуточного программного обеспечения с помощью продукта RAF

Установка актива интеграции

Акселератор Deployment Planning and Automation for the Cloud можно загрузить с веб-сайта Tivoli Integrated Service Management Library. Этот актив устанавливается поверх следующих обязательных продуктов:

  • Rational Software Architect 8.5.5 (RSA) со следующими дополнениями
    1. Extension for Deployment Planning
    2. Extension for Deployment Automation Planning
    3. (в качестве опции) IBM Rational Deployment Automation Content Pack for RAFW и WebSphere Application Server
  • Rational Asset Manager 7.5.0.1
  • Rational Build Forge 7.1.2.2 (в качестве опции — с продуктом Rational Automation Framework for WebSphere 3.0)
  • Tivoli Service Automation Manager 7.2.4 и Tivoli Provisioning Manager (TPM). Актив интеграции содержит подробные инструкции по установке поверх упомянутых обязательных продуктов.

Моделирование расширений системы хранения в инструменте RSA

Актив интеграции содержит подробные инструкции по установке поверх упомянутых обязательных продуктов.

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

На рис. 3 показан пример модели топологии, отражающей виртуальный образ VMware, в котором установлены сервер WebSphere Application Server, операционная система, сервер баз данных DB2 и EAR-компонент (стандарта JavaEE).

Рисунок 3. Пример топологии с образом VMware, содержащей сервер WebSphere Application Server и компоненты приложения
Diagram shows sample topology of VMware image with WebSphere Application Server and application components
Diagram shows sample topology of VMware image with WebSphere Application Server and application components

Компонент приложения можно ассоциировать с URL-адресом актива Rational Asset Manager с помощью кнопки Properties > Artifacts > Add.

Рисунок 4. Связь между модулем модели и EAR-файлом приложения, хранящимся в активе RAM
Screen capture shows connection between model unit and application EAR file stored in a RAM asset
Screen capture shows connection between model unit and application EAR file stored in a RAM asset

С помощью таких URL-адресов и номеров версий Салли и Сэм могут ассоциировать различные модели топологии с собственными версиями EAR-файла приложения для развертывания.

Чтобы спроектировать элементы системы хранения, Салли добавляет в топологию шаблон VMware Virtual Disk Def из секции Virtualization представления Palette.

Рисунок 5. Добавление модуля системы хранения к топологии
Screen capture shows that the VMWare Virtual Disk Def template falls under the Virtualization drawer of the Palette

Модуль VMware Virtual Disk Def будет добавлен к топологии. Салли присваивает состоянию installState этого модуля значение "to be installed" (подлежит установке) и создает хостинговую ссылку на модуль VMware Virtual Image.

Рисунок 6. Добавление модуля системы хранения к топологии
Screen capture shows that the VMWare Virtual Disk Def template falls under the Virtualization drawer of the Palette

В модуле VMware Virtual Disk Def Салли добавляет детали конфигурации к следующим свойствам согласно требованиям приложения к системе хранения.

  1. Типы дополнительных файловых систем.
    • Для Linux-образа Салли задает один из следующих типов файловой системы: ext2/ext3/None
    • Для Windows-образа Салли задает один из следующих типов файловой системы: NTFS/FAT32/None
  2. Дополнительные точки монтирования.
    • Каталог/диск, в котором будет смонтирована дополнительная система хранения
    • Для Linux-образа Салли задает имя каталога
    • Для Windows-образа Салли задает букву диска

    Примечание. Не используйте стандартные точки монтирования, такие как /root, /bin, /opt и т. д. В этом каталоге будет установлен сервер приложений (WebSphere Application Server) и сервер баз данных (DB2).

  3. Имена пула дополнительных систем хранения

    Салли задает такое же имя пула Cloud Storage Pool, какое определено в продукте TSAM. Например, на рис. 7 показано свойство Name на вкладке Cloud Storage Pool Definition в продукте TSAM. Салли задает это имя для каждого жесткого диска, который она хочет добавить (в разделенный запятыми список).

    Рисунок 7. Пул Cloud Storage Pool, заданный в продукте Tivoli Service Automation Manager
    Screen capture shows Cloud Storage Pool defined in Tivoli Service Automation Manager
    Screen capture shows Cloud Storage Pool defined in Tivoli Service Automation Manager
  4. Дополнительные размеры модуля системы хранения в гигабайтах

    Укажите размеры дополнительного модуля системы хранения в виде целого числа в гигабайтах. Пример: спецификации двух дополнительных жестких дисков.

    • Storage 1 details:
      File System Type: ext2
      Mount Point: mnt0
      Storage Pool Name: AD1
      Storage Unit size: 1
    • Storage 2 details:
      File System Type: ext3
      Mount Point: mnt1
      Storage Pool Name: AD2
      Storage Unit size: 2

    Салли вводит значения в модуль Virtual Disk Def модели инструмента RSA.

    Рисунок 8. Ввод данных о необходимой системе хранения в модуле дисковой системы хранения
    Screen capture shows example of storage need details                             captured in storage disk unit
    Screen capture shows example of storage need details captured in storage disk unit

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

Рисунок 9. Готовая топология с сервером WebSphere Application Server, сервером DB2, приложением и ресурсами хранения в виртуальном образе VMware
Screen capture shows a completed topology with WebSphere                     Application Server, DB2, application and  storage resources in a VMware virtual image
Screen capture shows a completed topology with WebSphere Application Server, DB2, application and storage resources in a VMware virtual image

Генерация специальных определений сервиса продукта TSAM и проектов продукта RAF

На основе этих топологий RSA Салли и Сэм могут генерировать специальные определения сервиса TSAM и проекты RAF. Определения сервиса TSAM хранятся в виде артефактов типа Cloud Service Archive. Сгенерированные проекты RAFW импортируются непосредственно в RAFW. Эта процедура осуществляется в двух шага. На первом шаге Салли или Сэм на основе модели топологии генерируют модель потока работ автоматизации Rational. На втором шаге они создают с целью генерации артефакт Cloud Service Archive и проект RAFW, используя меню Publish topology для сгенерированной на первом шаге модели потока работ автоматизации.

Рисунок 10. Генерация артефакта TSAM Cloud Service Archive и проекта RAFW на основе топологии RSA
Screen capture shows generating a TSAM Cloud Service Archive and RAFW project from RSA
Screen capture shows generating a TSAM Cloud Service Archive and RAFW project from RSA

Модель потока работ автоматизации RSA представляет собой упорядоченный список моделей сигнатур автоматизации, связанных с моделью топологии. Модель сигнатуры автоматизации представляет собой шаблон для задачи автоматизации, которая исполняется на ИТ-системе посредством механизма развертывания.

Например, задача может состоять в инициализации виртуального сервера с помощью TSAM. Сигнатуры автоматизации для задач автоматизации в продуктах TSAM, RAFW, Build Forge и Apache Ant предлагаются в готовом к применению виде в продукте RSA и становятся доступны при установке примера архива проекта, включенного в актив интеграции.

Модели сигнатур автоматизации связывают имена задач автоматизации в различных механизмах развертывания и их входные/выходные параметры с различными модулями в модели топологии. После генерации потока работ автоматизации все эти параметры имеют значения, полученные из топологии.

Одну мастер-сигнатуру автоматизации можно применить к разным топологиям для передачи в них разных значений атрибутов для разных сгенерированных потоков работ автоматизации. На рис. 11 показан пример такой сигнатуры автоматизации, которая связывает задачу автоматизации, заключающуюся в инициализации виртуальных серверов с использованием TSAM в качестве механизма развертывания.

Рисунок 11. Пример сигнатуры автоматизации для развертывания виртуальных серверов с использованием TSAM
Screen capture shows an example of the automation signature for deploying virtual servers with TSAM
Screen capture shows an example of the automation signature for deploying virtual servers with TSAM

Кроме того, эта сигнатура отображает входные параметры для этой задачи, такие как imageID, на аналогичные атрибуты топологии.

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

Салли или Сэм могут увидеть результаты шагов генерации в представлении Publish report продукта RSA.

Рисунок 12. Результаты работы публикатора
Screen capture shows results of publishe report
Screen capture shows results of publishe report

Руководство жизненным циклом актива приложения с помощью инструмента Rational Asset Manager помогает управлять активами приложения, участвующими в поставке программного обеспечения. В этом разделе Салли и Сэм создают новый параметр в сгенерированном артефакте Cloud Service Archive с целью указания иной версии актива RAM, хранящейся в их собственном EAR-файле приложения.

В модели потока работ автоматизации RSA имеются глобальные параметры, которые позволяют предоставить входную информацию для любой автоматизированной задачи в генерируемых потоках работ автоматизации. Эти параметры автоматически передаются в специальный сервис TSAM как обязательные параметры, которые запрашивающая сторона какого-либо сервиса должна указать до запроса этого сервиса.

Например, Салли и Сэм создают новый глобальный параметр DevTeamAssetVersion и ассоциируют его с параметром AssetVersion задачи автоматизации загрузки развертываемых активов.

Рисунок 13. Поток работ автоматизации Rational с новым созданным глобальным параметром DevTeamAssetVersion
Screen capture shows Rational automation workflow with new created DevTeamAssetVersion global parameter
Screen capture shows Rational automation workflow with new created DevTeamAssetVersion global parameter
Рисунок 14. Отображение нового созданного глобального параметра на существующий параметр автоматизированной задачи
Screen capture shows mapping of the new created global parameter to existing parameter of the automated task
Screen capture shows mapping of the new created global parameter to existing parameter of the automated task

После этой настройки Салли и Сэм смогут сгенерировать артефакт Cloud Service Archive и проект RAFW, как было показано выше.

Импорт специального сервиса в TSAM

TSAM позволяет осуществлять запрашивание, развертывание, мониторинг и управление для облачных сервисов с поддержкой утверждений и процессов. При установке модуля расширения акселератора TSAM (tsam_csd_pmp7.2.4.zip) к панели инструментов на консоли администратора TSAM в представлении Service Definitions добавляется новая кнопка Import Service Definition.

Рисунок 15. Кнопка Import Service Definition на панели инструментов Service Definitions
Screen capture shows Import Service Definition button on Service Definitions Application toolbar
Screen capture shows Import Service Definition button on Service Definitions Application toolbar

Эта кнопка позволяет инженеру развертывания Дугу импортировать в TSAM файлы типа Cloud Service Archive, сгенерированные в RSA (как было описано выше). В процессе этого импорта несколько артефактов TSAM (определения сервиса, планы управления, предложения и т.д.) для управления новыми сервисами создаются автоматически.

Чтобы импортировать файл Cloud Service Archive, Дуг указывает полный маршрут к артефакту Cloud Service Archive в локальной директории, а также категорию и каталог. Эта категория определяет категорию пользовательского интерфейса самообслуживания TSAM, в которой появится новый сервис. По умолчанию указывается категория Custom Services (специальные сервисы). Этот каталог определяет каталоги, в которые будут добавляться новые предложения. Выбор каталогов, к которым будут добавляться предложения, управляет группами пользователей (администраторы облака; запрашивающие стороны сервиса, которые смогут видеть и выбирать новые предложения в интерфейсе самообслуживания TSAM).

Рисунок 16. Задание категории и каталога для нового сервиса, созданного после импорта
Screen capture shows specifying category and catalog for the new service created after import
Screen capture shows specifying category and catalog for the new service created after import

После импорта артефакта Cloud Service Archive новое специальное определение сервиса (Service Definition) вместе с определенными планами управления (Management plan) создается со статусом approved (утверждено). Новая версия этого же определения сервиса создается в том случае, когда та же самая топология развертывания импортируется с изменениями. Предложения, создаваемые для каждого плана управления на рис. 17, демонстрируются в интерфейсе самообслуживания TSAM и могут быть использованы посредством запроса данного сервиса.

Рисунок 17. Новое определение сервиса создано для артефакта Cloud Service Archive
Screen capture shows creation of new service definition for Cloud Service Archive
Screen capture shows creation of new service definition for Cloud Service Archive

Запрос специального сервиса в TSAM

На рис. 18 показаны предложения, созданные в пользовательском интерфейсе самообслуживания TSAM для запроса сгенерированного определения сервиса. Сервис инициализации, например Provisioning_SingleTierDeploymentTSAMForVMware_Workflow, может быть использован для развертывания приложения на виртуальном сервере VMware в совместно используемой облачной среде в виде сервиса. Аналогично, сервис деинициализации (Deprovisioning_SingleTierDeploymentTSAMForVMware_Workflow) можно запросить с целью удаления развернутого виртуального сервера из совместно используемой облачной среды.

Рисунок 18. Операции управления для применения к облачному сервису, созданному в результате импорта
Screen capture shows management operations to perform on cloud service created as a result of import
Screen capture shows management operations to perform on cloud service created as a result of import

Салли может спроектировать модель сгенерированного потока работ в RSA с целью включения глобального параметра, чтобы запрашивающие стороны сервиса смогли указывать версию актива приложения в RAM. Этот атрибут демонстрируется в пользовательском интерфейсе самообслуживания как обязательный входной параметр.

Рисунок 19. Специальный атрибут как входной параметр при запросе экземпляра нового облачного сервиса
Screen capture shows customized attribute as an input during the Requesting a New Cloud Service Instance
Screen capture shows customized attribute as an input during the Requesting a New Cloud Service Instance

При поступлении запроса на инициализацию сервиса механизм TSAM включает автоматически сгенерированные потоки работ из RSA, в результате чего инициализируется виртуальный сервер, дополнительные жесткие диски подключаются к этому виртуальному серверу, продукт WebSphere Application Server устанавливается на первом отображенном жестком диске, DB2 устанавливается на втором отображенном жестком диске, а затем вызывается проект RAFW, который конфигурирует WebSphere Application Server и DB2, после чего устанавливает поверх них JEE-приложение. Таким образом, запрашивающая сторона сервиса получает исполняющееся "производственное" приложение буквально одним нажатием мыши.

Теперь Салли и Сэм могут запрашивать свои собственные версии разрабатываемого актива для развертывания через пользовательский интерфейс самообслуживания TSAM. Дополнительная настройка сгенерированной модели потока работ в RSA позволяет задавать другие параметры, такие как обязательная версия ОС, а также идентификаторы пользователей/пароли и т. д. Дуг также может стандартизировать другие параметры в топологии развертывания, такие как версии WebSphere Application Server и DB2.

Установка компонентов приложения и конфигурирование промежуточного программного обеспечения с помощью продукта RAF

Применяя актив интеграции акселератора, Салли может сгенерировать специальный поток работ автоматизации для установки EAR-файла приложения на виртуальные разделы, развернутые с использованием TSAM. На рис. 20 показан проект RAFW, сгенерированный на основе модели топологии RSA, описанной на рис. 8.

Рисунок 20. Сгенерированный проект RAFW для установки модели топологии, содержащей WebSphere, DB2 и приложение
Screen capture shows generated RAFW project for installing a                     WebSphere and DB2 application  eTierDeployment topology model
Screen capture shows generated RAFW project for installing a WebSphere and DB2 application eTierDeployment topology model

During the execution of the TSAM provisioning service generated by the accelerator (как показано в этом разделе), последняя задача в плане управления вызывает сгенерированный проект RAFW или BF. Задача TSAM передает в него параметры, требуемые для установки приложения и конфигурирования промежуточного программного обеспечения согласно модели топологии (например, пароль администратора WebSphere Application Server) или согласно выходной информации предыдущих задач для инициализации виртуальных серверов или установки промежуточного программного обеспечения (например, имя хоста виртуальной машины, развернутой на хосте WebSphere Application Server). На рис. 21 показан пример среды с параметрами, передаваемыми в проект RAFW из TSAM.

Рисунок 21. Переменные среды для сгенерированного проекта RAFW
Screen capture shows environment variables for the generated RAFW project
Screen capture shows environment variables for the generated RAFW project

Теперь Дуг может в консоли RAF осуществлять мониторинг состояние задания BF.

Рисунок 22. Результаты задания RAF, отражающие состояние выполняемой автоматизации (установка приложения и конфигурирование промежуточного программного обеспечения)
Screen capture shows RAF job results reflecting the status of the                     executed automation for installing apps  and configuring middleware
Screen capture shows RAF job results reflecting the status of the executed automation for installing apps and configuring middleware

Заключение

В статье были описаны моделирование и автоматизация дополнительного системы хранения данных для удовлетворения потребностей приложения с помощью акселератора IBM Deployment Planning and Automation for the Cloud.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Rational
ArticleID=996391
ArticleTitle=Автоматическая инициализация ресурсов хранения данных для удовлетворения потребностей приложения с помощью расширений Rational
publish-date=01302015