Облачные вычисления: Построение архитектуры частного облака от Microsoft

  • Статья

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

Дэвид Зембики

Существует множество определений облачных вычислений, но наиболее емкое и широко признанное принаджежит Национальному институту стандартов и технологий США (National Institute of Standards and Technology, NIST). NIST определил пять основных признаков, три модели обслуживания и четыре модели развертывания. В совокупности пять признаков составляют определение, то есть только решение, обладающее следующими признаками, может называться «облаком»:

  • самообслуживание по требованию;
  • широкий сетевой канал;
  • поддержка пулов ресурсов;
  • ыстрая масштабируемость (эластичность);
  • измеримость потребления сервисов.

Также в NIST определили три модели обслуживания, или, как иногда их называют, уровни архитектуры:

  • нфраструктура как сервис (Infrastructure as a Service, IaaS);
  • ПО как сервис (Software as a Service, SaaS);
  • латформа как сервис (Platform as a Service, PaaS).

Наконец, в NIST определили четыре модели развертывания:

  • астное облако (Private Cloud);
  • общее облако (Community Cloud);
  • публичное облако (Public Cloud);
  • гибридное облако (Hybrid Cloud).

Знакомство с облаком

В команде Microsoft Services спроектировано, создано и реализовано решение Private Cloud/IaaS на базе Windows Server, Hyper-V и System Center. На протяжении всех статей этой серии мы постараемся показать, как можно интегрировать и развернуть каждый составляющий продукт в качестве решения и при этом обеспечить такие основные атрибуты облака, как эластичность, поддержка пулов ресурсов и самообслуживание.

В этой статье дано определение Private Cloud/IaaS, описаны атрибуты облака и принципы проектирования центра обработки данных (ЦОД), используемые в качестве требований при детализации базовой архитектуры, построенной для их удовлетворения. Во второй и третьей статьях будет описан подробный проект базовой архитектуры, каждый ее уровень и содержащиеся в ней продукты, а также автоматизация технологических процессов. И, наконец, в четвертой части я расскажу о процессе автоматизации развертывания с помощью Microsoft Deployment Toolkit и Hydration Framework для обеспечения последовательности и повторяемости реализации.

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

Помимо характеристик, описанных в определении NIST, мы установим несколько дополнительных требований к этому проекту:

  • приоритет устойчивости перед избыточностью;
  • однородность и стандартизация;
  • поддержка пулов ресурсов;
  • виртуализация;
  • управление структурой Fabric;
  • эластичность;
  • секционирование общих ресурсов;
  • прозрачность расчета платы за пользование облаком.

В одной из команд Microsoft собрали и определили эти принципы. Команда оценила работу организации Global Foundation Services (GFS), в чьем ведении находятся наши глобальные ЦОД, отдела MSIT, который управляет инфраструктурой и приложениями Microsoft, а также нескольких крупных клиентов, согласившимися принять участие в исследовании. Вооружившись указанными определениями и принятыми требованиями, мы перешли к этапу проектирования архитектуры. Здесь мы определили требования и создали соответствующую им модель архитектуры.

Базовая архитектура Private Cloud/IaaS

Руководствуясь описанным в одной из моих ранних статей «From Virtualization to Dynamic IT» (От виртуализации к динамической IT) в журнале The Architecture Journal за июнь 2010 года подходом к созданию архитектуры, мы решили принять за основу базовой модели взять ту, что показана на рис. 1.

Рис. 1. Основа базовой архитектуры

Уровень оборудования

Уровень оборудования включает оборудование ЦОД и механические системы, а также подсистему хранения, сеть и вычислительную инфраструктуру. Для взаимодействия с расположенными выше слоями архитектуры каждый из этих элементов должен предоставлять интерфейсы управления. В качестве примеров можно привести серверы, поддерживающие интерфейсы Web Services-Management (WS-Management) и массивы хранилищ, предоставляющие интерфейсы на основе Windows PowerShell или SMI-S (Storage Management Initiative – Specification).

В Microsoft утверждают, что программа Hyper-V Cloud FastTrack создана для объединения ПО Microsoft, единых стандартов, полученных от партнеров OEM проверенных конфигураций для вычислений, сетей и хранилищ, а также дополнительных компонентов ПО с целью создания частных облачных решений. Такие компании, как Hewlett-Packard Co., Dell Inc., IBM Corp., Fujitsu, Hitachi Ltd. и NEC Corp., являются партнерами FastTrack и предоставляют интегрированные и проверенные решения уровня оборудования.

Уровень виртуализации

Этот уровень создается на основе Windows Server 2008 R2 (теперь с Service Pack 1) и Hyper-V. Он дает возможность использовать виртуальные машины и сети, включающие виртуальные сети VLAN, предоставлять ресурсы хранения, составленные из общих дисков кластеров и виртуальных дисков. Уровень виртуализации помогает обеспечить часть обязательных признаков в соответствии с классификацией NSIT, таких как поддержка пулов ресурсов и эластичность. Виртуализация позволяет гораздо быстрее совместно использовать и подготавливать ресурсы к работе.

Уровень автоматизации

За уровнем виртуализации следует уровень автоматизации (рис. 2). Уровни автоматизации, управления и оркестрации строятся от более мелких к более крупным согласно процессу автоматизации ИТ. Самый нижний из них – уровень автоматизации – включает технологии, такие как Windows PowerShell 2.0, Windows Management Instrumentation (WMI) и WS-Management. Эти фундаментальные технологии обеспечивают интерфейс между более высокими уровнями систем управления и физическими и виртуальными ресурсами.

Рис. 2. Модель архитектуры, используемая для построения модели частного облака

Уровень управления

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

Уровень оркестрации

В явном виде этот уровень обычно в традиционных ИТ-структурах не встречается, но он чрезвычайно важен для обеспечения признаков облака. Он связывает множество продуктов, технологий и процессов, позволяющих полностью автоматизировать ИТ-процессы. System Center Configuration Manager автоматизирует развертывание исправлений, но его интеграция с системой обслуживания и управления или дополнительными сторонними продуктами и решениями требует координации (оркестрации) сквозных процессов, в которых задействовано множество продуктов.

Для реализации этого уровня используется System Center Opalis (его название вскоре заменят на System Center Orchestrator). Opalis интегрирует набор System Center и способствует интеграции с множеством сторонних и партнерских решений. Уровень оркестрации помогает создавать рабочие процессы или задания по автоматизации таких сложных задач, как развертывание кластеров, внесение исправлений на хостах и подготовка виртуальных машин к работе.

Интерфейсы самообслуживания пользователей и администратора

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

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

В нашей базовой архитектуре мы определили и интерфейс самообслуживания и централизованный интерфейс администратора ИТ. Для создания интерфейса потребителя Microsoft предлагает использовать System Center Virtual Machine Manager (VMM) Self-Service Portal 2.0, а для нестандартных сценариев и хостинга — Dynamic Datacenter Toolkit for Hosters (DDTK-H). В нашем решении используется индивидуальная версия DDTK-H ввиду необходимости особой настройки и автоматизации. Мы ожидаем, что в будущих продуктах Microsoft будет больше готовых решений.

Интерфейс администратора создан с помощью System Center Service Manager (SCSM) и интерфейсов System Center. SCSM — самый новый продукт Microsoft. Он предоставляет базу данных управления конфигурацией (CMDB), а также надежное решение управления изменениями. В нашем решении все стандартные операции формируются в виде запросов на изменения в SCSM. Они инициируют автоматизированные рабочие процессы в Opalis. Так мы обеспечиваем надлежащее управление изменениями, предоставляя развитые возможности автоматизации.

Логическая модель Private Cloud/IaaS

Одним из ключевых отличий частного облака от традиционных ЦОД и серверных инфраструктур является абстрагирование от таких физических ресурсов, как серверы, сети и дисковые ресурсы. Они объединяются на более высоком уровне в пулы ресурсов, дефектные домены, домены обновления и т. д. Эти логические объединения относятся к физической инфраструктуре и помогают принимать информированные решения по подготовке и управлению ресурсами. Для нашей базовой архитектуры мы выбрали логическую модель, опираясь на результаты работ, проведенных Microsoft Global Foundation Services, Windows Azure и MSIT (рис. 3).

Рис. 3. Логическая модель группировки Private Cloud/IaaS

Определения объектов следующие.

Структура Fabric IaaS Вся инфраструктура и системы в рамках управления базовой архитектуры. Fabric может состоять из множества сайтов и ЦОД.

ЦОД/сайт Физическое расположение или нахождение сайта одного или более пулов ресурсов.

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

Единица масштабирования Это набор, состоящий из сервера, сети и устройства хранения и развертываемый как единый модуль. Это наименьший модуль из тех, что развернуты в структуре ЦОД. В зависимости от величины потребителя это может быть четырехузловой кластер Hyper-V или полная стойка 64 блейд-серверов. Размер компонента обычно задается, исходя из усредненной квартальной потребности в новых ресурсах. Вместо того чтобы всякий раз, когда потребуются дополнительные ресурсы, развертывать отдельный сервер, можно развертывать компонент для удовлетворения потребности и сохранения возможности дальнейшего роста.

Кластер хостов Это группа, включающая от двух до шестнадцати серверов Hyper-V в отказоустойчивой кластерной конфигурации, и связанные с ними сети и хранилища.

Домен обновлений Это набор элементов инфраструктуры в пуле ресурсов, который можно поддерживать, отключать или обновлять, не вызывая при этом каких-либо простоев виртуальных машин или рабочих процессов, выполняющихся в пуле ресурсов. В этой архитектуре каждый узел в каждом из кластеров пула ресурсов образует домен обновлений. Поскольку каждый кластер имеет резервный узел (15+1), можно поддерживать по одному узлу в каждом кластере без простоев (виртуальные машины мигрируются за пределы кластера для выполнения операций обслуживания). Так все узлы в одном пуле ресурсов образуют один домен обновления, следующие узлы – во втором домене обновления и т. д. (рис. 4).

Рис. 4. Пул ресурсов с дочерними единицами масштабирования

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

Опытные пользователи System Center заметят, что описанные здесь контейнеры и определения не входят в готовый пакет System Center. Чтобы определить эти контейнеры, атрибуты и отношения, мы воспользовались расширяемостью SCSM CMDB. Эти элементы лежат в основе выходных данных автоматизации рабочих процессов Opalis. В будущем, с помощью VMM 2012 многие из этих контейнеров и отношений будут поставляться в готовом виде, только имена будут другими.

Базовая реализация Private Cloud/IaaS

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

Рис. 5. Логическая диаграмма реализации архитектуры

Автоматизированное развертывание — один из ключевых элементов базовой реализации, служащий для улучшения и ускорения развертывания и последовательности реализации. Это на самом деле так, так как Microsoft Services работает с широким диапазоном партнеров и потребителей. Для автоматизации развертывания в базовой реализации предусмотрен бесплатный набор инструментов Microsoft Deployment Toolkit (MDT) и Microsoft Services Hydration Framework. MDT расширяет возможности автоматизации развертывания.

Определение обязательных областей подробного проекта – это следующий этап процесса проектирования. Вот эти области:

  • одробный проект каждого продукта System Center;
  • подробный проект инфраструктуры размещения управления структурой Fabric;
  • инициация управления структурой Fabric;
  • проектирование единиц масштабирования;
  • подготовка единиц масштабирования;
  • проектирование рабочих процессов.

Базовая архитектура обеспечивает наличие всех признаков облака в соответствии с определением NIST и механизм для расширенной автоматизации ИТ. При выборе сценария автоматизации мы сосредоточили внимание на повышенной сложности, более высоких затратах и рисках пользовательских ошибок в сценариях. С этой целью в решении автоматизированы следующие процессы:

установка управления структурой Fabric:

  • развертывание управления фабрикой Hyper-V Host;
  • развертывание виртуализированного кластера SQL;
  • развертывание VMM;
  • развертывание SCSM;
  • развертывание System Center Operations Manager (SCOM);
  • развертывание System Center Configuration Manager (SCCM);
  • развертывание System Center Opalis ;
  • персонализация и настройка;

подготовка к работе единицы масштабирования (хост-кластера):

  • установка «чистой» ОС;
  • установка Hyper-V;
  • настройка кластера;

установка исправлений единицы масштабирования (хост-кластера):

  • оркестрация миграции виртуальных машин с хостов для установки исправлений с помощью режимов поддержки VMM и SCOM для каждого домена обновления;
  • оркестрация SCCM для установки исправлений хостов и проверка успешной установки исправлений;
  • удаление хостов из режима поддержки и переход к следующему домену обновления;

поддержка хоста:

  • оркестрация живой миграции виртуальных машин с хостов, требующих поддержки, с помощью режимов сопровождения VMM и SCOM;
  • удаление хостов из режима поддержки;

подготовка виртуальной машины:

  • обеспечение возможности инициации виртуальной машины посредством интерфейса портала;
  • Opalis принимает запросы на подготовку к работе и выполняет оркестрацию подготовки виртуальных машин по заранее настроенным шаблонам;
  • Opalis проверяет, была ли создана виртуальная машина и обеспечена ее видимость во всех продуктах System Center;
  • Opalis выполняет установку агента SCOM на требуемых виртуальных машинах;
  • виртуальные машины становятся доступны и готовы к управлению посредством интерфейса портала;

отмена инициации виртуальной машины:

  • создание запроса на отмену инициации виртуальной машины посредством интерфейса портала;
  • Opalis принимает запросы на отмену инициации, удаляет виртуальную машину из всех продуктов System Center, после чего удаляет саму виртуальную машину;
  • Opalis удаляет учетную запись Active Directory  виртуальной машины и запись А в DNS.

В следующей статье этой серии мы изучим подробный проект архитектуры управления структурой Fabric, включая проект управления структурой Fabric кластера Hyper-V, проект виртуализированного кластера SQL и проект каждого из продуктов System Center. Кроме того, мы расскажем о проекте единицы масштабирования, содержащей кластеры Hyper-V из 16 узлов.

Дэвид Зембики (David Ziembicki) Дэвид Зембики (David Ziembicki) носит звание Microsoft Certified Architect и работает архитектором решений в организации Microsoft Public Sector Services CTO, специализируясь на виртуализации и частных облачных вычислениях. За пять лет работы в Microsoft Дэвид руководил проектами инфраструктуры во многих государственных учреждениях. Он является ведущим архитектором в области создания решений частных облаков Microsoft и виртуализации. Выступал на многих семинарах Microsoft и прочитал много лекций на курсах по виртуализации. С Дэвидом можно связаться через его блог https://blogs.technet.com/davidzi.