Всем пламенный привет и пожелания бодрого начала очередной рабочей недели!
В этот замечательный день мне хочется рассказать вам про то, как создается облако с помощью нашего замечательного инструмента — Virtual Machine Manager 2012 R2. Я уверен что подход использования облака как модели для предоставления ИТ-сервисов и ресурсов набирает обороты и многие администраторы, да и компании в целом, уже хорошо знакомы с виртуализацией — и постепенно начинают переходить на следующий уровень — создание частного облака. Ну что же — давайте более детально рассмотрим этот интересный процесс в действии!
Что такое облако?
Прежде чем мы перейдем непосредственно к рассмотрения процесса создания облака в VMM, не лишним будет еще раз вспомнить зачем мы это делаем и в чем будет польза.
Поскольку основой любого современного облака является технология виртуализации, то первая ассоциация которая должна возникнуть в пытливом разуме — это вычислительные ресурсы. В связи с распространением виртуализации, облако как следующий уровень ИТ-модели, использующий для своих задач виртуализацию, говорит нам о том, что теперь мы уже учитываем не сервера при учете мощностей и развертывания сервисов и приложений, а непосредственно вычислительные ресурсы. Основными ресурсами, которые нам необходимы и которые мы виртуализуем, это ресурсы ЦП, ресурсы оперативной памяти (ОЗУ), ресурсы хранилища для размещения данных (пресловутый сторадж) и коммуникационные ресурсы (или просто сети). Конечно, мы никуда не денемся от того, что ВМ и состоящие из них сервисы нужно где-то размещать, и вопрос размещения будет обращен непосредственно к объекту компьютера, хоста виртуализации, но с точки зрения облачного подхода нам больше интересен объем ресурсов — ведь такие технологии как Dynamic Memory не позволяют уже в стандартном режиме «по-привычке» воспринимать ресурсы негибкими блоками, коими хосты и являются, по сути…
И тот факт, что ОЗУ распределяется динамически, и если мы говорим про предоставление пространства хранилищ под ВМ и сервисы — то наверняка наткнемся на методы Thin Provisioning и механизмы дедупликации данных, — это лишь немногие, но самые явные примеры того, что подход к потреблению (а значит и выделению) ресурсов в традиционным стиле не позволяет точно и адекватно дать оценку ресурсам и правильно их выделить под сервисы… Теперь мы смотрим на количество необходимых нам именно вычислительных и инфраструктурных ресурсов, когда хотим создать новую ВМ или сервис на базе ВМ.
Не будем сильно зацикливаться на деталях облака, основной момент заключается именно в том, что, во-первых, мы относимся к ресурсам как к пулам, наборам, а во-вторых — это уровень абстракции, ведь виртуализация абстрагирует нас от физического уровня на логический (тут все просто — ведь ВМ представляет собой ничто иное, как набор файлов — а это логический уровень уже), т.е. мы оперируем с виртуальными машинами как с файлами… Для тех кто хочет более детально разобраться в особенности облака предлагаю копать здесь. Ну и картинка для пущей ясности.
Отличительные особенности облака как модели.
Lego перед облаком
Итак, давайте преступим к нашему процессу создания облака.
Именно таким образом, как на картинке ниже (Рисунок 1) выглядит консоль управления VMM, — и с первого взгляда не очень понятно, что нужно делать дальше, но давайте вместе с этим разберемся.
Рисунок 1. Интерфейс VMM.
Машинально так и хочется залезть во вкладку Clouds и начать ваять-создавать, но не будем спешить. В контексте VMM объект облака (cloud) является логическим периметром-ограничителем, который накладывается поверх физических ресурсов. А раз речь зашла про физические ресурсы, то в первую очередь нам нужно их добавить, т.е. сейчас мы добавим хосты виртуализации в VMM — для этого зайдем в раздел Fabric, далее — как на рисунке.
Как видно из следующего скрина, в качестве хостов виртуализации мы можем добавить множество различных платформ, не только Hyper-V — но и VMware ESXi/vSphere и Citrix XenServer тажке поддерживаются в качестве платформ виртуализации.
Рисунок 2. Добавление ресурсов хостов виртуализации в VMM.
В нашем случае мы остановимся на платформе Hyper-V и будем искать хосты именно с этой технологией. Далее по ходу движения по мастеру добавления ресурсов нам нужно указать имена целевых хостов — это могут быть NetBIOS- и FQDN-имена, а также просто IP адрес. Однако, стоит отметить что учетная запись, под которой вы производите поиск хостов должна обладать правами локального администратора на целевом хосте виртуализации — иначе ничего интересного у нас с вами не выйдет. После того, как мастер найдет нужные хосты — остается поставить галочки напротив интересующих нас объектов и завершить процесс.
Рисунок 3. Обнаружение хостов в службе каталогов Active Directory и их добавление в VMM.
Отлично, мы с вами добавили хосты виртуализации и теперь бежим уже создавать облако, но… Давайте не будем спешить и разберемся, что делать дальше. Если на минутку остановиться и задуматься, то в результате наших действий мы добавили 2 хоста (в данном случае), у которого есть ресурсы ЦП, ОЗУ (с этим все ровно), но вот дальше есть еще 2 очень важных элемента — это хранилища, сторадж и сети передачи данных. Со стораджем все примерно понятно: в самом простом случае для размещения ВМ мы можем использовать локальные диски нашего сервера, если таковые имеются (и в данном примере именно такая конфигурация и рассматривается), но все же — в реальной жизни мы скорее будем работать с промышленной СХД (которая может подключаться по iSCSI или Fibre Channel, а еще СХД может быть целый зоопарк разных — благо у нас SMI-S есть на этот случай. SMI-S — это вендор-нейтральнй протокол управления системами хранения данных, что позволяет выделять и управлять хранилищами под ВМ и сервисы напрямую в VMM), или как альтернативный вариант, мы можем использовать файл-сервера и SMB 3.0-шары для размещения ВМ, VMM с этим справится без проблем.
Рисунок 4. Добавление ресурсов хранилища для размещения ВМ и сервисов в VMM.
Если с размещением нагрузок мы в нашем частном случае проблему решили благодаря локальным дисковым ресурсам наших хостов, то теперь нам следует заняться последним инфраструктурным составляющим нашего облако — сетями. Тема создания и управления виртуальными сетями в VMM требует отдельного ряда статей, причем подробных — поэтому в рамках данной статьи я вкратце расскажу про те компоненты, которые нам понадобятся.
Сперва было бы очень неплохо создать единый виртуальный коммутатор для управления сетью вдоль всех наших хостов. В контексте VMM такой объект носит имя логического коммутатора (logical switch), однако помимо создания единого коммутатора, нам также потребуется механизм автоматического назначения сетевого адаптера хоста на связь с этим коммутатором — а вот для этой цели нам потребуется создать профиль uplink-порта. С точки зрения VMM сначала необходимо создать профиль порта (Для этого заходим в Fabric->Networking->Port Profiles и по последнему кликаем правой кнопкой мыши — далее без вариантов создаем профиль).
Рисунок 5. Создание профиля порта в VMM.
Обращу ваше внимание на то, что профиль порта может быть создан с учетом возможности тиминга (или агрегации интерфейсов), встроенного в Windows Server 2012/2012 R2. Если вы создаете профиль аплинка на обычном интерфейсе, то параметры тиминга никак не повлияют на свойства интерфейса. Если вы внимательны, то вы обратили внимание на то, что есть вариант создать не uplink-профиль, а профиль виртуального порта. Профиль виртуального порта, в свою очередь, назначается на виртуальный адаптер ВМ, чтобы мапиться на правильный физический адаптер — но об этом не сегодня, просто для полноты картины завершаю рассказ про эту тему.
Теперь давайте перейдем к созданию логического коммутатора (Logical Switch), создается он все там же, во вкладке Networking.
После запуска мастера мы зададим имя виртуального свитча-коммутатора, мы можем выбрать расширения коммутатора, если таковые у нас установлены (например, Cisco 1000 Nexus V). Самое же интересующие нас вещи находятся немного дальше, на вкладке Uplink — здесь мы как раз указываем созданный ранее профиль аплинка.
Рисунок 6. Создание виртуального коммутатора и настрйка связи с профилем аплинка.
Профиль виртуального порта нам сейчас неинтересен, поэтому смело завершаем настройку виртуального коммутатора на последнем экране мастера. После того как мы создали наш виртуальный коммутатор с и настроили профили, теперь было бы неплохо применить наш коммутатор на наши хосты Hyper-V. Для этого заходим в раздел Fabric->Servers->All Hosts, выбираем нужный нам хост и щелкаем по нему правой кнопкой мыши — далее нас интересует раздел Virtual Switches (виртуальные коммутаторы). Далее мы выбираем New Virtual Switch -> New Logical Switch. Выберите нужный сетевой адаптер и профиль аплинка. Повторите данную операцию на всех необходимых хостах (или свистните PowerShell скрипт и вставьте туда все имена))).
Рисунок 7. Создание и привязка логического коммутатора на хост.
Теперь дело осталось за малым. Хосты мы связали воедино, теперь нам нужно сделать сеть доступной для самого облака. Теперь нам нужно создать логическую сеть (Logical Network) — единое непрерывное пространство вдоль множества хостов, на котором будут располагаться сети виртуальных машин (VM Networks).
Здесь возникает вопрос: «А в чем разница между логической сетью и сетью ВМ?»
Ответ достаточно прост: сети ВМ размещаются поверх логических сетей. Здесь смысл заключается в том, что логическая сеть — это непрерывное пространство сети вдоль множества хостов. Сети ВМ строятся поверх логических сетей использую сетевую виртуализацию, т.е. создание изолированных сетей, которые ведут себя словно это разные физические сети, т.е. они не знают о существовании друг друга. Таким образом сочетание этих механизмов позволяет выстраивать огромное множество изолированных виртуальных сетей вдоль хостов, и естественно, если сети не знают о существовании друг друга — то и IP-адреса в них могут использоваться повторяющиеся. Именно так и мы поступим при создании нашей сети. Еще одним важным моментом является тот факт, что облако как элемент VMM работает с компонентом сети на уровне логической сети, т.е. создание логической сети является необходимым условием для создания облака.
Рисунок 8. Создание логической сети в VMM.
Для включения сетевой виртуализации мы активируем первую галочку, как на рисунке. Вторая же галочка нам необходима если мы хотим поставить знак равенства между логической сетью и сетью ВМ — т.е. при этом действии будет создана сеть ВМ с таким же именем и областью действия как и логическая сеть. Это нужно больше для сетей управления инфраструктурой, пользовательские нагрузки не рекомендуется размещать таким образом, т.к. возникает риск доступа к инфраструктуре со стороны неавторизованных пользователей.
Пора в облака
После того, как мы подготовили нашу инфраструктуру, настало самое время для того чтобы собрать все компоненты вместе и связать их логической ипостасью объекта облако (cloud) в VMM. для этого зайдем в VMs and Services->Clouds->щелчок правой кнопки мыши и create. Далее появится мастер создания облака, который попросит нас задать имя облака, потом попросит выбрать периметр ресурсов (хостов виртуализации) поверх которых будет натянуто облако (я выбрал All Hosts), выбираем нужную нам логическую сеть, назначаем хранилище под ВМ. Интересным моментом в создании облака является возможность ограничить потребление ресурсов, как в относительном, так и в количественном выражении.
Это необходимо для того, чтобы пользователи облака не сожрали все ресурсы, тем самым предотвратить недостаток ресурсов для других пользователей.
Рисунок 9. Ограничение потребления ресурсов в облаке в VMM.
После того, как мы создали облако остается назначить этому облаку его пользователей, которые буду как потреблять его ресурсы (с одной стороны), так и управлять непосредственно им (с другой стороны). Для этого все в том же разделе VMs and Services выберем свежесозданное облако и нажмем на клавишу Assign Cloud. Если у нас есть созданная ранее роль, то мы можем назначить ее на облако, но в нашем случае роль мы еще не создавали — поэтому давайте рассмотрим какие варианты ролей нам доступны и в чем их смысл.
И так — на выбор 4 роли: Fabric Administrator (он же Delegated Administrator, Read-Only Administrator, Tenant Administrator и Application Administrator (a.k.a. Self-Service User). Первая роль — это полноценный, все(почти)могущий админ, но в пределах границ облака, на которое его назначают. Read-Only Administrator — это явно роль пресловутого хелпдеск-траблшутера — так как никаких действий кроме как простой мониторинг ситуации, эта роль под собой не подразумевает… Tenant Administrator это роль для управления подписками Windows Azure и нужна для гибридных моделей облаков. Application Administrator — это собственно конечный пользователь сервиса и потребитель ресурсов.
Рисунок 10. Роли пользователей в облаке VMM.
После того, как вы создали облако и назначили пользователей, вы можете получить доступ к облаку со стороны пользователя и администратора на уровне веб-интерфейса, для этого необходимо развернуть App Controller и привязать экземпляр сервера VMM — облака из него автоматически подтянутся.
Рисунок 11. Доступ к облаку через портал App Controller.
Ну что же, уважаемы коллеги! Вот мы с вами и создали облако, теперь вы можете заняться вопросами создания ВМ и сервисов в вашем облаке.
Процесс этот крайне увлекательный и нетривиальный — поговорим о нем как-нибудь в другой раз в одной из очередных статей про облако и System Center 2012 R2.
Остаётся добавить ссылки на скачивание продуктов:
Windows Server 2012 R2 Preview — technet.microsoft.com/ru-ru/evalcenter/dn205286
System Center 2012 R2 Preview — technet.microsoft.com/ru-ru/evalcenter/dn205295
До новых встреч и безоблачной (хе-хе) вам недели!
С уважением,
Человек-огонь,
он же Лорд Пламень,
Георгий А. Гаджиев.
Автор: GeorgyGadzhiev
