Облака 0

Опубликовал: Igor

Прежде всего, позвольте мне не называть это дело “клаудами”. У меня это слово почему-то ассоциируется с шифером.

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

Основная особенность облаков, в полном соответствии с принципом “как вы яхту назовете, так она и поплывет” – это весьма туманное понятие. Никто точно не знает, что это такое. Поскольку слово модное, каждый кулик немедленно объявляет свое интернет-болото “облачным”. Возразить по существу никто не сможет, а звучит круто.

В принципе сам Интернет – это облако. Одно большое облако. Но это не значит, что все, что в нем находится – облачное. Признаки общего не переносятся на частности.

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

Саму идею, в широком смысле, когда некий сервис предоставляется через Интернет, и пользователь этого сервиса просто пользуется им, еще называют SaaS – Software as a Service – “Программное обеспечение как сервис”. То есть, по большому счету, разница в том, что оно, это программное обеспечение, находится не на компьютере пользователя, а где-то еще. Но с ним можно работать через Интернет как если бы оно было на локальном компьютере (а сам компьютер, таким образом, можно освободить от избыточного софта и/или избыточных данных). Если раньше такими сервисами были, по сути, только веб-сайты, то сейчас это уже может быть практически все что угодно.

Короче говоря, на этом уровне, назовем его пользовательским, с облаком все в порядке, и всегда было в порядке, тут никогда ничего и не менялось, за исключением разнообразия сервисов. Весь же шум вокруг облаков начался тогда, когда облака стали распространяться вертикально вниз – на нижележащие слои. То есть, к примеру, разработчики тех самых сайтов тоже хотели не знать и никогда не задумываться о том, что лежит ниже их уровня – какие-то там серверы, операционные системы и все такое, а сосредоточиться на программировании и дизайне интерфейсов, – и они это получили. Например Google Apps – это именно такая штука. Более официальное, скажем так, определение этого облачного слоя – PaaS – Platform as a Service – “платформа как сервис”.

Есть и еще один слой, самый нижний. В этих безобразных aaS-акронимах он называется IaaS – Infrastructure as a Service. Говоря проще, это облачный хостинг. Самый известный пример – AWS, Amazon Web Services. Да-да, это тот самый Амазон, который магазин. Они создали всю эту облачную инфраструктуру для себя, а потом подумали, а почему бы ее не продавать. Она (как и конкурирующие инфраструктурные облака) обладает тем же главным облачным признаком: клиенты AWS не знают и не задумываются о том, что за аппаратное обеспечение там у них, какие серверы, роутеры, жесткие диски и т.п., но имеют возможность этим пользоваться в виде ресурсов, которые можно покупать именно в виде ресурса. То есть можно прикупить вычислительную мощность, объем памяти, дисковое пространство. Можно попользоваться одну минуту и заплатить за одну минуту. Это было бы невозможно без “отчуждения” собственно ресурса, который можно купить-продать-арендовать, от нижележащего хардвера, который работает себе спокойно и никуда не продается.

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

Технологии виртуализации заслуживают отдельной статьи, но пару моментов надо осветить, для ясности (пролистнуть эту часть).

Их все можно расклассифицировать таким образом. Во-первых, есть контейнеры. Это не что иное как простейший старый добрый chroot jail. Его получают пользователи шаред-хостингов за 5 баксов в месяц. Вообще-то это не виртуализация, строго говоря. Это просто домашняя папка юзера, насильно превращенная в корень операционной системы (т.е. в корень файловой системы ОС), так чтобы пользователь не мог из нее выйти (jail ~ тюрьма). Потом к этому добавляются кое-какие трюки. Например, для того, чтобы пользователь мог пользоваться базой данных, установленной на сервере, ему нужен доступ к общесистемной папке, где эта база находится. Но выйти из домашней папки пользователь не может, поэтому папку базы ему хард-линкуют в домашнюю папку (это такой трюк с файловой системой, головная боль админов). Чтобы пользователь не съел всю память, ему ставят ulimit-ы на доступ к памяти, кол-ву открытых файлов и т.п. Чтобы он не съел весь диск, ставят квоту на диск. То есть это, в общем, такое трюкачество. Пользователь реально является пользователем всего сервера, только он не может реализовать свои права, потому что ему заблокирован доступ везде где только можно. Технология настолько широко распространена, что уже отработана до мелочей и довольно надежна. Основные примеры:

  • cPanel – коммерческий продукт для хостинговых компаний. Кажется может работать только на RH/Centos.
  • OpenVZ – изначально коммерческий продукт компании Parallels, отпущенный в свободное плавание. Требует модифицированного ядра, в настоящее время из линуксов его поддерживает только RH/Centos, да и то видимо только потому, что они традиционно отстают от мейнстрима лет на пять. Насчет поддержки в свежевышедшем Centos6 я не в курсе.
  • Контейнеры Solaris (забыл как называются). Упоминаю только потому, что на них построен хостинг Joyent, разрекламированный как компания номер один в облачных технологиях. В реальности это тот же шаред-хостинг, только уже не за 5 баксов в месяц2 :)
  • LXC – причина смерти OpenVZ. Это родные контейнеры ядра Linux3. Точнее это называется Cgroups, а LXC – это набор утилит для управления.
  • Прочие панели (Plesk и т.д.). Нет нужды перечислять их, они все примерно одно и то же.

Далее идут собственно технологии виртуализации (контейнеры я бы скорее назвал технологией управления ресурсами).

В терминах, как обычно, присутствует путаница, поэтому лучше классифицировать по сути, а не по названию. А суть там такая.

У реальной операционки (хост ОС), которая работает на реальном железе, есть ядро. Ядро есть у любой операционки, поэтому я не буду отвлекаться на детали.

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

Как бы ни осуществлялась виртуализация, она всегда обязательно требует работы специального сервиса, называемого монитором виртуальных машин или гипервайзором. Он нужен для перевода (трансляции) системных вызовов виртуальных систем к реальному ядру и обратно. Попросту говоря, это агент между ними, который дурит их обоих: гостевая виртуальная система думает, что шлет запрос ядру, но запрос поступает в гипервайзор. Гипервайзор отправляет запрос настоящему ядру, которое просто ничего не знает ни о каких гостевых системах и обрабатывает его как обычно. Гипервайзор получает от ядра что хотел, и выдает результат обратно гостевой системе. Только гипервайзор знает, куда отдать результат, он же его получал. Ядро не знает.

Гипервайзоры способны переводить инструкции туда и обратно между разными процессорами: то есть реальным процессором может быть Интел, а гостевая система при этом будет свято уверена, что работает с PowerPC или, скажем, каким-нибудь ARM. Но чем больше надо переводить инструкций, тем медленнее это все работает. Такая виртуализация, с полным переводом, так и называется – полная виртуализация.

Казалось бы, если виртуальные машины будут работать на виртуальном процессоре, аналогичном реальному, гипервайзор будет работать быстро, там же переводить инструкции не надо, только гонять их из виртуального процессора в реальный. Как бы не так. То есть оно как бы так и есть, вот только не для всех процессоров. Почти полвека уже назад такая виртуализация прекрасно работала на мейнфреймах. Работала она очень просто и очень быстро: системные вызовы, которые отправлялись в ядро гостевыми системами, не могли быть выполнены и вызывали ошибку “доступ запрещен”. Обработчик ошибок передавал их гипервайзору, который их транслировал. Это очень простая и надежная схема, но она не работает для процессоров Интел (а также, само собой, АМД и т.п. – всех совместимых по набору инструкций). Процессоры Интел волей-неволей наследуют все тот же убогий базовый набор, который был вшит в самый первый процессор Интел, созданный для калькулятора. Требования к калькуляторному набору были невысоки, и поэтому существенная часть инструкций (17 штук) вообще не вызывает ошибок, даже будучи отправленной куда не следует (куда их вообще можно отправить “не туда” в калькуляторе? :) ). Следовательно простой перехват невозможен, гипервайзор должен принимать решение сам, читая каждую инструкцию, и это делает неполную виртуализацию на интеловских архитектурах все еще слишком медленной для серьезного применения.

Однако же в начале этого века виртуализация начала активно развиваться и на интеловских архитектурах и даже пошла в народ. Существенную роль в этом сыграла компания VMWare, сосредоточившаяся на создании как можно более быстрого гипервайзора, что им, в общем, удалось в том смысле, что замедление работы гостевых систем через их гипервайзор было не таким ужасающим, и на заре этого второго прихода виртуализации их технология стала практически ее, виртуализации, синонимом. Разумеется разнообразного софта существовало и до них, в основном предназначенного для перевода инструкций из одного набора в другой, для разнообразных эмуляций и т.п., но VMWare сосредоточила усилия на виртуализации, скажем так, операционной системы, а не процессора, что не требует полного перевода всех инструкций, и только на процессорах x86. Это не единственный их продукт, разумеется, но только этот важен в том смысле, что сделал виртуальные машины реально работающими с более-менее разумной скоростью в пределах одного и того же процессора x86. Стало возможным запросто запускать, скажем, Linux внутри Windows и наоборот.

Основой для всех крупных облачных хостингов однако стал другой гипервайзор – опенсорсный Xen (произносится “Зен”). Причиной этого была предлагаемая последним технология паравиртуализации – которая не требует перевода инструкций на лету в силу того, что гостевые системы модифицированы таким образом, что они посылают “правильные” инструкции. То есть, попросту говоря, тот перевод инструкций, который гипервайзор VMWare делает сам, для паравиртуального гипервайзора Xen делается в исходном коде операционных систем (или драйверами). А сам гипервайзор только гоняет их туда-обратно. Это, конечно же, делает паравиртуализацию малопригодной для десктопа, но для хостинга – в самый раз. И, главное, это делает ее быстрой настолько, что в ней появляется коммерческий смысл: цена виртуализованной операционки у хостера становится разумной относительно производительности этой операционки. Некоторый минус паравиртуализации заключается в том, что по понятным причинам в качестве гостевых операционок используются только опенсорсные ОС.

Определенную интригу этой истории придало то, что примерно в это же время проснулись Интел с АМД и прилепили к своим процессорам очередные заплатки4 – по поводу тех самых 17 инструкций5. Это сделало возможным так называемую хардверную виртуализацию – запуск гостевых систем без модификаций и без тормозов, связанных с полным переводом инструкций.

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

Дальше, в общем-то ожидаемо, скорость хардверной виртуализации начала расти с каждым новым семейством процессоров. Лишнее время (оверхед) снизилось в несколько раз за время существования этих заплаток (они называются Intel-VT и AMD-V соответственно) и привело в итоге к тому, что если не хостинги, которые по понятным причинам более инертны, то поставщики операционок переключились с поддержки гипервайзора Xen на родной линуксовый гипервайзор KVM, который обладает весьма ограниченными возможностями в смысле паравиртуализации, но зато не требует манипуляций с ядром. Ядреная команда (Линус Торвальдс сотоварищи) правда поддержала Xen тоже, начиная с ядра 2.6.37, и, таким образом, оставила вопрос открытым. Каждый волен выбирать себе KVM или Xen, оба имеют свои плюсы и минусы.

Итак, мы наконец имеем возможность набросать “сумму технологий” виртуализации6:
  • Полная виртуализация. Может все: эмулировать любой процессор и запускать любую операционку. Но слишком медленная и работает за пределами уровня ядра (уровня 0), что не очень хорошо. Применяется в основном для исследований и построения сред разработчиков (например для разработчиков софта для мобильных устройств). Пример – QEMU, KVM использует именно его, когда нужно эмулировать чужой хардвер.
  • Бинарная трансляция (VMWare). Предназначена для архитектуры x86 и не умеет эмулировать другие процессоры. Работает не в уровне 0, но достаточно быстрая (не более 20% потери производительности). Применяется в продуктах VMWare :).
  • Паравиртуализация (Xen). Предназначена для архитектуры x86 и не умеет эмулировать другие процессоры. Работает за пределами уровня 0, но слегка улучшает ситуцию с этим делом тем, что операции ввода-вывода производятся через родные драйверы специальной привилегированной виртуальной машины. Вероятно до сих пор является самой быстрой технологией виртуализации для x86, но требует специально модифицированных операционных систем – существенно модифицированных “гостей” и по крайней мере специально подготовленных хост-систем (Амазон, к слову, до сих пор работает на старом ядре Xen версии 2.6.18, модифицированном РедХэтом для Xen хостов).
  • Аппаратная виртуализация. Тоже только для x86. Аппаратного в ней не очень много, это не очень удачный термин. На самом деле это “правильная” бинарная трансляция без необходимости оценивать инструкции, ибо процессоры с поддержкой виртуализации умеют выдавать только безопасные инструкции. Но сама трансляция никуда не делась, и производительность этого типа виртуализации хоть и выше, чем у бинарной трансляции VMWare, но видимо пока еще ниже, чем у паравиртуализации. Почему “видимо” – потому что а) быстро догоняет и б) сильно зависит от характера ваших задач. Самое же главное в аппаратной виртуализации – под ней гостевые операционки работают в правильном уровне 0. Сам гипервайзор работает в специальном уровне “минус один”, т.н. Root Mode, а все ядра – как хоста, так и гостей – имеют одинаковые привилегии, что делает гостей полноценными системами без даже гипотетической возможности как-то друг другу помешать. Это очень важно, и ради этого можно даже пожертвовать некоторой производительностью. Тем более что оверхед паравиртуализации и хардверной виртуализации составляет порядка единиц процентов, а разница между ними, соответственно, и того меньше.

Нетрудно заметить, что виртуализация, на которой держится вся идея облаков – штука сильно сложная. Возникает вопрос зачем такая нужна, она же снижает производительность и надежность. И это правда, снижает. Но это перевешивается с большим запасом гораздо более богатыми возможностями архитектурирования проектов. Ключевую роль тут играет чисто облачная возможность управлять серверами и ресурсами через API. То есть если у вас сервер у хостера, на сервере операционка, в операционке сервисы крутятся – каждый из нижележащих слоев является потенциальным убийцей всех вышележащих. Моргнуло электричество в датацентре, накрылся диск в сервере, кончилась память в операционке – в каждом таком случае ваш проект падает, сайт недоступен. Это называется SPOF – в случае традиционного хостинга их множество. Авария на любом уровне вызывает полную остановку вашего сервиса. Облака позволяют исключить их все – или по крайней мере большинство, но это вам решать, зависит от финансов. Чисто технически в облаке возможно реализовать такую инфраструктуру проекта, что уронить такой проект будет невозможно, поскольку у него не будет ни единой SPOF, а количество доступных вычислительных ресурсов будет изменяться динамически в зависимости от нагрузки.

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

Так вот, возвращаясь к API и SPOF. Как обеспечивается надежность в облаке? Очень просто: если у вас, скажем, накрылся сервер, другой сервер это видит и запускает новый такой же7. А погибший можно просто убить, он больше не нужен, и вы за него уже не платите. Операция занимает минут 15 плюс-минус. Чтобы не было даже этих 15 минут, можно предусматривать дублирующие сервера, и чтобы это не было накладно, нужно максимально разделить функции по разным серверам, в идеале один сервер – одна функция. Это дает возможность определять политику дублирования в зависимости от критичности функции.

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

Это, к слову, дает еще один профит от размещения проекта в облаке: когда вы планируете ресурсы в традиционном хостинге, вы закладываетесь на предполагаемый максимум нагрузки. То есть если у вас ресурсов столько, что они держат дневную нагрузку, значит ночью они простаивают, и вы зря платите деньги. В облаке ресурсы можно сделать полностью “резиновыми”. Нет посетителей – ресурсы минимальны, платите мало. Есть посетители – ресурсы добавляются, платите больше. Это, правда, не значит, что облако обходится дешевле всегда – но у вас есть возможность спроектировать общую структуру таким образом, чтобы получить от этого определенную выгоду. Можно, например, комбинировать хардверные и облачные ресурсы – но это уже “продвинутая” тема.

Как запускаются эти новые сервера, и откуда там нужный софт с нужными настройками? Очень просто: вы их сначала создаете, сетапите и конфигурируете, а потом сохраняете в файл, который хранится у хостера, но может храниться и где-то еще. Новые сервера запускаются из этого файла – “имиджа” сервера.

Вся эта функциональность требует, как можно догадаться, какого-то сервиса менеджмента, который мониторит нагрузку, доступность серверов, запускает и останавливает сервера и докладывает вам о произошедших событиях. Это интересный вопрос и большая тема. Я пожалуй оставлю ее для отдельной статьи-обзора, сейчас отмечу только два момента:
  • ни один из имеющихся на рынке сервисов, скорее всего, не удовлетворит ваши потребности без определенных усилий с вашей стороны: придется поскриптовать, у каждого проекта свои особенности
  • по этой причине я лично убежден, что вместо “готовых к использованию” сервисов нужен понятный и простой фреймворк для скриптования процедур и политик. Поэтому я порекомендую собственный продукт, созданный именно для этого – M-script

С облаками связана еще одна большая (и больная) тема. Я уже упомянул выше, что не все так называемые облачные сервисы одинаково облачны. Честно говоря, облачных сервисов почти не существует. По сути все сервисы, объявляющие себя облачными, являются ни чем иным как обычными сервисами, размещенными в облаке. Казалось бы, ну ладно, ну называют они себя облачными, делов-то. Но из этого есть одно неприятное следствие. Вот пример ужастика наших дней (по ссылке англоязычный пост в журнале Wired). Вкратце, у человека увели все аккаунты: гугловский, iCloud и Твиттер, удалили все файлы с Айфона, Айпада и Макбука при помощи утилиты, встроенной в iCloud, удалили гугловский аккаунт и разместили в Твиттере сообщение, что аккаунт хакнут8. Человек потерял (возможно полностью утерял, на нынешний момент нет полной ясности) последние фотографии умерших родителей и первого года своего сына, а также всю почту из Gmail.

Чем показателен этот случай: человек этот – ИТ-журналист. Пишет для Gizmodo и Wired – то есть должен понимать, что к чему в мире интернет-сервисов. И вот что он пишет:

Более того, если ваши компьютеры пока еще не подключены к облаку, они скоро будут. Эппл прилагает большие усилия для того, чтобы все его покупатели начали использовать iCloud. У Гугла целая операционная система основана на облаке. И Windows 8, наиболее облачно-ориентированная операционная система из всех, что мы видели до сих пор, попадет на десятки миллионов десктопов в следующем году. После того, что произошло, я думаю, что системы, основанные на облаке, нуждаются в фундаментально иных защитных мерах. Защитные механизмы, основанные на паролях – которые могут быть взломаны, изменены или получены при помощи социального инжиниринга – в эпоху облачного компьютинга уже не являются достаточными.

Конечно же я бы и не упоминал этого конкретного бедолагу, если бы это заблуждение не было чрезвычайно широко распространено. Возникло оно очень просто: ИТ-бизнесу хотелось денег поскорее, облачные дела выглядели как новый прорыв, buzzword, то есть нечто, подо что можно развести инвесторов на деньги. И развели весьма успешно: на эти деньги было создано немало псевдооблачных сервисов, многие из которых вполне неплохи сами по себе, вот только облачные вычисления тут ну совсем ни при чем. У всего этого сонма сервисов облачного – только подложка, то есть они хостятся в инфраструктурном облаке. Да и то далеко не все.

Ведь если бы iCloud и Google работали на одном-единственном сервере (ну да, вот такой сервер, ну очень большой) – разве что-то изменилось бы в смысле безопасности? У вышеописанного пострадавшего не увели бы пароли? Да ничего бы не изменилось, и пароли увели бы точно так же. Ну и при чем тут облако тогда? Облако тут оказалось “подставлено” теми самыми людьми и компаниями, которые активно продвигали облака в массы и называли облачным все проекты подряд, чтобы получше продать эти проекты инвесторам. Теперь это бьет по ним же самим обратно, потому что слыша звон о “незащищенности” облаков, пользоваться новыми продуктами и услугами не торопятся серьезные корпоративные клиенты. То есть с легкой руки дельцов индустрии облачным стали называть практически все, что существует в интернете, а в интернете существует много чего нехорошего, и теперь все это нехорошее тоже оказалось облачным.

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

Оттолкнусь снова от самого первого облака – Интернета. Почему он является облаком для пользователя? Потому что он распределен и децентрализован. Пользователь получает к нему доступ независимо от того, где этот пользователь находится, и Интернет при этом один и тот же (ну не без некоторых исключений типа великого китайского файрволла и трюков гео-айпи). Ключевое слово тут – децентрализация. Вы не можете потерять Интернет, вам ну нужно носить его с собой, он не может исчезнуть, у него нет единого центрального рубильника9.

Вот и идея облака вообще – в том же, в децентрализации. Почему в облаке безопасно хранить файлы? Потому что они хранятся децентрализованно, и не существует единого места, где можно их повредить или удалить. Это в теории так. На практике сервисы хранения файлов децентрализованы только на уровне ресурсов, а ресурсы эти принадлежат какой-то компании и являются основой какого-то сервиса. Ни этот сервис, ни тем более компания не являются децентрализованными, и таким образом, такой сервис не может являться облачным по определению. Что как раз и демонстрирует вышеописанный случай. Вы получаете доступ через центральную систему идентификации, принадлежащей компании и сервису, эти данные хранятся в базе данных, которая может сломаться, сохранность этих данных зависит от политики безопасности и правильной ее имплементации в рамках данного сервиса, их могут, таким образом, украсть и получить доступ к вашим файлам. Ну какое же это облако? Тут есть те самые “единственные точки отказов” (SPOF), которые я упоминал раньше, и наличие этих точек превращает облако в не-облако.

И вот к чему мы приходим в итоге: облако не может быть продано как сервис, оно от этого перестает быть облаком.

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

Так как же получить облако? Реальное облако, со стопроцентной надежностью?

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

Чтобы объяснить всю эту несколько запутанную философию, приведу пример.

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

Как и произошло с тем журналистом, вы можете это все потерять совершенно элементарно – если кто-то узнает ваш пароль. Никакой облачности в таком сервисе нет и быть не может, будь там хоть сто облаков внутри.

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

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

Возможно это при помощи тех самых облачных интерфейсов. Частично дело тут в аутентификации. Пароли, разные секретные вопросы-ответы – не являются достаточно надежными. Просто потому что они передаются через каналы связи и могут быть перехвачены; они хранятся (пусть даже и в хешированном виде) в базах данных, которые могут быть взломаны и т.д. И они человеческие. Сервисы же между собой могут аутентифицироваться гораздо более сложными (нечеловеческими :) ) методами, защищенными от перехвата и взлома. Об этом же и пишет пострадавший: “Защитные механизмы, основанные на паролях – которые могут быть взломаны, изменены или получены при помощи социального инжиниринга – в эпоху облачного компьютинга уже не являются достаточными.” – и это верно, вот только в облаке никогда не применяются защитные механизмы, основанные на паролях. Применяются же они только в сервисах, выдающих себя за облачные – а иначе у них не получится10.

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

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

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

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








используйте кнопку возврата браузера, чтобы вернуться к статье

1 Гугль использует обычные дешевые компьютеры вместо виртуальных машин. Не везде, иначе откуда бы взялся Ganeti. Но Гугль и не продает инфраструктуру, только платформу и софт (PaaS и SaaS), поэтому нет прямой необходимости виртуализовать инфраструктуру.

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

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

4 Упс, они сделали это снова: наборы команд Интел и АМД для поддержки виртуализации несовместимы друг с другом. Кто бы сомневался.

5 Конечно там не только эти инструкции, но они камень преткновения. Остальное (управление памятью и пр.) – дело хорошее, но вторичное.

6 Очень схематично и упрощенно, конечно.

7 Или, ровно так же, взломанный или зараженный сервер. Вопрос подачи сигнала и правильной обработки этого сигнала. Даже если что-то пошло не так (скажем, обновление приложения дало сбой) – в облаке проще и дешевле запустить новый сервер, чем разбираться с существующим, по крайней мере для живого сайта, функциональность которого надо восстановить как можно скорее. В предельно элементарном виде сервис авто-масштабирования и автозамены предоставляется и провайдерами облаков, но они не имеют доступа к внутренним делам сервера, и набор сигналов, которыми они могут руководствоваться, очень ограничен: они сводятся к вещам типа “ой, что-то трафика нету” и “ой, что-то много процессора кушаем”.

8 У группы взломщиков, взявшей на себя ответственность, как обычно, прослеживается по крайней мере частично русское происхождение. Но это к слову, это совсем другая тема.

9 Только не надо рассказывать сказки про DNS. DNS – не Интернет, а всего лишь служба в нем для удобства пользования.

10 Есть вещи типа OAuth – но это отдельный разговор. Универсальным средством это не является.

11 Вот пример на эту тему: Диаспора . Это не сервис, это продукт – ПО для организации так называемого “пода” социальной сети. То есть вы можете его скачать и установить. Нет, не совсем так же просто как какую-нибудь утилиту под Виндовс, но главное – что вы можете это сделать, и можете это сделать на своих собственных ресурсах, доступ к которым никто, кроме вас, не контролирует. А потом ваш под можно объединить с другими подами других людей или групп людей и получить социальную сеть. Чувствуете разницу? Есть и публичные поды, например diasp.org – но они не дают вам облако, ибо являются сервисами.

Комментарии

Выскажитесь:

Коммент