На рынке предлагается множество разнообразных облаков, в том числе внешние коммерческие (Public), внутренние (Private), гибридные (Hybrid) или общие (Community), однако для бизнес-пользователей различия между ними не всегда очевидны. Согласно информации из Wikipedia, для внутренних облаков на передний план выходит следующее условие: «и поставщик услуг, и их потребитель представляют одну компанию». Внешние же облака открыты, то есть «могут использоваться любыми лицами и предприятиями» и «не ограничиваются только внутренними приложениями отдельной организации». В случае гибридных облаков предприятие использует в качестве дополнения к своему внутреннему облаку еще и внешнее — с целью преодоления пиков нагрузок или в рамках стратегии по преодолению сбоев (Failover). А общее облако, в свою очередь, представляет собой объединение нескольких внутренних облаков, которые открыты для сотрудников отдельных компаний, но недоступны для посторонних.

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

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

Помимо рассматриваемой в данной статье инфраструктуры в качестве сервиса (Infrastructure as a Service, IaaS) к наиболее активно обсуждаемым моделям «облачных» сервисов относятся также платформа в качестве сервиса (Platform as a Service, PaaS) и программное обеспечение в качестве сервиса (Software as a Service, SaaS). В случае PaaS провайдеры услуг предоставляют пользователям среды разработки и исполнения в качестве сервиса. Эти платформы формируют основу для выполнения приложений и разработки собственных «облачных» бизнес-приложений. Модель SaaS позволяет, к примеру, через Интернет арендовать систему CRM в качестве стандартизованного сервиса и использовать его по мере необходимости.

IaaS расширяет выделенный хостинг инфраструктур ИТ в рамках концепций аутсорсинга или управляемых сервисов (Managed Services) с целью предоставления виртуальных компонентов инфраструктуры в виде услуги в соответствии с реальными потребностями. Эти компоненты — серверы, вычислительные мощности, сетевые ресурсы и средства хранения, системы архивирования и резервного копирования, коммуникационные устройства и другие элементы ЦОД и сетевой инфраструктуры — поставщик услуг предоставляет корпоративным пользователям в виде виртуальных служб посредством широкополосных сетей (обычно через Интернет).

 

ТРЕБОВАНИЯ

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

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

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

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

По сути, облачные сервисы могут размещаться на пространственно распределенных серверах. Но работа в реальном времени с распределенными приложениями возможна, только если расстояние между двумя вычислительными центрами не превышает 30 км, поскольку даже при наличии волоконно-оптических линий между ЦОД световым волнам требуется какое-то время на перемещение по сети. А если база данных в течение заданного интервала времени не получит ответа на запрос, то она может зависнуть или выдать сообщение об ошибке.

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

 

 

Рисунок 1. Построение сетевой инфраструктуры для надежного функционирования сервиса IaaS.

 

Кроме того, важную роль играют и сами центры обработки данных, которые должны обладать полностью избыточной инфраструктурой, чтобы простои серверов были минимальными. Таким образом, очень важно, чтобы в каждом ЦОД все необходимые для работы системы были избыточными. Это касается как активных устройств, систем бесперебойного электроснабжения, блоков питания, систем охлаждения, так и кабельных соединений. Требуется обеспечить максимальную доступность — насколько это экономически целесообразно. Согласно общепризнанным стандартам нормой является наличие двух параллельных структур ЦОД, соответствующих уровню надежности Tier III из стандарта TIA 942, что подразумевает доступность на уровне 99,982%, то есть за год суммарный простой систем ИТ не должен превышать 1,6 час

 

Рисунок 2. Среда IaaS предъявляет высочайшие требования не только к сети, но и к ЦОД, где размещаются виртуализированные компоненты.

Провайдер хостинговых услуг должен позаботиться о сохранности данных в модели IaaS. Стандарты безопасности в ЦОД учитывают это условие. Так, ЦОД высокой категории надежности имеют сертификат базовой защиты информационных технологий от BSI и соответствуют стандартам операционного аудита SAS70 Американского института дипломированных общественных бухгалтеров (American Institute of Certified Public Accountants, AICPA). Последнее подтверждает эффективность систем внутреннего контроля, что обусловливает сохранность клиентских данных внутри ЦОД (см. Рисунок 2). Оборудование, программное обеспечение и сеть должны постоянно снабжаться новейшими обновлениями и компонентами систем безопасности. На отдельных участках применяются, кроме прочего, автоматизированное управление безопасностью на базе правил для централизованной реализации брандмауэров, системы предотвращения/обнаружения вторжений (Intrusion Prevention/Detection Systems) и защиты от атак DDoS (Distributed Denial of Service). Таким образом, провайдер услуг IaaS обязан обеспечивать высокий уровень защиты, распределяя связанные с этим расходы между своими клиентами.

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

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

 

ЗАКЛЮЧЕНИЕ

Услуга IaaS обещает предоставление инфраструктур ИТ в виртуализированной среде в соответствии с потребностями заказчика. Основная выгода для предприятий заключается в гибком и быстром предоставлении услуг и снижении расходов за счет оплаты только реально потребленных ресурсов. Чтобы этот вид услуг завоевал широкое признание, корпоративные клиенты должны убедиться в их надежности и высокой доступности. Базовая предпосылка для этого состоит в том, что сервисы должны предоставляться на основе высокодоступной инфраструктуры операторского уровня (Carrier Grade) из ЦОД высокой категории надежности. Владельцы таких центров обработки данных часто имеют многолетний опыт работы в области хостинга и управляемых услуг, который они привносят в новый мир облачных сервисов.

 

Йенс Тамм — региональный менеджер по Германии и Австрии в компании Interoute.