Системы IBM® PureApplication® представляют готовые к применению возможности, которые улучшают процесс создания и доставки облачных решений, упрощая создание и повторное использование приложений и топологий. Заказчики получают инфраструктурные шаблоны экспертных знаний от корпорации IBM и ее партнеров, а также платформу, оптимизированную для корпоративных приложений. Но какое место занимает платформа PureApplication в публичных, частных и гибридных облачных сценариях? В статье объясняется, какой именно элемент семейства PureApplication - PureApplication System, PureApplication Software или PureApplication Service - следует предпочесть для того или иного облака.

Введение

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

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

Системы IBM® PureApplication® представляют готовые к применению возможности, которые улучшают процесс создания и доставки облачных решения, упрощая создание и повторное использование приложений и топологий. Заказчики получают инфраструктурные шаблоны экспертных знаний от корпорации IBM и ее партнеров, а также платформу, оптимизированную для корпоративных приложений. Кроме того, системы PureApplication хорошо интегрируются с Docker-контейнерами, с Chef-рецептами, с IBM Bluemix™ и с OpenStack.

Семейство продуктов PureApplication

В семейство продуктов PureApplication входят три элемента:

• IBM PureApplication System
• IBM PureApplication Software
• IBM PureApplication Service

PureApplication System - это конфигурация типа cloud-in-a-box. Это полностью интегрированная система, которая включает в себя аппаратные средства, программное обеспечение, гипервизоры и сетевые устройства, сконцентрированные в одном физическом конструктиве и управляемые через единую консоль. Система PureApplication System поставляется в нескольких конфигурациях, поддерживающих процессорные ядра с архитектурой x86 или POWER.

PureApplication Software - это программная версия механизма развертывания и консоли управления PureApplication. Чтобы воспользоваться этим элементом семейства PureApplication, заказчик должен задействовать собственные аппаратные средства. Вместо того чтобы приобретать систему типа cloud-in-a-box, заказчик может воспользоваться имеющейся у него инфраструктурой. Для этого ему нужно установить программное обеспечение на виртуальной машине, исполняющейся на гипервизоре VMware VSphere Hypervisor, а затем сконфигурировать его для работы с одним или несколькими существующими гипервизорами, включая тот же гипервизор, который осуществляет хостинг самого программного обеспечения PureApplication Software.

PureApplication System поддерживает операционные системы Red Hat Linux®, Windows® или AIX® (в зависимости от архитектуры используемых процессоров: x86 или POWER®). PureApplication Software на данный момент поддерживает только следующие операционные системы: RHEL 5.x, RHEL 6.x (32-bit и 64-bit), Windows 2008 R2 (64-bit), Windows 2012 (64-bit) и Windows 2012 R2 (64-bit).

PureApplication Service on SoftLayer® - этот элемент базируется на той же идее, что и элемент PureApplication Software, но пользуется глобальными центрами обработки данных SoftLayer, чтобы предоставлять возможности дистанционно. Этот сервис предоставляет выделенные аппаратные средства, сконфигурированные как PureApplication Software в облаке IBM SoftLayer. PureApplication Service также базируется на архитектуре x86 и на технологии виртуализации VMware.

Шаблоны, разработанные с использованием одного из элементов семейства PureApplication, можно совместно использовать с другими элементами (с небольшими изменениями или вообще без таковых). Например, шаблон, созданный в системе PureApplication на площадке заказчика, можно развернуть в облачной среде SoftLayer (за пределами этой площадки) с помощью сервиса PureApplication Service on SoftLayer.

Модели доставки облачных сервисов

Облако предлагает три модели доставки сервисов: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) и Software as a Service (SaaS). Эти модели определяют уровень совместного использования и возможности мультиаренды, которые поставщик облачных услуг может предложить своим пользователям. Как показано на рис. 1, на каждом уровне стека арендаторы совместно используют компоненты, которые являются частью соответствующей модели доставки.

Рисунок 1. Облачные модели доставки

Infrastructure as a Service (Инфраструктура как сервис)

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

Platform as a Service (Платформа как сервис)

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

Software as a Service (программное обеспечение как сервис)

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

Модели развертывания облака

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

Рисунок 2. Модели развертывания облака

Публичное облако

Публичное облако открыто для общественности. Облачная инфраструктура существует на площадке поставщика облачных сервисов. Она может принадлежать одному или нескольким субъектам, которые могут управлять этой инфраструктурой и эксплуатировать ее. Один из главных доводов в пользу перехода компании в публичное облако - замена ее капитальных затрат (CAPEX) эксплуатационными расходами (OPEX). Публичное облако использует модель тарификации pay as you go (тарификация по потреблению услуг), при которой потребителю не нужно заранее покупать необходимые аппаратные средства в расчете на пиковое потребление и не нужно беспокоиться о точном прогнозировании требуемых ресурсов. Эта модель тарификации, которую часто называют utility computing, позволяет потребителям использовать компьютерные ресурсы подобно обычным коммунальным услугам. Они платят только за то, что они используют, при этом у них создается впечатление о наличии неограниченных ресурсов, доступных по требованию. В этой модели развертывания потребители обычно не заботятся о том, где или на каких аппаратных средствах осуществляется обработка. Они уверены в том, что поставщик облачного сервиса поддерживает необходимую инфраструктуру, чтобы исполнять их приложения и предоставлять запрашиваемые услуги согласно соответствующему Соглашению об уровне обслуживания (SLA).

Частное облако

Частное облако развертывается для монопольного использования одной организацией. Организация или третья сторона может владеть этим облаком, управлять им и осуществлять его хостинг; инфраструктура этого облака может существовать на площадке этой организации или за ее пределами. Если управление облаком осуществляет третья сторона, оно называется управляемым частным облаком. Если хостинг частного облака и управлением им осуществляется за пределами организации, оно называется хостинговым частным облаком. Например, инфраструктура IBM SoftLayer осуществляет хостинг публичного облака, но предоставляет и услуги для частного облака, с помощью которых потребитель может создать используемые им виртуальные серверы, управлять ими и иметь над ними полный контроль.

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

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

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

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

Гибридное облако

Гибридное облако состоит из двух или нескольких различных облачных инфраструктур, которые остаются обособленными друг от друга, но совместно используют технологии, которые позволяют портировать данные и приложения между облаками. Гибридные облачные решения дают возможность взаимодействия рабочих нагрузок, управление которыми можно осуществлять в масштабе нескольких облачных сред, включая доступ к сторонним ресурсам и к партнерской сети клиента. Идея состоит в том, чтобы беспрепятственно связывать приложения на своей площадке - созданные своими силами, пакетные или исполняющиеся в частном облаке - с облаками на других площадках. Системы PureApplication отлично проявляют себя в этой области, поскольку организация может создать и развернуть шаблоны на своей площадке с помощью PureApplication System или PureApplication Software, а также развернуть эти шаблоны за пределами своей площадки в инфраструктуре SoftLayer с помощью сервиса PureApplication Service on SoftLayer.

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

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

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

Облако сообщества

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

Существенные характеристики облачной среды

Национальный институт стандартов и технологий США (NIST)был основан в 1901 году, чтобы стимулировать в США инновации на основе науки об измерениях, а также стандартов и технологий. Эта организация сформулировала пять существенных характеристик любой облачной среды.

• Широкий сетевой доступ

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

• Самообслуживание по требованию

  Среда должна поддерживать модель "сделай сам", позволяющую потребителям инициализировать ресурсы автоматизированным образом через веб-браузер или через API-интерфейс без взаимодействия человека с поставщиком сервиса.

  Помимо пользовательского интерфейса, который предоставляет консоль рабочих нагрузок и консоль администрирования для создания, развертывания и управлять облачными решениями на основе шаблонов, системы PureApplication System предлагают интерфейс REST API и интерфейс командной строки, которые позволяют поставщикам сервисов самостоятельно создать собственные интерфейсы для потребителей.

• Объединение ресурсов в пул

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

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

• Быстрое эластичное выделение ресурсов

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

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

  Не все рабочие нагрузки одинаковы. Например, у рабочей нагрузки с интенсивным использованием средств ввода/вывода потребности в ресурсах отличаются от потребностей рабочей нагрузки с интенсивным использованием процессоров или памяти. Кроме того, не всем рабочим нагрузкам требуется одинаковый уровень качества обслуживания (QoS). Выяснение того, какие рабочие нагрузки исполняются наилучшим образом в различных средах, может оказаться весьма эффективным способом снижения затрат. Именно в этой сфере важную роль играют гибридные облака и, в частности, продукты семейства PureApplication.

  Планирование ресурсов для конкретных рабочих нагрузок может быть трудным делом. Как показано на рис. 3, обычные болевые точки хорошо известны: выделение недостаточного объема ресурсов для удовлетворения потребностей рабочей нагрузки неблагоразумно и приводит к простою. И наоборот, завышенная оценка потребностей в ресурсах приводит к недостаточному использованию или к простою одного или нескольких серверов. Даже правильного выделения объема ресурсов в расчете на пиковое потребление недостаточно, поскольку потребности рабочей нагрузки подвержены флуктуациям, и часть ресурсов будет тратиться понапрасну в те моменты, когда система работает не на пиковом уровне. Например, после завершения цикла тестирования нагрузка на аппаратные ресурсы может значительно снизиться. Даже при наилучшем планировании ресурсов возможны случаи, в которых потребности рабочей нагрузки попросту непредсказуемы. Идеальная ситуация состоит в выделении лишь того объема ресурсов, который требуется в любой заданный момент времени. Эта характеристика называется эластичностью; она имеет большое значение для любой облачной среды.

  Рисунок 3. Эластичность

  
• Измерение объема услуг

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

Все о виртуальных шаблонах

В основе каждой системы PureApplication лежит так называемый механизм шаблонов (pattern engine). Механизм шаблонов присутствует в каждом из трех элементов семейства продуктов PureApplication, а также в других облачных предложениях IBM, таких как IBM SmartCloud Orchestrator.

Механизм шаблонов позволяет использовать следующие методы развертывания.

• Виртуальные аппаратно-программные комплексы

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

  Виртуальные аппаратно-программные комплексы представляют собой переносимые самодостаточные конфигурации комплекта программного обеспечения. Их также называют виртуальными образами. Обычно они создаются для развертывания одного бизнес-приложения. Формат виртуальных устройств соответствует отраслевому стандарту Open Virtualization Format (OVF) от организации Distributed Management Task Force (DMTF). Все компании, участвующие в этой организации (в том числе IBM, VMware, Citrix, Microsoft и Oracle), поддерживают стандарт OVF в своих продуктах.

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

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

  Рисунок 4. Виртуальные аппаратно-программные комплексы

  

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

• Шаблоны виртуальных систем

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

• Классические шаблоны виртуальных систем

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

• Шаблоны виртуальных приложений

  Шаблон виртуального приложения (другое название - шаблон рабочей нагрузки) - это ориентированный на приложение подход к развертыванию приложения в облаке. Шаблоны виртуальных приложений позволяют не беспокоиться о топологии, необходимой для исполнения приложения, но вместо этого определяют приложение (например, с помощью ear-файла) и набор политик в соответствии с соглашением об уровне обслуживания (SLA), которое необходимо соблюдать. После этого система PureApplication преобразует эту входную информацию в установленную, сконфигурированную и интегрированную среду промежуточного уровня для приложений. Кроме того, система осуществляет автоматический мониторинг потребностей рабочей нагрузки приложения, корректирует распределение ресурсов и подстраивает приоритезацию с целью соблюдения заданных политик. Шаблоны виртуальных приложений реализуют специфические решения, основанные на экспертных знаниях, полученных за много лет, и на наилучших методиках.

• Выбор надлежащего типа шаблона

  Очевидно, что использование шаблонов виртуальных приложений минимизирует объем работы; в определенном смысле, это идеальная ситуация. Так, вы можете создать приложение и позволить платформе PureApplication самой беспокоиться об инфраструктуре, необходимой для поддержания заданного качества обслуживания. Это обещает самую низкую совокупную стоимость владения и минимальное время до получения экономического эффекта. Однако не все конфигурации полностью соответствуют доступному типу "шаблон виртуального приложения". В некоторых случаях требуется более гранулярный контроль.

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

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

Понятие о гипервизорах, виртуальных машинах и контейнерах

Использование виртуализации для консолидации ресурсов, уменьшения занимаемого пространства и сокращения расходов на энергию - это один из ключевых факторов, обеспечивающих работоспособность облачных вычислений. Корпорация IBM первой создала технологию виртуализацию в 1960-х годах для мультиплексирования своих дорогих компьютеров-мэйнфреймов. В 1967 году на рынке появилась первая полностью виртуализированная машина IBM S/360-67, а в 1972 году поддержка виртуальных машин стала стандартной характеристикой всех мэйнфреймов S/370.

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

Как показано на рис. 5, существует два типа гипервизоров: гипервизоры типа 1, исполняющиеся непосредственно на физических аппаратных средствах, и гипервизоры типа 2, которым требуется наличие исполняющейся операционной система хоста. Примеры гипервизоров типа 1: IBM z/VM®, IBM PowerVM®, and VMWare VSphere/ESX/ESXi Server for Windows®. Другие примеры: Citrix Xen и Microsoft® Hyper-V®. Поскольку гипервизоры типа 1 исполняются непосредственно поверх аппаратных средств, они также носят название нативные гипервизоры или гипервизоры "на железе".

Рисунок 5. Типы гипервизоров

Примеры гипервизоров типа 2: VMWare Workstation, VMWare Server, Kernel-Based Virtual Machine (KVM) и Oracle® VM VirtualBox. Гипервизоры типа 2 также носят название хостинговые гипервизоры.

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

Контейнеры Linux Container

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

Две основных отличительных особенности контейнеров Linux Container - это пространства имен и группы контроля (cgroup). Пространства имен изолируют ресурсы Linux на уровне процесса, гарантируя, что контейнер видит только свою собственную среду, а группы cgroup позволяют контролировать, аудитировать и изолировать ресурсы, которые может использовать коллекция процессов.

Docker-контейнеры

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

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

В состав Docker также входит публичный реестр для обмена приложениями под названием Docker Hub, насчитывающий более 13000 контейнеров (число которых непрерывно растет). Эти контейнеры готовы к повторному использованию или к использованию в качестве базовых образов для новых контейнеров.

Платформа PureApplication поддерживает использование Docker-контейнеров в шаблонах в элементе PureApplication System (модели W2500 и W1500) и в элементе PureApplication Software. Если в вашей системе установлен и активирован шаблон типа Docker Pattern, вы можете с помощью инструмента pattern builder размещать Docker-контейнеры как компоненты программного обеспечения на холсте шаблона виртуальной системы. На Docker-контейнеры можно ссылаться из Docker Hub или из частного реестра Docker, уже включенного в систему PureApplication System.

Платформа PureApplication позволяет создавать и развертывать приложения с одним и несколькими Docker-контейнерами, также обеспечивает оркестровку многоузловых Docker-контейнеров. Внутри инструмента pattern builder контейнеры в разных узлах можно соединить простым связыванием. Кроме того, PureApplication позволяет обновлять образы контейнеров и распространять эти изменения между контейнерами, а также масштабировать создаваемые контейнеры и их количество.

Поддержка Chef

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

Каждая машина в Chef-системе играет определенную роль:

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

Платформа PureApplication поддерживает использование технологии Chef в элементе PureApplication System (модели W2500, W2700, W1500 и W1700) и в элементе PureApplication Software. Интеграция PureApplication с технологией Chef порождает такие новые возможности, как развертывание экземпляров шаблона с узлами, способными автоматически обновить себя на основе так называемых "рецептов" (recipe), передаваемых на Chef-сервер. Кроме того, в открытом сообществе Chef имеются тысячи рецептов, которые можно многократно использовать и внедрять в шаблоны PureApplication. Можно также создавать собственные рецепты и загружать их на Chef-сервер из среды PureApplication.

Рисунок 6. Развертывание Chef на платформе PureApplication

На рис. 6 показано, каким образом развертывание Chef поддерживается на платформе PureApplication.

1. Внутри PureApplication можно через внешний общий сервис соединиться с Chef-сервером и добавлять Chef-клиенты как программные компоненты на узлы PureApplication шаблона виртуальной системы.
2. Chef-клиенты могут быть узлами, представляющими собой виртуальные машины, или Docker-контейнерами внутри виртуальной машины. Chef-клиенты, развернутые при посредстве PureApplication, также используют общий сервис для коммуницирования с Chef-сервером.
3. Chef-сервер содержит рецептурные справочники (cookbook) и рецепты, описывающие, как определить, инициализировать и сконфигурировать ресурсы приложения в Chef-клиентах. Рецепты Chef представляют собой конфигурационные задачи или инструкции, описывающие установку и конфигурирование ресурсов на узле. Рецептурный справочник - это коллекция связанных рецептов.
4. Chef-клиенты периодически опрашивают Chef-сервер относительно обновлений в рецептурных справочниках или в настройках. Если обновления доступны, клиент извлекает соответствующий контент из сервера. PureApplication позволяет вам указать, как часто клиенты должны опрашивать сервер относительно обновлений.
5. Chef-сервер отсылает последние версии рецептурных справочников и рецептов запрашивающим эту информацию клиентам. Каждый Chef-клиент обновляет себя с помощью конфигурационной информации, которую он получает от сервера.
6. Рабочая станция Chef - это любая внешняя машина (например, ваш ноутбук), которая сконфигурирована как локальный репозитарий Chef и на которой установлен и сконфигурирован инструмент Knife. Knife - это инструмент командной строки, который, помимо прочего, позволяет выгружать рецептурные справочники и рецепты на Chef-сервер. Вы создаете и редактируете конфигурации и определения на рабочей станции, а затем, до отсылки этой информации на сервер, передаете их механизму управления версиями. Платформа PureApplication позволяет добавлять рецепты непосредственно для исполнения на этапе установки.
7. Инструмент Knife также регулярно используется для коммуницирования с узлами по SSH.

OpenStack

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

Основные сервисы OpenStack:

• Horizon: Информационная панель
• Heat: Оркестровка
• Nova: Вычислительные компоненты
• Cinder: Блочное хранилище
• Trove: База данных
• KeyStone: Идентификационные сервисы
• Neutron: Сеть
• Swift: Хранилище объектов
• Glance: Образы

В рамках общей открытой стратегии развития платформы PureApplication осуществляется непрерывное наращивание поддержки OpenStack. На данный момент на уровне technology preview на платформе PureApplication поддерживается потребление и развертывание шаблонов типа Heat Orchestration Template (HOT), а также доступ к экземплярам приложения через интерфейс OpenStack Services REST API. Конечная цель состоит в том, чтобы использовать формат HOT в качестве внутреннего представления шаблонов в механизме шаблонов.

PureApplication и Bluemix

IBM Bluemix - это IBM-реализация архитектуры Open Cloud Architecture. Платформа Bluemix, основанная на Cloud Foundry, позволяет очень быстро создавать и развертывать облачные приложения, а также управлять ими через веб-интерфейс. Bluemix исполняется на инфраструктуре SoftLayer и предлагает хорошее решение для быстрого создания фронтальных приложений в публичном облаке. Точкой интеграции с PureApplication являются облачные интеграционные сервисы Bluemix, которые позволяют интегрировать фронтальную часть с бэкенд-сервисами, исполняющимися на системе PureApplication.

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

Заключение

Говоря коротко, это был обзор доступных опций облачных вычислений и объяснение ценности платформы IBM PureApplication в сегодняшнем облачном мире. Вне зависимости от требуемого вам типа облачного решения - частного, публичного или гибридного - системы PureApplication с очень большой вероятностью смогут успешно решить все ваши задачи.