«Супероблако»: межоблачная инфраструктура на основе архитектурных принципов Интернета

Инфраструктура в виде сервиса (IaaS) стала сегодня предпочтительной платформой предоставления вычислительных ресурсов и хранилища для всевозможных онлайн-сервисов, однако единого облака не существует — есть множество публичных и еще больше частных облаков. Между тем для пользователей была бы удобной возможность объединить различные облака, получив улучшенные по сравнению с одиночным облаком надежность, производительность и экономическую эффективность. Идею объединения облаков в общий ресурс называют по-разному: интероблако (Inter-Cloud), мультиоблако (Multicloud), кросс-облако (Cross Cloud), гибридное облако (Hybrid Cloud), федерация (Federation), облачный «сплав» (Cloud Fusion) и т. п. [1]. За некоторыми исключениями сегодня нет простых способов интеграции нескольких облаков для выполнения одной задачи, как нет и возможности распределить нагрузку по обработке группы задач между несколькими облаками.

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

Похожая ситуация была характерна для мира сетей в 1960-х годах. В то время как телефонные сети для обеспечения возможности взаимного соединения полагались на набор строгих стандартов, существовал еще широкий круг пакетных сетей, и, если бы их все перевели на единый формат адреса и пакетов, это могло бы задушить новации и повысить барьеры входа. Вместо этого ранний Интернет построили на основе многоуровневой архитектуры — аппаратные сетевые технологии абстрагировались на уровне протокола Интернета (Internet Protocol, IP), что способствовало развитию сервисов и приложений, использующих эту абстракцию. Соответствующий уровень называют «тонкой талией» (thin waist) Интернета, поскольку в отличие от других уровней он с помощью простого в реализации интерфейса обеспечивал минимальные коммуникационные возможности. Так называемый принцип тотальности (end-to-end principle) требовал, чтобы уровень IP был как можно проще, довольствовался минимальными предположениями о нижних уровнях, а средства надежности и другие функции обеспечивались бы на более высоких уровнях [2]. В случае же с телефонной сетью средства обеспечения надежности были встроены в само ядро сети, поскольку ее конечные точки — телефоны — соответствующими возможностями не располагали. Архитектура с уровнем IP обеспечила возможность стремительных инноваций на уровнях ниже и выше — в сфере сетевых топологий, коммуникационных сервисов и приложений. При этом развитие практически не ограничивалось институтами стандартизации, благодаря чему возник процветающий рынок, участниками которого стали производители оборудования, провайдеры интернет-доступа и операторы веб-сервисов. В конечном счете это привело к появлению облаков.

Сегодня на аналогичном распутье находится сама индустрия облаков. Если проводить параллели, то роль, аналогичную поставщикам сетевого оборудования прошлого, выполняют разнообразные технологии виртуализации, включая Xen, KVM, VMware и Hyper-V, а провайдеров Интернета можно сравнить с операторами облаков, причем онлайн-сервисы сегодня работают в публичных и частных облаках. И если добиваться внедрения обширного набора стандартов на все аспекты облачных решений, то это подавило бы прогресс в области технологий виртуализации и приложений и повысило бы барьеры входа для новых провайдеров. Пример такой новации — Интернет вещей, построенный на периферийных облаках, для которых сегодня нужны новые формы виртуализации и которые породили совершенно новые приложения. Сегодня действуют малые специализированные сети в домах, автомобилях, на заводах и т. д., а в дальнейшем повсюду появятся небольшие облака. Чтобы соединить такие облака в общую глобальную инфраструктуру, нужен, по аналогии с IP, уровень абстракции облака (Cloud Abstraction Layer, CAL).

Уровень абстракции

Согласно принципу тотальности, уровень CAL должен быть максимально простым. Все, что нужно, — это возможность хостинга виртуальных ресурсов для вычислений и хранения, связанных виртуальными сетевыми соединениями. Сами ресурсы будут весьма разнообразными: базовые виртуальные машины разных размеров и с разными наборами инструкций; базовые виртуальные хранилища в форме больших двоичных объектов (data blob). Пользователям понадобится возможность контроля над местонахождением этих виртуальных ресурсов, для того чтобы варьировать задержку, надежность, приватность, стоимость, поэтому нужна возможность их перемещения по желанию без нарушения коммуникационных каналов. Подобно IP, CAL будет уровнем абстракции, действующим поверх уже имеющихся ресурсов. Нынешний IP — это простая сеть с виртуальными пакетами, которые передаются между виртуальными конечными точками с виртуальными адресами. Аналогично, в CAL будут виртуальные машины и виртуальные blob-хранилища, которые можно создавать в виртуальных местонахождениях и перемещать между ними. Что касается сетевых функций, то оптимальными для целей создания уровня абстракции облака представляются технологии программно-конфигурируемых сетей.

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

Рис. 1. Уровни мультиоблачного стека

На рис. 1 представлена многоуровневая архитектура мультиоблака в форме песочных часов, навеянная стеком IP. Нижний уровень — это доступное оборудование, дальше идет тонкий слой программного обеспечения, выполняющего мультиплексирование доступных аппаратных ресурсов. Затем следует уровень абстракции облака, выполняющий роль «тонкой талии», — он предоставляет виртуальные машины, blob-хранилища и программно-конфигурируемый слой сетевых межсоединений, поддерживающий переносимость и мобильность. Поверх данного уровня можно развертывать операционные системы и СУБД, соединяя их друг с другом с помощью сетевых протоколов, например TCP. Самый верхний уровень составляют приложения, включая облачные сервисы и Интернет вещей.

Супероблако

Ученые Корнеллского университета создали прототип уровня абстракции облака, дав ему название «супероблако» (Supercloud), которое охватывает как несколько зон доступности одного и того же оператора, так и зоны доступности многих операторов облаков и частных кластеров (рис. 2). Чтобы добиться этого, используют два уровня аппаратной виртуализации. Нижний — инфраструктура, управляемая провайдером публичных IaaS-сервисов, например Amazon EC2, или частной платформы. Этот уровень предоставляет виртуальные машины, облачное хранилище и сетевые функции. Поверх него находится еще один слой виртуализации, уровень абстракции облака, — инфраструктура в виде сервиса, управляемая супероблаком. Она использует ресурсы оператора облачных сервисов и предоставляет единый стандартный интерфейс виртуального облака. Важно, что уровень абстракции целиком подконтролен пользователям. Сейчас для управления виртуальными ресурсами супероблака используется OpenStack.

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

Что касается вычислительных ресурсов, то на канальном уровне имеются гипервизор, управляемый оператором облака, и набор аппаратных виртуальных машин. Уровень абстракции облака, доступный пользователям супероблака, аналогичным образом разделен на гипервизор и некоторое количество гостевых виртуальных машин, на каждой из которых могут выполняться процессы в какой-либо ОС. В супероблаке уровень абстрагирования реализован с помощью Xen-Blanket, который предоставляет единый паравиртуализованный интерфейс на основе Xen. На более низких уровнях поддерживаются все основные гипервизоры, включая Xen, KVM, Hyper-V и VMware, поэтому один экземпляр супероблака может охватывать всех крупнейших облачных провайдеров, включая Amazon EC2, Rackspace, Microsoft Azure и Google Compute Engine, а также большинство частных облаков.

Чтобы создать иллюзию единого виртуального облака, управляющие сервисы и пользовательские виртуальные машины должны иметь возможность стандартным образом обмениваться данными независимо от того, где находятся конечные виртуальные машины. При переносе пользовательской машины гарантируется сохранение ее IP-адреса. Для этого сетевой уровень супероблака построен на базе виртуальной частной сети, реализованной с использованием оверлейной программно-конфигурируемой сети на основе Open vSwitch, туннелей VXLAN и контроллера SDN. Оверлейная сеть обеспечивает контроль над маршрутизацией для CAL и беспрепятственный обмен сообщениями между виртуальными машинами в среде с многими провайдерами независимо от переносов виртуальных машин. Чтобы обеспечить поддержку открытых IP-адресов, в различных местонахождениях развернуты шлюзы. Клиенты соединяются с ближайшими шлюзами, которые с помощью проброса портов передают трафик между клиентами и виртуальными машинами, в том числе в процессе их переноса.

Новые перспективы

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

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

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

***

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

Литература

1. N. Grozev, R. Buyya. Inter-Cloud architectures and application brokering: taxonomy and survey // Journal of Software Practice and Experience. — 2014. Vol. 44, N. 3. — P. 369–390.
2. J. Saltzer, D. Reed, D.D. Clark. End-to-end arguments in system design // ACM Transactions on Computer Systems. — 1984. Vol. 2, N. 4. — P. 277–288.

Роберт Ван Ренессе (rvr@cs.cornell.edu) — профессор, Хаким Уэзерспун (hweather@cs.cornell.edu) — профессор, Чжимин Шэнь (zshen@cs.cornell.edu) — научный сотрудник, Вэйцзя Сун (wsong@cornell.edu) — научный сотрудник, Корнеллский университет (США).