Несколько дней назад вместе с Windows 10 Technical Preview for Enterprise стала доступна для загрузки и предварительная версия нового сервера – Windows Server Technical Preview. На фоне «десятки» последнее событие оказалось менее заметным, но отнюдь не менее значимым. Даже в этой довольно ранней сборке можно найти много новых возможностей. И далее мы поговорим о наиболее интересных из них с моей субъективной точки зрения.
Начнем с гипервизора.
Storage quality of service (QoS)
В Windows Server 2012 R2 впервые появилась возможность задавать максимальный и минимальный пороги для IOPS конкретного виртуального жесткого диска виртуальной машины. В Windows Server Technical Preview можно сформировать политику Storage QoS и применить ее:
· к виртуальным жестким дискам конкретной ВМ;
· к набору ВМ, на базе которого запущен сервис;
· ко всем ВМ, принадлежащим конкретному владельцу.
Таким образом, можно обеспечивать требуемый SLA для дисковых операций, например, на уровне кластера Scale-Out File Server(SOFS).
Production Checkpoints
Контрольные точки (checkpoints), они же снапшоты (shapshots), они же снимки используются уже давно. Создание же production checkpoint предполагает использование для снимка Volume Snapshot Service (VSS) внутри ВМ. Восстановление из такого снимка обеспечивает корректную поддерживаемую работу бизнес-приложений внутри ВМ. На серверах с Windows Server Technical Preview по умолчанию создается именно production checkpoint, хотя есть возможность использовать стандартный save state вариант.
Интеграционные компоненты с Windows Update
Для гостевых ОС Windows обновления интеграционных компонент будут распространяться через Windows Update. В хостерских сценариях это, в частности, означает, что владелец ВМ может сам контролировать версии интеграционных компонент для своих ВМ.
Безопасная загрузка (secure boot) для Linux
Для гостевых ОС Linux, поддерживаемых в ВМ второго поколения, теперь можно использовать опцию безопасной загрузки. Прежде чем впервые запустить такую ВМ необходимо явно указать, чтобы она использовала Microsoft UEFI Certificate Authority. Для этого в PowerShell необходимо выполнить командлет:
Set-VMFirmware vmname -SecureBootTemplate MicrosoftUEFICertificateAuthority
Горячее добавление/удаление сетевых адаптеров. Горячее добавление памяти
В ВМ второго поколения, как Windows, так и Linux, поддерживается горячее добавление/удаление сетевых адаптеров. Кроме того, в машины второго поколения вы можете на ходу добавлять оперативную память, даже если для ВМ не включена динамическая память.
Версии конфигурационной информации ВМ
В Windows Server 2012 R2 появилась возможность выполнять кросс-платформенную динамическую миграцию (live migration), а именно с Windows Server 2012 на Windows Server 2012 R2. Но такая миграция возможна только в одну сторону. В Windows Server Technical Preview если вы импортируете или выполняете динамическую миграцию ВМ с Windows Server 2012 R2, конфигурационные файлы ВМ автоматически не обновляются. Первое следствие из этого – вы не можете воспользоваться всеми новыми возможностями гипервизора для этой машины. Но второе и более важное – вы можете перемещать ВМ на ходу между Windows Server Technical Preview и Windows Server 2012 R2 в любую сторону. Если же перемещать ВМ обратно на Windows Server 2012 R2 более не требуется, то вы обновляете конфигурационную информацию с помощью, например:
Update-VmConfigurationVersion vmname
и пользуетесь всеми ,благами нового гипервизора, но уже без обратной миграции.
Обновление кластера без простоя
Кросс-платформенная миграция служит предпосылкой для обновления failover-кластера без простоя. Да, теперь вы можете обновлять узлы кластера Windows Server 2012 R2, не прерывая работу служб, запущенных на кластере Hyper-V или SOFS. Мигрируем с узла виртуальные машины, обновляем ОС на узле, добавляем узел с Windows Server Technical Preview обратно в кластер Windows Server 2012 R2. И так последовательно с остальными узлами. Пока идет процесс обновления кластер работает в ��ежиме Windows Server 2012 R2. Когда все узлы обновлены, с помощью
Update-ClusterFunctionalLevel
повышаем функциональный уровень кластера до Windows Server Technical Preview.
Поддержка OpenGL и MultiPoint Services
Remote Desktop Services поддерживает OpenGL 4.4 и OpenCL 1.1 API. Вы также можете выделять большее количество видеопамяти, что важно в различных сценариях VDI. Пока не успел сам попробовать, поэтому не могу написать точно «сколько в граммах».
Кроме того, роль MultiPoint Services теперь является частью продукта, интегрирована с RDSH и обеспечивает функциональные возможности Windows MultiPoint Server для совместного использования одного компьютера несколькими пользователями.
Storage Replica
Storage Replica (SR) – новая возможность, реализующая блочную синхронную репликацию между серверами. Благодаря SR можно реализовать различные сценарии катастрофоустойчивости, расширить возможности failover-кластеров по обеспечению высокой доступности приложений и служб. Синхронная репликация позволяет зеркалировать данные на сконфигурированных серверах, предотвращая потери на уровне файловой системы. Асинхронный режим, который также возможен для SR, не гарантирует 100% сохранность данных, однако применим во многих сценариях, когда компоненты высокодоступной системы располагаются в удаленных сайтах. Технических деталей по SR пока нет, но если не терпится, можно поэкспериментировать с новой компонентой и соответствующими командлетами:
Замечание для тех, кто планирует посмотреть на новый гипервизор. В текущей сборке Hyper-V не запустится, если процессор не поддерживает SLAT. Проверить этот момент можно, например, с помощью утилиты Coreinfo.exe (с ключом -v) из набора Sysinternals Suite. Например, вот в этом процессоре поддержка SLAT отсутствует, как следствие, Hyper-V работать не будет.
Это не все, но для первого обзора, мне кажется, можно остановиться.
Хотя нет, еще один момент. Плитки. Их по умолчанию нет. Но вы можете включить…, если захотите. :)
Удачных экспериментов, которые, я надеюсь, вы не станете проводить в production-среде. :).
По аналогии с дайджестомматериалов по Windows Server 2012/R2 свожу воедино все, что накопилось по System Center. Сюда же добавил те посты по гибридному облаку, которые так и или иначе затрагивают компоненты System Center и/или сервера.
Общие вопросы
Обзор новых возможностей System Center 2012 SP1
Облако растет и мужает — или новинки System Center Vitrual Machine Manager 2012 R2
Управление инфраструктурой
Bare-Metal Deployment — или как обеспечивается эластичность облака в System Center 2012 SP1 Virtual Machine Manager
На голое железо… Возможности VMM 2012 R2
Концепция виртуализации сети на базе Windows Server 2012 и System Center 2012 SP1
Виртуализация сети в System Center 2012 SP1 — Virtual Machine Manager
Управление хранилищами в System Center Virtual Machine Manager 2012 SP1
Гибридное облако
System Center 2012 App Controller: загоняем Virtual Machine Manager 2012 и Windows Azure в одну упряжку
Создание частного облака с помощью System Center Virtual Machine Manager 2012 R2
Шаблоны для создания служб и сервисов для Virtual Machine Manager 2012 R2
Расширение локальной инфраструктуры в облако
Windows Azure Pack — что за зверь и с чем его есть?
Практически все технологии, описанные в приведенных постах, можно посмотреть в следующих трех бесплатных курсах на MVA:
Настройка хостов виртуализации (Jump Start)
Обеспечение безопасности и высокой доступности виртуальных машин (Jump Start)
Развертывание виртуальных машин и сервисов (Jump Start)
Ну и парочка наиболее свежих курсов по теме:
Виртуализация серверов с Windows Server Hyper-V и System Center
Лучшие практики использования System Center
В нескольких предыдущих постах, посвященных технологии виртуализации сети (Hyper-V Network Virtualization, HNV), я рассказал об архитектуре, настройках, а также новых возможностях HNV в Windows Server 2012 R2. Сегодня речь пойдет о, пожалуй, самой сложной теме – построении HNV-шлюза на базе Windows Server 2012 R2 для предоставления виртуализованным сетевым сегментам доступа во внешн��й мир. Будет много скриншотов.
В большинстве случаев виртуальным машинам (ВМ), развернутым в виртуализованных сетях, необходимо взаимодействие с внешним миром – для связи с другими объектами ЦОД-а, для выхода в Интернет, для доступа к корпоративной сети компании, которая расположила в ЦОД-е эти самые ВМ и пр. Применительно к технологии HNV внешним миром является все что угодно, находящееся за пределами виртуализованной сети. И прежде чем двигаться дальше, необходимо лишний раз определиться с терминологией, которая за два года существования HNV слегка видоизменилась.
Итак, определяющим понятием HNV является сеть заказчика (Customer Network), обладающая уникальным идентификатором Routing Domain ID (RDID). Это и есть та самая виртуализованная сеть. Для Customer Network существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:
Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. А вот если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).
HNV-шлюз может представлять собой либо готовое аппаратное решение, либо хост на базе Windows Server 2012 R2. На текущий момент на рынке доступны три аппаратных решения:
В этом посте я сосредоточусь на создании HNV-шлюза на базе Windows Server 2012 R2, при этом управление HNV в моей демонстрационной сети, в том числе настройка шлюза, будет осуществляться с помощью System Center 2012 R2 Virtual Machine Manager (VMM). Используя далее сокращение VMM, я предполагаю именно версию R2, если явно не указано иное.
Напомню, что строго говоря, HNV – это технология Windows Server 2012 и выше, и она может быть настроена без VMM, просто с помощью командлетов PowerShell. Привожу ссылки на примеры соответствующих скриптов без использования и с использованиемHNV-шлюза. Но в реальных сценариях для управления HNV применяется VMM, который берет на себя роль централизованного хранения и распространения политик HNV.
Архитектурно HNV-шлюз на базе Windows Server 2012 R2 представляет собою физический хост, на котором запущена одна или несколько ВМ, выполняющих маршрутизацию пакетов из виртуализованных сетей во внешний мир и обратно. Обращаю внимание, это именно физический хост. Реализовать HNV-шлюз просто в виде виртуалки не получится уже хотя бы потому, что для инкапсуляции пакетов (см. посто концепции HNV) необходима роль Hyper-V, а вложенную виртуализацию Hyper-V не поддерживает.
Справедливости ради стоит отметить, что технически шлюз можно построить и на базе Windows Server 2012. Но при этом, во-первых, шлюз с Windows Server 2012 потребует запуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такого решения затруднительно. Во-вторых, для управления таким шлюзом с помощью VMM необходимо будет написать провайдер для VMM. Использование же Windows Server 2012 R2 + System Center 2012 R2 Virtual Machine Manager – это практически готовый HNV-шлюз «из коробки». В Windows Server 2012 R2 реализован мультитенантный шлюз, позволяющий задействовать одну ВМ для маршрутизации трафика различных виртуализованных сетей, а в System Center 2012 R2 Virtual Machine Manager уже встроен провайдер для управления таким шлюзом.
Какие варианты работы HNV-шлюза существуют? Таковых два.
Private Cloud (Routing)
Первый вариант реализует маршрутизацию трафика из Customer Network в сеть ЦОД-а, причем маршрутизация может быть как прямой, так и c трансляцией адресов (NAT).
На рисунке изображена прямая маршрутизация, которая имеет смысл, если пространства CA-адресов разных тенантов (Customer Networks) не пересекаются и им нужен доступ в корпоративную сеть. Или, как на рисунке, есть только один тенант с несколькими подсетями. Для частного облака, когда тенанты, например, представляют собой виртуализованные сети различных департаментов крупного предприятия, вполне возможный вариант.
При использовании NAT каждому тенанту HNV-шлюз ставит в соответствие выделенный IP-адрес на своем внешнем интерфейсе, и все пакеты от виртуальных машин тенанта отправляются во внешний мир с этим выделенным IP в поле «IP-адрес отправителя».
Hybrid Cloud (Site to site VPN)
Второй вариант предполагает построение туннеля типа «сеть-сеть» от HNV-шлюза до необходимой точки, например, через Интернет до корпоративной сети заказчика.
Это как раз типовой хостерский сценарий, когда ВМ заказчика располагаются в ЦОД-е хостера и связываются через VPN с сетью заказчика. Технология HNV при этом позволяет заказчику сохранить настройки IP и не бояться за работоспособность софта внутри ВМ, а хостеру –расположить у себя виртуалки с нужными заказчику IP, изолируя эти виртуалки от других ВМ и не настраивая VLAN-ы.
Завершая архитектурный раздел поста, отмечу кратко в чем же заключается мультитенантность шлюза на базе Windows Server 2012 R2.
Представьте себе, что в ЦОД-е виртуализованы сети двух заказчиков, Contoso и Woodgrove, использующие абсолютно одинаковые CA-пространства: 10.0.0.0/24. Как «развести» пакеты этих заказчиков на HNV-шлюзе? Первое возможное решение – создать на шлюзе для каждого заказчика свою ВМ и указать ее в настройках соответствующей сети заказчика в качестве default gateway. Таким образом, пакеты, направленные во внешний мир из Contoso, всегда будут приходить на сетевой интерфейс одной ВМ шлюза, пакеты из Woodgrove – на интерфейс второй ВМ и т. д. Как упоминалось, шлюз на базе Windows Server 2012 именно такой подход и использовал бы.
В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так называемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некий объект «ячейка» (compartment), в которую включаются виртуальные сетевые интерфейсы, IP-адреса, таблица маршрутизации, ARP-таблица и пр. Элементы одной ячейки изолированы от элементов другой ячейки. Маршрутизация пакетов от Contoso, таким образом, осуществляется в рамках соответствующей ячейки и не пересекается, не влияет на маршрутизацию пакетов Woodgroveв другой ячейке, даже если записи в таблицах маршрутизации этих ячеек выглядят одинаково. Такой подход позволяет использовать одну ВМ для маршрутизации пакетов разных тенантов без каких-либо конфликтов.
Как видно на рис. выше, существует ячейка по умолчанию (default compartment), которая включает в себя сетевые настройки, задаваемые при создании ВМ, и две ячейки для тенантов, появившиеся в процессе настройки HNV-шлюза.
Подкрепившись теорией, перейдем непосредственно к созданию шлюза. Для простоты я рассмотрю вариант шлюза без кластеризации, хотя понятно, что в реальном ЦОД-е такой важный элемент виртуализации предполагает работу в режиме высокой доступности. Детальный документ о том, как сделать HNV-шлюз высокодоступным можно найти здесь.
Основные шаги по созданию шлюза включают в себя следующее:
Давайте по порядку.
Настройка логических сетей и сетей ВМ
Этот пункт довольно подробно описан в одном из предыдущих постов, поэтому покажу лишь, как логические и виртуальные сети выглядят у меня в лабораторном свечном ЦОД-ике Contoso.
Для нашей задачи нужны три логические сети: внешний сегмент (Contoso_External_LN01), сеть для управления шлюзом (Contoso_Management_LN01) и сеть (Contoso_HNV_LN01), поверх которой собственно создаются виртуализованные сети. IP-пул сети Contoso_HNV_LN01 задает PA-пространство, а в свойствах этой сети обязательно должен быть помечен чекбокс, разрешающий использование технологии HNV.
Сети ВМ (VM Networks, они же сети заказчиков, они же Customer Networks) выглядят так:
Вы видите две сети ВМ для компаний Adatum и Fabrikam, использующие пересекающееся адресное пространство (10.30.1.0/24). В колонке Gateway Connectionвидно, что пока ни одна из сетей ВМ не использует шлюз.
Настройка хоста для роли шлюза
В общем-то любой хост с Windows Server 2012 R2, которым управляет VMM, можно настроить в качестве HNV-шлюза. По-хорошему, у этого хоста должно быть несколько физических сетевых интерфейсов, смотрящих в нужные сегменты (внешний, сегмент управления, сегмент HNV). Однако из архитектурной части поста следует, что собственно маршрутизацией пакетов в шлюзе занимается ВМ. Поэтому сколько физических сетевушек должно быть в хосте, выполняющем роль шлюза, определяется вопросами производительности, надежности (можно использовать тиминг, например) и, конечно, логикой того, как и куда вы хотите отправлять пакеты. Конкретно в моем стенде хост-шлюз содержит всего один физический сетевой интерфейс, мне этого пока вполне хватает для экспериментов.
Но в любом случае, в свойствах хоста, выбранного на роль шлюза, следует установить вот этот чекбокс
Он предотвратит запуск на шлюзе любых «рядовых» ВМ, предполагающих использование HNV. В реальной ситуации вы вообще вряд ли будете запускать на шлюзе еще что-то, кроме компонент самого шлюза.
Подготовка ВМ для шлюза
Теперь поговорим о той самой ВМ, которая будет осуществлять маршрутизацию пакетов с помощью compartments. Проще всего развернуть ее с помощью сервисного шаблона (service template). В этом случае можно сразу же сказать VMM, чтобы при развертывании ВМ в ней была поднята служба RRAS, чтобы для высокой доступности таких машин было поднято две на кластере и пр. Но, во-первых, мы договорились сделать все руками, чтобы лучше понять, что происходит, во-вторых, сервисные шаблоны не поддерживают ВМ второго поколения, которые разворачиваются, да и работают пошустрее.
Поэтому я создал шаблон ВМ второго поколения на базе VHDX с образом Windows Server 2012 R2. В этом процессе нет ничего необычного, покажу лишь сетевые настройки в шаблоне.
Вы видите три виртуальных сетевых адаптера (vNIC): один подключен ко внешней сети (см. рис.), второй к сети управления, третий можно в шаблоне оставить в состоянии Not Connected, а в процессе или сразу после развертывания ВМ, подключить его через виртуальный коммутатор (Hyper-V Extensible Switch) к сети, в которой используется HNV. Обычно при описании шлюза эту сеть называют Backend.
Разворачиваем теперь ВМ на основе этого шаблона на хост, который мы выбрали и настроили в качестве шлюза в предыдущем пункте. Обратите внимание на имя, которые вы дадите этой ВМ. Оно понадобится впоследствии при конфигурации шлюза.
После того, как ВМ развернута, зайдем в нее, подключим сетевой адаптер к Backend-сети, отключим Firewall и для удобства переименуем сетевые адаптеры так, чтобы имена отражали их предназначение, например
Теперь в ВМ (я назвал ее GatewayVM01) необходимо установить роль Remote Access. Делается это стандартно через Server Manager, Manage -> Add Roles and Features. Нажимаем Next, пока не дойдем до выбора роли, выбираем Remote Access, затем снова Next, пока не дойдем до Role Services, где помечаем две службы
Жмем до упора Next и Install. После завершения установки нажимаем Open the Getting Started Wizard
и в окне открывшегося мастера выбираем Deploy VPN only.
В итоге, откроется хорошо знакомая консоль RRAS, из которой видно, что служба пока не сконфигурирована.
Тем самым мы настроили хост и соответствующую ВМ, и теперь все готово, чтобы добавить эту «заготовку» в качестве HNV-шлюза в консоль VMM для последующей конфигурации.
Добавление шлюза в VMM
В консоли VMM переходим в раздел Fabric, нажимаем Add Resources и выбираем Network Service. На первой странице мастера даем шлюзу осмысленное имя и описание
Затем выбираем Microsoft в качестве производителя и Microsoft Windows Server Gatewayв списке моделей
На странице Credentials необходимо выбрать Run As accountдля доступа к устройству. Эта запись должна иметь административные права на ВМ шлюза. В нашем случае ВМ не включалась в домен, поэтому указываем запись с паролем локального администратора. Если в VMM такой записи нет, ее тут же можно создать.
Самый, пожалуй, интересный параметр – строка подключения (Connection String), в которой с помощью трех параметров VMHost, GatewayVM и BackendSwitch необходимо указать имя хоста и ВМ «заготовки» и имя виртуального коммутатора на хосте, через который ВМ подключается к Backend-сети. Обратите внимание, что в строке подключения нет пробелов, разделителем служит точка с запятой (;).
Кроме трех перечисленных выше существует еще несколько параметров, описание которых можно найти здесь (см. п.16). В частности, DirectRoutingMode=Trueнастроит шлюз на работу в режиме прямой маршрутизации.
При заданной выше строке подключения сертификаты не используются, поэтому на странице Certificates просто нажимаем Next.
На странице Provider нажимаем кнопку Testи убеждаемся, что все тесты проходят без ошибок.
На странице Host Groupуказываем, какие хостовые группы могут пользоваться данным шлюзом
Проверяем настройки на станице Summary, и если все правильно, жмем Finish.
Проверьте, что соответствующие задачи в разделе Jobs успешно завершены. Остается настроить сетевые интерфейсы только что созданного HNV-шлюза. В разделе Fabric -> Networking -> Network Service консоли VMM щелкните правой кнопкой мыши по шлюзу, выберите Properties и перейдите на закладку Connectivity. Здесь нужно включить Front End Connection и Back End Connectionи выбрать правильные сетевые адаптеры ВМ и соответствующие сайты логических подсетей.
Вот теперь VMM знает, какие адаптеры ВМ шлюза для каких целей предназначены, и должным образом сконфигурирует службу RRAS внутри этой ВМ. Когда отработают job-ы, в консоли RRAS ВМ шлюза вы увидите, что служба запущена и работает как мультитенантный шлюз.
Дело за малым, настроить требуемые сети ВМ на использование созданного HNV-шлюза.
Настройка шлюза для конкретных сетей ВМ
В консоли VMM переходим в раздел VMs and Services, щелкаем VM Networks, выбираем нужную сеть ВМ и нажимаем кнопку Properties. Идем на закладку Connectivity и разрешаем использование HNV-шлюза этой сетью. Для сети Fabrikam, например, включаем NAT:
VMM автоматически выделит из IP-пула логической сети, ассоциированной с внешним интерфейсом HNV-шлюза, адрес, в который будут транслироваться адреса отправителей всех пакетов из сети Fabrikam. Но вы можете вручную выбрать IP из пула, указав его в поле IP address
Закрыв окно свойств, в нижней части консоли VMM можно увидеть, какой конкретно внешний адрес используется для данной сети ВМ
Аналогично поступаем для сети Adatumи всех других виртуализованных сетей, которым нужен внешний доступ с поддержкой NAT.
Теперь давайте посмотрим, как настраивается подключение ко внешнему миру через VPN, то есть реализуем сценарий Hybrid Cloud (Site to site VPN). При этом я предполагаю, что VPN-устройство в корпоративной сети уже настроено, использует протокол IKEv2 и аутентификацию на основе Preshared Key, что типично для туннелей «сеть-сеть», и его внешний IP нам известен.
В свойствах той же сети ВМ Fabrikam на уже знакомой закладке Connectivityпомечаем самый верхний чекбокс
При этом в окне свойств сети ВМ появляется новая закладка VPN Connections, где нужно кнопкой Addдобавить VPN-подключение, указать его имя и IP-адрес VPN-устройства, до которого строится туннель
В разделе Authentication указываем подготовленную запись Run As accountс прописанным Preshared Key,
и в разделе Routesпрописываем нужные маршруты, например
Как вы могли обратить внимание, для динамического обновления маршрутов реализована поддержка BGP.
Можно посмотреть на расширенные настройки в Advanced, скажем поменять VPN-протокол или параметры шифрования, но если ничего этого не требуется, то жмем ОК. В нижней части консоли VMM для настроенной сети ВМ теперь будет отображаться что-то вроде
Как только из любой ВМ, запущенной в виртуализованной сети Fabrikam, попробуем сделать ping на адрес из подсети, указанной с настройках VPN-туннеля, например, 10.30.50.101, HNV-шлюз поднимет туннель и установит связь с заданным VPN-устройством, а через него с корпоративной сетью
Дело сделано!
Если информации из этого поста оказалось недостаточно, можете воспользоваться подробным пошаговым руководствомдля создания лабораторного стенда.
Остается открытым один вопрос, как собственно происходит маршрутизация пакетов при использовании HNV-шлюза, как это выглядит внутри шлюза? Но это уже уровень сложности 400 для особо искушенных. :) Хотя, если таковые найдутся, готов написать.
Надеюсь, материал был полезен.
Спасибо!
А вот и записи Jump Start от 22 апреля “Обеспечение безопасности и высокой доступности виртуальных машин”.
Напомню, что третий и последний Jump Start серии состоится 20 мая. Подключайтесь!
Рабочая неделя после длинных праздников началась ударно. Опубликованы записи мероприятия Jump Start “Настройка хостов виртуализации” от 8 апреля . Материалы доступны в виде курса на портале MVA.
К концу недели ожидаем публикацию материалов от 22 апреля.
Накопилась уже внушительная пачка материалов по Windows Server 2012 и Windows Server 2012 R2. Решил для удобства свести все ссылки в один пост. Надеюсь, будет полезно.
Что нового в Windows Server 2012 R2?
GUI, не GUI — или как включить и отключить графический интерфейс в Windows Server 2012
Hyper-V
Новые возможности Hyper-V 2012 R2
Поддержка Private VLAN в Windows Server 2012
Hyper-V Extensible Switch в Windows Server 2012
Shared VHDX в Windows Server 2012 R2
Второе поколение виртуальных машин в Windows Server 2012 R2
Настройка Hyper-V Replica в Windows Server 2012
SMB 3.0
SMB Multichannel в Windows Server 2012
SMB Transparent Failover в Windows Server 2012
SMB Scale-Out в Windows Server 2012
Хранилища
Хранилища и высокая доступность в Windows Server 2012 R2
Обзор и настройка средств дедупликации в Windows Server 2012
Создание Clustered Storage Spaces в Windows Server 2012
Сетевые технологии
NIC Teaming в Windows Server 2012
BranchCache в Windows Server 2012 и Windows 8
Обновление возможностей Remote Desktop Services в Windows Server 2012
Hyper-V Network Virtualization
Виртуализация сети в Hyper-V. Концепция
Виртуализация сети в Hyper-V. Настройка
Виртуализация сети в Hyper-V. Что нового в Windows Server 2012 R2?
Dynamic Access Control
Динамический контроль доступа: управление ресурсами по-новому
Динамический контроль доступа: как работать с утверждениями
Динамический контроль доступа: что собой представляют ресурсы
Динамический контроль доступа: списки свойств ресурсов и классификация файлов
Динамический контроль доступа: работа с централизованными правилами и политиками доступа
Периодически мне необходимо подключаться через VPN к моей домашней сети. Чаще всего для проведения демонстраций во время выступлений или проведения тренингов. Реже, чтобы достать определенные файлы или «посмотреть», что там с дочкиным планшетом. Подключаюсь либо с рабочего компьютера, либо со своего планшета. И там, и там Windows 8.1, а в этой версии появилась очень интересная возможность – автоматически срабатывающий (Auto-Triggered) VPN.
Все настройки покажу на примере планшета Surface с Windows 8.1 RT, хотя ровно также они выглядят в других редакциях 8.1. Пару слов о конфигурации домашней сети – Интернет-канал от «Ростелекома», есть внешний фиксированный IP, из ростелекомовской коробки кабель идет в роутер Linksys, который пробрасывает трафик, пришедший на внешний IP, на машину с Windows Server 2012 R2, служба Routing and Remote Access которого выступает в качестве VPN-сервера.
В домашней сетке поднят домен AD с именем “mva.com”. Использую его, например, для демонстрации туннеля с Windows Azure(проблематично сделать это в корпоративной сети с силу политик и пр.) и других бесчеловечных экспериментов. Домен “mva.com” снаружи мною не зарегистрирован и резольвится только в домашней сетке. Оставляю за кадром настройку VPN-сервера, здесь ничего необычного нет и, строго говоря, в этой роли совсем необязательно использовать Windows Server.
Перейду к настройке клиента. Первый шаг – создание VPN-подключения. Начиная с 8.1, это можно сделать в новом интерфейсе Windows, что особенно актуально для планшетов. К слову, прежний способ в традиционном интерфейсе никуда не пропал. Переходим в Change PC Settings -> Network -> Connections, нажимаем “Add a VPN connection”.
Выбираем поставщика VPN. В моем случае это Microsoft, но также в списке вы найдете встроенные клиенты от Check Point, F5, Juniper и SonicWALL. Заполняем необходимые поля.
Созданное подключение “Home” готово к использованию.
Единственное, что сделаю дополнительно, через PowerShell включу для этого подключения split tunneling.
Set-VpnConnection -Name "Home" -SplitTunneling $true
Пока ничего необычного. Проверяем подключение и убеждаемся, что ресурсы домашней сети доступны. В частности, контроллер домена пингуется. Во всех примерах ниже для подключения к Интернет использовался смартфон в качестве 3G-модема.
Но если попытаться обратиться к контроллеру по имени, то получим ошибку, поскольку для разрешения имени используется DNS-сервер Интернет-провайдера, который, естественно, ничего не знает о моем домашнем домене.
Хотелось бы получить следующее: первое, сделать так, чтобы при обращении по имени к ресурсам домена “mva.com” автоматически поднималось VPN-подключение “Home”; второе, для разрешения имен “mva.com” при этом использовался бы DNS-сервер контроллера домена домашней сетки.
Реализуется желаемое одним командлетом:
Add-VpnConnectionTriggerDnsConfiguration -Name "Home" -DnsSuffix "mva.com" -DnsIPAddress 10.40.1.200
Этот командлет, собственно, и настраивает триггер, то есть автоматическое срабатывание VPN-подключения с именем “Home” при обращении к именам с суффиксом “mva.com”. Разрешение имен для “mva.com” будет производиться с помощью машины с адресом 10.40.1.200, которая и является контроллером домена моей домашней сети.
Если после выполнения командлета посмотреть на VPN-подключение, то можно увидеть новый чекбокс, указывающий на наличие триггера для этого подключения.
В качестве проверки попробуем подключиться по имени к тестовому веб-сайту в домашней сети. Сайт откликается, VPN был автоматически поднят.
Что еще пожелать? Автоматическое подключение VPN при запуске определенного приложения. Конкретно для моего сценария это не особо нужно. Но уверен, во многих случаях подобная возможность может быть крайне востребована, особенно когда речь идет о клиентской части некоторого бизнес-приложения, серверная компонента которого расположена во внутренней сети компании.
Настроить триггер можно как для стандартных десктоп-приложений, так и для приложений нового интерфейса. В последнем случае необходимо узнать PackageFamilyName нужного приложения. Для этого можно запустить командлет Get-AppxPackage. Вы получите список всех приложений WinRT (тех самых приложений с новым интерфейсом из Windows Store) для данного пользователя. В списке нужно найти интересующее вас приложение. Для примера на моем планшете я поэкспериментирую с Fiction Book Reader Lite. Ниже информация именно по этому приложению:
Копируем строчку, содержащую PackageFamilyName, и создаем триггер:
Add-VpnConnectionTriggerApplication -Name "Home" -ApplicationID 4737VitaliyLeschenkoCo.FictionBookReaderLite_rt4gm7pfmw0sj
Тестируем. Запускаем приложение
и пытаемся открыть папку с контроллера домена:
Тот факт, что ресурсы доступны, видно в самом приложении. И конечно можно проверить, что VPN-подключение установлено.
Для традиционных десктопных приложений в качестве ApplicationIDдостаточно указать полный путь к исполняемому файлу:
Add-VpnConnectionTriggerApplication -Name "Home" –ApplicationID “C:\Windows\System32\notepad.exe”
Командлет Get-VpnConnectionTriggerпокажет всю информацию о триггерах для заданного подключения.
В частности, в отклике командлета для подключения “Home” можно увидеть, что триггер задан для приложения с соответствующим ID и домена “mva.com”.
В завершение несколько важных замечаний.
Auto-Triggered VPN работает только для подключений, для которых включен split tunneling.
Если при подключении к сети компьютер вместе с настройками IP получает от DHCP-сервера суффикс сети “mva.com”, триггер не будет срабатывать, так как ОС считает, что находится в нужной локальной сети и нет необходимости поднимать VPN.
Автоматически установленное для доменного имени VPN-подключение также автоматически разрывается, если в течение заданного интервала времени, по умолчанию 5 мин., через подключение не передается трафик. Интервал настраивается с помощью параметра -IdleDisconnectSeconds при создании подключения или в любой момент после создания с помощью командлета Set-VpnConnection. Однако надо иметь в виду, что этот интервал игнорируется до тех пор, пока запущено приложение, для которого задан триггер, даже если при этом трафик через VPN не передается.
Если вы вручную разорвали автоматические установленное соединение, то признак Auto-Triggered с подключения снимается, и далее автоматическая установка соединения не работает до тех пор, пока вы также вручную не установите заново упомянутый выше чекбокс “Let apps automatically use this VPN connection” в свойствах VPN-профиля.
Наконец, вы можете настроить триггеры для нескольких VPN-подключений в системе, но автоматическое подключение будет работать всегда только для одного из них, по умолчанию для первого созданного. Если позднее вы чекбоксом, либо командлетом включаете Auto-Triggering для некоторого другого профиля, то автоматическое подключение перестает работать для всех остальных VPN-профилей.
Мне кажется, технология довольно полезная, особенно для машин, не включенных в домен или которые невозможно включить в домен. Настройку через PowerShell, конечно, не назовешь user friendly, но пользователей можно освободить от этих хлопот, подготовив и распространив нужные VPN-профили с помощью System Center 2012 R2 Configuration Manager или Windows Intune.
Дополнительную информацию можно найти в подробном посте Windows Networking Team здесь(на англ.).
О программно-конфигурируемых или программно-определяемых сетях (Software Defined Networking, SDN) за последние полтора-два года писалось неоднократно. Технология виртуализации сети (Hyper-V Network Virtualization, HNV), впервые представленная в Windows Server 2012, является одной из реализаций подхода SDN. Об архитектуре HNV и настройке с помощью System Center 2012 Virtual Machine Manager (VMM) я рассказывал в предыдущих постах. HNV претерпела несколько изменений и усовершенствований в Windows Server 2012 R2, о которых кратко и пойдет речь сегодня.
Изменения в архитектуре HNV
Принципиальное изменение в архитектуре HNV заключается в переносе фильтра Windows Network Virtualization (WNV) внутрь расширяемого программного коммутатора Hyper-V (Hyper-V Extensible Switch). В чем важность этого изменения?
Напомню, что HNV использует инкапсуляцию пакетов для пересылки трафика между виртуальными машинами (ВМ) виртуализованной сети, расположенными на разных физических хостах. Исходный пакет с IP-адресами, принадлежащими виртуализованной сети (так называемыми CA-адресами) покидает ВМ, перехватывается WNV-фильтром и упаковывается в структуру NVGRE, которая, в свою очередь, помещается в пакет с IP-адресами, соответствующими физическому сегменту сети (PA-адресами). Далее такой пакет может беспрепятственно передаваться между хостами ЦОД-а. В сетевом стеке Windows Server 2012 упомянутый фильтр располагается между коммутатором Hyper-V и драйвером физического сетевого адаптера хоста. Как следствие, все модули расширения Hyper-V Extensible Switch, если таковые имеются, «видят» только исходные пакеты с CA-адресами, и ничего не знают о PA-адресах и вообще о том, что дальше происходит с пакетом, прежде чем он покинет хост.
В Windows Server 2012 R2 фильтр располагается внутри коммутатора Hyper-V. Любые расширения коммутатора, включая правила, списки управления доступом, антивирусные модули, могут быть применены как к исходному IP-пакету, так и к структуре NVGRE. Путь прохождения, например, входящего пакета выглядит следующим образом:
Стоит также отметить, что если в Windows Server 2012 WNV-фильтр необходимо включать в свойствах сетевого адаптера, то в Windows Server 2012 R2 фильтр включен по умолчанию, и технология HNV готова к использованию сразу после загрузки ОС.
Отслеживание изменения IP-адреса
Еще одно важное нововведение Windows Server 2012 R2 заключается в том, что Hyper-V стал «обучаемым», то есть умеет теперь отслеживать изменения CA-адресов внутри ВМ.
И ранее, и сейчас настроить HNV можно либо скриптами PowerShell, либо с помощью VMM. В первом случае соответствующими командлетами необходимо отредактировать политику HNV и отразить в ней те CA-адреса, которые заданы внутри ВМ. В случае с VMM, как показано здесь, требуется создать пул IP-адресов для CA-пространства, после чего при создании очередной виртуальной машины VMM будет брать из этого пула свободный адрес, присваивать его создаваемой ВМ и обновлять политику HNV.
Что произойдет, если владелец ВМ изменит вручную внутри своей виртуальной машины IP-адрес? Эта ВМ не сможет более взаимодействовать с другими ВМ виртуализованной сети, поскольку в Windows Server 2012 нет механизма, который в подобной ситуации автоматически изменил бы политики HNV и отразил в них новый CA-адрес. Конечно администратор физических хостов может через PowerShell отредактировать политику HNV, но в условиях ЦОД-а такой подход представляется слабо реальным. Если же ВМ была развернута с помощью VMM, то последний и призван контролировать распределение адресов. И он это делает до тех пор, пока выданный им из пула IP-адрес остается неизменным. Но изменение IP внутри ВМ вручную приводит к тому, что VMM теряет контроль над сетевыми настройками ВМ, а с ними теряется и централизованное управление политикой HNV, ради которого поддержка HNV и была встроена в VMM.
В Windows Server 2012 R2 ситуация иная. Изменение CA-адреса внутри ВМ сразу же отражается в политике HNV хоста, на котором запущена ВМ, хост передает эти изменения VMM, а тот, в свою очередь, синхронизирует изменения с остальными хостами, на которых присутствуют ВМ из этой же виртуализованной сети.
Способность отслеживать изменения CA-адресов позволяет теперь реализовать ряд важных сценариев:
1. Поддержка кластеризации. В виртуализованной сети можно объединять ВМ в высокодоступный гостевой кластер с помощью службы failover clustering и механизма общих VHDX-файлов (Shared VHDX). Кроме того, HNV-шлюз также может быть кластеризован.
2. Использование DHCP-сервера в виртуализованной сети. Внутри ВМ можно настроить DHCP, которым буду пользоваться другие ВМ этой сети.
Поддержка широковещательного и группового трафика (Broadcast/Multicast)
Возможность использования DHCP в виртуализованной сети требует дополнительных пояснений, поскольку кроме «отслеживания» динамических адресов необходимо обеспечить широковещательный трафик в пределах виртуализованного сегмента. Именно виртуализованного, ведь если broadcast каждой виртуальной сети выпускать в сеть физическую, то уровень флуда в ЦОД-е будет зашкаливать.
Прежде всего для передачи broadcast/multicast трафика будет ��спользоваться групповой IP, если таковой сконфигурирован на физическом адаптере хоста. Однако настройка multicast IP едва ли является распространенной практикой в ЦОД-ах. Соответственно, если multicast не сконфигурирован на физике, то широковещательные пакеты из виртуальной сети передаются с помощью одноадресной рассылки (unicast), причем только на те PA-адреса, где находятся ВМ, принадлежащие той же виртуальной подсети.
В качестве иллюстрации ниже в несколько упрощенном виде приведен процесс запроса и получения IP-адреса DHCP-клиентом. Синим цветом выделены PA-адреса, зеленым – CA-адреса.
Поддержка broadcast/multicast трафика также включает в себя поддержку Duplicate Address Detection (DAD), Network Unreachability Detection (NUD).
Повышение производительности
С точки зрения повышения производительности сетевых операций при использовании HNV следует отметить два момента.
Во-первых, при использовании тиминга сетевых адаптеров с динамическим режимом балансировки трафика (имеется в виду новый режим Dynamic для встроенной в ОС технологии NIC Teaming) для ВМ в виртуализованной сети обеспечивается не только отказоустойчивость на уровне сетевого адаптера, как было в Windows Server 2012, но и собственно балансировка трафика между адаптерами группы, а стало быть повышается пропускная способность сети для ВМ.
Во-вторых, на рынке начали появляться сетевые адаптеры с поддержкой NVGRE Encapsulated Task Offload. Производительность сетевых операций во многом зависит от того, используются ли аппаратные возможности сетевого адаптера, например, такие как Large Send Offload (LSO), Receive Side Scaling (RSS) или Virtual Machine Queue (VMQ). Если сетевой адаптер поддерживает перечисленные технологии, то для невиртуализованного сетевого трафика они просто работают. Применение же этих механизмов для инкапсулированных NVGRE-пакетов предполагает, что адаптер умеет анализировать CA-пакеты внутри GRE. Mellanox и Emulexобъявили о поддержке NVGRE Encapsulated Task Offload в некоторых моделях своих адаптеров. Ниже результаты тестов одного из таких адаптеров.
Диагностика и тестирование
Чем сложнее технология, тем сложнее выявлять причины возникающих проблем. По крайней мере, к HNV это относится в полной мере. А потому набор диагностических инструментов для HNV в Windows Server 2012 R2 расширен.
Microsoft Message Analyzer. Эта бесплатная утилита представляет собой сетевой (и не только) анализатор, пришедший на смену Network Monitor. Microsoft Message Analyzer распознает структуру NVGRE и позволяет легко анализировать инкапсулированные пакеты, включая CA-адреса. Замечу, что данный анализатор обеспечивает перехват не только сетевого трафика, но и с помощью Event Tracing for Windows (ETW) системных и других сообщений на удаленных хостах с Windows 8.1 и Windows Server 2012 R2.
На рисунке показан перехват ping-ов между двумя ВМ с CA-адресами 10.30.1.104 и 10.30.1.101 и PA-адресами 192.168.100.104 и 192.168.100.104.
Выделив GRE-пакет, можно увидеть поле, содержащее идентификатор виртуальной подсети (Virtual Subnet ID, VSID).
Ping. В утилите ping появился новый ключ «-p», который позволяет пропинговать хост по PA-адресу. Как правило PA-пространство задается в виде отдельной логической сети VMM, отличной от адресов, используемых для управления хостами виртуализации, да и любых других адресов.
В этом случае PA-адреса не отображаются в отклике ipconfig /all и не пингуются «обычным» пингом. Ключ «-p» решает эту проблему и позволяет проверить связь между хостами в PA-пространстве.
Test-VMNetworkAdapter. Для крупного ЦОД-а типичной является ситуация, когда администратор ЦОД-а не имеет доступа к гостевой ОС внутри ВМ. Если возникает проблема на уровне сетевого взаимодействия, то проверить прохождение пактов в PA-пространстве администратор ЦОД-а еще может, а вот настройки CA-пространства ему могут быть недоступны. Помочь может командлет Test-VMNetworkAdapter. По сути этот командлет реализует пинг между двумя ВМ, причем пинг с одного CA-адреса на другой CA-адрес. (Администратор может не иметь возможности поменять CA-адреса внутри ВМ, но увидеть эти адреса в консоли VMM или Hyper-V можно, «не залезая» внутрь ВМ). С помощью командлета необходимо указать, какая ВМ является получателем, какая отправителем пакетов, каковы адреса отправителя и получателя, номер последовательности и MAC-адрес получателя.
Test-VMNetworkAdapter -VMName Fabrikam_SRV02 -Receiver -ReceiverIPAddress 10.30.1.107 -SenderIPAddress 10.30.1.108 -SequenceNumber 102
Test-VMNetworkAdapter -VMName Fabrikam_SRV03 -Sender -ReceiverIPAddress 10.30.1.107 -SenderIPAddress 10.30.1.108 -SequenceNumber 102 -NextHopMacAddress 00-1d-d8-b7-1c-0c
Отклик, вроде изображенного ниже, говорит о том, что сетевое взаимодействие между ВМ происходит нормально, включая упаковку и распаковку CA-пакетов в PA-пакеты и обратно. А стало быть, с большой вероятностью проблемы следует искать уже внутри ВМ (правила firewall, запуск сервисов и пр.)
HNV-шлюз
Для того, чтобы ВМ виртуализованной сети могли взаимодействовать с внешним миром, необходимо настроить HNV-шлюз. Windows Server 2012 R2 может выступать в качестве такого шлюза что называется «из коробки». То есть все необходимые сервисы и компоненты для реализации функции шлюза Network Virtualization есть в составе новой серверной ОС, надо только их настроить. Как это делается, каковы возможности такого шлюза – тема отдельного поста, который я надеюсь в ближайшее время опубликовать.
Итак, реализация концепции SDN в Windows Server 2012 R2 получила свое дальнейшее развитие. Изменения направлены на повышение гибкости и производительности решения. Дополнительные инструменты диагностики помогут эффективнее обнаруживать и устранять возможные проблемы, а наличие встроенного шлюза и его поддержка в VMM 2012 R2 ускорят развертывание виртуализованных сетей в масштабах ЦОД.
Дополнительную информацию можно найти во втором модуле курса «Все о System Center 2012 R2 (Jump Start)» на обучающем портале MVA.
После проведенного Jump Start, целиком посвященного Windows Server 2012 R2, меня не покидало ощущение какой-то недосказанности. Хотя Леша Кибкало прочитал очень детальную презентацию о Hyper-V, чего-то все равно не хватало. Демонстраций! Продукт надо показывать, тогда картина получится законченной. Как раз тема Hyper-V получилась слегка обделенной в этом смысле.
Я решил восполнить пробел и записал для MVA курс: «Hyper-V в Windows Server 2012 R2». Один модуль продолжительность примерно полтора часа. Речь только о новых или усовершенствованных возможностях Hyper-V в R2. Никаких повторений с тем, что было в курсе по Windows Server 2012, за исключением, пожалуй, слайда по масштабируемости. Восемь демонстраций, от виртуальных машин второго поколения до поддержки Linux в качестве гостевых ОС.
Надеюсь, курс дополнит набор материалов по новой серверной ОС и будет полезен. Комментарии и замечания приветствуются.
С появлением в Windows Azure технологий виртуальных машин (ВМ) и виртуальных сетей реализация гибридных сценариев, когда часть локальной инфраструктуры переносится в облако или расширяется за счет ресурсов облака, становится вполне выполнимой задачей. Подобные сценарии предполагают наличие туннеля между локальной сетью предприятия и облаком. В этом посте я покажу, каким образом строится такой Site-to-Site (S2S) туннель в случае, когда в качестве облака выступает Windows Azure, а шлюзом в локальной сети является сервер под управлением Windows Server 2012 R2. Будет много картинок.
Давайте представим себе, что некоторая компания заинтересована в расширении своей локальной ИТ-инфраструктуры и хотела бы перенести часть нагрузок в Windows Azure. Для нас сейчас не принципиально, что конкретно будет переезжать в облако: веб-сервер, база данных, портал SharePoint или что-то еще. Важно, чтобы виртуальные машины, развернутые в Windows Azure, «виделись» как часть локальной инфраструктуры Active Directory (AD), были включены (или могли быть включены) в домен и по сути представляли собой просто еще один сегмент корпоративной сети.
Планируемая конфигурация выглядит следующим образом:
Точнее слева на рисунке то, что уже есть, справа то, что предстоит сделать.
В первую очередь мы создадим в Windows Azure виртуальную сеть с именем VPNnet01. В этой сети необходимо предусмотреть как минимум две подсети – одна (можно несколько) для ВМ, вторая для построения туннеля в локальную AD. Наличие выделенной подсети для шлюза является требованием Windows Azure.
Затем организуем туннель между созданной виртуальной сетью и локальной инфраструктурой, причем сначала этот туннель настраивается со стороны Windows Azure, потом со стороны локальной сети.
Наконец, создадим ВМ в Windows Azure и убедимся, что эта виртуальная машина доступна из локальной сети и наоборот, ВМ может взаимодействовать с контроллером домена, расположенным локально.
Вся процедура, таким образом, сводится к четырем основным этапам:
Поехали!
Я исхожу из того, что подписка Windows Azure в организации уже есть. Варианты получения подписки перечислены здесь. Я также предполагаю, что вы имеете представление о концепции виртуальных сетей в Windows Azure. Если это не так, можно подчерпнуть информацию в третьем модуле курса «Windows Azure для системных администраторов» на портале MVA. Но основные шаги я прокомментирую.
Итак, необходимо зайти на портал управления Windows Azure и выбрать в разделе NETWORKS создание новой виртуальной сети, нажав кнопку NEW.
Задаем имя виртуальной сети и выбираем AFFINITY GROUP, которая позволяет расположить ваши ВМ в рамках одного ЦОД Windows Azure для сокращения задержек в сети. Если ни одной AFFINITY GROUP у вас еще нет, вам предложено будет такую группу создать.
На следующей странице необходимо задать имя и IP-адрес сервера(-ов) DNS. Строго говоря, это поле не является обязательным, и его можно заполнить/изменить позже. Но для нашего сценария вся информация о DNS уже есть. Поскольку мы планируем использовать ВМ в Windows Azure как часть AD предприятия, то здесь я указываю имя и IP-адрес контроллера домена, традиционно выполняющего и роль DNS-сервера. Все создаваемые в этой сети ВМ автоматически получат именно этот адрес в качестве адреса DNS-сервера. Если поле оставить пустым, то создаваемые впоследствии ВМ будут использовать для разрешения имен службу DNS Windows Azure и при этом, разумеется, включить такие машины в домен не получится. Технически вы сможете потом зайти на конкретную ВМ, например, с помощью RDP и вручную изменить адрес DNS, но предлагаемый на данной странице вариант гораздо удобнее. Кроме того, надо заметить, что вообще не рекомендуется что-либо менять вручную в настройках TCP/IP виртуальных машин. Этими настройками управляет Windows Azure, чтобы вы, в свою очередь, имели надежный доступ к вашим машинам.
Второй важный параметр на странице – чекбокс Configure site-to-site VPN, который нужно не забыть отметить.
На странице Site-to-Site Connectivity задаем три параметра:
На странице Virtual Network Address Spaces необходимо сформировать виртуальное адресное пространство создаваемой виртуальной сети. ВМ в облаке будут получать IP-адреса как раз из этого пространства. Указав адресный диапазон всей сети, нужно затем разбить его на подсети. Напомню, что требуется как минимум две подсети: для ВМ и шлюза соответственно. В каждой виртуальной сети может быть только одна подсеть шлюза.
Нажимаем кнопку “Complete” и ждем завершение процесса создания виртуальной сети.
Собственно на этом первый этап завершен, и мы можем переходить к настройке шлюза Windows Azure.
После того как сеть создана, щелкаем по ней и видим закладку DASHBOARD.
В меню в нижней части экрана нажимаем CREATE GATEWAY и выбираем Dynamic Routing. Два типа маршрутизации поддерживает на текущий момент Windows Azure. Статическая маршрутизация основана на заданных пользователем политиках (списках доступа), динамическая – на заданных маршрутах и туннельном интерфейсе (любой пакет, попадающий на туннельный интерфейс, пересылается через VPN-туннель). В случае динамической маршрутизации, соответственно, если IP-диапазоны виртуального и локального адресных пространств при создании виртуальной сети в Windows Azure были заданы корректно (не пересекаются, не дублируются и пр.), то пакеты должны правильным образом маршрутизироваться между Windows Azure и локальной инфраструктурой.
Выбор типа маршрутизации определяется тем, какой шлюз используется на стороне локальной инфраструктуры. В документации в разделе Known compatible VPN devices можно посмотреть список поддерживаемых шлюзов и соответствующих им типов маршрутизации.
Остается ждать, пока Windows Azure настроит шлюз. Этот процесс занимает в среднем 15-20 мин.
По окончании на странице можно увидеть внешний IP-адрес созданного в Windows Azure шлюза, и этот адрес следует использовать в качестве конечной точки подключения при настройке шлюза в корпоративной сети.
Для определенных моделей шлюзов (VPN-устройств), в том числе для службы RRAS в Windows Server 2012/R2, Windows Azure может сгенерировать скрипт, который затем необходимо запустить на VPN-устройстве и тем самым сконфигурировать это устройство для организации туннеля в Windows Azure. Чтобы загрузить такой скрипт нужно создать ключ, используемый для туннельной аутентификации, нажав MANAGE KEY,
а затем щелкнуть по ссылке Download VPN Device Script справа на странице.
В открывшемся окне выберете производителя шлюза, платформу и операционную систему и загрузите скрипт.
Теперь полученный скрипт необходимо перенести на VPN-устройство и выполнить настройку.
Следует убедиться в том, что полученный на предыдущем этапе скрипт содержит корректные значения адресного пространства виртуальной сети и внешнего адреса шлюза Windows Azure. Эти значения выделены в приведенном фрагменте скрипта.
# Install RRAS role Import-Module ServerManager Install-WindowsFeature RemoteAccess -IncludeManagementTools Add-WindowsFeature -name Routing -IncludeManagementTools # !!! NOTE: A reboot of the machine might be required here after which the script can be executed again. # Install S2S VPN Import-Module RemoteAccess Install-RemoteAccess -VpnType VpnS2S # Add and configure S2S VPN interface Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly -Name 137.116.214.169 -Destination 137.116.214.169 -IPv4Subnet @("10.50.0.0/16:100") -SharedSecret 0pCpWdVuzaJuZtJpQq8TbtUAQWk7PtOk Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption # Set S2S VPN connection to be persistent by editing the router.pbk file (required admin priveleges) Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "IdleDisconnectSeconds" "0" Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "RedialOnLinkFailure" "1" # Restart the RRAS service Restart-Service RemoteAccess # Dial-in to Azure gateway (optional) #Connect-VpnS2SInterface -Name 137.116.214.169
# Install RRAS role
Import-Module ServerManager
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Add-WindowsFeature -name Routing -IncludeManagementTools
# !!! NOTE: A reboot of the machine might be required here after which the script can be executed again.
# Install S2S VPN
Import-Module RemoteAccess
Install-RemoteAccess -VpnType VpnS2S
# Add and configure S2S VPN interface
Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly -Name 137.116.214.169 -Destination 137.116.214.169 -IPv4Subnet @("10.50.0.0/16:100") -SharedSecret 0pCpWdVuzaJuZtJpQq8TbtUAQWk7PtOk
Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption
# Set S2S VPN connection to be persistent by editing the router.pbk file (required admin priveleges)
Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "IdleDisconnectSeconds" "0"
Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "RedialOnLinkFailure" "1"
# Restart the RRAS service
Restart-Service RemoteAccess
# Dial-in to Azure gateway (optional)
#Connect-VpnS2SInterface -Name 137.116.214.169
Если все верно, остается просто запустить это скрипт на машине с Windows Server 2012 R2, которая будет выполнять роль шлюза. Подчеркиваю, выше приведен лишь фрагмент. Запускать надо, конечно, весь скрипт целиком, причем под учетной записью с правами администратора. Например, это можно сделать в PowerShell ISE.
По приведенному фрагменту видно, что скрипт устанавливает и настраивает службу Routing and Remote Access Services (RRAS). Давайте посмотрим, как выглядят некоторые настойки RRAS после успешного выполнения скрипта.
Во-первых, в разделе Network Interfaces можно заметить интерфейс с именем, соответствующим внешнему IP-адресу шлюза в Windows Azure, причем состояние этого интерфейса должно быть Connected. Если это не так, щелкните по нему правой кнопкой мыши и в контекстном меню выберете Connect.
В свойствах этого интерфейса, используемого, как вы понимаете, для построения туннеля, мы найдем IP-адрес шлюза Windows Azure,
а также на закладке Security используемый протокол (IKEv2) и сгенерированный в Windows Azure ключ.
Кроме того, в разделе Static Routes появился статический маршрут, пересылающий по туннелю все пакеты с адресами получателя, принадлежащими виртуальной сети Windows Azure.
Сам RRAS-сервер сконфигурирован в качестве маршрутизатора, в чем можно убедиться посмотрев его свойства.
Используя приведенную информацию, вы сможете вручную настроить службу RRAS, если по каким-либо причинам скрипт отработал с ошибками.
Если же все в порядке, то вернувшись на закладку DASHBOARD виртуальной сети, созданной в Windows Azure, вы увидите примерно такую картину:
Либо она станет такой после нажатия кнопки CONNECT внизу страницы.
Теперь, когда туннель создан, остается проверить конфигурацию.
Для этого давайте создадим ВМ в Windows Azure и попробуем включить эту ВМ в AD локальной инфраструктуры. Шаги достаточно стандартные, в разделе VIRTUAL MACHINES нажимаем NEW и выбираем FROM GALLERY,
в качестве гостевой ОС выбираем, например, Windows Server 2012,
задаем имя ВМ, логин и пароль администратора,
и убеждаемся, что машина будет подключена к созданной ранее виртуальной сети.
На последней странице оставляем все без изменений.
После того как ВМ запустится, можно подключиться к ней по RDP и посмотреть параметры IP. В данном случае видно, что ВМ получила адрес 10.50.1.4 из адресного пространства виртуальной сети, при этом в качестве адреса DNS-сервера указан адрес контроллера домена (192.168.3.200).
Проверим разрешение имен и ping на контроллер домена, если конечно Firewall разрешает ICMP.
Коммуникации настроены, остается просто включить ВМ в домен, и это уже самая обычная процедура, на которой я останавливаться не буду.
Итак, мы прошли все этапы, и теперь наша локальная инфраструктура расширена сетевым сегментом в Windows Azure. В этом сегменте можно создавать дополнительные подсети, запускать ВМ нужной конфигурации, переносить в них требуемые сервисы, настраивать их мониторинг и использовать таким образом ресурсы облака для решения стоящих перед ИТ-департаментом задач.
Я привел достаточно подробное описание настроек для того, чтобы вы смогли при необходимости воспроизвести рассмотренные шаги. Как упоминалось, на сайте Windows Azure вы сможете найти скрипты для разных типов VPN-шлюзов. Но даже если в этом списке нет вашего устройства, вы можете настроить свой шлюз, понимаю логику работы и используемые протоколы и механизмы аутентификации Windows Azure. В общем, лучший способ изучить технологию – попробовать самому. J
Надеюсь, материал был полезен!
Сегодня я хотел бы подробнее остановиться на одной из новых возможностей Hyper-V в Windows Server 2012 R2, упомянутой мною в обзорном посте, а именно, обсудить второе поколение виртуальных машин (ВМ). Тема становится особенно актуальной с доступностью RTM Windows Server 2012 R2 для подписчиков TechNet и MSDN и скорым выпуском финальной версии System Center 2012 R2.
С выходом Windows Server 2012 R2 в Hyper-V появилось возможность создавать ВМ двух разных типов или двух разных поколений (Generation 1 и Generation 2). ВМ первого поколения представляют собой виртуальные машины, хорошо известные по предыдущим версиям Hyper-V. Все, что вы привыкли видеть в настройках ВМ, плюс ряд новых настроек, вы увидите в машинах первого поколения. Они никуда не делись, вы можете и дальше спокойно их использовать.
Но помимо этого вы можете теперь создавать ВМ второго поколения. Это поколение отражает изменения, которые произошли и продолжают происходить как в архитектуре ОС, так и в аппаратном обеспечении современных компьютеров. На рубеже Windows 2000, Windows XP, Windows Server 2003 операционные системы проектировались без учета технологий виртуализации, тогда еще только набиравших обороты. Чтобы нормально запустить такие ОС внутри виртуальной машины необходимо было создать для них иллюзию запуска на физическом компьютере. Как следствие, приходилось эмулировать различное оборудование, как то: BIOS, контроллер прерываний, IDE-контроллер, стандартные порты ввода-вывода и пр. Вы легко увидите перечень эмулируемых устройств, если загляните в Device Manager на ВМ первого поколения.
Эмуляция, с одной стороны, приводит к дополнительным накладным расходам, прежде всего, к лишним тактам процессора, с другой стороны, каждое эмулируемой устройство – дополнительный довольно сложный код, потенциально расширяющий поверхность для атак.
С течением времени ОС стали проектироваться с учетом того, что система может, или даже скорее всего будет работать в виртуальной среде. Такая ОС «знает», что запускается внутри ВМ и, как на этапе загрузки, так и в ходе своей работы, опирается на ресурсы, предоставляемые родительским разделом (хостовой ОС). Иными словами, ОС уже при старте общается с гипервизором через шину VMBus, а не рассчитывает обнаружить контроллер прерываний или чипсет определенного типа. Следовательно, для таких ОС можно отказаться от унаследованных эмулируемых устройств и повысить производительность ВМ. Действительно, в Deviсe Manager ВМ второго поколения картина будет иной.
Отказ от эмуляции устаревших устройств изменяет «начинку» ВМ второго поколения. В свойствах таких ВМ вы увидите примерно следующее:
Отсюда можно выделить следующие преимущества ВМ второго поколения:
Таблица ниже подытоживает «аппаратные» изменения в ВМ второго поколения.
Возникает резонный вопрос, отличается ли скорость работы ВМ первого и второго поколений? Когда ОС загрузилась, какую-то разницу в скорости работы вы, скорее всего, не заметите. Интеграционные компоненты внутри гостевой ОС позволяют работать ВМ максимально эффективно. Но есть две ситуации, в которых разница может быть очень ощутимой – это установка гостевой ОС и загрузка ВМ. Именно на этих этапах эмуляция оборудования сказывается весьма существенно.
В качестве иллюстрации я провел следующий эксперимент: создал две ВМ, первого и второго поколения соответственно, обеим ВМ выделил одинаковое количество оперативной памяти и виртуальных процессоров и одновременно запустил установку Windows Server 2012 R2 внутри созданных ВМ с одного и того же ISO-образа. Вот так выглядела картина в начальной фазе установки (ВМ второго поколения внизу):
И вот такую разницу можно было наблюдать позже:
Таким образом, при развертывании ВМ, а также при старте ВМ, что, например, особенно важно в сценариях VDI, разница в производительности ВМ второго поколения может достигать 50% и более.
Необходимо помнить несколько принципиальных моментов, относящихся к эксплуатации ВМ второго поколения.
В качестве гостевых ОС в ВМ второго поколения могут использоваться только:
Это связано с тем, что именно эти версии ОС поддерживают спецификацию UEFI 2.3.1, в которой, в частности, реализована технология Secure Boot.
Вы можете создать ВМ второго поколения в консоли Hyper-V,
либо с помощью командлета PowerShell New-VM, указав ключ –Generation 2.
При этом надо иметь в виду, что поколение указывается только на этапе создания ВМ. В дальнейшем конвертировать ВМ из одного поколения в другое невозможно как раз в силу того, что в одном случае используется BIOS, в другом – UEFI.
Последний аспект, который хотелось бы отметить, связан с управлением. Управление хостами с Windows Server 2012 R2 возможно с помощью System Center 2012 R2 Virtual Machine Manager. В доступной сейчас preview-версии System Center 2012 R2 поддержка второго поколения ВМ отсутствует. Но в RTM-версии System Center 2012 R2 (а она уже не за горами) эта поддержка будет добавлена.
Итак, новое поколение ВМ в Windows Server 2012 R2 лишено устаревших эмулируемых устройств, поддерживает ряд новых возможностей и обеспечивает прирост производительности, особенно на этапах установки и загрузки гостевых ОС. Применение машин второго поколения сейчас сужает перечень поддерживаемых гостевых ОС, однако для остальных систем можно по-прежнему применять ВМ первого поколения, которые прекрасно сосуществуют с ВМ второго поколения на одном хосте виртуализации.
Дополнительную информацию о новых технологиях Windows Server 2012 R2 вы сможете найти на портале MVA в курсе “Jump Start: Все о Windows Server 2012 R2”
В предыдущем посте, посвященном обзору Windows Server 2012 R2, я упоминал новую возможность Hyper-V – использование общих VHDX-файлов (Shared VHDX) для создания гостевых кластеров. Сегодня я хотел бы подробнее остановиться на этой теме и обсудить особенности настройки и применения Shared VHDX.
Для начала кратко о том, зачем вообще нужна гостевая кластеризация. Большая часть приложений и сервисов, используемых в современной ИТ-инфраструктуре, может быть запущена внутри виртуальных машин (ВМ). Виртуализация дает целый ряд очевидных и не очень преимуществ, перечисление которых выходит за рамки поста. Чем более критичное для компании приложение крутится внутри ВМ, тем более важной становится задача обеспечения высокой доступности такой ВМ.
Обеспечить высокую доступность ВМ можно разместив ее на физическом (хостовом) кластере, в данн��м контексте – кластере Hyper-V. Выход из строя физического узла кластера, на котором была запущена ВМ, приводит к автоматическому восстановлению ВМ на другом узле кластера. Эта процедура отработки отказа может привести пусть и к кратковременной, но потере связи с ВМ и приложением внутри нее.
Другой метод повышения доступности – объединение в Failover Cluster двух или более ВМ, то есть создание гостевого кластера в том смысле, что кластер создается на базе гостевых ОС. В этом случае мы уже говорим о высокой доступности не ВМ как таковых, а приложения (или приложений) внутри гостевого кластера.
Разумеется, для большей надежности можно сочетать хостовую и гостевую кластеризацию.
Гостевая кластеризация, впрочем как и хостовая, предполагает наличие некоторого общего хранилища. Применительно к виртуальным машинам таким хранилищем до выхода Windows Server 2012 мог выступать iSCSI-storage.
В Windows Server 2012 благодаря Virtual Fibre Channel появилась возможность подключать ВМ через HBA-адаптер хоста непосредственно к FC-storage.
Однако в любом случае для построения гостевого кластера необходимо было предоставить ВМ прямой доступ к хранилищу. Во многих сценариях, например для хостинг-провайдеров, такой вариант является очень неудобным. Общие VHDX-файлы как раз и позволяют эту проблему решить, поскольку абстрагируют ВМ от особенностей реализации СХД. Для создания гостевого кластера к виртуальным машинам подключается нужное количество Shared VHDX, которые и представляют собой общее кластерное хранилище. А где физически, на каком конкретно СХД и LUN-е эти файлы располагаются – это уже дело провайдера.
С точки зрения реализации описанного подхода можно выделить две основные конфигурации использования Shared VHDX. В первой конфигурации общие VHDX-файлы располагаются на CSV-томе физического кластера. CSV-том, в свою очередь, может быть реализован на любом поддерживаемом службой кластеризации Windows Server блочном хранилище (Fibre Channel, iSCSI, Shared SAS).
Во второй конфигурации VHDX-файлы располагаются в общей папке файлового кластера Scale-Out File Server. Последний, замечу, также предполагает наличие CSV-тома. Как видно, и та, и другая конфигурация в итоге приводят к сочетанию хостовой и гостевой кластеризации. Хостовая кластеризация повышает доступность общих VHDX, создаваемый затем поверх гостевой кластер обеспечивает высокую доступность сервисов и приложений внутри ВМ.
Для настройки Shared VHDX прежде всего, конечно, необходимо создать один или несколько VHDX-файлов и расположить их, используя одну из перечисленных выше конфигураций. Затем подключить Shared VHDX можно в консоли Hyper-V, командлетами PowerShell или с помощью сервисного шаблона (service template) в System Center 2012 R2 Virtual Machine Manager.
В консоли Hyper-V это делается путем добавления нового SCSI-диска: в свойствах ВМ выбираете SCSI Controller, затем Hard Drive, нажимаете кнопку Add, указываете путь к VHDX-файлу, после чего выбираете Advanced Features и помечаете соответствующий чекбокс.
Повторяете процедуру для всех ВМ, которые планируется объединить в кластер.
Тоже самое можно сделать в PowerShell следующими командлетами:
New-VHD -Path C:\ClusterStorage\Volume1\Shared.VHDX -Fixed -SizeBytes 30GB
Add-VMHardDiskDrive -VMName Node1 -Path C:\ClusterStorage\Volume1\Shared.VHDX -ShareVirtualDisk
Add-VMHardDiskDrive -VMName Node2 -Path C:\ClusterStorage\Volume1\Shared.VHDX –ShareVirtualDisk
В VMM 2012 R2 в сервисном шаблоне в разделе Hardware Configuration необходимо также добавить SCSI-диск, указать путь к VHDX-файлу и пометить чекбокс Share the disk across the service tier. При развертывании ВМ на основе такого шаблона VMM подключит указанный файл в качестве Shared VHDX.
Какой бы вариант вы не выбрали, внутри ВМ подключенный VHDX будет выглядеть как обычный SAS-диск.
Необходимо помнить следующие требования к Shared VHDX:
Для диагностики возможных проблем в Performance Monitor добавлен новый объект Hyper-V Shared VHDX с набором различных счетчиков, которые вы можете анализировать на хостах Hyper-V.
Кроме того, добавлены новые журналы, просмотр которых возможен, как обычно, с помощью Event Viewer,
либо PowerShell:
Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/Operational
Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/Reservation
Наконец, для целей тестирования, изучения, разработки есть возможность использовать «специальную» конфигурацию Shared VHDX. Для этой конфигурации достаточно одного физического хоста с Windows Server 2012 R2 и поднятой ролью Hyper-V, на котором и можно расположить общие VHDX-файлы, не создавая кластеры с CSV-томами и пр. Чтобы реализовать подобный вариант вам нужно:
Install-WindowsFeature Failover-Clustering
FLTMC.EXE attach svhdxflt D:
Но помните, что это неподдерживаемая конфигурация и применять ее в реальной среде не следует.
Таким образом, механизм общих VHDX-файлов помогает реализовать более эффективную схему гостевой кластеризации и, в конечном итоге, повысить доступность критически важных приложений и сервисов вашей инфраструктуры. Особенно полезной эта технология может оказаться для частных облаков и хостинговых сценариев.
В этом посте я хотел бы дать краткий обзор наиболее интересных новых возможностей Windows Server 2012 R2, отталкиваясь, естественно, от доступной сейчас предварительной версии. На каждую возможность постараюсь потратить буквально несколько предложений, чтобы пояснить ее смысл, оставив детали реализации для последующих публикаций. Таким образом, главная цель – составить у вас общее представление о том, что интересного привнесет новый сервер, а дальше вы уже решите, что из этого наиболее применимо к вашим конкретным задачам. В общем, текста будет много, картинок не будет вообще.
Не смотря на то, что R2 – минорное обновление ОС, новых возможностей очень много. Чтобы как-то упорядочить изложение, я распределил эти возможности по трем группам: изменения в Hyper-V, в сетевом стеке и подсистеме управления хранилищами. По аналогии с тем, как это было сделано в свое время в обзорном курсе по Windows Server 2012. Хотя подобная классификация весьма условна, поскольку многие возможности можно в равной степени отнести сразу к нескольким категориям. Начнем с Hyper-V.
Второе поколение виртуальных машин (Generation 2)
Помимо привычных виртуальных машин (первого поколения) вы можете создавать виртуальные машины нового (второго) поколения. Из этих ВМ удалены многие старые эмулируемые устройства, при этом поддерживается:
Производительность ВМ второго поколения выше, особенно разница заметна при загрузке и установке ОС в ВМ. В качестве гостевых ОС для ВМ второго поколения поддерживаются Windows Server 2012, Windows Server 2012 R2 и 64-битные версии Windows 8 и Windows 8.1.
Удаленное подключение через шину VMBus (Remote Desktop over VMBus)
Если гостевыми ОС являются Windows Server 2012 R2 или Windows 8.1, и в этих ОС запущена служба Remote Desktop Services (RDS), то подключаться к службам RDS гостевых ОС можно не только по сети, но и непосредственно через шину VMBus. Такое подключение происходит, когда вы просто открываете ВМ в консоли Hyper-V. При этом вы получаете все преимущества RDP-сеанса, такие как: выбор разрешения дисплея, поддержка аудио, поддержка буфера обмена (clipboard), перенаправление принтеров, смарт-карт и USB-устройств. Подчеркну, ВМ может быть вообще не подключена к сети.
Автоматическая активация
Если хостом виртуализации является Windows Server 2012 R2 Datacenter, а гостевой ОС любая редакция Windows Server 2012 R2, то такая гостевая ОС активируется автоматически при условии, что хостовая ОС уже активирована. Причем активация гостевых ОС не требует подключения к сети (ни к Интернет, ни к KMS, ни куда-либо еще).
Динамическая миграция (Live Migration)
Во-первых, возможная миграция ВМ с Windows Server 2012 на Windows Server 2012 R2. Речь идет о всех возможных видах live migration, включая shared nothing. Такой вариант миграции упрощает перевод инфраструктуры на Windows Server 2012 R2, поскольку позволяет не останавливать запущенные ВМ. Но надо помнить, что миграция на предыдущую версию, то есть с Windows Server 2012 R2 на Windows Server 2012, не поддерживается.
Во-вторых, динамическая миграция между серверами Windows Server 2012 R2 выполняется по умолчанию с компрессией (может быть отключена) данных, что сокращает нагрузку на сеть и время выполнения миграции.
В-третьих, если на источнике и приемнике установлены сетевые адаптеры с поддержкой RDMA, то динамическая миграция может осуществляться с использованием возможностей этих адаптеров, то есть с применением технологии SMB Direct, что, в свою очередь, еще более чем компрессия ускоряет процесс миграции.
Изменение размеров VHDX-дисков online (VHDX resizing)
В Windows Server 2012 R2 можно увеличивать и уменьшать размер виртуальных жестких дисков, не останавливая ВМ. Online resizing поддерживается только для VHDX-дисков, включая диск с ОС, и только подключенных к SCSI-контроллеру. Функция доступна как в консоли Hyper-V, так и в PowerShell.
Экспорт/клонирование ВМ online (Live VM export/clone)
В Windows Server 2012 R2 можно не выключая ВМ выполнять ее полный экспорт, то есть фактически создавать клон, либо экспортировать требуемый моментальный снимок (snapshot) запущенной ВМ.
Quality of Service для хранилищ (Storage QoS)
Для каждого виртуального жесткого диска ВМ на ходу можно задать максимальное и минимальное значения операций ввода-вывода в секунду (IOPS). Hyper-V будет ограничивать пропускную способность дисков сверху и генерировать оповещения, если дисковая активность ниже заданного минимального порога. Кроме того, обновлена функция resource metering, собирающая статистику по заданной ВМ или группе ВМ. В результаты измерения включены теперь и показатели IOPS.
Общий VHDX-файл (Shared VHDX)
Две и более виртуальных машин могут использовать один общий виртуальный жесткий диск формата VHDX. Эта возможность позволяет строить гостевые кластеры, то есть кластеры, узлами которых являются ВМ. Общий VHDX внутри ВМ представляется как Shared SAS-диск. В принципе, создавать гостевые кластеры можно было и раньше. Но для этого приходилось явным образом подключать ВМ к SAN с помощью, например, iSCSI или Fibre Channel. Однако подобный вариант не вполне оптимален для хостеров, которым в идеале хотелось бы полностью абстрагировать свои СХД от уровня ВМ, то есть скрыть от ВМ особенности реализации хранилища. Теперь такой сценарий легко реализовать. Нет необходимости выделять для очередного гостевого кластера отдельный LUN или CSV-том. Гостевой кластер строится на основе общего VHDX-файла, который можно расположить на CSV-томе физического failover-кластера, либо в общей папке (на шаре) Scale-Out File Server-а. При этом надо иметь в виду, что узлы failover-кластера или Scale-Out File Server-а должны работать под управлением Windows Server 2012 R2. В качестве ОС виртуальных машин, составляющих гостевой кластер, могут выступать как Windows Server 2012 R2, так и Windows Server 2012. В последнем случае необходимо обновить интеграционные компоненты ВМ.
Hyper-V Replica
Два полезных нововведения в механизме репликации ВМ.
Virtual RSS (vRSS)
Технология RSS, при условии, что она поддерживается сетевым адаптером хоста, позволяет обрабатывать входящий сетевой трафик хоста несколькими ядрами доступных физических процессоров. Однако, трафик внутри ВМ по-прежнему обрабатывается одним виртуальным процессором. В Windows Server 2012 R2 благодаря vRSS появилась возможность распределять обработку сетевого трафика по различным виртуальным процессорам ВМ. Это особенно важно в сценариях, когда на хосте запущено немного или вообще одна ВМ, но очень интенсивно обрабатывающая сетевые потоки. Подобная ситуация характерна, например, для различных шлюзов, специализированных устройств на базе Windows Server. Чтобы задействовать vRSS, на хосте доложен быть сетевой адаптер с поддержкой VMQ.
Динамический режим балансировки трафика в NIC Teaming (NIC Teaming Dynamic Mode)
Встроенная в Windows Server 2012 технология NIC Teaming позволяет агрегировать несколько сетевых адаптеров в группу, обеспечивая отказоустойчивость и балансировку сетевого трафика. Балансировка возможна в двух режимах: Hyper-V Port, когда фактически запущенная на хосте ВМ ставится в соответствие некоторому сетевому адаптеру тиминговой группы; Address Hash, когда по сути трафик на конкретный TCP- или UDP-порт (или IP-адрес) направляется через конкретный адаптер группы. В Windows Server 2012 R2 появился еще один режим балансировки – динамический. В этом случае исходящий трафик разбивается на так называемые flowlets и распределяется по всем адаптерам группы. Данный режим позволяет достичь более равномерного распределения трафика по имеющимся сетевым адаптерам. Для примера предположим, что на хосте в тиминг объединены четыре сетевых адаптера, при этом запущены три ВМ. В случае режима балансировки Hyper-V Port, исходящий трафик от ВМ будет передаваться с использованием только трех адаптеров группы (каждая ВМ будет «привязана» к одной сетевушке), в случае динамического режима – с использованием всех четырех.
Расширенные списки управления доступом (Extended ACLs)
В Windows Server 2012 для каждого порта Hyper-V Extensible Switch можно задать ACL, тем самым разрешив или запретив трафик на конкретный MAC-адрес либо IP-адрес, в одну либо в обе стороны. В Windows Server 2012 R2 в настройках ACL появилась возможность дополнительно указать протокол, порт, а также задать признак stateful для, например, расширенного анализа трафика.
Удаленные мониторинг сетевого трафика (Remote Live Monitoring)
Благодаря новым функциям в WMI и ETW появляется возможность удаленного мониторинга сетевого трафика в режиме online, либо сбора информации для последующего offline-анализа. Для этого на свою рабочую станцию вы устанавливаете Microsoft Message Analyzer (следующая версия Network Monitor, сейчас находится в бета-версии) и указываете трафик какого хоста или даже конкретной ВМ на этом хосте вас интересует. Понятно, на хосте предполагается Windows Server 2012 R2, упомянутые расширения WMI и ETW доступны только в этой ОС.
Изменения в Network Virtualization
Я упомяну четыре наиболее важных изменения в технологии виртуализации сети (Network Virtualization, NV).
Управление коммутаторами (Standards Based Switch Management)
Коммутаторы, поддерживающие Open Management Infrastructure (OMI), могут управляться через PowerShell. В Windows Server 2012 R2 добавлен набор командлетов, позволяющих задавать необходимые настройки для свитчей: настраивать VLAN-ы, конкретные порты и пр.
IP Address Management (IPAM)
Модуль для взаимодействия с System Center Virtual Machine Manager позволяет теперь настроить двусторонний обмен информаций между VMM и службой IPAM и аккумулировать в IPAM данные как о физическом, так и виртуальном адресном пространстве.
Поддержка VHDX в iSCSI Target
iSCSI Target Server, который, напомню, является встроенной компонентой серверной ОС, теперь поддерживает формат VHDX со всеми вытекающими последствиями: поддержка файлов размером до 64 ТБ, увеличение/уменьшение размеров VHDX в режиме online и пр. VHDX теперь является форматом по умолчанию для iSCSI Target, реализована полная поддержка SMI-S для управления iSCSI Target с помощью VMM. Немного уклоняясь от темы, замечу здесь, что из консоли System Center 2012 R2 Virtual Machine Manager можно не только настраивать iSCSI-хранилища с поддержкой SMI-S, но и создавать и конфигурировать Scale-Out File Server, причем как из хостов с уже установленной Windows Server 2012 R2, так и bare metal.
Усовершенствования файлового кластера
Файловый кластер в Windows Server 2012 можно настроить в режиме «активный-активный», когда все узлы кластера могут обрабатывать SMB-подключения клиентов к общим папкам (кластерным шарам). Это и есть Scale-Out File Server. Такой режим подразумевает наличие CSV-томов (Cluster Shared Volume), поскольку запросы на чтение/запись в один и тот же файл, хранящийся на общем кластерном хранилище, могут приходить с разных (активных) узлов кластера. CSV как раз и реализует такую возможность. Но для каждого CSV-тома все равно назначается владелец (owner), который отвечает за операции над метаданными (создание, переименование, удаление файлов и т.д.). Представим, что очередной SMB-клиент подключается к кластеру и пытается создать файл. SMB-подключение от клиента обрабатывает конкретный узел кластера, скажем, Node3. Но владельцем тома, где нужно создать файл, является узел Node2. В этом случае происходит перенаправление (SMB Redirect) запроса по сети с Node3 на Node2, и уже последний, как владелец тома, выполняет операцию создания файла. Так вот в Windows Server 2012 все подключения конкретного SMB-клиента обрабатывались одним и тем же узлом кластера, в приведенном примере узлом Node3, что могло порождать большое количество операций перенаправления. В Windows Server 2012 R2 подключения отслеживаются не per server, а per share. Если тот же SMB-клиент подключается к другой шаре кластера, то это подключение может обрабатывать другой узел кластера. Такой подход обеспечивает более оптимальную балансировку нагрузки между узлами кластера. Более того, владение различными CSV-томами, принадлежащими кластеру, теперь автоматически распределяется между узлами кластера, и это распределение изменяется при изменении конфигурации кластера (добавление узла, отработка отказа узла и пр.).
Управление полосой пропускания для SMB-трафика (SMB Bandwidth Management)
В Windows Server 2012 R2 вы можете задать лимит, выраженный в байтах в секунду, для определенного типа SMB-трафика. Таких предопределенных типов пока три: VirtualMachine (трафик между виртуальной машиной и VHDX-файлом, расположенным на файловом SMB-сервере), LiveMigration (трафик динамической миграции, если используется SMB), Default (весь остальной трафик). Лимиты задаются с помощью командлета Set-SMBBandwidthLimit.
Усовершенствования дедупликации
Впервые представленная в Windows Server 2012 дедупликация теперь поддерживается в том числе для открытых файлов VHD/VHDX, для CSV-томов, подключенных к Scale-Out File Server.
Поддержка многоуровневого хранилища в Storage Spaces (Storage Spaces – Storage Tiering)
При создании пулов Storage Spaces в Windows Server 2012 R2 можно объединять в отдельные уровни диски SSD и HDD. Для повышения производительности ОС автоматически размещает на SSD-уровне наиболее востребованные данные, плюс администратор может явным образом указать, какие конкретно файлы необходимо расположить на этом уровне.
Это не все. Как уже говорил, я отобрал наиболее интересные с моей субъективной точки зрения возможности. В дальнейшем о некоторых из них, а также о тех, которые в обзор не вошли, мы поговорим более подробно. Если есть пожелания, о чем рассказать в первую очередь, пишите.
На русском TechNet обновлены шесть основных хабов, посвященных Windows Server 2012, Windows 8, System Center 2012, Windows Azure, платформе данных и вопросам продуктивности. Ссылки на хабы можно увидеть прямо на главной странице TechNet.
На портале TechNet содержится масса технической информации по многочисленным продуктам Microsoft – от документации до форумов и ссылок на блоги. Не всегда особенно новичку просто разобраться в этом многообразии. Поэтому мы решили немного упростить «вход» к этому многообразию, создав так называемые хабы по шести основным продуктам/направлениям.
Каждый хаб группирует информацию по определенному принципу и упрощает навигацию по остальным разделам портала TechNet. Первые четыре упомянутых хаба имеют одинаковую структуру с тремя основными подразделами:
Два последних хаба имеют несколько иное наполнение в силу своей специфики. В «Платформе данных» вы найдете три основных раздела: базы данных, бизнес-аналитика, базы данных в облаке. Таким образом, мы постарались собрать воедино все технологии и решения работы с данными.
Хаб «Продуктивность» отражает офисное направление и аккумулирует информацию по Office 365, Exchange, SharePoint, Lync и Project.
Мы надеемся, подобный вариант подачи информации поможет вам легче ориентироваться и быстрее начать использование той или иной технологии. И конечно, будем обновлять содержимое хабов с учетом выхода Windows Server 2012 R2, System Center 2012 R2, Windows 8.1.
Ровно 10 лет назад я приступил к работе в Microsoft. О своем пятилетии в компании я вспоминал в картинках. Нынешняя дата все-таки более серьезная, поэтому к картинкам я решил добавить немного цифр. :)
Я стал третьим сотрудником офиса MS в Санкт-Петербурге, спустя три месяца нас стало 6 человек, и таким своеобразным «стартапом» мы проработали больше года. А в августе 2003 года я присутствовал в Москве на первой для меня встрече всего отдела по развитию регионального бизнеса, отдела, который отвечал за весь бизнес MS за пределами Москвы. Тогда я насчитал 10 человек. Задачи предстояли непростые, но поддержку я чувствовал с первых шагов. :)
Незадолго до моего прихода Microsoft перешел на новую флагманскую версию своей почтовой системы – Exchange Server 2003. Между прочим, этот переход позволил увеличить размер почтового ящика каждого сотрудника в два раза… со 100 МБ до 200 МБ.
Первый год работы оказался очень запоминающимся. Я впервые попал на обложку альбома…, правда не моего сольного, там многие отметились после очередного team building-а. :)
Трудностей, конечно, хватало. Иногда приходилось буквально балансировать на краю бездны и продираться к цели. :)
Но мы всегда стремились к новым высотам. :)
И, время от времени, таки высот достигали. У меня были награды, чего уж там. :) Но это, безусловно, самая ценная.
Чем я, собственно, занимаюсь? Одна из существенных составляющих моей работы – публичные выступления на семинарах, конференциях, вебинарах и пр. Где я только не выступал: в университетах, ДК, ресторанах, ночных клубах, на теплоходах…, но все по делу. :) Однажды с моим коллегой мы объехали 16 городов России за два месяца. Выступления были разные. Не самые удачные. :)
Технически очень сложные.
Мега-ответственные.
Просто волшебные. :)
Вот, что делают с человеком время и работа в Microsoft. :) Между этими фотографиями ровно десять лет, день в день.
Это были хорошие яркие десять лет. Надеюсь, следующие десять, где бы они не были, получатся как минимум не хуже. А лучше, лучше. :)
Коллеги, приветствую!
Обычно июнь – довольно спокойный месяц в плане мероприятий Microsoft. Я, конечно, не имею в виду крупнейшие TechEd-ы, которые по традиции проходят в июне-июле в США и Европе. Я говорю о локальных мероприятих для ИТ-специалистов. Но, похоже, нынешний июнь – исключение.
18 июня в Москве в отеле “Renaissance Olympic” мы проводим крупную конференцию из серии IT Camp, полностью посвященную Windows 8. Регистрация уже открыта, программа опубликована, мы с Георгием Гаджиевым во всю готовимся к выступлениям. Если есть силы и возможности, приходите, буду рад пообщаться. Кроме привычных докладов и демонстраций будут доступны лабораторные работы по Sideloading приложений, AppLocker-у, возможностям Refresh и Reset для восстановления работоспособности рабочих станций. Если присутствовать лично не сможете, будет организована трансляция, а в дальнейшем мы выложим записи всех выступлений.
Одна из принципиально новых тем, которую я буду затрагивать на Windows 8 IT Camp, это развертывание корпоративных приложений нового типа (приложений Windows Runtime) без подключения к Windows Store, используя такие инструменты как System Center 2012 Configuration Manager SP1 и Windows Intune. Подобный вариант развертывания и называется Sideloading, и вы сможете познакомиться с ним ближе на лабораторных работах.
Второй, не менее важный и интересный набор мероприятий, которые будут проходить только в online, – серия вебинаров по IaaS в Windows Azure. В апреле функционал виртуальных машин и сетей в Windows Azure был запущен в коммерческое использование, и теперь мы постараемся сделать технический обзор имеющихся возможностей и особенностей. Конкретно я провожу два вебинара серии: по сетям 20 июня, и по развертыванию SharePoint в Azure 2 июля.
Смотрите, заходите, пишите.
Коллеги!
Предлагаю вам принять участие в новом конкурсе «Серверное сияние» — совместном проекте Intel IT Galaxy и Microsoft Virtual Academy. Изучите новые технологии, поделитесь своим опытом, и вы сможете выиграть специальные призы от Intel IT Galaxy и MVA.
Период проведения конкурса: с 22 апреля по 14 мая включительно. Победители будут выбраны согласно критериям и объявлены до 22 мая.
Для участия в конкурсе:
Перед написанием поста ознакомьтесь с требованиями к посту в блоге IT Galaxy.
Призы
1 место: автор лучшего блога, прошедший курс на MVA, получит 3000 баллов программы Intel IT Galaxy, которые он может обменять на любой приз из предложенных, либо присоединить к накопленным ранее. А также специальный приз от MVA - наушники Sennheiser HD 518, чтобы греть уши на «серверном» полюсе.
2-е место: мышка и клавиатура Microsoft и админский бубен от Intel IT Galaxy.
3-е место: футболка от MVA и кружка от Intel ITGalaxy.
Все участники конкурса: выполнившие все обязательные условия, получают по 500 баллов программы Intel IT Galaxy и 100 премиальных баллов от MVA.
Желаю удачи!
Добрый день, коллеги!
Хотел бы поделиться с вами последними новостями по нашему публичному облаку Windows Azure.
С 16 апреля сервисы Windows Azure IaaS (Виртуальные машины и виртуальные сети) доступны на коммерческой основе для всех организаций. Ранее пользователи могли работать с ними только в режиме Public Beta Preview.
Вы можете протестировать платформу Windows Azure по ссылке. Полная информация о новых возможностях Windows Azure IaaS представлена на сайте www.windowsazure.com
Вторая важная новость - теперь новый сервис облачного архива Windows Azure Backup доступен в публичном превью (Public Beta Preview)! Сервис предлагает дешевый механизм резервного копирования данных в облако, при этом, первые 5 гигабайт доступны бесплатно! Резервное копирование в облачное хранилище теперь доступно в таких продуктах как Windows Server 2012, Windows Server 2012 Essentials, а также Data Protection Manager из состава System Center 2012 SP1. Ознакомиться с ценами на сервис Windows Azure Backup можно по ссылке.
В прошлый раз я описал концепцию и общую архитектуру Hyper-V Network Virtualization (NV) – технологии Windows Server 2012, обеспечивающей виртуализацию на уровне сетевого сегмента. Сегодня речь пойдет о настройке этой технологии с помощью PowerShell и System Center 2012 SP1 Virtual Machine Manager (VMM).
На хосте с развернутой ролью Hyper-V доступно несколько командлетов PowerShell, с помощью которых выполняется настройка требуемой конфигурации NV. Основных командлета четыре:
Как обычно для PowerShell, существуют аналогичные команды с префиксами Get-, Set-, Remove- для получения текущих параметров, изменения и удаления соответственно.
Еще пара командлетов, Get-NetVirtualizationGlobal и Set-NetVirtualizationGlobal позволяют определить (и, соответственно, задать), используется ли внешний Gateway для маршрутизации трафика.
Самый простой способ познакомиться с перечисленными командлетами – изучить и попробовать применить в тестовой среде два скрипта-примера, разработанных моими коллегами. Каждый скрипт содержит детальные комментарии, описание моделируемой среды и указание на те переменные и константы, которые вам необходимо заменить на собственные значения. Найти и скачать скрипты можно здесь:
Проверял лично, работает. :) Но, думаю очевидно, что в масштабах ЦОД-а манипуляция подобными скриптами превращается в крайне сложную задачу. Поэтому далее гораздо более детально я рассмотрю настройку NV с помощью VMM.
Технология NV является частью Hyper-V в Windows Server 2012. System Center поддерживает Windows Server 2012, начиная с версии System Center 2012 SP1. Здесь и далее речь идет о VMM именно из System Center 2012 SP1. Я предполагаю, что VMM уже развернут, хосты Hyper-V в него добавлены, поэтому буду обращать внимание только на те настройки, которые непосредственно связаны с NV.
Настройка NV с помощью VMM состоит из следующих шагов:
Рассмотрим последовательно каждый шаг.
Вручную
Напомню, что правила, определяющие работу NV, задаются в так называемой политике виртуализации. Определенные настройки, заданные в политике виртуализации, непосредственно к сетевым пакетам применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Этот фильтр необходимо включить на тех хостах Hyper-V, на которых планируется использовать NV. Вручную это делается в свойствах физического сетевого адаптера хоста. Подчеркиваю, именно физического адаптера, а не виртуального, который, как правило, создается при настройке внешнего свитча Hyper-V.
С помощью Logical Switch
В качестве альтернативы ручной настройке можно использовать появившийся в VMM 2012 SP1 механизм логических свитчей (Logical Switch). Более подробное описание настроек сети в VMM можно найти вот в этом посте Георгия Гаджиева. Здесь же кратко упомяну, что логический свитч необходим для того, чтобы применить заданный набор настроек к сетевым адаптерам и свитчам Hyper-V Extensible Switch на множестве хостов. Найти описанные ниже настройки можно в разделе «Fabric», подразделе «Networking» консоли VMM. Фактически в логическом свитче можно задать три группы настроек: настройки для физических сетевых адаптеров хостов, настройки для виртуальных сетевых адаптеров ВМ (а точнее, для портов Hyper-V Extensible Switch, к которым ВМ подключаются) и настройки для расширений (extensions) Hyper-V Extensible Switch.
Первая группа настроек, а именно она нас больше всего интересует, задается путем создания специального профиля, который называется Uplink Port Profile. В профиле необходимо установить чекбокс, показанный на рисунке, благодаря которому и будет в дальнейшем включен фильтр WNV.
Вторая группа настроек задается путем создания профиля, который называется Virtual Adapter Port Profile. В этом профиле нет настроек, напрямую связанных с NV, но именно там можно задать различные параметры безопасности свитча (например, DHCP Guard), производительности (например, IP Sec offload), ограничения трафика (Quality of Service).
Ну а далее при создании логического свитча можно указать необходимые расширения для Hyper-V Extensible Switch, выбрать Virtual Adapter Port Profile и, самое главное, добавить Uplink Port Profile, в котором мы пометили чекбокс «Enable Windows Network Virtualization».
Тем самым, мы создали некоторый набор настроек в виде логического свитча. Остается применить созданный логический свитч к требуемым хостам Hyper-V, а как следствие, применятся к хостам и все настройки этого логического свитча. Для этого в консоли VMM в свойствах хоста переходим на закладку Virtual Switches, нажимаем «New Virtual Switch», затем «New Logical Switch» и выбираем нужный логический свитч. Проверяем, что для требуемого физического сетевого адаптера применяется тот самый Uplink Port Profile.
Следующий шаг – включение NV для требуемых логических сетей (Logical Networks). Логические сети в VMM позволяют администратору описать физическую сетевую топологию ЦОД-а. Это описание в дальнейшем помогает существенно упростить подключение ВМ к требуемым сетевым сегментам. Похожим образом администратор Active Directory (AD) с помощью сайтов и подсетей описывает физическую сеть предприятия для оптимизации трафика репликации AD. Применительно же к NV логические сети VMM не просто описывают реальную сетевую топологию, но и определяют пространство PA-адресов, которые будут использоваться для передачи пакетов между ВМ на разных хостах.
Итак, представим себе, что в физической сети используется IP-адресация из диапазона 192.168.1.0/24. Нам же необходимо поверх этой сети виртуализовать сети двух компаний ОАО «Синие» и ОАО «Красные». Причем обе компании используют одинаковый диапазон IP-адресов, а именно: 10.0.0.0/24.
Создаем логическую сеть (кнопка меню «Create Logical Network») и на первом же экране разрешаем для этой сети NV:
На следующем экране создаем сайт и указываем, какие группы хостов могут этот сайт использовать (фактически в нем располагаются) и какие IP-подсети этому сайту принадлежат.
Теперь для этой логической сети необходимо создать пул IP-адресов. В контексте NV именно из этого пула VMM будет выделять PA-адрес и ассоциировать с ВМ и настроенными внутри них CA-адресами. В консоли VMM нажимаем «Create IP Pool», задаем имя пула и на следующем экране указываем для какого сайта и какой IP-подсети создаем пул.
Затем необходимо задать диапазон IP-адресов и, если требуется, какие-то адреса зарезервировать. Например так:
На последующих экранах можно указать адрес шлюза по умолчанию, а также адреса серверов DNS и WINS. Теперь, когда логическая сеть создана и настроена, остается указать, какие конкретно хосты Hyper-V будут с ней ассоциированы, или иными словами, на каких хостах могут быть запущены ВМ, требующие доступ к этой сети. В свойствах хостов на закладке «Hardware» надо выбрать сетевой адаптер хоста и пометить соответствующую логическую сеть.
На предыдущих шагах мы включили фильтр WNV и настроили логическую сеть с пулом IP-адресов, который будет использоваться для выделения PA-адресов. Таким образом, мы подготовили физическую инфраструктуру или, в терминологии VMM, подготовили Fabric. Теперь поверх этой инфраструктуры можно создавать и виртуализовывать произвольные сети клиентов нашего ЦОД-а. В рассматриваемом сценарии этими клиентами, как вы помните, являются компаний ОАО «Синие» и ОАО «Красные», использующие одинаковую подсеть 10.0.0.0/24.
С выходом SP1 для System Center 2012 в VMM появился новый тип объектов – сеть виртуальных машин (VM Network), далее просто «сеть ВМ». В первую очередь, этот тип объектов предназначен для NV, хотя, как вы увидите в дальнейшем, даже если NV не используется, как минимум одну сеть ВМ создать необходимо. Ну а в нашем случае, очевидно, нужно создать две сети ВМ для «Синих» и «Красных» соответственно. Процесс этот очень похож на создание логической сети – мы создаем сеть ВМ, определяем в ней один или несколько сайтов с указанием подсетей, затем создаем для подсетей пулы IP-адресов. Но эти пулы уже будут использоваться для выделения CA-адресов виртуальным машинам.
Итак, в консоли VMM переходим в раздел «VMs and Services» и нажимаем кнопку «Create VM Network». В первом окне задаем имя создаваемой сети и выбираем из списка логическую сеть, поверх которой будет работать данная сеть ВМ.
Следующий шаг весьма важный. Коль скоро мы настраиваем NV, выбираем верхний пункт. Он будет доступен для выбора только в том случае, если для логической сети, указанной на предыдущем шаге, была включена поддержка NV, что мы уже сделали.
Но здесь же хотел бы обратить ваше внимание на вторую опцию «No Isolation». Если выберем ее, то укажем тем самым VMM, что виртуальные машины этой сети должны напрямую (без изоляции) подключаться к логической сети. Никаких дополнительных настроек в этом случае уже не потребуется. Создаваемые затем ВМ буду получать IP-адреса из пулов, настроенных непосредственно в логической сети. То есть опцию «No Isolation» вы выбираете в том случае, когда технология NV вам не нужна. И поэтому закономерно, что для каждой логической сети можно создать только одну сеть ВМ без изоляции.
Мы же двигаемся дальше и в следующем окне создаем подсеть (одну или несколько), которая требуется клиенту.
На завершающем экране мастера выбираем способ взаимодействия ВМ создаваемой сети с внешним миром. Поскольку мы не настраивали специально внешний шлюз (об этом речь пойдет в следующем посте), то выбор здесь один – «No Connectivity», означающий, что ВМ смогут взаимодействовать только в пределах этой сети ВМ.
Последняя задача данного этапа – настроить для созданной сети ВМ пулы адресов, то есть CA-адреса. В консоли VMM выбираем сеть ВМ и нажимаем «Create IP Pool». На первом экране проверяем, что указаны нужные сеть ВМ и подсеть:
На втором задаем диапазон IP-адресов для ВМ:
Указываем шлюз по умолчанию:
При необходимости задаем далее адреса серверов DNS и WINS. Сеть «Красных» настроена. Повторяем процедуру для ОАО «Синие» и в результате получаем вот такую картину:
Настройка собственно виртуализации сети на этом завершена. Если вспомнить концепцию и архитектуру NV, описанные мною в предыдущем посте, то становится понятно, что VM Network соответствует термину Customer Network, а VM Subnet – термину Virtual Subnet. Действительно, если с помощью командлетов Get-SCVMNetwork и Get-SCVMSubnet получить информацию о созданных только что нами объектах, то в отклике первого командлета среди прочего вы увидите Routing Domain ID (RDID), а второго – Virtual Subnet ID (VSID).
Остается создать шаблоны ВМ для каждой сети, и на их основе можно будет развертывать требуемое количество «Синих» и «Красных» ВМ.
Процедура создания шаблонов для ВМ, которые будут использовать NV, совершенно стандартная и по сути ничем не отличается от создания шаблонов для любых других ВМ. Единственное, на что надо обратить внимание, что виртуальный сетевой адаптер подключен к нужной сети ВМ. Например, для шаблона «Красных» эта настройка выглядит следующим образом:
Параметр «Static IP» указывает VMM на то, что при создании ВМ по этому шаблону необходимо выделить статический IP-адрес из пула, связанного с сетью Red_VMnet01. А поскольку для этой сети включена технология NV, то выделенный адрес будет CA-адресом. Кроме того, в процессе развертывания виртуальной машины VMM выделит из пула, связанного с соответствующей логической сетью, PA-адрес, ассоциирует пару CA-адрес / PA-адрес и пропишет необходимые строчки в политику виртуализации того хоста, на котором будет развернута ВМ. Если в ЦОД-е используется динамическая адресация, то IP-адреса могут выделяться не из пулов VMM, а из скопов DHCP-сервера, и в этом случае в шаблоне ВМ необходимо выбрать параметр «Dynamic IP».
Теперь все полностью готово, и можно разворачивать ВМ на основе подготовленных шаблонов. Нажимаем кнопку «Create Virtual Machine» и выбираем нужный шаблон.
Если все перечисленные шаги проделаны без ошибок, то для эксперимента можно создать пару «Красных» и пару «Синих» ВМ на одном или нескольких физических хостах Hyper-V и убедиться в том, что полученные ВМ работают с адресами из сети 10.0.0.0/24, возможно даже IP-адреса «Синих» и «Красных» полностью совпадают, но при всем при этом «Красные» видят друг друга и полностью изолированы от «Синих».
Давайте посмотрим, как выглядит отклик одного из упомянутых в начале поста командлетов в моей тестовой среде. Ниже фактически изображена политика виртуализации на одном из хостов:
В частности видно, что машине Red-Web1 был выделен CA-адрес 10.0.0.2 (первый доступный адрес в пуле) и ассоциирован с PA-адресом 192.168.1.52. ВМ принадлежит подсети с VSID=15184632 и относится к Customer Network с идентификатором RDID={206146EB-F035-4A19-A625-054C49DEEBD7}.
Еще один очень интересный параметр «Rule» со значением «TranslationMethodEncap» говорит о том, что для виртуализации IP-адресов используется механизм NVGRE. Этот механизм применяется по умолчанию при настройке NV в VMM и рекомендуется для большинства сценариев виртуализации сети. Можно проверить работу механизма инкапсуляции, сделав c машины Red-Web1 ping на адрес 10.0.0.3 и посмотрев сетевым монитором на структуру передаваемых пакетов.
Во-первых, можно наблюдать, что пинги передаются в виде GRE-пакетов между хостами с PA-адресами 192.168.1.52 и 192.168.1.53. Во-вторых, в заголовке GRE указано, что внутри лежит пакет некоторого протокола с номером 0x6558 (выделен на рисунке синим), каковым и является стандарт NVGRE. В-третьих, по спецификации NVGRE следующие 24 бита (обведены красным) содержат VSID. Действительно, если 0xE7B2F8 перевести в десятичный вид, получим VSID=15184632, что является подсетью «Красных».
Таким образом, мы настроили и выполнили проверку работоспособности технологии Hyper-V Network Virtualization. Однако пожалуй, это не более чем лабораторные испытания, поскольку мы не обеспечили взаимодействие ВМ с внешним миром. О том, как это выглядит с архитектурной точки зрения и как настраивается, поговорим в следующем посте.
А пока вы можете:
В Windows Server 2012 появилась технология виртуализации сети (Network Virtualization, NV), обеспечивающая возможность виртуализации на принципиально новом уровне – уровне сетевого сегмента. В отличие от привычной серверной виртуализации NV позволит вам виртуализовать IP-подсети и полностью скрыть от виртуальных машин (ВМ) и приложений внутри ВМ реальную IP-адресацию, используемую в вашей инфраструктуре. При этом ВМ по-прежнему могут взаимодействовать между собой, с другими физическими хостами, с хостами в других подсетях.
С технологической точки зрения виртуализация сети представляет собой довольно сложный механизм, поэтому сделать более-менее полный обзор этой технологии в рамках одного поста, пожалуй, не удастся. Сегодня обсудим концепцию и архитектуру, в следующем посте я сосредоточусь на настройке NV, затем отдельно погорим об организации внешнего доступа к ВМ, запущенным в виртуализованной сети.
Начнем с основополагающего вопроса: «Для чего нужна виртуализация сети?»
В случае серверной виртуализации с небольшими оговорками ОС внутри ВМ работает так, как если бы была установлена на физический сервер и являлась единственной ОС на этом оборудовании. Подобная абстракция позволяет запускать несколько изолированных экземпляров виртуальных серверов на одном физическом. По аналогии виртуализация сети приводит к тому, что виртуальная, а точнее в данном контексте виртуализованная сеть, функционирует так, как если бы она являлась физической сетью. Соответственно, данный уровень виртуализации позволяет создавать и использовать несколько виртуальных сетей, возможно с перекрывающимися или даже полностью совпадающими пространствами IP-адресов, на одной физической сетевой инфраструктуре. И эта сетевая инфраструктура, вообще говоря, может включать в себя произвольное количество физических серверов и сетевого оборудования (см. рис. ниже).
На приведенном рисунке виртуальные машины из синей сети и красной сети, принадлежащих разным департаментам или организациям, могут использовать одни и те же IP-адреса, могут быть запущены на одном и том же или разных физических хостах, но при этом с одной стороны, они будут полностью изолированы друг от друга, и, с другой стороны, при этом будут безо всяких проблем взаимодействовать с другими сетевыми объектами (реальными или виртуальными) своего департамента или своей организации. Отсюда вытекают назначение технологии NV, преимущества и основные сценарии ее применения.
Большая гибкость в размещении ВМ в пределах ЦОД
NV предоставляет определенную свободу при размещении ВМ в рамках ЦОД. В частности, размещение ВМ предполагает настройку IP-адреса, соответствующего физическому сегменту сети, и настройку VLAN для обеспечения изоляции. Коль скоро NV допускает сосуществование на одном хосте ВМ с совпадающими IP-адресами, мы более не связаны применяемой в ЦОД схемой IP-адресации и не упираемся в ограничения, накладываемые VLAN.
Упрощенный перенос ВМ в облако
Поскольку при использовании виртуализации сети IP-адрес и конфигурация ВМ остаются неизменными, это значительно упрощает процесс переноса ВМ в соседний ЦОД организации, в облако хостера или публичное облако. И клиенты приложения, и ИТ-администраторы продолжают использовать свои инструменты для взаимодействия с ВМ/приложением без переконфигурации.
Динамическая миграция (Live Migration) за пределы подсети
Динамическая миграция ВМ ограничена пределами IP-подсети (или VLAN-ами). Если мигрировать ВМ в другую подсеть, потребуется перенастройка IP внутри гостевой ОС со всем вытекающими последствиями. Однако если динамическая миграция выполняется между двумя хостами с Windows Server 2012 с включенной NV, то хосты могут располагаться в различных сегментах физической сети, при этом виртуализация сети обеспечит непрерывность сетевых коммуникаций перемещаемой ВМ.
Повышенная утилизация ресурсов физических хостов и сетей
Отсутствие зависимости от IP-адресации и VLAN-ов позволяет более равномерно загружать физические хосты и более эффективно утилизировать имеющиеся ресурсы. При этом следует отметить, что NV поддерживает VLAN, и вы можете сочетать оба способа изоляции, например, изолировав трафик NV в выделенном для этих целей VLAN-не.
При настройке NV с каждым виртуальным сетевым адаптером (vNIC) ассоциируется пара IP-адресов:
В процессе сетевого взаимодействия ВМ формирует пакет с адресами отправителя и получателя из пространства CA. Такой пакет покидает ВМ и хостом Hyper-V упаковывается в пакет с адресами отправителя и получателя из пространства PA. Адреса PA определяются на основе таблицы политики виртуализации. После этого пакет передается по физической сети. Хост Hyper-V, получивший пакет, на основе все той же таблицы политики виртуализации выполняет обратную процедуру: извлекает исходный пакет, определяет ВМ-получателя и перенаправляет исходный пакет с адресами CA нужной ВМ.
Таким образом, виртуализация сети, в конечном счете, сводится к виртуализации адресов, используемых виртуальными машинами. В свою очередь, виртуализация адресов в Hyper-V Windows Server 2012 возможна с помощью двух механизмов: Generic Routing Encapsulation и IP Rewrite. Рассмотрим кратко каждый их них.
В первом механизме исходный пакет c CA-адресами инкапсулируется в структуру GRE (Generic Routing Encapsulation, см. RFC 2890), которая упаковывается в IP-пакет с необходимыми PA-адресами. В заголовок GRE добавляется также уникальный идентификатор виртуальной подсети (Virtual Subnet ID, поле «Ключ GRE» на рис.), которой принадлежит исходный пакет, и МАС-адреса виртуальных сетевых адаптеров ВМ отправителя и получателя.
Идентификатор подсети позволяет хосту-получателю правильно определить ВМ, для которой предназначен пакет, даже в случае возможного совпадения CA-адресов в ВМ разных заказчиков. Вторая важная особенность данного механизма заключается в том, что вне зависимости от количества запущенных на хосте ВМ достаточно одного PA-адреса для передачи пакетов от любых ВМ. Это существенным образом влияет на масштабируемость решения при использовании GRE-механизма виртуализации адресов. Наконец надо отметить, что описанная схема полностью совместима с имеющимся сетевым оборудованием и не требует какого-либо обновления сетевых адаптеров, коммутаторов или маршрутизаторов.
Однако в перспективе было бы совсем не лишним, чтобы свитч или роутер могли анализировать поле Virtual Subnet ID пакета, и администратор мог бы настраивать соответствующие правила для коммутации или маршрутизации пакетов на основе этого поля. Или например, чтобы все задачи, связанные с упаковкой-распаковкой GRE, брал на себя сетевой адаптер. С этой целью Microsoft совместно с партнерами разработали стандарт NVGRE – Network Virtualization using Generic Routing Encapsulation, находящийся сейчас в стадии IETF Draft. В частности, в рамках этого стандарта регламентируется 24-битное поле Tenant Network Identifier (TNI) для хранения идентификатора подсети, тип протокола 0x6558, указывающий на NVGRE-пакет, и другие нюансы.
Второй механизм по своей идеологии несколько проще. Каждому CA-адресу ставится в соответствие уникальный PA-адрес. Когда пакет покидает ВМ, хост Hyper-V заменяет в заголовке IP-пакета CA-адреса на PA-адреса и посылает пакет в сеть. Принимающий хост выполняет обратную замену адресов и доставляет пакет ВМ. Как следует из описанного алгоритма, на каждом физическом хосте с ролью Hyper-V необходимо сконфигурировать столько PA-адресов, сколько CA-адресов используется во всех запущенных на данном хосте виртуальных машинах, использующих виртуализацию сети.
Инкапсуляция пакетов с помощью GRE требует дополнительных накладных расходов. Поэтому для сценариев с высокими требованиями к пропускной способности канала, например, для ВМ активно использующей 10Gbps-адаптер, как и раз и рекомендуется IP Rewrite. Для большинства же остальных случаев оптимальным является механизм GRE. Ну а с появлением оборудования, поддерживающего NVGRE, этот механизм не будет уступать IP Rewrite и в производительности.
В терминологии Hyper-V Network Virtualization заказчик – это «владелец» группы ВМ, развернутых в ЦОД. На практике, если речь идет о ЦОД-е провайдера хостинговых услуг, таким заказчиком может быть какая-либо компания или организация. Если говорим о частном облаке, то заказчиком, как правило, выступает департамент или отдел организации. В любом случае заказчик может владеть одной или несколькими сетями (Customer Network), и каждая такая сеть состоит из одной или нескольких виртуальных подсетей (Virtual Subnet).
Customer Network
Virtual Subnet
Применение этих двух понятий позволяет заказчику переносить свою сетевую топологию в облако. На рис. ниже изображены две сети компании «Синие» - сеть R&D и сеть отдела продаж. Изначально эти сети изолированы и не должны взаимодействовать между собой. Поскольку при переносе в среду Hyper-V Network Virtualization этим сетям присвоены различные RDID, ВМ этих сетей не могут «видеть» друг друга. При этом, например, ВМ из виртуальных подсетей 1, 2 и 3 сети R&D могут обмениваться пакетами.
NV доступна только в Windows Server 2012.
На хостах с Hyper-V Network Virtualization должна поддерживаться политика виртуализации, в которой собственно задается и хранится информация о пространствах CA и PA, идентификаторах RDID и VSID, применяемых механизмах виртуализации адресов. Windows Server 2012 содержит набор программных интерфейсов (API), с помощью которых ПО может управлять всеми аспектами NV. Таким управляющим ПО в самом простом случае могут быть скрипты PowerShell, в промышленном сценарии эту роль выполняет System Center 2012 Virtual Machine Manager SP1 (VMM). Обращаю внимание, что именно с выходом SP1 в System Center 2012 появилась поддержка Windows Server 2012, а стало быть и NV.
Настройки, заданные в политике виртуализации, непосредственно применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Фильтр WNV располагается ниже Hyper-V Extensible Switch. Это означает, что коммутатор Hyper-V и все его расширения (если таковые имеются) работают с CA-адресами и ничего не знают о PA-адресах. Однако VSID-ы доступны коммутатору и расширениям, поэтому Hyper-V Extensible Switch способен различать, например, CA-адреса 10.0.0.5, принадлежащие разным заказчикам.
Если для ВМ включается виртуализация сети, то для портов Hyper-V Extensible Switch, к которым подключены виртуальные сетевые адаптеры этой ВМ, гипервизор включает списки управления доступом (Access Control List, ACL). Подробнее об ACL я рассказывал здесь. В ACL указывается VSID виртуальной подсети, которой принадлежит ВМ. Любые пакеты, приходящие на данный порт свитча, с VSID, отличным от заданного в ACL, игнорируются.
Приняв эту логику во внимание, перемещение пакетов выглядит следующим образом. Исходящий от ВМ пакет через порт Hyper-V Extensible Switch попадает в фильтр WNV, который анализирует политику виртуализации NV и применяет к пакету необходимые операции (замена IP-адреса или упаковка в GRE), после чего пакет отправляется в сеть.
На принимающей стороне входящий пакет попадает в фильтр WNV, который анализирует политику виртуализации NV. Если входящий пакет – пакет GRE, фильтр считывает из GRE-заголовка поле VSID, извлекает исходный IP-пакет и передает его вместе с VSID на тот порт Hyper-V Extensible Switch, к которому подключен vNIC виртуальной машины с CA-адресом, соответствующим адресу получателя в заголовке исходного IP-пакета. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине. Если используемый механизм виртуализации – IP Rewrite, фильтр на основе информации из политики виртуализации меняет PA-адреса в пакете на CA-адреса, все по тем же парам PA- и CA-адресов определяет VSID и пакет с уже CA-адресами вместе с VSID направляет на соответствующий порт Hyper-V Extensible Switch. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине.
Описанная логика применяется, когда пакет передается между ВМ, расположенными на одном или разных хостах с Windows Server 2012 и поднятой ролью Hyper-V. Ситуация несколько усложнится, если пакет из ВМ, в которой, например, запущено некое бизнес-приложение, должен добраться до рабочей станции с клиентской частью этого бизнес-приложения. В этом случае нам потребуется настроить Hyper-V Network Virtualization Gateway, о чем мы поговорим отдельно.
В следующем посте я расскажу, как настроить NV с помощью: 1) скриптов PowerShell, 2) VMM.
11 марта я вместе с Гошей Гаджиевым провожу однодневную конференцию “Новые возможности Частного облака от Microsoft”. Приглашаю тех из вас, кто хотел бы, но не сможет посетить мероприятие лично, присоединиться к online-трансляции, которая будет организована на сайте TechNet. Начало трансляции в 10:15.
Мы поговорим о том, что собой представляет частное облако, как его реализовать с помощью Windows Server 2012 и System Center 2012 SP1, что нового появилось в компонентах System Center 2012 с выходом Service Pack 1.
Программа мероприятия выглядит следующим образом (транслироваться online будут все доклады):
Приходите или подключайтесь, буду рад!
Технология Windows To Go (WTG) – одна из новых возможностей Windows 8 – позволяет создать должным образом сконфигурированный имидж ОС с установленным необходимым ПО, который будет загружаться непосредственно с USB-носителя в независимости от того, какая ОС установлена на компьютере, к которому подключается данный USB-носитель. В рамках поста кратко обсудим возможные сценарии применения WTG, настройку и некоторые особенности использования.
Прямым результатом применения технологии WTG является загрузочный USB-носитель (флэшка или внешний HDD), на котором располагается полностью готовая к использованию ОС Windows 8. «Полностью готовая» означает, что эта ОС должным образом сконфигурирована в соответствии с требованиями организации: включена в домен, если необходимо, к ней применены групповые политики, включая политики безопасности, патчи, настроены технологии удаленного доступа (VPN/DirectAccess), установлен требуемый набор ПО и т.д. Такой носитель достаточно подключить к любому компьютеру, совместимому с Windows 7 или Windows 8, и загрузиться прямо с него. При этом вы получаете вашу персональную ОС со всеми настройками и никак не влияете на ОС, установленную непосредственно на жесткий диск данного компьютера.
Соответственно, WTG относится к корпоративным возможностям Windows 8, то есть ориентирована на использование, в первую очередь, на предприятии. Наиболее очевидные сценарии применения WTG:
Этот список, конечно, можно расширить. Также очевидно, что все перечисленные выше сценарии могут быть реализованы другими способами, без WTG. Однако, наличие дополнительного варианта в виде WTG может стать неплохим подспорьем для ИТ-отдела организации.
Сначала рассмотрим аппаратные требования, которые существуют как для USB-носителей, так и для хостов, к которым носители будут подключаться.
Требования к носителю
Чтобы решение было поддерживаемым, необходимо использовать носители, сертифицированные для WTG. На момент написания поста согласно информации с портала TechNet в список сертифицированного оборудования входят:
На практике я использовал, например, полутерабайтный Seagate FreeAgent GoFlex с USB 3.0, не входящий в данный список. Технических проблем не было никаких, но надо помнить, что во-первых, устройство должно быть USB 3.0, во-вторых, раз HDD не является сертифицированным, то в случае проблем обращаться в техподдержку Microsoft не стоит.
Требования к хосту
Любой компьютер, сертифицированный для Windows 7 или Windows 8. Но опять же, с практической точки зрения можно говорить о любой не сильно устаревшей x86 или x64 системе с USB 2.0 и выше и с возможность загрузки с USB-устройства.
Варианты развертывания WTG
Можно выделить три основных варианта развертывания WTG:
Поддерживаемые редакции Windows 8
Какой бы вариант развертывания вы не выбрали, вам потребуются wim-файлы, содержащие сконфигурированные имиджи ОС и необходимое ПО. Внутри wim-файла должна быть Windows 8 Enterprise. Другие редакции не поддерживаются. Кроме того, мастер Windows To Go Creator Wizard также есть только в Windows 8 Enterprise, поэтому именно эта редакция рекомендуется для машины, на которой вы планируете создавать WTG.
Создание имиджа с помощью Windows To Go Creator Wizard
Предполагая, что хотя бы один wim-файл у вас уже есть, и необходимый USB-носитель подключен, рассмотрим по шагам создание WTG с помощью мастера. Настройку с помощью командной строки можно посмотреть здесь. Найти мастер можно нажав Win+W и набрав “Windows To Go”.
На первом экране выбираем нужный носитель.
С помощью кнопки “Add search location” указываем папку с wim-файлом (-ами).
Мастер анализирует и отображает найденные имиджи.
На следующем экране можно включить шифрование носителя с помощью BitLocker.
Все готово для создания WTG, остается нажать “Create”.
Создание имиджа занимает некоторое время. В моем случае wim-файл имел объем примерно 3 GB, располагался на SSD-диске, время создания носителя WTG составило 12 минут.
На последнем экране мастер предлагает изменить порядок загрузки вашего компьютера с тем, чтобы в следующий раз машина грузилась с USB.
Собственно, это все. Остается загрузиться с подготовленного носителя и начать работу.
Есть ряд особенностей WTG, которые следует иметь в виду при эксплуатации технологии.
При первой загрузке с WTG-носителя на некотором компьютере происходит определение оборудования и установка соответствующих драйверов. Этот процесс, разумеется, занимает какое-то время. Однако система запоминает конфигурацию для данного компьютера и последующие загрузки на нем происходят без задержек.
По соображениям безопасности, по умолчанию, локальный жесткий диск компьютера, на котором мы загрузились с помощью WTG, находится в состоянии offline, и доступ к разделам этого диска запрещен. Данная настройка может быть изменена. Кроме того, если у пользователя есть административные права на компьютер, он может вручную перевести диск в online и получить доступ к разделам.
По тем же соображениям в обратной ситуации, когда, работая за компьютером, вы подключаете WTG-носитель, Windows монтирует этот носитель без присвоения литер разделам носителя. Таким образом, в Windows Explorer WTG-устройство не видно.
При запуске на новом железе Windows должна быть активирована. Напомню, WTG позиционируется как корпоративная возможность, поэтому предполагается, что в организации настроен сервис KMS или активация через Active Directory (новая возможность Windows Server 2012), и тогда для пользователя процесс активации пройдет незамеченным.
При использовании WTG доступны все возможности Windows, кроме Windows Store. Сделано это, поскольку покупки в Windows Store привязываются к конкретному компьютеру, и соответствующие приложения отключаются при запуске на другой машине. Тем не менее, если необходимо, чтобы Windows Store был доступен, можно включить его для имиджей WTG через групповую или локальную политики: \\Computer Configuration\Administrative Templates\Windows Components\Store\.
Последнее замечание связано с настройкой загрузки компьютера с USB-носителя. Если нужно, чтобы пользователь самостоятельно мог изменить порядок загрузки компьютера без залезания в BIOS или нажатия какой-то волшебной комбинации клавиш, можно воспользоваться специальной утилитой, присутствующей в любой редакции Windows 8. Найти ее можно уже известным способом, нажав Win+W и набрав “Windows To Go”.
Выберите нужный пункт, и при очередном рестарте система начнет загрузку с USB.
Таким образом, WTG – простой и безопасный способ создания управляемого мобильного образа Windows 8 для ваших сотрудников.
Дополнительную информацию о технологии Windows To Go можно получить в докладе «Обзор технологии Windows To Go: новые возможности, сценарии применения и способы развёртывания в корпоративной среде» конференции TechEd Russia 2012.
Возможности Active Directory в Windows Server 2012, включая активацию через AD, рассматриваются в первом модуле курса «Новые возможности Windows Server 2012. Часть 2. Безопасность, управление, удаленный доступ, веб-платформа» на портале MVA.
В рамках этого поста я хотел бы обсудить изменения, которые претерпела технология BranchCache в Windows Server 2012 и Windows 8. Принцип работы и архитектура технологии уже обсуждались в одном из предыдущих постов, поэтому в основном сосредоточусь на новых возможностях и усовершенствованиях.
Тем не менее, буквально в двух словах о том, что собой представляет BranchCache на случай, если вы впервые сталкиваетесь с этой технологией. BranchCache – технология кэширования данных, передаваемых по протоколам SMB, HTTP/HTTPS. Соответственно, BranchCache используют в филиалах и удаленных офисах для сокращения трафика, передаваемого по WAN-каналам, и для повышения скорости отклика приложений при работе с данными, расположенными на удаленных серверах.
Две важные характеристики BranchCache, выделяющие ее на фоне других технологий кэширования:
Для использования BranchCache файловый сервер или веб-сервер должны располагаться на Windows Server 2008 R2 или Windows Server 2012, на клиентских компьютерах должна быть установлена одна из следующих ОС: Windows 7 Enterprise, Windows 7 Ultimate или Windows 8 Enterprise.
Все изменения в BranchCache в Windows Server 2012 и Windows 8 можно сгруппировать по трем направлениям: производительность, управление, масштабируемость. Рассмотрим последовательно каждое направление.
Производительность
Изменился принцип разбиения исходных файлов на блоки для вычисления метаданных (хэша для каждого блока). Если раньше файл разбивался на блоки равного размера (64 KB), то теперь границы блоков для каждого файла определяются на основе метода Rabin fingerprint.
Что это дает? Предположим, на странице веб-сайта есть некая картинка размером 100 KB. Эту же картинку вставляют в документ, который сохраняется на файловой шаре. При обработке и страницы сайта, и документа с помощью fingerprint границы блоков будут расставлены таким образом, что картинка и там, и там будет выделена в отдельный блок размером 100 KB. И поскольку содержимое этих блоков в обоих случаях одинаковое, будут совпадать и хэши этих блоков (например, ID2 на рисунке выше). Пользователь из филиала впервые обращается к веб-странице, и она поблочно скачивается с веб-сайта и помещается в кэш. Теперь если тот же или другой пользователь данного филиала открывает с удаленной шары упомянутый документ, то содержимое документа также поблочно скачивается с файлового сервера, за исключением картинки, блок с которой уже находится в филиале.
Следует добавить, что точно такой же алгоритм определения границ блоков используется службой дедупликации Windows Server 2012. Поэтому если раздел, на котором располагается содержимое веб-сайта и/или файловой шары, дедуплицирован, то файлы на блоки уже разбиты, хэши уже вычислены, и BranchCache использует эти метаданные, не проводя повторные разбиения/вычисления.
Управление
Ранее фактически приходилось для каждого филиала создавать свой GPO для настройки BranchCache на клиентах филиала. Это особенно верно, если в филиале применялся выделенный кэш-сервер (hosted cache), поскольку именно в GPO указывалось имя этого сервера, и клиенты, таким образом, понимали, где располагается выделенный кэш.
Hosted cache сервер под управлением Windows Server 2012 может регистрировать Service Connection Point (SCP) в Active Directory. Клиенты с Windows 8 Enterprise, обращаясь к AD, используют SCP для обнаружения кэш-сервера, причем сервера ближайшего к ним, то есть расположенного в том же сайте AD. Это, в свою очередь, позволяет потенциально иметь всего один GPO для настройки всех BranchCache-клиентов организации.
Традиционно для Windows Server 2012 и Windows 8 весь спектр задач администрирования BranchCache – установка, настройка, проверка статуса – можно реализовать с помощью PowerShell, что я тоже отношу к плюсам. В Windows 7, например, для проверки статуса или сброса кэша необходимо было использовать менее дружелюбный Netsh. Возвращаясь к hosted cache, установка необходимых компонентов BranchCache, конфигурация сервера в качестве кэш-сервера и регистрация SCP осуществляется двумя командлетами:
Install-WindowsFeature BranchCache –IncludeManagementTools
Enable-BCHostedServer –RegisterSCP
После чего, запустив Get-BCStatus, необходимо убедиться в том, что два параметра в секции HostedCacheServerConfiguration имеют значение True.
Чтобы клиенты с Windows 8 использовали SCP для поиска кэш-сервера, в GPO необходимо включить новый параметр Enable Automatic Hosted Cache Discovery by Service Connection Point.
Замечу, что если вместе с этим параметром включен параметр Set BranchCache Distributed Cache mode, то клиент сначала пытается через SCP обнаружить и использовать hosted cache, а если это не удается, то переключается в режим distributed cache.
Во многих сценариях было бы полезно иметь возможность заранее закэшировать определенные данные, например, обновляемые в конце каждой недели отчеты, с тем чтобы в понедельник утром свежие отчеты уже располагались в кэше филиалов. Теперь это можно реализовать следующими командлетами:
Publish-BCFileContent 'D:\Branch Documents' -StageData
Export-BCCachePackage -Destination D:\Temp
Первая строчка генерирует метаданные для файлов в указанной папке и добавляет блоки данных этих файлов в так называемый пакет данных (data package) для последующего экспорта. Аналогичный командлет для веб-сайта называется Publish-BCWebContent. Вторая строчка собственно экспортирует набор хэшей и блоки данных в архивный файл со стандартным именем PeerDistPackage.zip в указанную директорию. Структура архива выглядит следующим образом:
Полученный в результате экспорта архив любым доступным образом копируется на требуемые кэш-серверы в филиалы, где импортируется с помощью:
Import-BCCachePackage -Path D:\Temp\PeerDistPackage.zip
Таким образом, мы получаем «разогретый» кэш.
Последнее нововведение, которое я хотел бы отметить в контексте управления, заключается в том, что кэшированные данные по умолчанию хранятся в зашифрованном виде. От администратора более не требуются никакие дополнительные телодвижения, как то: включение BitLocker, настройка EFS и пр., для обеспечения безопасности кэша. Также не требуется настройка сертификата на hosted cache сервере, что еще более разгрузит и без того занятого сисадмина. J Правда сертификат все-таки понадобится, если к кэш-серверу будут обращаться клиенты с Windows 7.
Масштабируемость
Филиал филиалу рознь. После появления BranchCache в Windows Server 2008 R2 и Windows 7 мы столкнулись со сценариями использования технологии в филиалах с количеством сотрудников в несколько тысяч и объемом кэша в сотни гигабайт. Исходная реализация BranchCache не была оптимизирована для таких масштабов. Теперь BranchCache в качестве хранилища использует Extensible Storage Engine (ESE), позволяя обрабатывать терабайты данных.
Кроме того, если раньше можно было сконфигурировать только один hosted cache сервер на филиал, то теперь, в частности за счет SCP, такого ограничения нет. Вы можете масштабировать кэш филиала как вертикально за счет движка ESE, так и горизонтально, развертывая столько кэш-серверов, сколько необходимо.
В целом, мне кажется, изменения весьма интересны. Ряд новых настроек (см. п. New BranchCache Group Policy settings по ссылке) BranchCache в групповых политиках помогут обеспечить корректную работу в одном филиале клиентов Windows 7 и Windows 8. И, стало быть, поводов не использовать технологию становится еще меньше.
Получить дополнительную информацию по этой и другим возможностям Windows Server 2012 и Windows 8 вы можете, просмотрев бесплатные курсы на портале Microsoft Virtual Academy:
В канун длинных новогодних и рождественских праздников мы опубликовали три новых курса на портале Microsoft Virtual Academy, два из них посвящены Windows Server 2012, третий – System Center 2012.
Новые возможности Windows Server 2012. Часть 2. Безопасность, управление, удаленный доступ, веб-платформа
Курс представляет собой продолжение первой части и завершает технически обзор Windows Server 2012. В четырех модулях рассматриваются следующие технологии:
Миграция на Windows Server 2012. Часть 1
При миграции всегда всплывает много нюансов и подводных камней, в первой части курса мы постарались обозначить некоторые из них:
Обзор System Center 2012 Orchestrator
Данный курс рассказывает о таком компоненте System Center 2012, как Orchestrator, его возможностях, а также о функциональной роли в семействе System Center 2012, и в реализации частного облака с помощью семейства System Center.
Надеюсь, вы найдете что-то интересное и полезное для себя!
Но на самом деле, хотелось бы поздравить всех с наступающими праздниками и пожелать поменьше находиться у компьютеров в эти новогодние дни и побольше времени посвятить своим близким и родным. Счастливого Нового года!
За последние несколько недель портал Microsoft Virtual Academy пополнился несколькими новыми бесплатными курсами по Windows Server 2012. Эти курсы более детально рассматривают ряд вопросов, затронутых в техническом обзоре операционной системы.
Windows Server 2012: серверная виртуализация
Windows Server 2012: сетевая инфраструктура
Windows Server 2012: системы хранения данных
Windows Server 2012: управляемость и автоматизация
До нового года планируется публикация еще нескольких курсов, если что-либо не нарушит наши планы…