Облачные вычисления

Термин “облачные вычисления” (cloud computing) сегодня уже достаточно хорошо известен и в IT и в бизнес кругах. Почти каждую неделю появляются новые статьи, книги, презентации об облачных вычислениях – новой сервисной модели предоставления вычислительных услуг. Эта тема стала очень модной и перспективной [4]. Почему же я тоже решил внести свою лепту в этот поток статей?

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

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

1. 
   Что такое облачные вычисления?
   

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

Первыми возможности облачных вычислений оценили американцы. CIO американского правительства Вивек Кундра (Vivek Kundra) в феврале 2011 года опубликовал стратегию американского правительства по переносу части информационных систем в облако. Документ под названием “Federal Cloud computing Strategy” [2] четко описывает порядок и сроки переноса части систем в облако. Работы уже начались. Их цель – уменьшить сложность и повысить управляемость

Рис 1. Эволюция архитектуры информационных систем

IT, увеличить загрузку оборудования до 70-80%, уменьшить количество центров обработки данных (ЦОД) (сейчас у правительства США их более 800).

Итак, что же такое облачные вычисления? Существует много определений этого термина, но мы будем ориентироваться на определение, данное американским институтом стандартов и технологий (NIST). Оно гласит, что облачные вычисления - это вычислительная модель, обеспечивающая быстрый, простой и удобный сетевой доступ к пулу вычислительных ресурсов (сеть, сервера, диски, приложения и сервисы) по требованию, причем такой доступ требует минимального привлечения администраторов или сервис провайдеров. О

• 
  Выделение вычислительных ресурсов по требованию
  
• 
  Выделение требуемого пула вычислительных ресурсов из большого пула ресурсов
  
• 
  Эластичность (т е размер выделяемых ресурсов может меняться по мере необходимости)
  
• 
  Оплата по мере использования ресурсов
  
• 
  Доступ к выделяемым ресурсам по сети (т е с помощью веб броузера)
  

• 
  Вся IT инфраструктура находится не у нас, а где-то там, в облаке, часто мы даже не знаем где и сколько там есть ресурсов. Наше дело – попросить и быстро получить требуемые вычислительные ресурсы (например, компьютер с определенной операционной системой и мощностью, или базы данных определенных размеров и версий) Причем не мы отвечаем за обеспечение надежности работы системы, администрирование и настройку, резервное копирование и восстановление, обеспечение безопасности. Этим где-то там занимаются специально обученные люди.
  
• 
  Заказать, получить и использовать ресурс мы можем с любого устройства, где есть веб броузер – это может быть ноутбук, iPad, смартфон или любой компьютер организации. Интерфейс веб броузера прост и всем хорошо знаком, он не требует дополнительного изучения.
  
• 
  Развертывание требуемого нам ресурса происходит быстро, т е через несколько десятков минут после ввода требования мы уже можем получить затребованный ресурс и начать с ним работать. Это очень важно для развития бизнеса. В традиционной модели развертывание нового вычислительного ресурса занимает недели и месяцы.
  
• 
  Эластичность означает, что размер выделенного компьютера (его памяти, дисков, количество процессоров) может расти (или уменьшаться) по мере изменения наших требований. Например, при росте числа пользователей или пиковых нагрузках мы можем быстро добавить ресурсов нашему компьютеру или нашей СУБД
  
• 
  Еще одним важным преимуществом облачной модели вычислений является то, что оплату полученного и используемого вычислительного ресурса мы производим по факту использования. Т е если мы заказали компьютер, поработали с ним 2 часа, потом неделю отдыхали и снова поработали 2 часа, то мы платим всего за 4 часа работы, а можно сделать еще более гибкую модель оплаты, которая учитывает использование процессора, памяти, дисков, тех или иных программных продуктов и т д. В любом случае, поскольку мы используем разделяемый пул ресурсов, цена будет намного ниже, чем при традиционном подходе.
  
• 
  Когда нам выделяется компьютер, мы можем попросить, чтобы на нем было уже предустановленно и настроено требуемое нам программное обеспечение (например, СУБД, сервер приложений, программная среда для разработки и т д). Это делается быстро, поскольку компьютеры для нас создаются на базе заранее подготовленных шаблонов, где это ПО установлено, пропатчено, оттестировано.
  

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

Экономия происходит и за счет централизованного администрирования системы. Качество администрирования повышается, а число администраторов БД, сетевых и системных администраторов уменьшается или сводится к нулю (при использовании публичного облака). Уже существует множество расчетов, показывающих, что оплата по факту использования ресурсов намного ниже, чем при развертывании собственной IT инфраструктуры в каждом подразделении и для каждого приложения. Теперь устаревание оборудования, докупка компьютеров и т д – не ваша проблема. А быстрое получение новых ресурсов позволяет бизнесу гораздо быстрее и качественнее создавать и тестировать новые бизнес сервисы, выводимые на рынок, опережать конкурентов, делать сервисы быстрее и надежнее, а главное дешевле.

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

В соответствии с определением NIST существует 3 основные сервисные модели облака:

- SaaS – приложения (Solutions) как сервис. Пользователи получают доступ к готовым приложениям через свой веб броузер. Примерами такой модели может служить приложение электронной почты mail.ru или сервисы Yandex. Мы не развертываем у себя эти приложения, но можем работать с ними. Такая модель очень удобна, например, для работы с большими и сложными бизнес приложениями, такими как Oracle E-Business Suite, Sibel CRM, 1C и т д

- IaaS – инфраструктура (Infrastructure) как сервис. Пользователи получают доступ к созданному для них компьютеру с установленной операционной системой. Размеры компьютера (память, диски, число процессоров) задает заказчик. Далее он сам может установить на этот виртуальный компьютер то ПО, которое ему необходимо. Работа с этим виртуальным компьютером осуществляется через веб броузер и аплет эмулятора терминала (например, VNC).

- PaaS –платформа (Platform) как сервис. В этом случае заказчик получает не просто “голый” компьютер с ОС. На компьютере уже установлено и настроено дополнительное ПО, необходимое либо для разработки и тестирования, либо для развертывания приложений. Например, на таком компьютере может быть установлена СУБД или сервер приложений или среда для разработки на Java, Perl и т д

В последнее время появились некоторые специализированные версии PaaS. Например, Microsoft (проект Azure) и Oracle выделили модель DBaaS – СУБД (Database) как сервис. При этом для заказчика создается по требованию база данных требуемой конфигурации и предоставляется доступ к ней. У Oracle возможны два варианта DBaaS – чистый DBaaS и DB in Cloud. Во втором случае для заказчика создается новый виртуальный компьютер, внутри которого установлена СУБД и создана БД. Заказчики получают доступ как к компьютеру, так и к БД. В первом же случае компьютер не создается, а новая БД (простая или кластерная) создается на существующих в облаке физических компьютерах. Этот вариант работает эффективнее, т к нет накладных расходов, связанных с работой виртуальной машины. Аналогичный подход может быть реализован и для сервера приложений – создание виртуальной машины с сервером приложений или развертывание серверов приложений Web Logic на реальных компьютерах.

В соответствии с определением NIST существуют четыре реализации облачной модели:

• 
  Публичные облака (Public cloud)
  
• 
  Частные облака (Private cloud)
  
• 
  Общественные облака (Community cloud) – для конкретного сообщества потребителей
  
• 
  Гибридные облака (Hybrid cloud) – смесь 2 и более выше перечисленных моделей облаков (приложение одновременно использует ресурсы двух моделей)
  

Частное облако – это облако нашей организации. Для сотрудников оно выглядит как публичное и обеспечивает все преимущества публичного облака, но реально его развертыванием и обслуживанием занимается ЦОД нашей организации. На его развертывание придется потратить время и деньги, но нам представляется, что этот подход более перспективен для отечественного бизнеса. Навряд ли многие организации захотят отдавать свои ценные конфиденциальные данные в публичное облако, особенно если оно размещено за рубежом. Персонал организации, поддерживающей публичное облако, сложно призвать к ответу в случае сбоев или неудовлетворительной производительности работы. Хорошей практики наказания за необеспечение качества сервиса (SLA) пока нет. А на своих сотрудников руководство повлиять может. И главное – проблема обеспечения безопасности при работе в облаке. В публичном облаке угроза безопасности ваших данных и систем очень высока. Существует много статей, предлагающих различные механизмы повышения уровня безопасности, но до сих пор хороших решений нет.

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

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

Amazon Cloud EC2, VMWare – IaaS

Microsoft Azure – DbaaS (или DaaS) – реализация подмножества функций MS SQL Server в облаке

Salesforce, GoogleApps, офисные приложения от IBM и MS - SaaS

GoogleApEngine ( c Java и Pyton), EngineYard (c Ruby on Rail) – PaaS

Public cloud от IBM, Oracle

Но проблема заключается в том, что большинство из этих предложений закрывают только часть проблематики облачных вычислений. Часто это лоскутные решения, связанные с выделением по требованию виртуальных машин или урезанных версий СУБД и связующего ПО, не использующие мощные средства мониторинга и управления. Или предоставление конкретного приложения (например, MS Office) в виде сервиса через интернет.

Поскольку идея облачных вычислений понятна и популярна, появилось множество отечественных компаний, заявляющих, что они предлагают услуги облачных вычислений. Чаще всего это варианты SaaS. Например, на сайте http://cloud.zapeecee.ru/igroki я нашел длинный список таких облачных сервисов. К сожалению, при ближайшем рассмотрении оказывается, что это не совсем облака. Например, многие компании, использующие приложения с веб интерфейсом устанавливают эти приложения в чужом ЦОД и отдают владельцам ЦОД право на их администрирование. При этом заявляется, что это облачные сервисы. На самом деле это некоторый вариант хостинга, который тоже дает ряд преимуществ, но реализует только часть достоинств облака. Если мы вспомним 5 характеристик облачных вычислений из определения NIST, то при хостинге не всегда реализовано динамическое выделение пула ресурсов (скорее это фиксированная установка), трудно говорить об эластичности, нет мощного механизма выделения ресурсов по требованию и часто отсутствует гибкий план тарификации и биллинга.

На сегодня компания Oracle имеет одно из наиболее полных облачных предложений в мире. Oracle предлагает как публичное облако, так и средства построения частных и гибридных облаков, поддерживает все модели (IaaS, PaaS, SaaS, DBaaS). Он не сводит облачные вычисления только к предоставлению виртуальных машин, но предлагает набор продуктов и технологий для поддержки всего жизненного цикла облака – от планирования и реализации облака до его эксплуатации и мониторинга. При этом используются стандартные элементы, такие как гипервизор Oracle VM и средства управления им, полноценная СУБД Oracle для DBaaS, стандартные средства управления облаком и элементами инфраструктуры. Это позволяет быстро создавать частные облака и переносить в них приложения, а также перемещать приложения из частного облака в публичное и обратно.

Простые средства создания облачной инфраструктуры позволяют развернуть частное облако за 1-2 недели (опыт наших партнеров). Oracle сегодня имеет наверное самые мощные и развитые средства для учета и тарификации использования вычислительных ресурсов в облаке. Можно строить очень сложные планы биллинга, учитывающие десятки характеристик использования оборудования и ПО. Управление всем технологическим стеком облака от железа до приложений осуществляется с единого пульта, хорошо знакомого всем пользователям Oracle – это Oracle Enterprise Manager. Он позволяет контролировать все этапы жизненного цикла облака.

Еще одной уникальной возможностью предложения Oracle является возможность быстро по требованию развертывать в облаке не только отдельные виртуальные машины или базы данных, но и сложные многокомпьютерные комплексы, состоящие из нескольких связанных машин (например, многоузловый кластер баз данных плюс ферма серверов приложений плюс несколько HTTP серверов).

Если заказчик хочет использовать сервис DBaaS (Database as Service) то он может выбрать один из трех вариантов реализации (см рисунок 2). Иногда полезно последовательно использовать все эти 3 варианта, чтобы облегчить задачу консолидации существующих приложений в облаке.

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

Рис 2. Варианты реализации dBaaS

Второй вариант (чистая DBaaS) позволяет унифицировать ОС и версию СУБД, упростить управление, повысить эффективность использования оборудования. Экземпляры СУБД Oracle (а лучше экземпляры кластера СУБД Oracle) работают на пуле физических компьютеров с единой операционной системой.

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

2. 
   Как создать частное облако?
   

• 
  Планирование структуры облака и вариантов консолидации приложений в облако
  
• 
  Создание облачной инфраструктуры
  
• 
  Подготовка сервисов, образцов машин, БД, серверов приложений, шаблонов, сборок для пользователей облака, выдача привилегий пользователям
  
• 
  Тестирование созданных сервисов и публикация их для пользователей
  
• 
  Заказ и использование сервисов конечными пользователями с помощью портала самообслуживания
  
• 
  Мониторинг использования облачных сервисов
  
• 
  Управление облачной инфраструктурой
  
• 
  Тарификация и биллинг используемых ресурсов
  
• 
  Оптимизация использования ресурсов
  

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

1. 
   Определить характеристики компьютеров, необходимых для установки этого ПО, найти бюджет и купить компьютер (или несколько компьютеров), систему хранения и т д
   
2. 
   Подключить и сконфигурировать все это оборудование, протестировать его
   
3. 
   Установить, протестировать, пропатчить операционную систему
   
4. 
   Скачать, установить, настроить, пропатчировать требуемое ПО и СУБД
   
5. 
   При недостатке мощности оборудования докупить новое оборудование и повторить процесс
   

Интерфейс портала самообслуживания достаточно прост (см рис 3). На нем можно создать заявку на выделение машины с ПО (IaaS), базы данных (DBaaS) или сервера приложений Web Logic. На портале можно видеть какие машины, базы, сервера приложений созданы для этого пользователя и работать с ними. Можно удалять их после использования (если они созданы на неограниченный срок). Также для каждого пользователя установлены ограничения на использование ресурсов облака (диски, память, процессоры, количество баз данных и машин и т д) и на портале он может контролировать использование ресурсов. Можно используя облачный API создать собственный портал самообслуживания – на русском языке, с лого компании, с другим внешним видом. Можно также встроить его в свои приложения.

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

Рис 3. Портал самообслуживания

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

1. 
   Планирование и создание облачной инфраструктуры
   
2. 
   Создание и каталогизация в библиотеку ПО шаблонов, сборок и процедур развертывания, создание пользователей
   
3. 
   Мониторинг и управление облаком, тарификация и биллинг
   

Прежде чем начать консолидацию существующих приложений и баз данных на серверные пулы облака, надо понять, как их консолидировать на разделяемые ресурсы так, чтобы с одной стороны – использовать компьютеры облака наиболее эффективно, а с другой стороны – не получить снижения качества работы этих приложений и БД. Например, если перенести на один физический компьютер два приложения у которых пик загрузки процессора, (или сети, памяти и т д) приходится на одно и то же время, то нам потребуется очень мощный компьютер, который большую часть времени будет недозагружен. Поэтому, прежде чем принимать решение о том, на какие физические компьютеры консолидировать наши текущие приложения, надо проанализировать как распределяется нагрузка, создаваемая этими приложениями, во времени и консолидировать их с учетом этих данных и характеристик наших компьютеров. Для решения этой задачи используется компонента Oracle Consolidation Planner.

Средство Oracle для мониторинга баз данных и приложений - Oracle Enterprise manager (OEM) Cloud Control 12c умеет сканировать сеть и находить все компьютеры, на которых работают те или иные программы Oracle (СУБД, сервера приложений и т д) Для этого он использует утилиту Nmap. Получив список этих компьютеров, мы можем выбрать те из них, которые планируем консолидировать в будущем, и дать OEM команду установить на них управляющий агент OEM. Эти агенты втечение заданного времени будут собирать информацию о том, как эти компьютеры используют процессоры, память, диски и сеть. На основе этой информации Consolidation Planner выдаст рекомендации о том, какие приложения, базы, компьютеры имеет смысл объединять. При этом будет использоваться не только профиль нагрузки, но и заданные ограничения. Например, не стоит объединять на одном компьютере узлы одного кластера БД или тестовые и эксплуатационные базы. Бессмысленно объединять компьютеры с разными операционными системами. А вот тестовые базы под Windows XP одного отдела с несовпадающими профилями нагрузки объединить можно.

Предположим, что мы анализируем коэффициент использования процессора приложениями А и В и видим, что их сумма в какой-то момент времени превышает 100% (см рис 4). Это значит, что консолидировать А и В на одном компьютере нельзя. Если же профили нагрузки компенсируют друг друга, как на рисунке 5, то эти приложения – хорошие кандидаты для консолидации на один компьютер.

Мы можем указать Consolidation Planner какие из собранных метрик (использование процессора, памяти, диска, ввод/вывод дисков, загрузка сети) учитывать при принятии решения о консолидации. Мы можем установить бизнес ограничения для консолидации (из одного отдела, единство географического положения, назначение – эксплуатационная/тестовая и т д) и технические ограничения (операционная система, тип компьютера, узлы кластера). Мы также можем ограничить загрузку потенциальных серверов консолидации.

Существует три сценария консолидации:

• 
  P2P – физические сервера на другие физические сервера
  
• 
  P2V – физические сервера превращаются в виртуальные
  
• 
  P2E – физические сервера БД консолидируются на машины баз данных Exadata
  

Теперь, когда мы выбрали план консолидации, нам надо подготовить инфраструктуру для облачных вычислений, т е установить компьютеры, сконфигурировать сеть, подключить и подготовить систему хранения, установить на серверы ПО. Для IaaS, DBaaS, PaaS создаются разные инфраструктуры. Но в каждой из них группа физических серверов объединяется в серверный пул. А пулы объединяются в зоны. Сервера серверного пула имеют доступ к единой системе хранения. Это позволяет, например, виртуальным машинам IaaS без остановки работы

Рис 4. Плохие кандидаты для консолидации на 1 компьютер

Рис 5. Хорошие кандидаты для консолидации на 1 компьютер

переползать на другой сервер пула при сбое или перегрузке текущего сервера. В случае DBaaS на серверах одного пула могут быть развернуты узлы кластера одной разделяемой БД. На всех серверах пула должно быть установлено одинаковое ПО. Для IaaS – это гипервизор Oracle VM, для DBaaS – это ПО Oracle Database (Oracle Home). Зона объединяет несколько серверных пулов, например по географическому или логическому принципу. Мы сможем привязать план тарификации ко всем машинам или базам зоны.

При организации облака у нас появляются две новые роли – администратор облака и администратор самообслуживания.

Администратор облака как раз и создает, а затем и мониторит инфраструктуру облака. Он устанавливает ПО гипервизора или другое инфраструктурное ПО (например, Oracle Home), конфигурирует систему хранения и сеть, объединяет компьютеры в пулы, а затем пулы в зоны, создает пользователей облака, присваивает им роли и привилегии. Еще одна задача администратора облака – создать библиотеку По или репозиторий шаблонов (для IaaS), в которую далее администраторы самообслуживания будут загружать шаблоны виртуальных машин, процедуры развертывания БД, сборки, которые сможет выбирать конечный пользователь.

Шаг 2. Создание и каталогизация в библиотеку ПО шаблонов, сборок и процедур развертывания, создание пользователей

В свою очередь администратор самообслуживания должен определить предлагаемые варианты виртуальных машин (для IaaS), баз данных (для DBaaS), серверов приложений, описать их характеристики, назначить пользователям и ролям квоты на использование дисков, памяти, процессоров, количество создаваемых виртуальных машин, баз, серверов приложений, создать тарифные планы и привязать роли и планы к зонам облака. И, наконец, администратор самообслуживания облака должен создавать, тестировать и публиковать в библиотеке ПО те шаблоны, сборки, процедуры развертывания БД, которые сможет использовать конечный пользователь. Важно описать эти объекты библиотеки ПО на максимально понятном языке, чтобы конечный пользователь мог легко выбрать из списка именно то, что ему нужно. Oracle Enterprise Manager предоставляет удобный инструмент, который позволяет администратору самообслуживания быстро готовить эти объекты библиотеки ПО.

Для создания процедур развертывания БД (одиночных, кластерных, с ASM) OEM запускает Database Configuration Assistant, в котором администратор описывает все параметры будущей БД и настройки СУБД. Для построения шаблонов виртуальных машин OEM использует Oracle VM Template Builder, который создает шаблон на основе существующей физической или виртуальной машины. Для создания многокомпьютерных приложений в облаке создаются сборки (Assembly), описывающие все виртуальные машины такого приложения и правила их взаимодействия (имена, конфигурации сети, конфигурации дисков и т д). Это делается с помощью программы Oracle Virtual Assembly Builder. Она позволяет описать все компоненты такого приложения и связи между ними, после чего генерирует набор шаблонов и описаний, объединенный в сборку. Сборку он загружает в библиотеку ПО.

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

При создании виртуальных машин пользователь может работать с ними через эмулятор терминала VNC прямо из портала, при создании БД пользователю сообщается строка связи, которую он может использовать для работы с этой БД из приложений (сервер приложений, SQL*Plus, SQL Developer и т д). Можно также создавать в БД приложения Application Express (если он был предусмотрен в шаблоне БД) и работать с ними через веб броузер. Также для доступа к БД можно использовать протокол Restful API.

Шаг 3. Мониторинг и управление облаком, тарификация и биллинг

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

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

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

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

Oracle в качестве такого универсального средства мониторинга и управления от диска до приложения и облака предлагает продукт Oracle Enterprise Manager. Мы не будем здесь рассматривать его возможности по управлению традиционными объектами (БД, сервера приложений, приложения, оборудование) – они хорошо известны, а остановимся на средствах мониторинга специфичных для облака.

Во-первых, часть работы по управлению и мониторингу созданными объектами отдается пользователю, создавшему объект. На портале самообслуживания пользователь, создавший БД или виртуальную машину может нажать на нее мышкой и перейти на экран мониторинга объекта. Здесь он видит не только информацию об использовании памяти, дисков, процессоров, но и специфическую информацию, например, для БД – наиболее ресурсоемкие операторы SQL, ожидания и т д. На этом экране пользователь может легко включить режим автоматического резервного копирования БД, задать частоту полного и инкриментального резервирования. На главной странице портала самообслуживания пользователь видит сколько баз/машин/серверов приложений создано и сколько он еще может создать, какие ему выделены квоты на использование памяти/дисков/процессоров и как они используются. Владелец объекта может также остановить или запустить объект (например, виртуальную машину) или вообще удалить объект из облака. Он также может задать политику автоматического сопровождения объекта. Например, можно определить, что виртуальная машина будет автоматически останавливаться в 8 вечера и стартовать в 10 утра, что при слишком большой загрузке процессора виртуальная машина или СУБД переедет на менее загруженный компьютер и т д

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

Поскольку OEM позволяет работать с продуктом Oracle RUEI (Real User Experience Insight), можно также мониторить работу приложений облака с точки зрения бизнеса и конечных пользователей. RUEI позволяет контролировать выполнение бизнес процессов, бизнес транзакций, KPI, качество работы конечных пользователей приложения, пропускную способность приложения, соблюдение уровня сервиса (SLA) и т д, и посылать администратору извещения в случае ухудшения параметров работы приложения. Это помогает оперативно выявлять и решать проблемы работы облачных приложений.

Как уже было упомянуто, необходимо обеспечить техническую поддержку огромного количества объектов облака. Необходимо анализировать и исправлять возникающие в разных объектах облака ошибки. Для этого OEM интегрирован со службой технической поддержки Oracle – My Oracle Support. Информация о возникающих ошибках автоматически дополняется информацией, необходимой для анализа причин этих ошибок, пакетируется и через Firewall отправляется в службу My Oracle Support. Администраторы облака и его объектов могут отслеживать состояние открытых сервисных запросов (Service requests). Они также могут создавать, мониторить и обновлять эти сервисные запросы, выкачивать и применять подготовленные патчи. Патчи можно применять к группе объектов.

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

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

При составлении тарифных планов можно списывать деньги динамически (пропорционально использованию ресурса – например, использование 1 Гб диска в месяц). Для некоторых ресурсов логичнее установить фиксированную оплату, например, для Windows систем платить дополнительно 100$ в месяц, а для Linux систем – не платить ничего. Можно взимать дополнительную плату за конфигурацию (например, версию БД или кластер). Созданные тарифные планы приписываются объектам или группам объектов (например, зоне) и после этого мы начинаем получать отчеты и панели показывающие использование ресурсов.

1 Стоимость. Первый вопрос, который возникает у организации, собирающейся строить частное облако – что надо купить и сколько это стоит? Существует ряд документов, сравнивающих стоимость ПО для облака от разных производителей. Например, можно посмотреть документ Microsoft [3] в котором детально сравнивается стоимость различных облачных конфигураций от разных вендоров. И сравниваемые цены достаточно велики. Самое смешное, что для многих рассматриваемых конфигураций облачную инфраструктуру на продуктах Oracle можно развернуть почти бесплатно. Например, если вы создаете IaaS без биллинга, то и средства виртуализации Oracle VM и операционная система машин Oracle Linux и средства создания и мониторинга IaaS (Oracle VM manager и OEM) и средства подготовки шаблонов и сборок (Oracle Virtual Assembly Builder, Oracle VM template Builder) и средства управления компьютерами от Oracle – Oracle Ops center – бесплатны. У конкурентов все это стоит немалых денег.

Конечно, если вы хотите развернуть БД или сервер приложений или машину с ОС Windows, вы должны иметь лицензии на эти продукты. Для использования тарификации и биллинга нужно купить пакет OEM – Cloud management pack.

2 Безопасность. Когда мы начинаем говорить про облака, первым делом встает вопрос о безопасности данных и приложений в облаке. Для публичных облаков вопрос действительно болезненный. Но если мы говорим о частном облаке своей организации, то там применимы все меры защиты данных и приложений, которые мы использовали до сих пор, без облака. Например, если создается БД в облаке, то можно использовать Advanced Security option для кодирования данных и разных методов идентификации пользователей, Database Vault для защиты от администратора, Identity manager для управления пользователями, средства управления ролями, привилегиями, аудит и т д. [5]. Все это используется уже много лет. То же верно и для виртуальных машин, широко используемых в организациях и без облака и обеспечивающих хорошую изоляцию приложений друг от друга.

1. 
   М Ривкин. Взаимодействие пакетов разных фирм в архитектуре клиент-сервер //Мир ПК, 1995, N II, 12
   
2. 
   Vivek Kundra . Federal Cloud computing Strategy, USA, 2011
   
3. 
   Microsoft Private Cloud. A comparative look at functionality, benefits and economics. Microsoft, 2011
   

4. Л Черняк. Интеграция – основа облака, «Открытые системы» , № 07, 2011

5. Описание продуктов на сайте Oracle, http://www.oracle.com