jabuin

about.

1. Введение

Microsoft давно пытается завоевать рынок виртуализации как десктопной, так и серверной. Не так давно вышла ОС Windows Server 2012 с новым гипервизором Hyper-V 3.0, который теоретически догнал гипервизор от вендора №1 виртуализации – VMware. Но речь пойдет не о серверной виртуализации, а о десктопной. Почему Microsoft? Потому что MS позиционирует свое VDI-решение как наиболее дешевое (и не зря, кстати), что мгновенно сказывается на заинтересованности рынка данным продуктом. Т.к. в VMware уже все понятно (там все хорошо), с Citrix тоже, осталось познать VDI от MS. Итак, каков он, VDI от MS в 2012-м, да и, пожалуй, в 2013-м и может даже 2014м? Да, т.к. большой любитель VMware, поэтому то тут, то там, будут проскакивать сравнения MS vs VMware.

2. Как это работает

На картинке показаны компоненты, необходимые для работы MS VDI (на самом деле если кто хорошо знаком с VMware View, разница невелика):

Прежде всего, нужен клиент – Remote Desktop Client. Да, для клиента сейчас уже лучше всего использовать Windows 8 и Windows 7 SP1, меньше и тем более XP – плохо.

· Remote Desktop Web Access (RDWA) — Веб-доступ к удаленным рабочим столам разрешает пользователям доступ к подключению к удаленным рабочим столам и удаленным приложениям RemoteApp через меню Пуск на компьютере, работающем под управлением Windows 8 или Windows 7, либо через веб-браузер. Подключение к удаленным рабочим столам и приложениям RemoteApp предоставляет настраиваемое представление удаленных приложений RemoteApp и рабочих столов на основе сеансов в коллекции сеансов, а также удаленных приложений RemoteApp и виртуальных рабочих столов в коллекции виртуальных рабочих столов. В VMware это собственно View Client, за исключением веб-портала.

· Remote Desktop Gateway (RDG) — Шлюз удаленных рабочих столов (шлюз RD) позволяет авторизованным пользователям подключаться к виртуальным рабочим столам, удаленным приложениям RemoteApp и рабочим столам на основе сеансов во внутренней корпоративной сети с помощью любого устройства, подключенного к Интернету. В VMware некий аналог View Security Server.

· Remote Desktop Session Host (RDSH) — Узел сеансов удаленных рабочих столов позволяет серверу размещать удаленные приложения RemoteApp или рабочие столы на основе сеансов. Пользователи могут подключаться к серверам узла сеансов удаленных рабочих столов в коллекции сеансов, чтобы выполнять программы, сохранять файлы и использовать ресурсы на этих серверах. Проще говоря, это управлялка службами терминалов. У VMware аналогов нет.

· Remote Desktop Virtual Host (RDVH) — Узел виртуализации удаленных рабочих столов объединяется с Hyper-V для развертывания коллекций помещенных в пул или личных виртуальных рабочих столов в организации с помощью подключения к удаленным рабочим столам и приложениям RemoteApp. Проще говоря, машина с ролью гипервизора – на ней должен стоять Hyper-V. В VMware это ESXi.

· Active Directory (AD) – тут все понятно: собственно AD, DNS и DHCP. В данном мануале DHCP сервера нет ввиду технических ограничений сети тестирования – я обошелся статикой, вовремя подменяемой в момент создания пулов машин J

· Licensing Server — Лицензирование удаленных рабочих столов управляет лицензиями, необходимыми для подключения к серверу узла сеансов удаленных рабочих столов или к виртуальному рабочему столу. Лицензирование удаленных рабочих столов можно использовать для установки, выдачи и отслеживания доступности лицензий.

· Remote Desktop Connection Broker (RDCB) – собственно управлялка подключениями. Аналог View Connection Manager.

Для развертывания простого варианта VDI нам потребуется физический сервер с ОС Windows Server 2012 и установленными ролями Hyper-V и RDVH, и две виртуальные машины: на одной будут службы AD, а на второй – роли RDWA и RDCB. Также нужно будет две виртуалки-шаблона с ОС Windows 7 и ОС Windows 8.

Про RemoteFX: протестировать чудеса графики от MS не получится, потому как хоть процессор (Xeon X56xx) и удовлетворяет требованиям RemoteFX, но нет в сервере физической карты GPU.

3. Подготовка инфраструктуры

Для начала подготовим инфраструктуру.

Что нам требуется:

· 1 физический сервер с ОС W2012 и ролями Hyper-V, RDVH: в качестве сервера у меня под рукой оказался Fujitsu PRIMERGY RX300 S6 с двумя Xeon X56xx, 24GB RAM и дисками 6x 300 SAS 15k;

· 1 контроллер домена с ролями ADDS, DNS (2GB, 2 vCPU);

· 1 сервера брокера соединений с ролями RDWA и RDCB (4GB, 2 vCPU;

· Клиент – ноутбук с правленым файлом hosts – в файл добавим инфу о сервере-брокере.

192.168.1.201/24 iRMC управляющий порт сервера

192.168.1.202/24 hvhost01.vdi.local гипервизор, порт 01

192.168.1.203/24 hvhost01.vdi.local гипервизор, порт 02

192.168.1.204/24 msvdi-dc.vdi.local контроллер домена

192.168.1.205/24 msvdi-broker.vdi.local сервер брокера соединений

192.168.1.206/24 win7template шаблон windows 7

192.168.1.207/24 win8template шаблон windows 8

192.168.1.211/24 win7-01 пул windows 7

192.168.1.212/24 win7-02 пул windows 7

192.168.1.213/24 win8-01 пул windows 8

192.168.1.214/24 win8-02 пул windows 8

192.168.1.10/24 gate шлюз

192.168.1.100/24 client ноутбук-клиент

4. Установка Windows Server 2012 и роли Hyper-V. Создание виртуальных машин.

Установка проста – монтируем диск и устанавливаем, затем вводим пароль и делаем базовую настройку – меняем IP на нужный нам (в примере 192.168.1.202 и 203), правим настройки DNS (выставляем адрес будущего сервера DNS 192.168.1.204) , выставляем время, включаем доступ по RDP и переименовываем машину:

Далее, создаем какую-нибудь папку для образов ISO, и копируем в нее образы W2012, W7 и W8 — у меня эта папка C:\ISO. Далее, создадим папку для конфигурационных файлов Hyper—V, образов машин и образов десктопов. У меня это E:\VM\Config, E:\VM\VHD и E:\VM\VDI соответственно.

Далее добавляем роль Hyper—V:

Выбираем установить роли:

Выбираем наш сервер, на котором будут крутиться все виртуальные машины:

Тут ничего не выбираем, просто жмем Next:

Выбираем один адаптер – второй сейчас не нужен, т.к. для каждого адаптера Hyper—V создает свой коммутатор:

Сервер у нас один – никаких миграций не планируется:

Здесь указываем пути, где будут храниться файлы жестких дисков машин и конфигурационные файлы:

Все, роль гипервизора установлена – можно создавать виртуальные машины. Теперь ребут и идем в консоль Hyper—V Manager для создания виртуальных машин:

Создадим виртуальные машины для контроллера домена и брокера – жмем New в панели Hyper—V Manager:

Обзовем машину запланированным именем и раздаем ресурсы.

Дадим контроллеру домена 2GB, а брокеру – 4GB. Десктопам позднее дадим тоже 2.

Выберем, к какому коммутатору будет подключена виртуальная машина:

Каким будет диск виртуальной машины и где он будет лежать (стоит отметить, что диски создаются в Thin-формате, т.е. место на физическом диске используется по требованию):

Далее указываем ранее скопированные нами ISO-образы ОС:

И создаем машину, но пока ее не стартуем:

Теперь дадим машине 2 vCPU (идем в свойства машины), также включим автостарт (нужен чтобы после ребута хоста машины поднимались автоматически):

Далее запуск, и ждем…

Итак, машины проинсталлены:

Стоит отметить, что шаги по созданию виртуальной машины практически идентичны аналогичным шагам в клиенте VMware vSphere Client. Также по ощущениям, создание 2-х машин на 4-х дисках в RAID-5 было уж очень неповоротливым, ОС Windows Server 2012 ставилась порядка 40 минут (ставилось их всего две параллельно). Может сказывается медлительность NTFS over VHD over NTFS? В аналогичных условиях на VMware VMFS (получаем NTFS over VMDK over VMFS) параллельная установка ОС выполняется быстрее.

Теперь установим роль контроллера домена и включим в домен машину-брокер msvdi— broker и собственно хост hvhost01.

Концепция виртуализации сети на базе Windows Server 2012 и System Center 2012 SP1

Доброго времени суток, уважаемые коллеги!

Совсем недавно у нас в Microsoft, в офисе на Крылатском было мероприятие посвященное System Center 2012 SP1, многим новинкам которые появились в сервис-паки были представлены на данном мероприятии. Однако, мы с коллегами проанализировали данные мероприятия, посмотрели что у людей вокруг с SP1 творится и пришли к выводу… что тему виртуализации сетей, концепт этой технологии плохо понятен рядовому системному администратору. Я имею в виду не саму технологию, а как она реализуется в продуктах MS и какие технологии отвечают за виртуализацию сети в Windows Server 2012 и System Center 2012 SP1.
У нас недавно было несколько постов на Хабре на тему виртуализации сети, но мы решили уделить особое внимание этому вопросу, так как тема действительно сложная и критично необходимая.

И так, давайте обо всем по порядку.

Виртуализация сети

Виртуализация сети — это технология, механизм виртуализации который позволяет абстрагироваться от физического уровня работы с сетью до уровня логического, т.е. до уровня программных софтверных механизмов. Также под виртуализацией понимается и типичная консолидация, но здесь она носит немного другой характер. Под консолидацией сети подразумевается возможность создать несколько, множество виртуальных сетей поверх общей телекоммуникационной среды, проще говоря — поверх обычных сетевых адаптеров. Таким образом можно разнести инфраструктуру поверх очень большого количества оборудования. Решение скорее для провайдеров, чем для средних компаний, или для крупных компаний со сложной гетерогенной инфраструктурой.
Однако виртуальные сети — это, конечно, хорошо — но что на счет безопасности? Да и вопросы масштабируемости закрытыми не назовешь такой технологии. И вот для этого в технологиях виртуализации сети присутствует понятие изоляции — простыми словами это механизм, который позволяет работать множеству изолированных сетей поверх общего физического канала таким образом, что ни один канал не знает о существовании друг друга и ведет себя так, как будто он работает поверх собственного выделенного физического канала. Это очень важный момент, поскольку он позволяет реализовывать такие нынче популярные тренды, как BYOIP (Bring Your Own IP) и BYON (Bring Your Own Network) на практике. Эти подходы интересны в первую очередь для провайдеров и представляют собой возможность полностью перенести и сохранить всю сетевую адресацию при миграции инфраструктуры в облако на базе System Center 2012 SP1 и Windows Server 2012 SP1, а второй механизм позволяет также перенести и всю конфигурацию сети за счет ее виртуализации (самой сети и ее компонентов — шлюзов, адресов, виртуальных адаптеров, создание логических коммутаторов и категоризация портов сетевых адаптеров по определенным параметрам и т.п.). Но это уже совсем сложные сценарии, так что пока давайте разберемся с самыми основами, про более сложные вещи погорим с вами в следующих постах на Хабре.

Who is Ху или как-бы понаглядней

Не мудрствуя лукаво, перед тем как рассказывать про всякие там элементы инфраструктуры и дабы не вгонять читателя в больший конфуз, предлагаю в начале ознакомиться с принципиальной схемы устройства компонентов сети с точки зрения вопросов виртуализации сети и возможностей Windows Server 2012 и System Center 2012 SP1.

Рисунок 1. Принципиальная схема виртуализации сети

Я специально не стал убирать англоязычные названия, так как многим они пригодятся в работе с WS и SC. Ну а перевод прилагается — так что все понятно. Ну и глядя на схему, давайте кратко опишем принцип работы такой сети, начиная с физического уровня и заканчивая уровнем клиентов (в данном случае это уровень ВМ). На самом низком уровне, как оно и положено, находится физическая есть, сама среда передачи данных, аппаратная инфраструктура, физические каналы, железо, сеть — называйте как хотите.
Дальше у нас с вами есть хосты виртуализации Hyper-V и они у нас включают в себя два важных элемента — логические коммутаторы (logical switches) и профили Uplink-порта на физическом сетевом адаптере. То есть хост Hyper-V представляет собой интерфейс для доступа к физической среде — с одной стороны, виртуализацию сети и предоставление интерфейса для ВМ — с другой. Поскольку логический коммутатор представляет с собой набор виртуальных коммутаторов Hyper-V с идентичными настройками то мы можем с вами говорить о том, что логические коммутаторы в совокупности представляют собой логическую сеть (logical network). По логике вещей конфигурация из логических коммутаторов составляющее логическую сеть можно классифицировать как сайт (site) — единое непрерывное сетевое пространство.

А вот дальше, уже, на уровень выше, у нас с вами начинается уже непосредственно виртуализация сети (даже лучше «сетей»). Следующий уровень — Сеть ВМ. Сеть виртуальных машин представляет собой следующий уровень виртуализации уже именно сетей — поскольку сети виртуальных машин, как уровень виртуализации, способны к изоляции собственной инфраструктуры, то есть именно этот слой позволяет создавать нам виртуальные изолированные сети, которые не имеют доступа друг к другу — фактически каждая сеть воспринимает себя как единственно-физическую в своем окружении.
Поверх сетей у нас находятся виртуальные машины, а общаются они с сетью средствами виртуального сетевого адаптера. Собственно говоря с точки зрения вопросов управления и развертывания (System Center 2012 VMM SP1) — есть профили портов и они применяются поверх сетевых адаптеров виртуальных машин, задавая им необходимые сетевые настройки.

Это если вкратце как оно работает — теперь давайте подробней посмотрим какие новшества в VMM 2012 SP1 помогают нам в работе.

Компоненты VMM

Теперь давайте рассмотрим компоненты VMM 2012 SP1 с точки зрения всего вышесказанного.

Итак, в порядке появления в VMM:

1) Логические сети (logical networks) — в контексте VMM, логическая сеть это необходимое условие для дальнейшего создания сетей ВМ, то есть механизм который использует виртуализацию сети хостов и представляет его как единое непрерывное сетевое пространство, поверх которого можно «нарезать» виртуальные изолированные сети. Этот объект мы создаем всегда в первую очередь, когда говорим о виртуализации сети в VMM 2012 SP1.

Рисунок 2. Логические сети в VMM 2012 SP1

Сам по себе механизм виртуализации сети заложен в Windows Server 2012 — и по сему 12-ый сервер — единственная ОС от MS которая позволяет реализовать виртуализацию сети без пресловутого метода VLAN’ов, но также позволяет использовать данный метод самим конечным пользователям внутри их виртуальной сети. Сама фишка поддерживается на уровне драйвера сетевого адаптера — поэтому не забудете его активировать на самом физическом адаптере, поверх которого вы будете назначать виртуальный коммутатор.

Рисунок 3. Активация драйвера сетевой фильтрации для виртуализации в Windows Server 2012

Далее мы как раз-таки и создаем саму логическую сеть — а после нехитрых манипуляций с драйвером мы можем использовать и виртуализацию сетей для их изоляции.

Рисунок 4. Создание логической сети с возможностью последующего создания изолированных сетей ВМ

2) В простейшей конфигурации для реализации виртуализации сетей все, что было бы необходимым сделать для «нарезания» бесконечного числа (образно) изолированных сеток — это воздание сети ВМ (VM Networks). Это по сути объект логической сети которая строится поверх логической сети и предоставляется как инфраструктура сети для обмена данными между ВМ. B вот теперь мы можем создавать изолированные виртуальные сети (сети ВМ) для выделенных изолированных инфраструктур.

Рисунок 5. Создание сетей ВМ в SC VMM 2012 SP1

Как вы видите, изоляция распространяется на адреса IPv4 и IPv6 выборочно или же единовременно. Также есть возможность создать сеть без изоляции — в этом случае область сети ВМ будет совпадать с областью логической сети — такие конфигурации сетей ВМ используют с целью предоставление доступа к объектам инфраструктуры VMM и частного облака.

3) Далее в VMM мы с вами встретим еще один интересный компонент — это пулы MAC-адресов (MAC Address Pool). Данный механизм интересен с точки зрения управления и развертывания инфраструктурой. Проще гововря — у каждого производителя оборудования есть свой пул MAC-адресов, которые они назначают своим устройствам. Поскольку в пределах одного вендора оборудования, как правило, используются схожие драйвера и компоненты — это позволяет автоматизировать задачи развертывания кластеров Hyper-V с нуля, включая необходимые компоненты для категории серверов. Допустим, у нас есть 3 вендора оборудования: Dell, IBM и HP.

Рисунок 6. Пулы MAC-адресов

Мы можем подготовить свои образы развертывания для каждой группы серверов, тем самым исключив вероятность дисконфигурации хоста, а благодаря MAC-адресам мы гарантируем соответствие образа с нужными драйверами и компонентами с оборудованием, на которое они разворачиваются.

4) Дальше в VMM у нас присутствует такой элемент, как балансировщики нагрузки (load balancers) — это могут быть как аппаратные, так и виртуальные элементы инфраструктуры, которые позволяют обеспечивать как отказоустойчивую, так и увеличенную полосу пропускания к необходимому сервису, который запущен на виртуальных машинах. Иными словами — привычный балансировщик. По умолчанию поддерживает работу с Microsoft NLB (а кто бы сомневался!?), но поддержка сторонних балансировщиков осуществлена через провайдер — допустим, вы можете поставить Citrix NetScaler и использовать его. Только помните — прежде чем использовать балансировщик — вы должны установить провайдер для работы с ним на сервере VMM и перезапустить его службу (VMM). Также вам понадобятся реквизиты доступа к вашему балансировщику.

Рисунок 7. Регистрация баласнировщика Citrix NetScaler

5) Сам по себе балансировщик — штука полезная, но в данном случае неэффективная. А вот если мы будем использовать профили VIP (Virtual IP) — виртуальных IP-адресов в сочетании с балансировщиками и задействуем их при развертывании и масштабирования наших сервисов — инструмент отличный. Иными словами профиль VIP — это виртуальный IP-адрес, который получает ваш сервис при развертывании из шаблона VMM. Этот адрес скрывает под собой все компоненты инфраструктуры сервиса (web-сервера, СУБД и прочие) и позволяет таким образом внутри сервиса организовать ферму и кластер для решения вопросов доступности и масштабируемости, ведь при развертывании сервиса из шаблона и использовании балансировщиков с VIP-профилями мы можем на лету создавать необходимые компоненты сервиса (в виде ВМ) — и сразу же добавлять их в общий пул для работы, а поскольку VIP-шаблон производит по сути виртуализацию IP-адреса внешней среды — того канала, откуда пользователи получают услугу.

6) Перед тем как подробнее говорить про логические коммутаторы (logical switches), давайте посмотрим на одну картинку ниже:

Рисунок 8. Требования для создания логического коммутатора в VMM

Из того, что мы видим следует то, что просто так создать логический коммутатор нам никто не даст — есть ряд некоторых условий:

a) Сначала нам необходимо создать логическую сеть и сети ВМ — ну с этим мы уже разобрались.
б) Дальше нам необходимо понимать, будем ли мы использовать расширения виртуального коммутатора Hyper-V из Windows Server 2012 — и если да, то нам нужно необходимо зарегистрировать провайдер в VMM для работы с ними. Здесь речь идет именно о механизмах расширенных возможностей коммутатора — фильтрация трафика или же дополнительных возможностей за счет сторонних дополнений.
в) Если же мы не планируем использовать прошлый сценарий ни на базе WS2012, ни на базе сторонних решений интеллектуального перенаправления, то нам не остается ничего другого, кроме как создать профили нативных портов (native port profiles) и портов для виртуальных машин для дальнейшего их сопоставления друг другу. Данный механизм фактически предъявляет требования по настройкам именно драйвера сетевого адаптера и сопоставления требований с фактическими возможностями драйвера. Иными словами мы можем логически разделить трафик по его типу (служебный, коммуникационный, SAN-трафик и прочие его типы) и применять эти настройки с точки зрения сети как механизм сопоставления настроек и поведения адаптеров хостов Hyper-V, который подключены к нему (физические адаптеры) с профилями портов виртуальных адаптеров внутри ВМ. Иными словами это механизм который с одной стороны разделяет логически трафик от комутатора до хоста, назначает физическим адаптерам определенную кофигурацию для обработки того или иного типа трафика, а на виртуальных машинах этот же механизм используется для определения свойств виртуальных адаптеров внутри ВМ, чтобы сопоставить их со свойствами адаптеров хоста — как крезультат — автоматическое назначение портов.

Рисунок 9. Создания профиля типа uplink

Как вы видите, при создании профиля нативного порта вы можете выбрать тип профиля, и собственно область его действия. Uplink — для применения на сетевые адаптеры, которые обеспечивают работу виртуального коммутатора, а профили виртуальных адаптеров — собственно работают на уровне адаптеров виртуальных машин. Область действия профиля же назначается на уровне логической сети.

И вот тут наступает самый интересный и связующий момент. Есть еще один компонент — классификация портов (Port Classification) — это собственно говоря, механизм для группирования профилей нативных портов. То есть вы создаете различные профили портов, допустим с низкой скоростью, но для разного типа трафика — и объединяете дальше эти порты в классификацию «Slow». И когда вы создаете логический коммутатор, вы указываете сразу в нем канал для выхода во вне (uplink) и задаете сразу классификации портов, включая все необходимые профили. Так как профиль распространяется на логическую сеть, то область его действия определяет и область действия логического коммутатора. Классификации портов также применяются при создании облака в VMM.

7) И последний механизм-компонент в VMM — это шлюзы (gateways). Шлюзы, как ясно из их названия, предназначены соединять между собой разрозненные и изолированные сети в единую непрерывную сеть. Иначе говоря, это механизмы удаленного доступа и взаимодействия на уровне сетей и их границ. Компонент шлюзов в VMM также использует сторонние инструменты и провайдеры для работы со шлюзами. Шлюзы могут быть как аппаратные так и программные. Шлюзы также могут использовать механизмы VPN для обеспечения своей деятельности. Также шлюзы позволяют использовать сценарии гибридного облака при создании гибридной сети Windows Azure VM. А если проще и по основному — то вы можете с помощью шлюзов соединять между собой виртуальные изолированные сети или же виртуальные сети с внешними сетями клиентов с помощью привычных для них инструментов (ну это если железо идентичное либо с функционалом и механизмами взаимодействия).

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

С уважением,
человек-огонь
Георгий А. Гаджиев

Эксперт по информационной инфраструктуре
Microsoft Corporation