Распродажа складских остатков ключей Corel Выбирайте настоящее ПО Microsoft

 

 

 

 

 

 

 

В статье описывается моделирование и автоматизация ресурсов хранения данных для удовлетворения дополнительных потребностей приложения с использованием акселератора IBM Deployment Planning and Automation for the Cloud 2.1.0. Этот свободно загружаемый акселератор устанавливается поверх IBM Rational® Software Architect, IBM Rational Automation Framework и IBM Tivoli® Service Automation Manager и интегрируется с их возможностями. В статье рассматривается применение этого инструмента с целью задания специальных требований к хранению данных для компонентов приложения в виртуальных образах с помощью модели топологии развертывания и использование этой информации для генерации артефактов автоматизации развертывания, которые инициализируют элементы системы хранения и присоединяют их к виртуальным машинам в облаке.

В статье 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. Сквозная автоматизация всех шагов развертывания

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

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

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

Рисунок 2. Пример сценария развертывания

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

С помощью акселератора Салли может спроектировать требуемую модель топологии развертывания с модулем модели сервера, состоящим из модуля модели веб-сервера (такого как 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 и компоненты приложения

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

Рисунок 4. Связь между модулем модели и EAR-файлом приложения, хранящимся в активе RAM

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

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

Рисунок 5. Добавление модуля системы хранения к топологии

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

Рисунок 6. Добавление модуля системы хранения к топологии

В модуле 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

   
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. Ввод данных о необходимой системе хранения в модуле дисковой системы хранения

   

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

Рисунок 9. Готовая топология с сервером WebSphere Application Server, сервером DB2, приложением и ресурсами хранения в виртуальном образе VMware

 

Генерация специальных определений сервиса продукта 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

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

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

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

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

Рисунок 11. Пример сигнатуры автоматизации для развертывания виртуальных серверов с использованием TSAM

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

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

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

Рисунок 12. Результаты работы публикатора

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

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

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

Рисунок 13. Поток работ автоматизации Rational с новым созданным глобальным параметром DevTeamAssetVersion

Рисунок 14. Отображение нового созданного глобального параметра на существующий параметр автоматизированной задачи

После этой настройки Салли и Сэм смогут сгенерировать артефакт 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

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

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

Рисунок 16. Задание категории и каталога для нового сервиса, созданного после импорта

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

Рисунок 17. Новое определение сервиса создано для артефакта Cloud Service Archive

 

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

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

Рисунок 18. Операции управления для применения к облачному сервису, созданному в результате импорта

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

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

При поступлении запроса на инициализацию сервиса механизм 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 и приложение

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

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

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

 

Заключение

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