Облако и отраслевые приложения: Часть 3. Tелекоммуникационные решения

Совершенствование разработки и интеграции с помощью Service Storm

В этой третьей части нашей серии статей об отраслевых решениях, использующих облачные вычисления, вы узнаете о новом процессно-ориентированном PaaS-предложении. Service Storm представляет собой поддерживающую облако телекоммуникационную платформу для изготовления прототипов, работающую по модели PaaS на принципах самообслуживания. Узнайте, как эта модель для быстрой интеграции позволяет пользователям, не обладающим техническими знаниями, создавать приложения, объединяя зарегистрированные сервисы, гибридные приложения, встроенные правила, события и сервисы для работы с базами данных. Ознакомьтесь с тем, как облачные технологии и Service Storm расширяют возможности PaaS в телекоммуникационных решениях и корпоративных средах.

Синь Пэн Лю, программист-консультант и ведущий разработчик, IBM

Xin Peng Liu photoСинь Пэн Лю — программист-консультант и ведущий разработчик облачных услуг отдела передовых технологий IBM SOA подразделения IBM Software. Занимался проектированием и разработкой технологий и решений SOA в ряде важных проектов. В настоящее время занимается облачными вычислениями и отраслевыми решениями.



Юй Чэнь Чжоу, старший технический сотрудник и ведущий архитектор, IBM

Доктор Юй Чэнь Чжоу — старший технический сотрудник IBM Research в КНР. Будучи ведущим архитектором отдела облачных вычислений и проектирования решений Китайского центра по проектированию систем SOA отдела передовых технологий IBM SWG SOA, он организовал и возглавил ряд перспективных проектов, в том числе по отраслевым решениям, поддерживающим облачные вычисления, интегрированному управлению метаданными и политикам SOA. Является старшим членом IEEE и ACM, ведущим изобретателем IBM, членом технологической академии IBM; был членом рабочих групп W3C и TOG. Является основным автором книги Service Oriented Computing (Сервис-ориентированные вычисления), опубликовал 17 статей в материалах конференций IEEE, отчетах о научных исследованиях IBM и на портале IBM developerWorks.



Cи Нин Ван, штатный программист и ведущий разработчик, IBM

Xi Ning Wang photoСи Нин Ван — штатный программист и ведущий разработчик облачной инфраструктуры отдела передовых технологий IBM SOA подразделения IBM Software. Занимался проектированием и разработкой технологий и решений SOA в ряде важных проектов. В настоящее время занимается облачными вычислениями и отраслевыми решениями. Публикует статьи на IBM developerWorks с 2009 года.



Лян Сюэ, менеджер, IBM

Liang Xue photoЛян Сюэ — менеджер отдела передовых технологий IBM SOA подразделения IBM Software. Занималась проектированием и разработкой технологий и решений SOA. В настоящее время занимается облачными вычислениями и отраслевыми решениями.



Сяо Син Лян, штатный программист, IBM

Xiao Xing Liang photoСяо Син Лян — штатный программист отдела производительности бизнеса и оптимизации услуг подразделения IBM Software. Имеет богатый опыт разработки решений и технологий SOA, BPM и Web 2.0.



Чан Хуа Сунь, штатный программист, IBM

Chang Hua Sun photoЧан Хуа Сунь — штатный программист отдела производительности бизнеса и оптимизации услуг подразделения IBM Software. Занимается разработкой технологий и решений SOA и BPM.



Лян Шуан, программист, IBM

Shuang Liang photoШуан Лян — программист отдела производительности бизнеса и оптимизации услуг подразделения IBM Software. Имеет богатый опыт разработки решений и технологий SOA и BPM.



17.07.2012

Введение

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

В наши дни телекоммуникационные и ИТ-технологии стремительно сближаются. Поставщикам телекоммуникационных услуг с их огромными затратами на инфраструктуру необходимы:

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

Часто используемые сокращения

  • PaaS: платформа как сервис
  • SDP: платформа доставки услуг

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

SDP для телекоммуникационной отрасли представляет собой открытую горизонтальную основанную на стандартах платформу, позволяющую поставщику создавать и поставлять новые инновационные услуги. Для привлечения и обслуживания растущей базы абонентов поставщики телекоммуникационных услуг переходят от старых сетевых услуг, ориентированных на голосовую связь, к услугам, нацеленным на «длинный хвост», который охватывает много отраслей и сообществ. Услуги становятся более направленными, сфокусированными и персонализированными. Это создает определенные трудности для бизнес-моделей и технологий, используемых для разработки и внедрения таких дополнительных услуг. До сих пор телекоммуникационные сети и Интернет развивались независимо друг от друга в том, что касается программных приложений и технологий их разработки.

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

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

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

  • Телекоммуникационный оператор
  • Партнер по разработке дополнительных услуг
  • Предприятия, использующие телекоммуникационные приложения
  • Отдельные потребители

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


Service Storm

Изучив поставщиков телекоммуникационных и мобильных телекоммуникационных услуг на опыте работы с десятками заказчиков и проанализировав требования и проблемы экономической и технической моделей, мы создали Service Storm — облачную телекоммуникационную SDP на основе модели PaaS, работающую по принципу самообслуживания. Service Storm удовлетворяет требования разных ролей экосистемы, используя Web 2.0 и другие технологии виртуализации. Она отличается от обычных корпоративных или партнерских моделей разработки тем, что поддерживает модель «открытого сообщества разработки»; каждый может быстро разрабатывать телекоммуникационные приложения с учетом требований конкретной сферы применения, сообщества или даже нужд конкретного пользователя.

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

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

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

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

Телекоммуникационный оператор
Телекоммуникационный оператор разрабатывает и размещает у себя дополнительные услуги для публичных сообществ, которые вписываются в обычную бизнес-модель дополнительных услуг. Здесь существует потребность в более мощной и гибкой модели разработки и инфраструктуре, позволяющих сократить время вывода на рынок сильно дифференцированных дополнительных услуг для небольших сообществ пользователей.
Бизнес-партнер
Бизнес-партнер разрабатывает дополнительные услуги для публичных групп пользователей и делится прибылью с телекоммуникационным оператором. Требования здесь аналогичны требованиям к телекоммуникационному оператору, но с некоторыми дополнениями: необходимо снизить стоимость размещения среды разработки; необходима среда для тестирования и поставки продукта, совместимая со стандартами телекоммуникационной отрасли.
Корпоративный пользователь
Традиционно корпоративный пользователь владеет специализированными приложениями, которые являются частью корпоративной системы, и пользуется телекоммуникационными услугами, такими как мобильные решения для управления рабочим персоналом и фронтальные системы управления отношениями с клиентами — что особенно характерно для малых и средних предприятий с недостаточно мощной информационной инфраструктурой.

Требование заключается в снижении стоимости обслуживания ИТ-инфраструктуры за счет частичного аутсорсинга и быстрой разработки и развертывания новых приложений.

Платформа Service Storm нацелена на удовлетворение требований всех четырех категорий пользователей. Архитектура Service Storm показана на рисунке 1.

Рисунок 1. Архитектура Service Storm
Архитектура Service Storm

В этой архитектуре:

  • Сборщик услуг— визуальный инструмент для задания логики работы приложения путем перетаскивания мышью. Вы можете интегрировать телекоммуникационные услуги (SMS, MMS, услуги, предоставляемые с учетом местоположения (LBS)) и другие элементы, включая интерфейс пользователя Web 2.0 и внешние услуги сторонних поставщиков, для реализации дополнительных услуг. Кроме того, вы можете автоматически генерировать разворачиваемые объекты без написания программного кода.
  • Компоненты управления предоставляют функции управления для SDP во взаимодействии с системой биллинга и операционной поддержки. Имеются следующие компоненты управления:
    • Управление услугами— используется для управления телекоммуникационными услугами, раскрываемыми в SDP, внешними услугами сторонних поставщиков, зарегистрированными в SDP, и вновь создаваемыми приложениями
    • Управление решениями— используется для управления решениями, реализующими услуги и развернутыми в облачной среде
    • Управление облаком— используется для управления вычислительными ресурсами как облачной инфраструктурой
  • Платформа для исполнения приложений— создается в облачной среде и предоставляет среду исполнения для размещения приложений дополнительных услуг. Обычно состоит из серверов приложений, серверов процессов и других сред исполнения, предназначенных для обработки бизнес-правил, событий и рабочих состояний.
  • Инфраструктура облака— облачная среда, обеспечивающая централизованное управление виртуализированными вычислительными ресурсами для базовых функций в целях совместного использования ресурсов и сокращения затрат.

Элементы инфраструктуры

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

  • Высоких требований к качеству сервиса поддерживаемых приложений
  • Затрат на управления ресурсами

Перед развертыванием приложения необходимо зарезервировать для него среду исполнения с необходимыми ресурсами, причем эта среда должна создаваться в SDP автоматически. Для обеспечения безопасности Service Storm гарантирует изоляцию зарезервированных ресурсов от других групп пользователей с помощью трехуровневого механизма изоляции ресурсов. В то же время ресурсы, выделенные поставщику услуг, могут масштабироваться в обе стороны в зависимости от размера группы пользователей и меняющихся бизнес-требований. Механизм планирования ресурсов помогает более эффективно управлять ими с учетом требований, исходящих от разных ролей.

Изоляция ресурсов

Концепция облачных вычислений позволяет исполнять услуги на арендованных вычислительных платформах, тем самым отделяя поставщика услуг от владельца платформы и от поставщика облачной инфраструктуры. Эта модель подразумевает, что поставщик инфраструктуры обеспечивает возможность надежной изоляции услуг друг от друга. Service Storm состоит из физических ресурсов, включающих хост-системы, ЦП, память, дисковое пространство и сети. Программные ресурсы Service Storm включают операционную систему, промежуточное ПО и приложения.

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

Уровень приложения
Изоляция на уровне приложения гарантирует надлежащее разделение данных приложений и бизнес-логики. Конечные пользователи не могут получить несанкционированный доступ к данным и бизнес-логике других пользователей. Информация, относящаяся к учетной записи каждого конечного пользователя, привязывается к приложениям. Только авторизованные конечные пользователи могут получить доступ к приложению, предоставляемому соответствующим поставщиком услуг. Такая изоляция гарантирует, что конечные пользователи будут иметь доступ к приложениям, созданным специальной группой телекоммуникационных операторов или деловых партнеров. Приложения разных групп пользователей, телекоммуникационных операторов и деловых партнеров изолируются друг от друга.
Уровень сети
Для повышения безопасности и эффективности сети часто используется сетевая изоляция, которая изолирует определенный сетевой трафик в определенных физических сетях. Существуют два распространенных способа такой изоляции:
  • Физическая изоляция, разрывающая физические соединения между физическими узлами
  • Логическая изоляция, при которой для изоляции обычно используется специальное программное обеспечение
Применение виртуальных машин, подключенных к виртуальным сетям и виртуальным коммутаторам, позволяет обеспечить эффективную изоляцию сети для физических серверов и работающих на них виртуальных машин.
Уровень виртуальной машины
Разные виртуальные машины, работающие на одной физической машине, изолированы друг от друга. Монитор виртуальных машин должен обеспечивать изоляцию виртуализированных гостевых сред и хост-систем как при паравиртуализации, так и при полной виртуализации систем. Программы, работающие на виртуальной машине, не имеют доступа к программам, работающим на мониторе виртуальной машины или на другой виртуальной машине, и не могут изменять их. Пример изоляции виртуальных ресурсов показан на рисунке 2.
Рисунок 2. Изоляция виртуальных ресурсов
Изоляция виртуальных ресурсов

Управление ресурсами и масштабирование

Под загрузкой ресурсов обычно понимается используемая емкость системы хранения, используемая полоса ввода/вывода, загрузка ЦП и занятый объем памяти. Функции быстрого перераспределения ресурсов предлагают гибкие механизмы обеспечения оперативности бизнеса. Поставщикам телекоммуникационных услуг необходимы разные функции, уровни качества и масштабы ресурсов. Например, поставщику ключевого бизнес-процесса необходимо больше виртуальных ресурсов для сокращения времени реагирования и повышения уровня доступности. Поставщику вспомогательных услуг выделяется меньше ресурсов или предоставляется доступ к общим ресурсам для сокращения расходов. Гибкость легко достигается за счет настройки виртуальных ресурсов в инфраструктуре облака.

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

Допустим, бизнес-услуга повысила требования к ресурсам, чтобы улучшить качество обслуживания. Для повышения качества услуге необходимо больше ресурсов. Решить эту проблему можно путем исполнения промежуточного ПО на кластерных системах. Встроенные в Service Storm виртуальные шаблоны предлагают топологии, включающие как автономные серверы приложений, так и кластеры, как для нормальной, так и для повышенной производительности системы. Для выполнения масштабирования, будь то для увеличения числа конечных пользователей или для обеспечения высокого уровня доступности, корпоративный пользователь просто выбирает соответствующее качество сервиса в Service Storm. Соответствующие виртуальные ресурсы выделяются автоматически в соответствии с требованиями к качеству сервиса.

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

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

Планирование ресурсов

Планирование ресурсов включает:

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

Предлагаемая в Service Storm функция планирования ресурсов учитывает особенности разных ролей. Телекоммуникационный оператор и бизнес-партнер могут наложить ограничения на изначально выделяемые ресурсы и указать верхние пределы для будущего роста. Кроме того, в соглашении об уровне сервиса они могут определить условия добавления и возврата ресурсов.

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

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

Масштабирование системы

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

Вертикальное масштабирование означает изменение ресурсов работающих сервисных узлов в зависимости от реально наблюдаемых характеристик. При масштабировании вверх в развернутые сервисные узлы добавляются ресурсы ЦП или объем памяти; при масштабировании вниз ресурсы ЦП или объем памяти уменьшаются.

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


Интеллектуальное развертывание и мониторинг

Для гибкости и эффективности SDP среда исполнения (включая операционную систему, сеть, промежуточное ПО и приложения) должна создаваться и настраиваться автоматически. Принятая в Service Storm модель развертывания содержит гибкую комбинацию шаблонов виртуальных машин, сетевых ресурсов и автоматических скриптов. Развертывание в целом становится настраиваемым; в отличие от традиционного развертывания единичных решений, компоненты допускают гибкую настройку. Кроме того, Service Storm предоставляет агрегированные представления бизнеса и средства мониторинга инфраструктуры, которые существенно облегчают управление средой исполнения после развертывания.

Настраиваемая модель развертывания

Для реализации автоматического развертывания в Service Storm предусмотрена полная модель развертывания со следующими элементами.

Шаблон виртуальной машины
Операционная система и промежуточное ПО интегрируются в один шаблон виртуальной машины, как показано на рисунке 3. При этом для конкретного шаблона виртуальной машины определяются точки настройки ОС и промежуточного ПО, которые может настраивать поставщик услуг. Существуют три типа точек настройки: специальные точки настройки программного обеспечения, точки настройки уровня ОС и свойства базовых аппаратных ресурсов.
Сетевые ресурсы
Service Storm предоставляет средства централизованного управления сетью, в том числе:
  • Резервирование внутренних сетевых адресов для виртуальных машин
  • Настройка адресов и портов для внешних услуг
  • Маршрутизация к внутренним виртуальным системам
Конечный пользователь не может вручную указывать эти значения для управления развернутой средой.
Автоматические скрипты
Автоматические скрипты настраивают или перенастраивают ресурсы конкретной точки настройки. Service Storm использует во время настройки специальные автоматические скрипты в рамках единой модели. Все этапы настройки выполняются организованно; вызов соответствующих автоматических скриптов освобождает поставщика услуг от необходимости настройки базовой инфраструктуры.
Рисунок 3. Автоматическое развертывание приложения во время исполнения
Автоматическое развертывание приложения во время исполнения

После развертывания Service Storm выбирает шаблоны виртуальных машин из хранилища шаблонов и привязывает к ним необходимые автоматические скрипты настройки, как показано на рисунке 3.

Развертывание решения

Service Storm предлагает возможности развертывания полных решений, а также развертывания и настройки отдельных компонентов. Для достижения гибкости в сфере телекоммуникаций необходимо, чтобы SDP предоставляла быстрый и простой метод автоматического развертывания либо решения в целом, либо отдельных ресурсных компонентов .

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

Агрегированные представления для мониторинга

Другой важной функцией SDP является мониторинг с целью контроля рабочего состояния физических и программных ресурсов. В платформе Service Storm, основанной на модели PaaS, можно выбирать для мониторинга конкретные ресурсы, такие как время реакции экземпляра бизнес-процесса и состояние ресурсов виртуальной системы (ЦП, память и дисковое пространство).

Данные мониторинга бизнес- ресурсов и инфраструктуры объединяются для пользователя в едином представлении. Оно предоставляет глобальный интегрированный обзор состояния всей SDP, помогая снизить операционные риски SDP и существенно упрощая оперативное реагирование на аварийные ситуации. Измеренные ключевые показатели эффективности (KPI) бизнес-процессов отображаются в портале мониторинга Service Storm, как показано на рисунке 4.

Рисунок 4. Контролируемые KPI бизнес-процесса
Контролируемые KPI бизнес-процесса

Ресурсы

Комментарии

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=Open source
ArticleID=826235
ArticleTitle=Облако и отраслевые приложения: Часть 3. Tелекоммуникационные решения
publish-date=07172012