Как создаются облака

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

Облака — следующий шаг в эволюции архитектур построения информационных систем, возможности которых были сразу оценены на самом высоком уровне. Например, ИТ-директор правительства США Вивек Кундра в феврале 2011 года опубликовал стратегию федерального правительства («Federal Cloud computing Strategy», USA, 2011) по переносу управленческих систем в облако для уменьшения сложности и повышения управляемости ИТ, увеличения загрузки оборудования до 70–80% и сокращения количества центров обработки данных с нынешних 800.

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

Существуют три основные сервисные модели облака: SaaS (Software as a Service — «программа как сервис»), IaaS (Infrastructure as a Service — «инфраструктура как сервис») и PaaS (Platform as a Service — «платформа как сервис»). Недавно появились специализированные версии PaaS, например Microsoft Azure, а в Oracle выделяют еще модель DBaaS (Database as а Service — «СУБД как сервис»), при которой заказчику предоставляется доступ к созданной по его требованию базе данных. Oracle предлагает два варианта DbaaS: «чистый» и «база данных в облаке», в котором для заказчика создается виртуальный компьютер с установленной СУБД и создана база данных. Для каждой модели может быть четыре типа реализации облака: публичные (public); частные (private); общественные (community), предназначенные для конкретного сообщества потребителей; и гибридные (Hybrid cloud).

Частное облако — облако компании или организации, которое для сотрудников выглядит как публичное, обеспечивая все его преимущества, но реально разворачиваемое на базе корпоративного ЦОД. На сегодняшний день это наиболее востребованная модель реализации для отечественного бизнеса — многие компании еще не готовы передавать свои данные в публичное облако, особенно если оно размещено за рубежом. Хорошей практики санкций за отсутствие сервиса нужного уровня пока нет, и, кроме того, до сих пор имеется проблема обеспечения безопасности при работе в облаке. В большинстве случаев для частного облака решение этих задач упрощается — достаточно традиционных мер, уже применяемых в организации, причем перенос приложения и баз в частное облако не снижает защищенности данных.

Сегодня множество компаний предлагает те или иные облачные сервисы и продукты, например IaaS от Amazon Cloud EC2 и VMware или DBaaS от Microsoft Azure и Oracle DBaaS, а также SaaS от Salesforce и GoogleApps. В качестве примеров PaaS можно рассматривать GoogleApEngine (c Java и Pyton) и EngineYard (c Ruby on Rail). Однако большинство этих предложений закрывают только часть вопросов, возникающих при создании и эксплуатации облаков, и часто представляют собой лоскутные решения, связанные с выделением по требованию виртуальных машин, урезанных версий СУБД и связующего ПО без мощных средств мониторинга и управления, предоставление конкретного приложения (например, Office) в виде сервиса.

Сегодня ряд отечественных компаний заявляют, что они предлагают облачные сервисы (чаще всего это варианты SaaS), однако при ближайшем рассмотрении оказывается, что речь идет о реализации лишь некоторых возможностей облаков. По определению Национального института стандартов и технологий CША, облако должно обладать всеми пятью характеристиками (пул разделяемых ресурсов, эластичность, оплата по факту, доступ через браузер, быстрое и простое выделение ресурса по требованию как сервиса). Например, многие компании, использующие приложения с Web-интерфейсом, устанавливают их на ЦОД провайдера, передавая ему право на администрирование. На самом деле это вариант хостинга, а не облако: не всегда реализовано динамическое выделение пула ресурсов, трудно говорить об эластичности (изменении размера выделенных ресурсов по мере изменения требований — например, при росте числа пользователей или пиковых нагрузках можно быстро добавить пространство на дисках), нет мощного механизма выделения ресурсов по требованию и часто отсутствует гибкий план тарификации и биллинга. Не следует также ставить знак равенства между виртуализацией и облаками. Да, очень часто облако использует и механизмы виртуализации, но облако можно реализовать и без виртуализации. Например, Oracle DbaaS и некоторые решения от Google — все это облачные решения без виртуализации.

Облака от Oracle

Сегодня компания Oracle предлагает как собственно сервис облака — Oracle Private Cloud, так и средства построения частных облаков, поддерживающих модели IaaS, PaaS, SaaS и DBaaS. Пользователям предоставляется набор продуктов и технологий для поддержки всего жизненного цикла облака — от планирования и реализации до эксплуатации и мониторинга. При этом используются стандартные элементы, такие как гипервизор Oracle VM и средства управления им, полноценная СУБД Oracle для DBaaS, стандартные средства управления облаком и элементами инфраструктуры. Все это позволяет создавать частные облака, переносить в них приложения и перемещать приложения из частного облака в публичное и обратно.

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

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

Если заказчику нужна модель DBaaS, то он может выбрать один из трех вариантов реализации (рис. 1). Первый вариант — Database in VM, или Infrastructure Cloud, подразумевает развертывание баз данных в отдельных виртуальных машинах. Перенос базы из существующей инфраструктуры в облако при этом достаточно прост — в каждой виртуальной машине остается своя операционная система, своя база данных и своя версия СУБД. Все виртуальные машины могут размещаться на одном серверном пуле, что повышает эффективность использования оборудования. Однако работа СУБД внутри виртуальных машин приводит к дополнительным накладным расходам, а оборудование используется неэффективно. Кроме того, приходится поддерживать много разных ОС, версий СУБД и т. д. Данный вариант хорошо применять в качестве первого шага консолидации.

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

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

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

Частное облако средствами Oracle

Полный жизненный цикл облака состоит из следующих этапов:

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

Для управления всеми этапами этого жизненного цикла предназначено решение Oracle Enterprise Manager 12c, с помощью которого за три следующих шага создается частное облако:

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

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

Планирование и создание облачной инфраструктуры

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

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

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

Есть три сценария консолидации: P2P — физические серверы на другие физические серверы; P2V — физические серверы превращаются в виртуальные; P2E — физические серверы баз данных консолидируются на машины баз данных Exadata.

Рис. 2. Плохие кандидаты для консолидации

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

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

Библиотека и пользователи

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

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

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

При создании виртуальных машин пользователь может работать с ними через эмулятор терминала VNC viewer (Virtual Network Computing), распространяемый по лицензии GPL прямо из портала — при создании базы данных пользователю сообщается строка связи, которую он может использовать при работе из приложений (сервер приложений, SQL*Plus, SQL Developer и т. д.). Можно также создавать приложения Application Express (если это было предусмотрено в шаблоне) и работать с ними через браузер.

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

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

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

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

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

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

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

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

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

При использовании облачных сервисов для каждого объекта (виртуальная машина, база данных, зона, и т. д.) на основе тарифного плана будут формироваться отчеты о платежах. Они могут служить как для реальной оплаты (печатать или загружать в биллинговые системы), так и для контроля расходования ресурсов и для взаиморасчетов (например, между отделами или центрами затрат). При составлении тарифных планов можно списывать деньги динамически, пропорционально эксплуатации ресурса, например за использование 1 Тбайт дискового пространства в месяц. Для некоторых ресурсов логичнее установить фиксированную оплату, скажем, для Windows-систем платить дополнительно 100 долл. в месяц, а для Linux — не платить ничего.

***

У организации, которая собирается строить частное облако, в первую очередь возникают вопросы — что надо купить и сколько это стоит? Здесь можно, например, посмотреть документ «Microsoft Private Cloud. A comparative look at functionality, benefits and economics» (Microsoft, 2011), где сравнивается стоимость различных облачных конфигураций. Кстати, для ряда рассматриваемых конфигураций облачную инфраструктуру на продуктах Oracle можно развернуть почти бесплатно. Например, если создается IaaS без биллинга, то средства виртуализации Oracle VM, операционная система машин Oracle Linux, средства создания и мониторинга IaaS (Oracle VM manager и OEM), средства подготовки шаблонов и сборок (Oracle Virtual Assembly Builder, Oracle VM template Builder), а также средства управления компьютерами (Oracle Ops Center) — предоставляются бесплатно. Для целей тарификации и биллинга нужно купить пакет Cloud management pack.

Следующий вопрос — безопасность. Для публичных облаков этот вопрос пока очень болезненный, но в частном облаке применимы все уже существующие в организации меры защиты данных и приложений. Например, Advanced Security option для кодирования данных и использования разных методов идентификации, Database Vault для защиты от администратора, Identity manager для управления пользователями и т. д.

Сегодня Oracle IaaS использует в качестве средства виртуализации Oracle VM, а это означает, что в качестве платформы могут служить компьютеры архитектуры x86 или SPARC. Модель DBaaS может поддерживаться на любых компьютерах, где работает ппрограммное обеспечение СУБД Oracle. Удобно строить DBaaS на машине Oracle Exadata, в которой есть возможность установки приоритетов использования системы ввода/вывода для различных баз данных, а также собраны и сконфигурированы система хранения, узлы кластера и сетевые элементы.

Марк Ривкин (mrivkin@mail.ru) — начальник отдела технического консалтинга по серверным технологиям Oracle CIS (Москва).