Что вам не расскажет провайдер о приватном облаке

Приватное облако представляет собой набор компромиссов между изоляцией, контролем, ценой и ответственностью. При этом под одним термином на рынке могут предлагаться принципиально разные архитектурные решения. На конференции «Код ИБ» в Ташкенте Артем Гринберг, Head of Cloud Products UzCloud, рассказал, что на самом деле стоит за приватным облаком, где проходит ответственность провайдера и клиента и на что обратить внимание при выборе сервиса. 

Что такое приватное облако

Выделенные ресурсы сами по себе еще не делают сервис приватным облаком. Нужна именно облачная модель потребления и эксплуатации, три составляющих одновременно:

— Исключительное использование (exclusive use).Ресурсы предназначены для одной организации. Не обязательно всё физически отдельное, но модель должна быть рассчитана на исключительное использование клиентом, без конкурирующих нагрузок от других арендаторов.

— Облачная модель потребления.Самообслуживание, API, эластичность, оплата по факту использования. Если ресурсы выдаются только через заявку, а масштабирование занимает дни, это уже не полноценное облако, а управляемая виртуализация.

— Эксплуатационная модель.Провайдер управляет платформой, клиент своими сервисами, данными и доступами. Приватное облако это не только изоляция, но и понятное разделение ответственности между сторонами. 

Что продают под видом приватного облака

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

Настоящие модели приватного облака. Во всех трёх случаях инфраструктура находится в исключительном пользовании одной организации:

— Приватное облако на собственной площадке (on-premises).Облачная платформа на вашем оборудовании и в вашем помещении. Максимальный контроль и максимальная ответственность.

— Размещенное приватное облако (hosted private cloud).Выделенная инфраструктура на площадке провайдера. Однопользовательская модель: серверы, а часто и сеть с хранилищем, принадлежат только вам.

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

Что продают как приватное облако, хотя строго им не является

— Виртуальная частная сеть в публичном облаке (VPC).Логически изолированная сеть внутри общего облака. Изоляция только на сетевом уровне: физические серверы, гипервизор и хранилище общие с другими арендаторами. Крупные облачные провайдеры сами называют это «приватным облаком», однако критерий исключительного использования здесь не выполняется.

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

Отдельно стоит гибридное облако. По стандарту NIST SP 800-145 (базовое определение облачных вычислений) это самостоятельная модель развертывания, связка приватного и публичного, а не разновидность приватного. Но в коммерческих предложениях его часто упаковывают вместе с «приватностью», поэтому уточняйте, какая именно часть договора приватна.

Спросите провайдера: к какой модели относится ваш договор и на каком уровне обеспечивается изоляция — сеть, сервер, хранилище или вся платформа? Реальный уровень изоляции определяет ответ на этот вопрос, а не название тарифа.

Если нет самообслуживания и эластичности, это не совсем облако

Если масштабирование делается по заявке, ресурсы фиксированы, а учета нет, это чаще управляемая виртуализация (managed virtualization), а не полноценное облако.

Полноценное облако:

— Самообслуживание по требованию: ресурс создается через портал или API без заявок.

— Быстрая эластичность: масштабирование занимает минуты, а не дни согласования.

— Измеряемое потребление: прозрачная тарификация по факту потребления и/или за выделенный пул.

Управляемая виртуализация:

— ресурсы по заявке, изменение конфигурации требует обращения и ожидания;

— фиксированные квоты, нет динамического пула, всё заранее выделено и зафиксировано;

— непрозрачная тарификация, оплата за емкость без фактически выделенного пула.

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

Как выглядит реальная топология размещенного приватного облака

В инфраструктуре могут быть как общие, так и выделенные компоненты.

Могут быть общими: управляющий слой (control plane), тарификация, мониторинг, контур резервного копирования, фабрика хранения.

Могут быть выделенными: физические серверы, сетевые устройства, узлы хранения.

Отдельно стоит уточнять уровень гипервизора, планировщик и узлы Kubernetes. 

Производительность: vCPU и RAM только верхушка

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

— CPU.Важно не количество vCPU, а политика выделения: коэффициент переподписки (overcommit), закрепление ядер (CPU pinning), NUMA-топология и соседние нагрузки на том же физическом сервере.

— RAM.Важно не только сколько памяти, но и как она резервируется: гарантия выделения, переподписка, динамическое изъятие памяти (ballooning), возврат ресурсов платформой под нагрузкой.

— Диски и хранилище.Часто узкое место именно здесь: лимиты IOPS, задержки, политика пиковой производительности (burst), классы хранения, ограничения на виртуальную машину и диск.

— Сеть и пропускная способность.Сеть это не только «до 10 Гбит/с»: ограничения полосы, лимиты по пакетам в секунду, внутренний и внешний трафик, переподписка на уровне сетевой фабрики.

Отказоустойчивость: зона ≠ регион, SLA ≠ непрерывность

SLA на доступность платформы не равен непрерывности вашего приложения. За разрыв между этими понятиями отвечаете вы.

— Зона отказа.Зона, площадка и регион — это разные домены отказа с разным радиусом поражения. Разнесение по зонам уменьшает один тип риска, но не закрывает все сценарии: отказ платформы, хранилища или управляющего слоя может затрагивать несколько зон.

— Плановые работы.Плановые работы всё равно будут.
Нужно понимать: возможны живая миграция, перезагрузка, повторное развертывание. Важны окна обслуживания, сроки уведомления, гарантии по доступности во время работ и ограничения по вашей нагрузке.

— Аварийное восстановление (DR). Его всегда нужно проектировать отдельно. Это не опция платформы, а архитектурное решение. Репликация, регламент действий, порядок переключения, регулярные тесты восстановления, зафиксированные RPO и RTO.

SLA провайдера покрывает доступность платформы, а не вашего приложения. RPO и RTO ваша ответственность, если иное явно не прописано в договоре. 

Безопасность и резервное копирование: ответственность не исчезает

Провайдер отвечает за:

— физическую безопасность дата-центра;

— сетевую инфраструктуру и гипервизор;

— базовую доступность платформы и управляемых сервисов;

— патчинг гипервизора и физических хостов.

Клиент отвечает за:

— гостевую OS: установку, обновления, усиление защиты (hardening);

— прикладное ПО и его конфигурацию;

— правила межсетевого экрана, группы безопасности, политики управления доступом (IAM);

— шифрование данных при хранении и при передаче;

— резервное копирование, тестирование восстановления;

— политики доступа и управление ключами.

Разделяемая ответственность (shared responsibility) не означает ответственность поровну. В модели IaaS большая часть операционной ответственности остается на стороне клиента.

Экономика: скрытые счета приходят за трафик и архитектуру

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

— Сеть:исходящий интернет-трафик, межзонный и межплощадочный трафик, публичные IP-адреса, балансировщики нагрузки. Всё это тарифицируется отдельно.

— Надежность:вторая площадка, репликация данных, резервная емкость, снимки состояния, полноценный контур аварийного восстановления. Резервирование стоит денег.

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

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

Сравнивать нужно не цену виртуальной машины, а полную стоимость сервиса: вычисления + хранение + сеть + отказоустойчивость + эксплуатация.

10 вопросов, которые надо задать провайдеру

1. Что именно приватно?Сеть, кластер, серверы, хранилище или вся платформа?
2. Логика или физика?Логическая изоляция или выделенные физические серверы?
3. Виртуализация или bare metal?Что лежит под вашими виртуальными машинами: гипервизор или просто оборудование?
4. Какие слои общие?Управляющий слой, контур резервного копирования, мониторинг, фабрика хранения?
5. Гарантии производительности?Что гарантировано, а что предоставляется без гарантий?
6. Что происходит при плановых работах? Живая миграция, перезагрузка или повторное развертывание? За сколько уведомляют?
7. Что реально в SLA?Платформа, виртуальные машины, гостевая ОС или только управляющий слой?
8. Кто отвечает за резервное копирование? Тестирование восстановления, RPO и RTO — ваши или провайдера?
9. Как считается трафик?Межзонный, межрегиональный и исходящий интернет-трафик: тарифы и лимиты?
10. Как выглядит выход?Миграция образов, данных и т.п.: формат, стоимость, сроки?

Провайдер, который отвечает на все 10 вопросов четко, партнер. Тот, кто уходит от ответов, риск. 

Об авторе: Артем Гринберг, Head of Cloud Products в UzCloud. Более 12 лет в ИТ. Последние пять лет строил и развивал облачные сервисы. Сейчас в UzCloud отвечает за развитие облачной инфраструктуры, IaaS- и PaaS-сервисов, а также managed-решений.