Статья, впервые опубликована в онлайн-журнале «В Облаке.РФ» (№2, апрель 2015 г.) под названием «ВЦОД — распределение облачности». http://воблаке.рф/archive/ed2/02strategy.html

Новый подход к созданию платформы IaaS – распределённый облачный ЦОД.

Услуги облачных вычислений принято подразделять на три класса, в соответствии с уровнем абстрагирования и сервисной модели провайдера. Заметим, что существуют и другие разнообразные облачные услуги (BPaaS, VSaaS и пр.), однако, в конечном счете, все известные облачные услуги можно, так или иначе, отнести к трем классам:

1) Инфраструктура, как услуга (IaaS, Infrastructure as a Service)

2) Платформа, как услуга (PaaS, Platform as a Service)

3) Программное обеспечение, как услуга (SaaS, Software as a Service).

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

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

Рис. 1 Традиционные ЦОДы и распределённый облачный ЦОД

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

На строительство ЦОДа для развертывания нового бизнеса или охвата нового рынка, как правило, уходит от полутора до двух лет. Ресурсы используются крайне неэффективно – от 40% до 60% мощностей серверов после запуска нового ЦОДа обычно простаивают.

Виртуальный ЦОД (VDC) можно создать из имеющихся ресурсов распределенного облачного ЦОДа за 1-2 часа.

В традиционных ЦОДах на разработку нового приложения уходит от 1 до 3 месяцев. В решении распределённого облачного ЦОД возможно автоматическое проектирование приложений на базе шаблонов с возможностью репликации. На создание и развертывание нового приложения с использованием виртуальных серверов приложений уходит несколько десятков минут. При этом обеспечивается эластичность использования серверов приложений.

Для управления и диспетчеризации ресурсов распределённого облачного ЦОД используется облачная операционная система с централизованной системой управления.

При заказе ресурсов пользователем для своего бизнеса по модели IaaS, провайдером услуг распределённого облачного ЦОД из имеющихся ресурсов «нарезаются» виртуальные ЦОД (VDC), на что уходит не недели и месяцы, как при строительстве традиционных автономных ЦОДов, а часы и минуты.

Преимущества распределённого ЦОД: сокращение времени вывода услуг на рынок (ТТМ), экономия затрат на техническую эксплуатацию, улучшение эффективности унифицированного управления и глобального администрирования.

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

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

Цель планирования ёмкости – обеспечение достаточной ёмкости IT-систем по оптимальной цене, при этом удовлетворяя как текущим, так и будущим операционным требованиям, а также учёт всех проблем производительности, зависящих от наличной ёмкости, услуг и ресурсов, предоставление требуемых IT-ресурсов без задержек и с учетом операционных потребностей в будущем.

Арендатор виртуальных дата-центров VDC (Virtual Data Center) использует только выделенные ему ресурсы и может ими управлять, ресурсы разных арендаторов изолированы друг от друга. Как видно, на базе решения распределённого облачного ЦОД можно предоставлять фактически новый вид облачных услуг DCaaS (ЦОД как услуга), относящихся тем не менее, к основному классу – IaaS. В настоящее время основной проблемой облачных провайдеров является преодоление недостатка наличных ресурсов ЦОД, увеличение коэффициента использования ресурсов, снижение операционных затрат, и сокращение времени вывода услуг на рынок. Решение распределённого ЦОД является эффективным решением данной задачи.

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

Логика централизации имеет два аспекта:

• централизация администрирования, диспетчеризация ресурсов и управления, техническая эксплуатация всеми дата-центрами и их ресурсами;
• менеджмент распределения ресурсов и разделения на домены с использованием платформ управления и обслуживания

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

Трансформация традиционных ЦОД становится всеобщим трендом и проходит в три ступени развития:

• Автономные ЦОДы
• Облачные ЦОДы
• Распределённые облачные ЦОДы

В настоящее время в ИТ-отрасли наблюдается переход от 2 к 3 ступени.

Одним из первых в мире проектов распределённого облачного ЦОД, реализованных на практике, был проект UNICA крупного глобального телеком-оператора Telefonica. В начале проекта оператор развернул более 85 ЦОДов в автономном режиме, в которых содержалось более 50 тыс. серверов и работало более 20 версий операционных систем. Это приводило к высоким операционным расходам, время запуска новых приложений на рынок и развертывания новых бизнесов занимало от 3 до 6 месяцев (т.е. соответствовало времени развертывания очередного ЦОДа). Энергопотребление системы было очень высоким (PUE = 2~3). Совместное использование ресурсов (sharing) было невозможным. Конфигурация ресурсов выполнялась вручную

Анализ стоимости владения ТСО проекта показал, что экономия проекта UNICA по сравнению с традиционными ЦОД за 5 лет составила 53,66% (см. рис. 2), в т.ч.:

• Инвестиции в инфраструктуру 27,71%
• Интеграция и развертывание 51,81%
• Управление 63,88%
• Обслуживание 65,07%

Рис. 2. Анализ ТСО проекта UNICA (источник: Telefonica)