Заказ обратного звонка

Пожалуйста, оставьте свой телефон и мы перезвоним в удобное для вас время!
Нажимая кнопку ОТПРАВИТЬ, Вы принимаете условия пользовательского соглашения

Заказ обратного звонка

Ваш заявка принята. Ожидайте звонка.

Эволюция облаков


История и предпосылки появления

Идея совместного использования вычислительных мощностей прорастает корнями в переплетениях проводов мейнфреймов, университетских и военных сетях, в бобинах магнитных лент и стопках перфокарт. Для того, чтобы воспользоваться вычислительными ресурсами организации, очередность доступа к Deus Ex Mashine расписывалась с точностью до минут, что не устраивало пытливые умы. Ошибка в программе приравнивалась к “провалу” сессии, а следующее свободное “окно” в расписании приходилось бронировать заново.

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

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

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

Принципы построения облаков

Несмотря на кажущуюся размытость принципов и понятий, у облачной технологии есть набор четких правил, которыми руководствуется любой Cloud-service. На настоящий момент, все используют понятия и терминологию, сформулированную в документе “Определениях облачных вычислений” Национального института стандартов и технологий США от 2011 года. Ниже приведены определения, де-факто ставшие мировым стандартом для облачных систем.

1. On demand self-service – предоставление по запросу.
Сервис предоставляется по требованию клиента. То есть использование сервиса носит сеансовый характер – подключился, приступил к работе, завершил работу, отключился. Тарифицируется только время от включения до выключения сервиса, решение о подключении и отключении принимает сам клиент. При этом рабочий сеанс может длиться сколь угодно долго (например аренда веб-серверов в датацентре).

2.  Broad network access – развитая сеть доступа к сервису.
Сервис должен быть одинаково доступен с любого клиентского рабочего места. Вид клиентского устройства (IBM PC совместимый ПК, Mac, тонкий клиент, мобильный телефон) не должен влиять на качество предоставления сервиса. “Облачный” сервис, требующий наличия у клиента определенного типа рабочей станции или браузера, облачным не может называться по определению.

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

4. Rapid elasticity – гибкость сервиса.
Вычислительные мощности должны быть масштабируемыми. Клиент должен иметь возможность оперативно подключиться или отключиться от запрашиваемого ресурса. Например, добавление серверов в виртуальную облачную ферму должно быть прозрачным для пользователя и требовать от него минимума затраченного времени.

5. Measured service – измеримость сервиса.
Сервис должен иметь метрики для измерения. Как поставщик сервиса вы должны иметь возможность оценить как качество его предоставления, так и его себестоимость, которая зачастую зависит от десятка параметров - не только памяти и дискового пространства, но и энергопотребления серверов и арендной платы за помещение датацентра.

Модели построения облаков

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

1. Software as a Service (SaaS)

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

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

Наглядный пример SaaS-облака – Google Documents, который предоставляется на безвозмездной основе. В любой момент и из любой точки можно получить доступ к программному обеспечению для создания документов, редактирования электронных таблиц и т.д.

2. Platform as a Service (PaaS)

Допустим, потребность рассматриваемого для примера бюро в программном обеспечении удовлетворена, но возникает новая задача – есть CRM-система с СУБД, которую необходимо размещать на серверной платформе. Других задач у данного сервера не будет, поэтому покупка серверной операционной системы как и самого сервера представляется нам неэффективным расходованием средств стартапа. На помощь приходит второй тип облаков – “Платформа как сервис” PaaS. Провайдер по запросу предоставляет удаленный доступ к системе, на которой можно поднять не только необходимую СУБД, но и другие необходимые сервисы и программное обеспечение. При этом оплачивается не только сервер и операционная система, но и ее обслуживание – а значит, можно снизить требования к квалификации “приходящего” системного администратора или вообще отдать клиентские рабочие места на аутсорсинг

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

3. Infrastructure as a Service (IaaS)

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

Теперь приходит время для перехода на третий уровень абстракции облачного сервиса – “инфраструктура как сервис” IaaS. От его провайдера необходима возможность оперативно менять мощности наших виртуальных серверов и их число, а также гарантии их доступности из определенных точек мира, в которых расположены наши офисы. Таким для примера может являться Amazon Elastic Compute Cloud (Amazon EC2). Тарификация будет производиться только на основании количества и производительности предоставляемых виртуальных серверов, что более чем устраивает нас как на этапе бурного роста компании, так и на перспективу следующих трех лет.

Архитектура облаков

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

1. Private cloud - Частное облако

Если пользователями сервиса будут сотрудники одной организации – то это ее выбор. Частные облака также допускают использование сервиса подрядными организациями или клиентами компании. Размещение вычислительных мощностей никак не влияет на выбор модели – серверная ферма может находиться как в стенах самой организации, так и быть частью IaaS-облака в удаленном центре обработки данных. Примером частного SaaS-облака может с успехом служить виртуализованный кластер Microsoft Exchange с веб-интерфейсом.

Частный случай Private cloud – Community cloud (общественное облако). Данная модель подразумевает то, что облачным сервисом будут пользоваться сотрудники различных организаций, объединенные общей задачей. Само определение данной модели было впервые озвучено сравнительно недавно, в сентябре 2010 года Гордоном Хафф, одним из идеологов облачных сервисов. В качестве примера потребителей общественных облаков обычно приводятся медицинские организации, желающие распространять и делиться информацией невзирая на территориальное распределение и государственные границы.

2. Public cloud – публичное облако

Сервисами, предоставляемыми публичным облаком, будет пользоваться широкая аудитория. Один из самых известных примеров - youtube.com, позволяющий любому подключенному к сети интернет пользователю предоставлять доступ к своим видеофрагментам и просматривать видео, опубликованные другими пользователями.

3. Hybrid cloud – гибридное облако

“Смешать, но не взбалтывать” – это часть не только любимого Джеймсом Бондом коктейля, но и идеологии гибридного облака. Если соединить две или более системы различных приведенных выше типов – то получится именно оно.

По материалам: upgrade.cnews.ru