Реклама

Инфраструктура в виде сервиса (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, а провайдеров Интернета можно сравнить с операторами облаков, причем онлайн-сервисы сегодня...

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF