Облако как шаг к трансформации ИТ

В настоящее время множество разных организаций в мире работают над четким определением того, что должно входить в понятие «облачные вычисления». Наиболее полным и непротиворечивым источником информации на эту тему можно считать документ «Определение облачных вычислений», выпущенный американским институтом стандартизации NIST (National Institute of Standards and Technology). В нем облачные инфраструктуры описываются с 3 разных сторон:

1. Модель использования и характеристики, которые ей определяются.

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

Рис. 1. Определение облачных вычислений

2. Типовые сервисы и граница разделения ответственности между оператором облака и клиентом. В этой части описываются 3 основных сервиса.

• IaaS (инфраструктура как сервис). Клиент использует физические или виртуальные серверы, дисковые хранилища, сетевые устройства и другие элементарные блоки, предложенные оператором облака, для строительства ИТ-инфраструктуры по своему усмотрению. Клиент не может определять, как указанные блоки физически соединены между собой, но может строить из них логические конфигурации в рамках ограничений, определенных оператором. Последний несет ответственность за функционирование элементарных блоков и их связь между собой, обслуживанием ОС и прикладных систем занимается клиент.
• PaaS (платформа как сервис). Сервис, позволяющий пользователю установить в облачной инфраструктуре самостоятельно разработанное приложение, использующее операционные системы, языки программирования, библиотеки, СУБД и другие сервисы, предоставленные оператором. Оператор обеспечивает функционирование платформы и ее масштабирование при необходимости, клиент занимается только поддержкой приложения.
• SaaS (программное обеспечение как сервис). Клиент использует приложение, запущенное внутри cloud-среды. Пользователи подключаются к нему с помощью различных протоколов (HTTP, RDP и т.д) и разных устройств, состав которых определен оператором облачного сервиса и разработчиком приложения. Поддержка приложения полностью осуществляется оператором, клиент может влиять только на ограниченное число настроек (заведение пользователей, назначение прав, включение/выключение дополнительных сервисов).

3. Расположение относительно пользователя и порядок взаимоотношений с ним.

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

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

Важным следствием перехода к облачной модели является определение уровня ИТ-инфраструктуры, на котором проходит граница разделения ответственности между оператором cloud-среды и клиентом. Клиент может выбрать, какую часть задач по поддержке инфраструктуры отдать в облако, а какую оставить в своем ИТ-подразделении. Также точка разграничения ответственности влияет на то, в каких измеримых величинах пользователь оплачивает оператору потребляемые услуги. В случае с IaaS это могут быть объем дискового пространства и параметры виртуальных машин, в то время как с SaaS – количество пользовательских логинов и доступных пользователю возможностей приложения. «Перевод» актуального количества потребленных ресурсов ИТ-инфраструктуры в метрики приложения выполняет оператор облачного сервиса.

Вторым важным следствием выбора облачных вычислений является то, что пользователь больше не контролирует оборудование напрямую, передав эту задачу оператору. Он заключает с оператором соглашение об уровне сервиса (SLA, Service Level Agreement), в котором прописаны все параметры предоставляемых услуг, их стоимость, а также ответственность сторон за несоблюдение условий соглашения.

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

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

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

Поскольку с момента возникновения интереса к облачным технологиям прошло уже несколько лет, мы с вами можем проанализировать накопленный опыт, чтобы понять, какие из направлений развития являются наиболее перспективными. Недавно консалтинговым подразделением нашей компании был выпущен отчет, основанный на опросе около 50 крупных компаний по поводу результатов внедрения облачных решений и планов на ближайшее будущее ( «Enterprise Journey to the Clouds», https://www.jetinfo.ru/Uploads/EJ-to-Clouds.DE9BE2AF83284C479026B4A58398ACAD.pdf.). Согласно его результатам, наибольший интерес представляют решения уровня SaaS, упрощающие поддержку рабочего пространства пользователей. Примером является перенос в облако SaaS корпоративной почты, телефонии, CRM, виртуальных десктопов пользователей.

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

Аппаратная платформа для облака

У человека, хорошо разбирающегося в принципах построения ИТ-инфраструктуры современного ЦОД, часто возникает ощущение, что облако – это некая «обертка» для все тех же серверов, дисковых массивов, коммутаторов и т.д. Многие компании даже пытаются утверждать, что ничего нового cloud-технологии в себе не несут, считая их лишь маркетинговой уловкой. Это утверждение верно лишь в той части, что на самом нижнем уровне инфраструктуры мы действительно видим привычные для нас серверы, СХД, коммутаторы. Важным отличием облачной архитектуры является то, что она позволяет нам делить нашу физическую инфраструктуру на множество «виртуальных инфраструктур», или «виртуальных ЦОД», и осуществлять управление каждым из них независимо от остальных. Причем эти ЦОД могут иметь различный состав виртуальных компонент и разную внутреннюю структуру, и все это должно поддерживаться физической архитектурой нашего облака. Это требование обеспечивается за счет применения технологий виртуализации на всех уровнях, основным его следствием является возможность построения нашей системы из стандартных компонентов, и даже более того – мы можем стандартизировать архитектуру всей нашей облачной системы. Это дает нам ряд преимуществ:

• проблемы с совместимостью компонентов решаются один раз при разработке стандартизованной инфраструктуры, в дальнейшем используются только оттестированные конфигурации, что значительно сокращает ввод новых систем в эксплуатацию;
• процесс обновления физической архитектуры, занимающий несколько месяцев, никак не связан с созданием логических конфигураций ЦОД. Они могут создаваться в течение нескольких минут и меняться хоть каждый день в соответствии с требованиями бизнеса;
• обслуживание физической и логической инфраструктуры может выполняться разными группами специалистов;
• регламентное обслуживание отдельных элементов инфраструктуры может проводиться без остановки предоставления услуги;
• решение о необходимости модернизации и расширения физической инфраструктуры может приниматься заранее на основании данных мониторинга нагрузки и информации о планируемых к внедрению системах. Это означает сокращение простоев, связанных с отсутствием необходимых ресурсов;
• стандартные элементы инфраструктуры имеют известные характеристики производительности, ресурсы, необходимые для работы сервисов, могут быть определены заранее путем тестирования. Поэтому типовая архитектура системы позволяет нам планировать распределение во времени затрат на создание и поддержку ИТ-инфраструктуры.

Исходя из преимуществ, которые дает виртуализация, наша компания спроектировала типовую архитектуру виртуального многопользовательского дата-центра – VMDC (Virtual Multi-Service Data Center) – высокодоступного, безопасного, гибкого и эффективного. Архитектура проверена на совместимость всех компонент, сбалансирована по производительности и подходит для построения виртуализированных ИТ-инфраструктур любого уровня. Она строится по модульному принципу, что позволяет наращивать ее мощность по мере появления требований к различным типам ресурсов. Также архитектура VMDC поддерживает построение различных архитектур «виртуальных ЦОД» и позволяет значительно упростить процесс проектирования облачной платформы.

По умолчанию архитектура VMDC определяет 4–5 типовых шаблонов виртуальных ЦОД, которые могут быть развернуты автоматически, они схематично изображены на рис. 2.

Рис. 2. Архитектура Cisco VMDC как основа для создания облачных платформ

Конечно, при необходимости под каждую конкретную задачу может быть разработан свой набор шаблонов, также существует возможность «выключать» отдельные компоненты. Например, клиент может выбрать шаблон Gold, но отказаться от использования балансировщика нагрузки или маршрутизатора в нем. И конечно же заказчик может в автоматизированном режиме гибко управлять составом и характеристиками виртуальных машин и сетевых подключений внутри такого виртуального ЦОД.

Модульный дизайн включает в себя 2 основных понятия – модуль (POD, Point Of Distribution) и интегрированная вычислительная система (ICS, Integrated Computer Stack).

ICS представляет собой заранее протестированную и интегрированную комбинацию из вычислительных систем, систем хранения и платформы виртуализации. В настоящий момент архитектура VMDC ориентирована на существующие модели ICS, такие как Vblock компании VCE или FlexPod компании NetApp. Однако концепция VMDC не привязана к использованию каких-то конкретных ICS определенного производителя и может быть легко расширена. Компания может собрать собственные конфигурации вычислительных систем, наилучшим образом удовлетворяющие ее потребностям и принципам модульной архитектуры. Модули ICS используются для обеспечения требуемой вычислительной мощности облачной инфраструктуры, они определяют такие характеристики, как процессоры, память, дисковый объем.

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

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

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

Что делает инфраструктуру облаком

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

Рис. 3. Общая схема системы управления облаком

В этой архитектуре выделяются 3 уровня, выполняющие определенные функции.

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

2. На уровне автоматизации сервисов сосредоточена основная логика облачной платформы:

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

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

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

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

Наша компания предлагает собственный продукт для автоматизации услуг IaaS – Cloupia (сокращение от CLOud UtoPIA, создатели продукта старались подчеркнуть, что он способен решить все или почти все рутинные проблемы, возникающие при администрировании ИТ-инфраструктур).

Cisco Cloupia предназначен для автоматизации начальной конфигурации и дальнейшего управления конвергентной инфраструктурой, под которой понимается аппаратно-программный комплекс, состоящий из системы хранения, сети (LAN и SAN), вычислительного ядра и платформы виртуализации. Управление осуществляется на основе объектно-ориентированных моделей, описывающих сервисы, которые должны быть развернуты поверх конвергентной инфраструктуры. В продукте реализованы уровни 2 и 3 из вышеописанной модели.

Рис. 4. Cisco Cloupia (официальное название: UCS Director) – центральный элемент для создания платформы управления облачным ЦОД

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

Пользовательский портал – другой важный компонент Cloupia. Во-первых, он позволяет гибко разграничивать права сотрудников в системе, объединять их в организации, делегировать отдельным пользователям права администрирования внутри их организаций, тем самым снимая эту работу с администраторов облачной платформы. Также он позволяет показывать каждой группе только те сервисы, которые ей доступны. Каждый пользователь системы во время работы находится в своем виртуальном рабочем кабинете, из него он может управлять только отведенными ему ресурсами виртуального пространства.

Мир многих облаков

Конечно, вопросы, рассмотренные в этой статье, – это лишь верхушка айсберга, в реальности компании, задумавшейся о предоставлении облачных сервисов, придется решить ряд довольно сложных задач. И б?льшая их часть даже не техническая, а организационная, ведь, как мы говорили вначале, внедрение cloud-технологий означает перераспределение задач и ответственности между операторами услуг и их потребителями. Но мир устойчиво движется в сторону внедрения облачных технологий. Так, по данным Cisco Global Cloud Index, в 2012 году соотношение между задачами, решаемыми с помощью традиционных и облачных инфраструктур, составляло примерно 60 к 40%, и тенденция такова, что к концу 2013 года эти доли сравняются. А дальше нас ждет устойчивый рост числа задач, решаемых с помощью облачных инфраструктур, и необходимо готовиться к нему уже сейчас.

Если смотреть вперед, внедрение облачных технологий способно значительно изменить нашу жизнь. Уже сегодня жители мегаполисов активно пользуются облачными сервисами навигации с учетом дорожной ситуации. А сайты многих компаний позволяют посмотреть местоположение офисов, магазинов, банкоматов на карте и не только найти ближайший к человеку, но и проложить к нему маршрут, например, с использованием общественного транспорта. Решение подобных задач требует развитых механизмов взаимодействия между различными системами, и разработкой стандартов для них занимается в настоящее время несколько крупных организаций, таких как Distributed Management Task Force и Open Grid Forum. Как только эти механизмы взаимодействия будут разработаны и начнут использоваться, нас ждет много интересных новшеств. Например, возникновение систем с обратной связью, когда количество проложенных маршрутов в автомобильных навигаторах будет приводить к изменению настроек системы регулирования дорожного движения, ведь автоматические системы управления светофорами испытываются сейчас во многих странах мира.

Сразу оговоримся, что речь идет не только о рынке платных облачных услуг, но в первую очередь о модернизации внутренних ИТ-служб компаний, переходе на облачные принципы при построении внутренней инфраструктуры. Использование подхода Private Cloud позволяет упорядочить процессы внутри компании, автоматизировать большую часть выполняемых задач и за счет этого снизить себестоимость и повысить качество оказываемых ею услуг. Применительно к инфраструктуре оператора связи, например, это означает, что вместо построения отдельных комплексов под предбиллинг, биллинг, PCRF, порталы пользователей (внутренних и внешних), бухгалтерские системы, CRM и т.д. создается универсальная облачная платформа, внутри которой по принципам IaaS организуются отдельные «виртуальные ЦОД» под каждую систему. Для разработчиков внутренних приложений создаются контейнеры PaaS с набором необходимого ПО. Наиболее универсальные сервисы, такие как электронная почта, разворачиваются из готовых SaaS-пакетов и отдаются в управление администратору электронной почты. Это позволяет разделить процессы администрирования прикладных систем и задачу поддержки функционирования ИТ-инфраструктуры, значительно сократить сроки ввода новых систем в эксплуатацию и в конечном итоге сэкономить за счет более высокой степени утилизации оборудования.