Облачные технологии как рынок, как тенденция или феномен нам всем уже более или менее понятны: всё-таки первая составляющая рубрики «Облака и ЦОД» освещается здесь во всевозможных аспектах. Однако архитектурные вопросы мы поднимаем не столь часто, как могли бы, ведь большинство наших читателей занимается скорее управленческой составляющей процесса внедрения облачных решений. Но понимание проектирования или развёртывания облачной инфраструктуры на уровне архитектуры все же необходимо составить. Поэтому, с вашего позволения, сегодняшняя колонка будет посвящена именно этому вопросу.
Любая архитектура, бесспорно, начинается со стандартов. Пожалуй, самый ёмкий и адекватный стандарт, а также целый комплекс всевозможных описаний и определений задал «Национальный институт стандартов и технологий США» (National Institute of Standards and Technology) — NIST. Согласно стандартам NIST, облачным может называться только решение, обладающее следующим набором характеристик: самообслуживание по требованию, широкий сетевой канал, поддержка пулов ресурсов, быстрая масштабируемость и эластичность, возможность измерения потребления сервисов. NIST определяет также три уровня архитектуры — IaaS (инфраструктура как сервис), SaaS (программное обеспечение как сервис) и PaaS (платформа как сервис). С точки зрения моделей развёртывания Институт также не предлагает ничего нового, разделяя облака на частное, общее, публичное и гибридное.
Как я говорил в начале текста, сегодняшняя задача состоит в том, чтобы определить и понять архитектуру облачных решений и принципы их проектирования. Поэтому курс взят на довольно простую и прозрачную модель, данную специалистом Microsoft Дэвидом Зембицки (David Ziembicki). Собственно говоря, эта архитектура не является его личным изобретением, но он весьма подробно и, главное, без лишних сложностей описал её в материале «From Virtualization to Dynamic IT», опубликованном ещё в 2010 году в The Architecture Journal. Пожалуй, текст господина Зембицки можно сжать до следующей иллюстрации-схемы, заботливо переведённой на русский язык.
Это, однако, не более чем основа базовой архитектуры, которая нуждается в пояснении.
Начнём с уровня оборудования. В архитектуре облачного решения уровень оборудования — наиболее важный и базовый уровень. В него входит всё оборудование дата-центра, включая механические системы, а не только интеллектуальные. Здесь же находятся подсистема хранения, сеть и вычислительная инфраструктура. Для связи со следующим уровнем — уровнем виртуализации — в рамках каждой подсистемы предусмотрены интерфейсы управления. Это могут быть серверы, поддерживающие интерфейсы, СХД и так далее.
Виртуализация является одним из ключевых уровней архитектуры облачного решения. Как пишет Дэвид Зембицки, виртуализация — это критически важный уровень архитектуры, который необходим для того, чтобы достигнуть высокого уровня зрелости ИТ-инфраструктуры, однако остальные уровни, такие как автоматизация и оркестрация, не менее важны. Виртуализация позволяет использовать виртуальные машины и сети (включая сети типа VLAN), даёт возможность предоставлять ресурсы хранения, составленные из общих дисков кластеров и виртуальных дисков. Виртуализация помогает обеспечить значительную часть обязательных признаков облачного решения по классификации NIST. Это, как вы уже поняли, поддержка пулов ресурсов и гибкость. Кроме того, эта технология ускоряет совместное использование и подготовку ресурсов к работе.
Экспертное мнение
Эдуард Бавижев, руководитель группы виртуализации DataLine
Проектирование «облака» состоит из следующих этапов.
— Написание/получение технического задания (ТЗ): на этом этапе происходит постановка и уточнение задачи, формулируются требования к облаку и устанавливаются сроки внедрения. Здесь важно тщательно фиксировать все требования заказчика и возможности их реализации провайдером, чтобы в будущем не возникло спорных ситуаций.
— Составление плана внедрения облака. Здесь хочется отдельно отметить необходимость правильно рассчитать потребность в человеческих ресурсах для реализации проекта. Отсутствие должного внимания к этому вопросу может остро проявиться в проектах со сжатыми сроками.
— Дизайн системного ландшафта облака. Если на предыдущих этапах, например, связанных с формированием ТЗ, не возникло трудностей, то эта стадия должна пройти без каких-либо ощутимых проблем.
— Написание проектной документации, включающей в себя подробное описание системно-функциональной архитектуры и программно-технической реализации проекта.
— Закупка оборудования и необходимого программного обеспечения. При составлении плана внедрения облака также необходимо учесть сроки и условия поставки оборудования и ПО, выбранного для проекта.
— Составление процедуры и методики тестирования облачного пула и непосредственно тестирование основных показателей (функциональность, отказоустойчивость, производительность и соответствие требованиям ИБ).
— Включение нужных показателей в SLA. По результатам тестирования, когда необходимые параметры производительности, отказоустойчивости и пр. достигнуты, необходимо включить эти показатели в соглашение.
— Передача в эксплуатацию. Если на ранних этапах были соблюдены все процедуры и рекомендации, то в процессе передачи системы в эксплуатацию не должно возникнуть каких-либо проблем.
Следующая ступенька в архитектуре облачного решения — это уровень автоматизации. Это своеобразная база, необходимая для построения уровня управления, о котором мы поговорим чуть ниже. На этом этапе задействуются технологии, призванные обеспечить интерфейс между высокими уровнями систем управления и ресурсами — как физическими, так и виртуальными.
Далее следует уровень управления, активно использующий технологии уровня автоматизации. Он предусмотрен для выполнения таких задач, как определение совместимости исправлений, установка и проверка результатов установки. Как правило, уровень управления подразумевает некоторую автоматизацию процессов в силу использования технологий предыдущего уровня. Однако обычно он ограничен только одним из аспектов жизненного цикла управления сервером (например, резервное копирование или развёртывание).
Ещё одна составляющая архитектуры облаков — это уровень оркестрации. В чистом виде он практически не встречается, однако невозможно переоценить его важность для обеспечения соответствия принципам облачных технологий NIST. Это связующее звено между большим количеством технологий и процессов, помогающих автоматизировать ИТ-инфраструктуру. По сути, этот уровень необходим для того, чтобы координировать сквозные процессы, в которых участвует множество ИТ-продуктов. Уровень оркестрации создаёт рабочие процессы и задания по автоматизации таких непростых задач, как развёртывание кластеров, внесение исправлений на хостах и подготовка виртуальных машин к работе.
На практике проектирование начинается с ответов на ряд вопросов и решения множества задач, ключевой из которых является выбор облачного провайдера или компании, которая создаст для вас частное облако. От используемой платформы зависит надёжность, доступность и безопасность вашего облачного решения. Как правило, провайдер проводит аудит и выявляет предварительные запросы клиента, исходя из следующих положений: информационные системы и ресурсы, переносимые в облако, тип облака (публичное, гибридное, частное), роли пользователей, типы и варианты доступа, требования к вычислительным мощностям будущего облака, требования к надёжности и безопасности, выявление зон ответственности и способов администрирования, уровень поддержки на этапе, когда решение уже внедрено и запущено.
Подобный чисто инструментальный подход к описанию архитектуры облачного решения, вероятно, собьёт с толку часть читателей. Однако лишь понимание архитектуры не только в контексте, но и в деталях позволяет ИТ-специалисту заявить, что он разбирается в облачных технологиях.