Про "облака"

Предисловие

В последнее время студенты приносят рефераты про "облачные технологии Google", и у меня возникает сильное ощущение, что у информатиков слово "облако" заменило приставку "нано-" у пустозвонов про физику и технологии.

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

Введение (немного о RAID)

Для начала позвольте привести пример никак не связанной с облаками серверной технологии. 

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

Время копирования 3 Тб данных со средней скоростью 150 Мб/сек составит примерно 3·1024²/150 ≃ 20972 сек ≃ 5.83 часа. Выключение на это время сервера с "жалкой сотней посещений в минуту" означает потерю 35000 посетителей, поэтому сервера предусматривают дублирование данных или на уровне базы данных, или на аппаратном уровне.

Пример последнего - технология RAID, где несколько винчестеров не подключаются как независимые накопители, а доступны системе через RAID-контроллер как одно устройство. Данные при этом дублируются, вносится избыточная информация, используемая позже для коррекции ошибок. Благодаря этому, в RAID-массиве повреждённый диск уже можно просто заменить на ходу, без остановки системы (RAID hot swap) [1].

Архитектура серверной части приложений

Теперь давайте вернёмся к нашим "белокрылым лошадкам". Сперва очертим, что такое веб-сервер, который присылает веб-странички.

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

Идём дальше. Что такое запущенная программа? Это, если идти снизу вверх:

1. Железо: ЦПУ, ОЗУ, и периферия, доступная через BIOS.
2. Ядро ОС, абстрагирующая все устройства через их драйвера и администрирующая все процессы получения и использования ресурсов (порождение/уничтожение потоков, выделение памяти, доступ к файловой системе, ...) через API операционной системы. Для Linux это ядро (kernel) и POSIX API.
3. Оболочка ОС, начиная от минималистичного шелла (sh, bash, zsh) с отключенными по максимуму потребителями ресурсов, и заканчивая полноценными оконными менеджерами поверх X-сервера.
4. И только внутри этого кокона (или поверх всего этого фундамента) уже живёт сам веб-сервер, или база данных, или балансировщик, прокси, DNS-сервер, ssh-сервер, ftp-сервер и много кто ещё, причём в любых сочетаниях. 

Рисунок [3] иллюстрирует вышесказанное (ещё один внешний слой с веб-сервером и товарищами здесь не указан):

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

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

Механика работы сервера

Для понимания сути облака давайте нарисуем весь пусть сообщений от http запроса клиента до вызова функции API внутри сервера:

Сервер включён постоянно и в случае отсутствия запросов простаивает, а в случае пиковой нагрузки разбирает постоянно пополняемую очередь из запросов по одному запросу за раз. Самое хорошее, что веб-сервер каждое сообщение обрабатывает так, словно он его первый раз в жизни увидел (см. приложение 1 и [2]).

Виртуальная машина - это hot swap контейнер для работающего сервера

Если взять виртуальную машину (дальше ВМ), и запустить всю среду в ней, мы получим следующую картину:

По сравнению со старым вариантом, теперь весь "компьютер" хранится в файле виртуальной машины, гипервизор которой предоставляет доступ к самим устройствам. Такой вариант, несмотря на дополнительную нагрузку на ЦПУ в гипервизоре, даёт целый спектр новых возможностей.

Администрирование:

• файл виртуальной машины можно сохранять и восстанавливать без затрат времени на загрузку и инициализацию всей ОС;
• типичные предустановленные ОС (нужный набор из ядра, библиотек и сконфигурированных сервисов) можно просто скопировать и донастроить, сэкономив до пары часов времени на установку свежей системы;
• замену оборудования можно делать, остановив машину и скопировав её на аналогичную систему;
• аккуратное использование того факта, что бо́льшая часть системы идентична среди многих машин, позволяет свести операции копирования, переноса и обновления до работы только с различающимися участками [4].

С точки зрения облачных технологий, преимущества следующие:

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

Paas, SaaS, IaaS и прочая "латынь"

В вышеописанной архитектуре нет практически ничего нового. И до изобретения облачных технологий и виртуальных машин люди запускали сотни серверов для разгрузки очереди. И после их появления готовые чистые ВМ сдают в аренду с завидной регулярностью (VPS). Для всего этого придумано много терминов, дробя и запутывая простую в общем-то предметную область. 

Ниже я возьму сервер и, последовательно замораживая слои, доступные клиенту для администрирования и настройки, назову используемые для обозначения такой конфигурации названия [6].

IaaS: Infrastructure as a Service

Вам дают запущенную чистую ВМ, на которую вы сами ставите свою ОС (часто из списка готовых образов, предоставляемого провайдером). Все вышележащие слои и ответственность за их настройку и защиту целиком в ваших руках. Выйти из контейнера ВМ достаточно сложно, поэтому остальных пользователям датацентра вы вреда не нанесёте. Пример - Amazon t2.micro или большинство провайдеров [7]. Число запущенных ВМ можно регулировать.
Провайдер вам обеспечивает железо, IP-адрес, возможность держать свои ВМ в датацентрах всего мира (это позволяет направлять пользователя к ближайшему из них для обеспечения лучшего соединения).

PaaS: Platform as a Service

Провайдер даёт вам уже инсталлированные экземпляры ВМ с запущенными и настроенными базами данных, серверами и т.п.. Вы сами собираете их них кластер, пишете сайт на PHP или на чём хотите,  разрабатывая архитектуру всего решения, сами выкладываете материал для раздачи, сами думаете о масштабировании под нагрузкой.
Это большинство провайдеров LAMP решений (Linux + Apache (веб-сервер) + Mysql (база данных) + Php (язык генерации контента)) или решений на основе IIS (Windows, ...).
Провайдер обеспечивает: IaaS + настройку и функционирование ОС и всего софта, своевременное обновление ядра и всех компонент, быструю локальную связь внутри датацентра.
Для примера нетривиального SaaS/PaaS, рекомендую самостоятельно разобраться с GWT [8].

Saas: Software as a Service

Вместо написания своего сайта на PHP, вы берёте у провайдера доступ к уже готовому, настроенному и запущенному движку (от мощного WordPress до фреймворка наподобие Joomla или Django) и инжектируете только управляющий код (через админку или копированием файлов в открытые папки).
Это уже и блог-платформы, и первые ласточки всего направления вроде GWT [8], и решения наподобие GoogleDocs/Dropbox/WordPress, и этот самый блог на blogger.com. Говоря коротко, вы покупаете услугу ПО, не думая о поддержке и реализации.

Коротко: провайдер обеспечивает всё, вы только даёте материал (контент).

Заключение

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

Облачный сервис не имеет никакого отношения к:

• web 2.0;
• социальным сетям и сервисам;
• развёрнутым на их основе службам и услугам;
• большой производительности (High Performance Computing) и большим данным (Big Data).

Иными словами, называть SaaS "сервис хранения данных" dropbox "облаком" - это тыкать пальцем в джип и называть его "дизелем" или "бесступенчатой трансмиссией", и думать, что это синоним слова "джип".

Сама облачность с таким же успехом исправит ваш веб-проект, как и замена винчестера на RAID-массив - то есть никаким, если только ваша проблема не заключалась исключительно в тормозах системы хранения. Думать, что "облачность" - это некая серебряная пуля, так же глупо, как путать язык, на котором написана программа, с её алгоритмом.

Смысл этого поста

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

Или попрошу выполнить анализ того, как принципиально изменятся возможности пользователя с точки зрения того, что вместо изоляции отдельных ОС сейчас доходит до изоляции средствами гипервизоров отдельных процессов [5].

Приложение 1: обработка сообщений веб-сервером

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

Давайте рассмотрим, как выглядит типичный сеанс работы с веб-приложением:


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

---------------------------------------------------------------------------------------

[1] http://www.techrepublic.com/article/maximize-uptime-with-hot-swap-raid/

Статья про замену дисков на лету в RAID Level 1 конфигурации.

[2] REST - принцип.

[3] Рисунок из работы ??.

[4] Amazon - файловая система с хранением diff-ов для работы с кучей идентичных ВМ.

[5] OS Cube, ссылка на Xakep.

[6] http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F#.D0.9C.D0.BE.D0.B4.D0.B5.D0.BB.D0.B8_.D0.BE.D0.B1.D1.81.D0.BB.D1.83.D0.B6.D0.B8.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F


[7] провайдеры ВМ http://serverfault.com/questions/41037/best-hosted-vm-provider

[8] GWT