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

Из чего состоит частное облако

Частное облако – это не «купили блейды и поставили гипервизор». Это четыре связанных уровня.

Аппаратный уровень. Серверы, СХД и сеть, объединённые в пулы ресурсов. Здесь важна однородность: разнокалиберное железо превращает балансировку нагрузки в ручной труд. Закладывайте резерв 20–30% мощности под пиковые сценарии и отказ узлов.

Уровень виртуализации. VMware vSphere, Hyper-V или Xen абстрагируют железо от приложений. Виртуальная машина переезжает между узлами без остановки сервиса, а пул ресурсов нарезается под нужды подразделений. Без этого уровня «облака» нет – есть просто серверная.

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

Уровень приложений. Корпоративные системы, базы данных, среды разработки и тестирования. Сюда же ложатся ресурсоёмкие задачи – например, аналитика на больших объёмах, где уместен подход MapReduce на практике: кластер поднимается под расчёт и гасится после него.

Разграничение зон ответственности

Технология – половина дела. Вторая половина – договорённость о том, кто за что отвечает. Мы фиксируем это в матрице ответственности ещё на этапе проектирования.

  • Служба эксплуатации держит аппаратный уровень и виртуализацию: доступность пулов, резервное копирование, мониторинг, замена вышедшего из строя железа.
  • Команда облачной платформы отвечает за оркестрацию, каталог сервисов и соблюдение квот. Она же ведёт учёт потребления – без прозрачного биллинга бизнес не видит реальной стоимости своих систем.
  • Владельцы приложений отвечают за то, что крутится внутри виртуальных машин: настройку ПО, обновления, прикладную безопасность.
  • Информационная безопасность задаёт правила для всех уровней: сегментацию сети, аттестацию по требованиям ФСТЭК для систем с персональными данными, разграничение доступа к порталу.

Когда границы размыты, инцидент превращается в перекладывание ответственности между службами. Чёткая матрица снимает этот спор заранее.

С чего начать внедрение

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

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

Вывод

Частное облако – это инфраструктура плюс дисциплина. Архитектура из четырёх уровней даёт эластичность, а матрица ответственности удерживает её под контролем. Начните с малого домена, зафиксируйте, кто за что отвечает, и масштабируйте по результату – тогда облако станет рабочим инструментом, а не дорогим экспериментом.