"Облака" и другие модели вычислений

Написать отдельную статью меня заставило некоторое количество статей (в том числе на EJ) за последние месяцы, в которых слово "облако" используется как синоним сочетанию "размещение системы у внешнего провайдера". Писать коментарий к каждой статье мне показалось не самым разумным. Надеюсь, что данная заметка сможет расставить точки над "i" хотябы в рамках данного ресурса.

Начнем с определений...

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

Представления сегодняшнего дня об "облаках" отличаются от представлений всего лишь 2-х, 3-х летней давности. Мне больше всего нравится вариант определения, который предложил Национальный институт стандартов США (его русскую версию можно найти в Wikipedia, в статье Облачные вычисления):

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

Итого - облако, это модель управления (владения, распределения, использования) вычислительных ресурсов или хостинга.

Какие еще есть модели предоставления ресурсов? Из "классических" я бы назвал такие:

• Виртуальный или разделяемый хостинг (англ. shared hosting)
• Выделенный сервер (англ. dedicated server)
• Виртуальный выделенный сервер (англ. Virtual Private Server, VPS или Virtual Dedicated Server, VDS)

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

Итак, пример.

Представьте, что у нас есть заказчик СЭД. Пусть это будет ВУЗ, а объектом автоматизации выступают внутренние управленческие процессы, включающие как приказы, так и процессы утверждения результатов сессий, приема абитуриентов и т.д.

У нашего заказчика есть очень интересная особенность - в течение года количество экземпляров процессов остается практически постоянным, за исключением периодов

• сессий (идут потоки ведомостей, допусков, приказов о переводах/отчислениях, и пр.)
• приема (личные дела, результаты экзаменов, приказы о зачислении).

Все эти пики суммарно занимают максимум 3-4 месяца в году, однако на время того же приема нагрузка на систему может превышать среднегодовую в несколько раз.

Вопрос: как правильно заказчику спланировать нагрузку, выбрав достаточные по производительности сервера, но при этом не переплатив за простаивающие мощности?

Чтобы наши рассуждения были более полными, дабавлю, что у заказчика есть и ряд других систем, которые тоже имеют свои пики нагрузки (иногда пересекающиеся - иногда нет):

• Бухгалтерия. Небольшие пики ежемесячно при начислении ЗП и приличный пик в конце года - сдача отчетности, закрытие бюджетов, ...
• Кадры. Пик: начало учебного года (прием/увольнение сотрудников и продление трудовых контрактов)
• Библиотека. Пики: начало и конец учебного года (выдача и прием учебников у студентов младших курсов - им выдают учебники централизованно), конец семестра (студенты принимаются за учебу)
• ... и т.д.

Однако, регулировка мощности - это не единственная проблема.

Вторая сложность: каждая система требует своих настроек среды. Например, СЭД требует обязательную установку последней версии Internet Information Services, Бухгалтерия использует аппаратные ключи защиты, а Библиотечная система была написана в незапамятные времена и очень нестабильно работает (если работает вообще) на последних версиях ОС.

Третья сложность - каждая из систем может иметь очень разные требования по безопасности и надежности (доступности).

...

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

Поэтому смело переходим к рассмотрению моделей размещения

Разделяемый хостинг

Как следует из названия, при таком типе размещения на одном сервере (а точнее внутри одного запущенного экземпляра ОС) устанавливаются сразу несколько систем (в пределе - все системы внутри единственного экземпляра).

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

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

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

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

Выделенный сервер

Здесь каждой системе выделяется свой физический сервер с установленной на нем ОС. Мы решаем проблему изоляции, но остается проблема распределения ресурсов. Мы вынуждены тщательно выбирать сервера под задачи, причем очень часто еще и закладывать довольно приличный запас по ресурсам (как в случае нашего заказчика, у которого загрузка может прыгать в несколько раз).

Кроме того, в случае возникновения проблем с одним из серверов мы не сможем оперативно перенести систему, т.к.:

• ведь все сервера у нас загружены своими задачами. или у нас есть несколько простаивающих "под парами" серверов)
• аппаратура серверов может различаться и весьма сильно, и простое копирование образа ОС (с настроенной и работающей системой) может быть не возможно. А значит на новом сервере нужно развертывание системы с 0 и перенос всех данных туда.

Как результат, у нас имеется пул серверов, с приличной недозагрузкой и риск простоев в случае возникновения аварий.

Виртуальный выделенный сервер

Это развитие предыдущего варианта. Теперь наш экземпляр системы размещается не на "голом железе" а внутри виртуальной среды, а это позволяет:

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

В следствие чего мы можем:

• закупать унифицированные сервера под несколько задач сразу. Как следствие:
  • снижение затрат на обслуживани
  • не будет проблем с "вырастанием" задачи из возможностей сервера (когда в прошлом небольшая задача теперь потребляет много больше, ее пришлось перенести, а ее бывший сервер, увы, никому больше не подходит)
• регулировать нагрузку, перемещая виртуальные машины с нагруженного сервера на менее нагруженный
• относительно безболезненно решать аппаратные проблемы, перенося виртуальные машины со сломанного сервера на оставшиеся рабочие

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

Возвращаемся к облаку...

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

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

Облако - это всегда внешний провайдер?

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

Более того, почти все крупные поставщики инфраструктуры: Microsoft, RedHat, Oracle, VMware, ... - имеют решения для организации частных облаков.

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

Ой, у меня еще остался вопрос(ы)!

А все-таки:

• кому реально полезны облака?
• на сколько они выгодны?
• на какую модель развертывания (частная, публичная или смешанная) стоит ориентироваться?
• и далее по списку...

А вот на эти вопросы я ответа не знаю! Ни одного толкового исследования или отчета касающегося внутренних бизнес-систем, я не знаю. Если вам попадется - прошу поделиться.