Облачные иллюзии

Общеизвестны такие преимущества облаков, как обеспечение гибкой, перестраиваемой ИТ-инфраструктуры; быстрое развертывание новых сервисов; снижение расходов на ИТ; эффективное использование оборудования; повышение надежности; учет использования ресурсов; стандартизация; консолидация; быстрое клонирование баз данных и сред для тестирования и разработки [1]. Многие заказчики обсуждают или планируют перенос своих приложений в облако и модернизацию корпоративной инфраструктуры в облачную, но оказывается, что не всегда правильно понимается суть облачной инфраструктуры. Например, часто приходится слышать утверждение: «Я не собираюсь переносить свои приложения в облако, поскольку это опасно, требует больших инвестиций и переписывания приложений». Да, перенос приложений в публичное облако может создать проблемы с обеспечением безопасности — например, если его инфраструктура расположена за границей и контролировать безопасность данных и приложений заказчик не может. Но если говорить о частном облаке, расположенном в корпоративном ЦОД, то там можно применить все необходимые уровни защиты, используемые в традиционной ИТ-инфраструктуре. Например, для СУБД можно использовать весь арсенал обеспечения безопасности: шифрование, аудит, разграничение доступа, различные способы аутентификации, защиту от администратора, установление уровня конфиденциальности для отдельных строк, динамически изменяющиеся политики безопасности и т. д. То есть утверждение об опасности справедливо только для публичного облака.

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

Таким образом, перед принятием решения о переходе в облака надо определиться с его типом, моделью облачных сервисов (IaaS, PaaS, SaaS) [2] и разобраться с иллюзиями.

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

Облако от производителя формируется только на платформе от этого производителя. Большинство производителей облачных продуктов реализуют модель IaaS (Infrastructure as a Service — «инфраструктура как сервис») и предоставляют сервисы на платформе х86. Oracle реализует модели IaaS и PaaS (Platform as a Service — «платформа как сервис», базы данных и серверы приложений), поэтому говорить о вычислительных платформах надо отдельно для IaaS и PaaS. Сервисы IaaS от Oracle можно реализовать на любой платформе х86 любого производителя, а также на RISC-машинах с процессорами SPARC. Хорошо реализуется IaaS на системах Oracle Database Appliance (ODA) и Exalogic. Кроме того, специально для быстрого развертывания IaaS выпущен специальный аппаратно-программный комплекс Oracle Virtual Computing Appliance (OVCA). Для PaaS нет требований обязательного использования Exadata или Exalogic — разворачивать облачные СУБД и серверы приложений можно на любом оборудовании: х86, Unix-серверах от IBM, HP или Oracle. Естественно, эффективнее базы данных Oracle «как сервис» (DBaaS) можно развернуть на Exadata, а серверы  приложений  WebLogic — на Exalogic, причем преимущество Exadata только в том, что там есть менеджер ресурсов ввода-вывода, позволяющий для разных баз данных задавать разные приоритеты выполнения операций ввода-вывода.

Конечно, хорошо делать все облако из продуктов от одного поставщика, что упрощает, например, управление неоднородным облаком. Однако часто заказчики хотят иметь IaaS от VMware, SaaS от кого-то другого, а СУБД развертывать в DBaaS от Oracle. Обычно облако состоит из зон (рис. 1), в каждой из которых размещаются группы связанных ресурсов с единой системой хранения — пулы. В одном облаке можно иметь зоны из продуктов разных производителей: например, развернуть три IaaS-зоны — от VMware, Microsoft и Oracle, а их виртуальные машины могут работать с четвертой зоной, где развернут DBaaS-сервис Oracle.

Рис. 1. Облако состоит из нескольких зон, в которых расположены пулы серверов

Во многих работающих сегодня облаках представлены продукты и виртуальные машины от нескольких поставщиков — единый портал самообслуживания позволяет заказывать и использовать сервисы в разных зонах и ресурсы от разных поставщиков. При этом возникает вопрос организации управления таким разнородным облаком, и здесь имеется три варианта. Можно использовать собственные средства управления от каждого производителя, а если сервисов в облаке много, то у каждой группы сервисов обычно имеются свои зоны и свои администраторы. Можно использовать инструмент одного поставщика, предлагающего дополнительные модули для управления чужими гипервизорами. Например, стандартное средство управления облаком Oracle (Oracle Enterprise Manager) работает с плагином BlueMedora, позволяющим в том же интерфейсе управлять машинами VMware. Аналогичное решение для VMware имеется и у IBM. Можно использовать универсальные средства управления облачными сервисами, предлагаемые сегодня разными производителями: Nimbula Director, Rackspace OpenStack, Hotlink SuperVisor, Convert, IBM System Director, EMC Hybrid Cloud Solution и т. д. Однако возможности универсальных средств управления ограниченны, поэтому, скорее всего, придется совмещать все три подхода.

Облако — это только виртуализация. Ни в одном определении модели облачных сервисов не указано, как именно должно быть реализовано развертывание и предоставление этих сервисов, а лишь выделяются три модели: IaaS, PaaS и SaaS. Если, например, заказчику нужен какой-то сервис СУБД, то совсем не обязательно его реализовывать в виде виртуальной машины. Базу данных можно развернуть как виртуальную машину, как схему в уже существующей базе или автоматически создать новую базу (или их кластер) без виртуальной машины на имеющемся пуле компьютеров (модель PaaS или ее «трактовка» для баз данных — DBaaS). Очевидно, что облака не сводятся только к виртуализации машин и IaaS, — это только одна из моделей реализации, однако большинство известных облачных провайдеров (Amazon, Microsoft, Citrix, VMware) могут реализовывать только виртуальные машины IaaS, а все остальные сервисы разворачиваются уже внутри них, причем только на платформе х86. Конечно, IaaS — важная и неотъемлемая часть облака, но если нужны платформные сервисы, такие как базы данных и серверы приложений, то их проще и эффективнее разворачивать прямо на оборудовании (PaaS), а не на виртуальной машине — в облаке должны быть как зоны IaaS, так и зоны PaaS. Не секрет, что порой быстрее и экономически выгоднее строить дом, складывая его не из кирпичей, а из готовых модулей, блоков. То же относится и к облаку. PaaS — это блочное строительство.

Если не используется PaaS, а разворачиваются виртуальные машины с сервисами, то заказчик получает ПО, работающее внутри виртуальной машины, что имеет ряд недостатков. Во-первых, деградирует производительность приложений, которые работают внутри виртуальной машины, отбирающей ресурсы у оборудования. Во-вторых, увеличивается число объектов управления и возрастает сложность управления. Если у вас было 10 компьютеров с базами и вы превратили их в 10 виртуальных машин, то все равно придется управлять десятью виртуальными машинами и базами. В случае PaaS можно развернуть эти 10 независимых баз внутри одной контейнерной СУБД Oracle 12c, и при этом виртуальных машин нет, а управлять надо только одним экземпляром СУБД вместо 10. Получается, что IaaS не упрощает администрирование. В-третьих, падает эффективность использования ресурсов (памяти, процессоров, дисков). Для 10 виртуальных машин нужно выделять место на дисках, память и процессоры для всех машин. В случае PaaS — оперативной памяти, дисков и процессоров надо меньше [3]. Если говорить о DBaaS, то выигрыш будет также в надежности работы базы данных и скорости клонирования баз данных. Например, в IaaS от ряда производителей предусмотрен режим синхронной поддержки копии работающей виртуальной машины, но при реальной эксплуатации базы данных внутри такой машины объем изменений бывает настолько велик, что быстрая синхронизация виртуальных машин (не знающих, как работает СУБД) невозможна. В то же время режим автоматической поддержки синхронной или асинхронной резервной (standby) базы для любых нагрузок и на любых расстояниях — это типичный режим работы любой СУБД.

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

Еще одним преимуществом PaaS перед IaaS является то, что PaaS позволяет развертывать базы данных и серверы приложений не только на платформе х86. Если надо в облаке развернуть серьезные унаследованные базы и серверы приложений на Unix-серверах или интегрированных системах, то IaaS не подойдет.

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

Облако — это сложно, долго, дорого, и оно требует полного изменения корпоративной инфраструктуры. Конечно, перестройка всей ИТ-инфраструктуры организации — сложный процесс, да и не все приложения стоит переносить в облако. Сегодня многие заказчики понимают необходимость перехода к облачной инфраструктуре, но не знают, с чего начать, и боятся это делать. Чтобы развеять сомнения и доказать возможность создания облачной инфраструктуры и ее пользу, лучше всего начать с пилотного проекта. Созданное облако в дальнейшем станет основой для построения полноценного облака, и в него можно постепенно переносить имеющиеся приложения и сервисы и создавать новые сервисы. Если в облаке реализуются IaaS, DBaaS и FMaaS (Fusion Middleware — серверы приложений как сервис), то архитектура пилотной конфигурации может выглядеть, как на показано рис. 2. Имеется управляющая машина с системой создания и управления облаком (например, Oracle Enterprise Manager) и три зоны: для развертывания виртуальных машин (IaaS), для развертывания баз данных Oracle (DBaaS) и для развертывания серверов приложений Oracle WebLogic (FMaaS). Кроме этого, могут быть добавлены зона для развертывания кластеров баз данных и компьютер для системы управления доступом.

Рис. 2. Архитектура стенда для пилотного проекта облака

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

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

При развертывании FMaaS требуется определить: платформу (х86, Unix-серверы, Exalogic); способ развертывания WebLogic (в кластере или без); разворачивать WebLogic с Java-приложениями или добавлять их позже. Для DBaaS: платформу (x86, Unix-серверы, ODA, Exadata); способ развертывания (в виртуальной машине, на голом железе, в контейнерной базе или в виде схемы); порядок использования механизма мгновенного клонирования; вид базы (пустая, полная из резервной копии, полная из экспортного файла, из копии существующей базы); создавать отдельную базу или кластер; маскировать или урезать промышленную базу, на основе которой разворачиваются новые базы в облаке.

Если планируется использовать механизм быстрого клонирования, то это накладывает ограничения на выбор системы хранения — сегодня это возможно сделать на ZFS Storage Appliance, NetApp, Solaris ZFS File System и вскоре на Oracle ASM.

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

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

***

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

Литература

1. Марк Ривкин. Как создаются облака // Открытые системы.СУБД. — 2012. — № 4. — С. 22–27. URL: http://www.osp.ru/os/2012/04/13015781 (дата обращения 18.09.2014).
2. Марк Ривкин. Облачные вычисления. Как создать облако от  Oracle. URL: http://mrivkin.narod.ru/Publ/Mark_cloud_art.doc (дата обращения 18.09.2014).
3. Марк Ривкин, Игорь Мельников. СУБД для облаков // Открытые системы.СУБД. — 2013. — № 6. — С. 30–33. URL: http://www.osp.ru/os/2013/06/13036850 (дата обращения 18.09.2014).

Марк Ривкин (mark.rivkin@oracle.com) — старший менеджер по технологическому консалтингу, Oracle CIS (Москва).