пятница, 8 декабря 2017 г.

Как работает облако на базе Windows Azure Pack

Продукт Windows Azure Pack, который Microsoft довольно активно (можно даже сказать, агрессивно) продвигала, уже уходит в прошлое. На него давно не выходят обновления, хотя и заявлена поддержка до 2027 года. Ему на замену пришел Microsoft Azure Stack, который работает в составе программно-аппаратного комплекса. Поэтому для тех, у кого уже есть свое облако Hyper-V под управлением System Center, WAP часто является едва ли не единственным бесплатным решением для организации портала самообслуживания для внутренних или внешних клиентов. Я до сих пор сталкиваюсь с тем, что его внедряют у себя различные организации.



В данной статье будет предельно просто (схематично) описана работа инфраструктуры Windows Azure Pack. Нужна она тем, кто решил его внедрить у себя, но пока не имеет опыта работы с ним. Или же тем, кому WAP достался в наследство и теперь надо научиться его готовить. Более подробную информацию можно запросто найти в многочисленных блогах и на Microsoft Technet.

Для начала посмотрим общую схему работы облака Windows Azure Pack:

В самом верхнем ряду находятся сервисы, которые видит клиент, и с которыми он может взаимодействовать. 

WAP Tenant - публичный портал (сайт IIS) Windows Azure Pack. Так же в его состав входит сервис API,  с помощью которого они получают возможность управлять подпиской с помощью PowerShell

RDS - Remote Desktop Services. Используется неявно и только в том случае, если клиент пытается подключиться к консоли виртуальной машины. Не работает с "Shielded VM", так же может отсутствовать вообще, так как не является обязательным компонентом облака.

Далее следуют сервисы оркестрации:

WAP Admin - портал администратора WAP. Именно здесь производится настройка услуг, с которыми будут работать клиенты. Так же на нем работает API, с которым взаимодействует портал WAP Tenant. Взаимодействует он с сервисами SPF и SMA. Так же может работать с некоторыми дополнительными услугами, например "5nine Cloud Security", без посредников.

SPFSystem Center Service Providers Foundation. Это конмонент System Center Orchestrator. Через него портал WAP Admin общается с SCVMM и SCOM. По-сути, представляет собой набор скриптов  PowerShell, которые находятся в каталоге IIS. При необходимости их можно править под свои задачи, меняя поведение тех или иных функций или добавляя новые. Так же SPF хранит в базе данных информацию о тенантах и использовании ресурсов.

SMA - System Center Service Management Automation. Это конмонент System Center Orchestrator, который отвечает за выполнение RunBooks, которые мы можем добавлять на портале WAP Admin. Грубо говоря, основной его компонент это база данных MSSQL, в которой хранятся Workflow. SMA является необязательным компонентом облака WAP

Ниже идет самое сердце облака - System Center Virtual Machine Manager и хосты Hyper-V, которыми он управляет (вероятно это будет кластер).

Тут следует отметить только то, что WAP работает с объектом Cloud, который создается в SCVMM, включает в себя набор хостов Hyper-V и описывает некоторые их параметры. Если используется виртуализация сети (NetworkServices), то тоже все управление идет через него. 

Учет потребления ресурсов:

System Center Operations Manager. Все его знают, как мониторинг. Но он так же "из коробки" может интегрироваться с SCVMM и вести учет используемых ресурсов для виртуальных машин. Вся эта информация хранится в базе данных DataWarehouse. Далее ее забирает SPF и передает на портал WAP Admin

Организация работы сетей


Есть три основных варианта:



1. Можно использовать VLAN. Требуют настройки оборудования и создания сетей для подписок вручную как на стороне WAP, так и в SCVMM. Не увеличивают стоимость текущего решения, можно использовать всегда. Так же не требуют дополнительных виртуальных машин. Являются самым универсальным вариантом. 

2. NVGRE. Одна из умирающих технологий виртуализации сети, поддержка которой все же осталась в Windows Server 2016, но только для совместимости. Имеет множество ограничений и сложная для обслуживания и траблшутинга. Требует виртуальные машины Windows Server 2012R2 Standard для добавления их как NetworkService в SCVMM. Если не уверены, что вам нужен NVGRE, лучше его не использовать. Есть риск, что в следующей версии Windows Server технология не будет поддерживаться вообще.

3. Network Controller. Виртуализация сети на основе VXLAN, в Windows Server 2016 пришла на смену NVGRE. Требует как минимум одну виртуальную машину Windows Server 2016 Datacenter. Если нужна виртуализация сети, то этот вариант является предпочтительным. 

На этом все. Если появились вопросы, уточнения или вы нашли ошибки - пишите в комментарии или на почту. 

Комментариев нет:

Отправить комментарий