Hyper-V Replica и катастрофоустойчивость?

Hyper-V Replica, впервые появившаяся в Windows Server 2012, представляет собой механизм асинхронной репликации ВМ. В минимальной конфигурации для работы Hyper-V Replica необходимы два хоста с поднятой ролью Hyper-V, связанные каким-либо каналом передачи данных. После настройкирепликации для выбранной ВМ на целевом хосте создается копия этой ВМ (в выключенном состоянии), и далее с исходного хоста с определенным интервалом передаются изменения, происходящие в оригинальной ВМ. В Windows Server 2012 интервал репликации составляет 5 мин., в Windows Server 2012 R2 – может быть выбран из трех допустимых значений: 30 сек., 5 мин., 15 мин.

В случае недоступности оригинальной ВМ вследствие падения хоста или любых других проблем, администратор инициирует переключение на реплику. На целевом хосте при этом запускается реплицированная ВМ, после чего остается переключить клиентов на эту ВМ, у которой может быть другой IP, другие настройки VLAN и пр. При подобном незапланированном сбое (unplanned failover) в силу асинхронной репликации возможны потери данных (с момента последней репликации до момента сбоя). Мы также можем использовать запланированное переключение на реплику (planned failover), например, для выполнения каких-либо задач сервисного обслуживания на исходном сервере или в основном сайте. В этом случае Hyper-V Replica гарантирует передачу всех изменений с момента последней репликации, прежде чем остановит оригинальную ВМ и запустит реплицированную.

Построение катастрофоустойчивых решений – одно из главных применений Hyper-V Replica. Действительно, никаких специальных требований к оборудованию хостов нет, все делается средствами Windows Server. Специальных требований к каналу связи тоже нет. Его толщина определяется количеством и объемом реплицируемых ВМ и частотой репликации. Оценку различных параметров для конкретной конфигурации можно сделать с помощью Capacity Planner for Hyper-V Replica. Но есть несколько принципиальных моментов, которые надо иметь в виду:

• Hyper-V обеспечивает переключение с оригинальной ВМ на реплику и, если необходимо, в обратную сторону. Но не содержит никаких инструментов для переключения клиентов (нагрузки) на ВМ.
• Hyper-V выполняет мониторинг участников репликации. Но в отличие от Failover Clustering он не содержит какой-то встроенной логики автоматической отработки сбоя, например, если связь с основной площадкой потеряна. Решение о переключении должен принимать администратор.
• Даже если мы подготовили скрипты для автоматического переключения, (командлеты PowerShell для управления Hyper-V Replica, конечно, имеются), эти скрипты необходимо где-то хранить и в час «Х» откуда-то запускать. По канонам надежности это «где-то» не должно быть ни основным сайтом, ни резервным. Нужна третья точка – наблюдатель или оркестратор.

Azure Site Recovery (ASR)

Набор облачных служб Azure Site Recovery (ранее Azure Hyper-V Recovery Manager) изначально как раз и задумывался как такой оркестратор процессов репликации и переключения в случае запланированных или незапланированных простоев.

Для обеспечения катастрофоустойчивости нам необходимо как минимум:

• Обеспечить связь Azure с основным и резервным сайтами, эти каналы связи и будут использоваться для мониторинга состояния защищаемых объектов
• Указать, какие ВМ необходимо защищать с помощью репликации, каковы параметры репликации
• Создать план восстановления (recovery plan), в котором отразить все необходимые шаги по переключению на резервный сайт, включая последовательность запуска ВМ в резервном ЦОД, возможные скрипты и последовательность их запуска и пр.

Архитектура такого решения выглядит следующим образом:

Обратите внимание, что каналы связи с Azure используются для настройки, мониторинга и управления при переключении между площадками. Трафик же репликации передается не через облако, а по тем каналам между ЦОД-ами, которые у вас используются.

Благодаря ASR, у нас есть третья точка наблюдения/оркестрации, высокую доступность которой обеспечивает Microsoft. Более того, вам не нужно сначала настраивать репликацию на хостах. После того как настроен канал связи Azure – ЦОД, прямо на портале управления Azure вы сможете увидеть информацию о ваших частных облаках, хостах и ВМ и отсюда же настроить репликацию. Канал Azure – ЦОД защищается с помощью сертификатов, поддерживается настройка подключения через proxy-серверы, причем применительно к вашей инфраструктуре эти подключения являются исходящими. Наконец, план восстановления позволяет описывать логику failover, включая запуск скриптов, которые могут выполнять самый широкий спектр задач – от открытия портов до изменения параметров виртуальной машины. Все составляющие плана восстановления, в том числе скрипты, также хранятся в Azure, чем обеспечивается их высокая доступность. Выражаясь образно, настроив Azure Site Recovery, мы получили «аварийную кнопку», нажать которую и тем самым запустить процесс восстановления можно из любой точки, где есть Интернет.

Описанная выше архитектура подразумевает наличие у организации минимум двух ЦОД-ов. Коль скоро речь идет об использовании Hyper-V Replica, предполагается, что средой виртуализации управляет System Center Virtual Machine Manager (VMM). Так вот в самой первой реализации Azure Site Recovery связь между Azure и ЦОД представляла собой связь между Azure и VMM, для чего на VMM устанавливался специальный провайдер. С помощью провайдера VMM сообщает Azure о конфигурации физической и виртуальной среды и получает от Azure запросы мониторинга и команды управления, например, с заданными администратором параметрами репликации, которые VMM применяет к необходимым хостам Hyper-V и ВМ.

Несколько площадок и обязательное использование VMM, очевидно, ограничивало сферу применения Azure Site Recovery. Недавние обновления этого сервиса позволяют теперь реализовать новые сценарии. Давайте посмотрим на них.

Сценарии использования Azure Site Recovery

На момент написания статьи доступны следующие варианты использования Azure Site Recovery для защиты ваших ВМ.

1. On-premises Hyper-V site to Azure protection with Hyper-V replication. Репликация ВМ с одного или нескольких серверов Hyper-V в Azure. VMM не требуется.
2. On-premises VMM site to on-premises VMM site protection with Hyper-V replication. Репликация ВМ между хостами или сайтами, управляемыми VMM. Это изначально реализованный вариант, который мы рассмотрели выше.
3. On-premises VMM site to on-premises VMM site protection with SAN replication. Репликация ВМ между кластерами Hyper-V, управляемыми VMM. В отличие от предыдущих сценариев, здесь репликация выполняется не с помощью Hyper-V Replica, а с помощью механизмов, предоставляемых SAN. Этот сценарий предназначен, в первую очередь, для организаций, которые уже используют аппаратную репликацию СХД.
4. On-premises VMM site to Azure protection. Репликация ВМ с одного или нескольких серверов Hyper-V, управляемых VMM, в Azure. Похож на первый сценарий, но применяется, если локально развернут VMM.
5. On-premises VMware site to on-premises VMware site with InMage. Репликация между сайтами VMware с использованием компоненты InMage Scout.

Более детально эти варианты и соответствующие требования к локально инфраструктуре описаны здесь. Мы же далее посмотрим на простой пример реализации 4-го сценария – репликация ВМ, управляемой VMM, в облако Microsoft Azure.

Репликация ВМ между сайтом VMM и Microsoft Azure

Я не буду описывать процесс настройки репликации. Если инфраструктура VMM развернута, частные облака созданы, ВМ запущены, вы можете воспользоваться очень неплохим пошаговым руководством здесь. Отмечу лишь несколько важных моментов.

Во-первых, поддерживается только последняя версия VMM – System Center 2012 R2 Virtual Machine Manager, при этом на хостах, которыми он управляет, может использоваться как Windows Server 2012, так и Windows Server 2012 R2. Много полезной информации по миграции с более старых версий моно найти вот в этойподборке материалов.

Во-вторых, репликацию в Azure можно настроить только для ВМ первого поколения (Generation 1), причем не важно, используют они в качестве виртуальных жестких дисков файлы VHD или VHDX.

Настройка репликации начинается с создания на портале управления Azure так называемого recovery vault – хранилища, которое будет содержать все настройки Azure Site Recovery, включая планы восстановления, но не реплики ВМ. Последние, как и любые другие ВМ в Azure, создаются в учетных записях хранения (storage accounts). Для учетной записи хранения, которая будет использоваться под реплику, должна быть включена опция гео-репликации, и располагаться эта учетная запись должна в том же регионе (location), что и recovery vault.

После установки провайдера на VMM и агентов на хосты Hyper-V, на портале Azure вы увидите информацию обо всех созданных в VMM облаках. Защиту необходимо сначала включить для облака,

а затем для необходимых ВМ в этом облаке.

Иными словами, ВМ, которые вы хотите реплицировать в Azure, должныбыть ассоциированы с облаками VMM.

При настройке репликации конкретной ВМ мастер предложит шаблон ВМ в Azure (target size), наиболее подходящий для защищаемой машины. Хотя этот параметр вы можете изменить по своему усмотрению. В моем примере для двухъядерной машины с 4 ГБ ОЗУ был предложен шаблон D2. Замечу, защищаемая ВМ использует динамическую память, 4 ГБ – это максимальный объем в настройках динамической памяти. Именно на него ориентируется Azure при выборе шаблона.

В нижней части рисунка вы видите еще одну принципиальную настройку – network mapping. С помощью этого механизма вы фактически указываете, к какой виртуальной сети Azure подключит реплицированную ВМ, когда произойдет плановый или внеплановый failover. В параметрах этой виртуальной сети как минимум задается адресное пространство, в данном примере 10.2.1.0/24. Но кроме этого, можно настроить VPN-туннель между данной виртуальной сетью и вашей инфраструктурой. Тогда после failover ВМ в Azure сможет взаимодействовать через туннель с другими машинами вашей сети. Конечно за исключением ситуации, когда туннель связывал Azure с тем самым датацентром, который мы потеряли после сбоя.

Хотелось бы еще раз подчеркнуть, что после установки провайдера и агентов, все действия по настройке осуществляются на портале Azure. После того, как вы настроили репликацию, можно проверить, что на всех хостах Hyper-V защищаемого облака действительно включилась Hyper-V Replica (по умолчанию она выключена), и изменения регулярно реплицируются в Azure. Проверить это можно как на портале Azure по журналам в разделе JOBS, вот один из примеров:

Так и непосредственно в консоли Hyper-V на хосте, где запущена защищаемая ВМ:

Последний важный момент – это план восстановления. В моем самом простом демонстрационном сценарии это план выглядит вот так:

Есть всего одна группа ВМ – Group 1, которой принадлежит всего одна защищаемая ВМ – Web-App01. Если запустить это план на выполнение, то Azure попытается:

1. Выключить все ВМ в группе (при незапланированном сбое этот шаг скорее всего выполнить не удастся, так как связь с ЦОД-ом наверняка потеряна)
2. Выполнить failover, то есть указать, что реплика теперь становится основной машиной
3. Запустить ВМ в группе.

В более сложном сценарии приложение, которое мы в конечном итоге защищаем с помощью репликации, может быть распределено по нескольким ВМ – front-end, back-end и т. д. Эти ВМ при failover требуется запускать в определенной последовательности, для чего их необходимо распределить по соответствующим группам в созданном плане восстановления. Может потребоваться выполнение дополнительных задач, например, открытие портов, по которым пользователи будут подключаться к ВМ. Для этого в нужное место плана восстановления можно добавить заготовленные скрипты.

Наконец, реальные ситуации могут быть сколь угодно сложные, и полностью автоматизировать процесс переключение на резервные ВМ не удастся. Какие-то шаги потребуют вмешательства ИТ-персонала. В план восстановления можно добавить такие «ручные» действия.

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

Предположим, план восстановления полностью готов, что дальше? Дальше крайне рекомендуется выполнить тестирование отработки сбоя. Большим плюсом Hyper-V Replica является то, что такое тестирование вы можете выполнить, не нарушая уже настроенный процесс репликации. Операция Test Failover фактически создает снимок реплицированной ВМ и на его основе создает и запускает копию реплицированной ВМ с именем Имя_ВМ-Test. Эту ВМ имеет смысл подключить к изолированному сегменту сети и проверить, как себя ведет приложение внутри, как к нему смогут подключиться тестовые клиенты и пр. При этом собственно репликация между оригинальной и реплицированной ВМ продолжается. Ровно такую же возможность предоставляет Azure Site Recovery при репликации ВМ в облако Microsoft. Мы можем создать в Azure некоторую тестовую виртуальную сеть, затем выбрать план восстановления, нажать внизу кнопку TEST FAILOVERи выбрать сеть, к которой будет подключена копия реплицированной ВМ.

Когда создание ВМ завершится, мы сможем выполнить все необходимые проверки и тесты. О завершении тестирования мы должны оповестить Azure, нажав The test failover is complete, после чего тестовая ВМ будет автоматически удалена.

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

И я всячески желаю, чтобы для последнего варианта нажимать на нее вам так и не потребовалось бы.

Дополнительная информация:

· Обеспечение катастрофоустойчивости и высокой доступности приложений и сервисов

· Справочник по ресурсам миграции с Windows Server 2003/R2

Давайте представим себе довольно распространенный на сегодняшний день сценарий. В корпоративной сети развернуто некоторое количество бизнес-приложений. Эти приложения опубликованы для доступа снаружи по HTTPS. Мобильные сотрудники компании, находясь за пределами корпоративной сети, хотят подключаться к этим приложениям со своих личных планшетов, работающих под Windows, iOS или Android. Эти устройства либо невозможно включить в домен, либо пользователи просто не будут этого делать. Как повысить безопасность доступа с таких устройств к корпоративным приложениям? Помочь может служба регистрации устройств (Device Registration Service, DRS) в Windows Server 2012 R2.

В этой статье я сосредоточусь на основных принципах и архитектуре DRS. Детали настройки можно посмотреть в четвертом модуле курса «Корпоративные устройства. Как управлять гибридными учетными данными».

В чем основная проблема?

Внутри корпоративной сети есть веб-приложение с доступом по HTTPS, опубликованное для подключения снаружи. С любой платформы из любого браузера подключились, весь трафик между браузером и приложением шифруется, чего еще желать. Но при всех очевидных преимуществах современных мобильных устройств, планшетов в частности, есть и обратная сторона. То, что везде удобно носить с собой, легко может быть потеряно или украдено. Любой новый «владелец» устройства любопытства ради или же по злому умыслу может попытаться «поизучать» URLs в history браузера. И при сохраненных cookies, которые наверняка используются на личных устройствах, получить доступ в том числе к приложениям организации не составит труда.

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

Одно из решений – использование DRS из состава Windows Server 2012 R2.

В чем основная идея?

Как следует из названия службы, DRS реализует процедуру регистрации устройства. В процессе регистрации DRS генерирует X.509-сертификат, который загружается на устройство, а также создает в Active Directory новый объект, содержащий информацию как об устройстве, так и пользователе, выполнившем регистрацию.

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

Но важно отметить несколько моментов:

1. Процедура регистрации максимально проста и не требует предварительной настройки устройства ИТ-специалистом.
2. DRS поддерживает различные платформы:
   1. Windows 8.1 и выше
   2. iOS 6 и выше
   3. Android – Samsung KNOX
   4. Windows 7 Pro (включенная в домен)
3. DRS не требует развертывания PKI

Как это выглядит?

В Windows Server 2012 R2 служба DRS устанавливается вместе с ADFS. ADFS, как видно из рисунков выше, играет ключевую роль в процессе аутентификации. Чтобы воспользоваться сервисом регистрации для приложения необходимонастроить аутентификацию через ADFS. Поскольку по соображениям безопасности сервер с ADFS как правило располагают внутри корпоративной сети, в зоне периметра нужна проксирующая компонента, которая будет принимать запросы из Интернет и перенаправлять их ADFS. Роль прокси может выполнять Web Application Proxy (WAP) – новая служба Windows Server 2012 R2. ADFS, в свою очередь, выполняет аутентификацию пользователя и, если настроена регистрация устройств, проверку сертификата. В случае успешной аутентификации ADFS формирует маркер (token) доступа для запрашиваемого приложения и возвращает маркер браузеру на пользовательском устройстве. После чего пользователь получает доступ к приложению.

Если говорить о требованиях к инфраструктуре, то для использования DRS необходимо расширить схему AD и иметь как минимум один сервер с Windows Server 2012 R2 и поднятой ролью ADFS.

Процесс регистрации устройства изображен на следующем рисунке.

Давайте посмотрим, как выглядит этот процесс с точки зрения владельца планшета с Windows 8.1, и что при этом происходит за кадром. В роли корпоративного приложения будет выступать SharePoint 2013. В моей инфраструктуре ADFS настроена таким образом, что регистрация устройств требуется, только если устройство находится за пределами корпоративной сети. Если же планшет подключен, например, к корпоративному Wi-Fi, то достаточно аутентификации по логину и паролю пользователя. И, конечно же, от пользователя вообще ничего не требуется, если он обращается к приложению с доменного компьютера в корпоративной сети. Имеет место полноценный Single Sign-On. Возможность настройки подобных условий доступа (conditional access), причем для конкретного приложения – еще одно серьезное преимущество использования ADFS для рассматриваемого сценария. Как задаются политики conditional access, можно посмотреть в упомянутом четвертом модуле курса «Корпоративные устройства. Как управлять гибридными учетными данными».

Итак, сотрудник компании находится за пределами компании и в браузере планшета, не включенного в домен, набирает URL корпоративного портала SharePoint. Запрос через WAP перенаправляется ADFS, и мы видим такую картину.

Как видно, элементы страницы аутентификации ADFS, равно как и страниц сообщений об ошибках (картинка, логотип, тексты сообщений), настраиваются. Пользователь указывает логин и пароль своей доменной учетной записи, причем логин вводится в формате User Principal Name (UPN). Так как устройство пока не зарегистрировано, в доступе отказано.

В тексте сообщения об ошибке я указал действия, которые необходимо совершить пользователю для регистрации планшета. Эти действия отличаются для разных платформ. Так для iOS надо просто пройти по URL: https://<имя adfs-сервера>/enrollmentserver/otaprofile. Для Windows 8.1 регистрация предусмотрена в интерфейсе ОС: PC Settings->Network->Workplace. И называется Workplace join.

Нажав на кнопку Join, увидим уже знакомое окно аутентификации ADFS.

Каким образом Windows 8.1 обнаруживает ADFS? Из введенного пользователем UPN берется суффикс, в данном случае, contosomsspb.com, к нему пристыковывает предопределенное имя, enterpriseregistration и получается FQDN, enterpriseregistration.contosomsspb.com, которое ОС пытается разрешить в IP. Соответственною, чтобы такой механизм обнаружения DRS работал, необходимо зарегистрировать в публичном DNS-домене организации A record с именем enterpriseregistrationи IP-адресом пороксирующей компоненты, например, сервера WAP.

Если пароль введен верно, то выполняется регистрация устройства, и мы возвращаемся в предыдущее окно, где можно заметить, что операция Workplace joinзавершена.

Что же происходит за кадром? На самом планшете с помощью оснастки Certificates можно обнаружить появление нового сертификата.

Именно он и будет теперь использоваться в качестве второго фактора аутентификации при подключении к приложению.

В Active Directory соответствующий сертификату объект можно найти в новом контейнере RegisteredDevices. Имя объекта совпадает с CN сертификата. Атрибуты этого объекта можно посмотреть, например, с помощью ADSI Edit.

Среди атрибутов мы найдем имя устройства, тип и версию ОС, SID пользователя, выполнившего регистрацию, дату и время регистрации и др.

Пробуем снова подключиться к порталу, снова попадаем на страницу ADFS, снова вводим credentials учетной записи AD. Но теперь помимо проверки пароля успешно завершается и проверка сертификата, и доступ к приложению получен.

Более того, после первого успешного подключения пользователь получает SSO для этого приложения. Он может закрыть браузер, перезагрузить машину, открыть браузер снова, набрать URL и… получить доступ к приложению безо всяких дополнительных вопросов. Действительно, cookies обеспечивают первый фактор аутентификации, сертификат – второй. Естественно, не навечно, и периодически пользователю придется подтверждать свою аутентичность вводом пароля. Но это срок контролирует ИТ.

Дополнительные соображения безопасности

Давайте вернемся к ситуации с утерей/кражей планшета. Если устройство уже зарегистрировано, для приложения реализован SSO, и устройство попало в чужие руки. Первая линия защиты – пароль или PIN-код для входа в устройство. Для недоменных устройств обязательную блокировку можно включить, например, через Microsoft Intune или другое MDM-решение. Если этого не было сделано? Получается, мы дали злоумышленнику дополнительные козыри – ему остается просто открыть браузер и набрать URL. Очевидно, в такой ситуации владелец должен как можно быстрее оповестить свою службу ИТ. Что тогда предпримет ИТ? Посмотрим на несколько вариантов.

Если сервис регистрации устройств вообще не используется.

1. Можно запретить доступ учетной записи пользователя к опубликованным приложениям. Но что, если он в длительной поездке, и ему нужен доступ к приложению с другого устройства (основного ноутбука, второго планшета и пр.)?
2. Можно сбросить пользователю пароль. Но не всегда очевидно, как это отразится на доступе к другим сервисам.

Оба решения, а также другие варианты, которые можно предложить, вполне применимы, но не идеальны.

Если устройство было зарегистрировано.

Администратору достаточно найти в AD объект, ассоциированный с утерянным устройством и либо удалить объект, либо в его свойствах для атрибута msDS-IsEnabled задать значение FALSE.

Тогда при подключении к приложению сертификат устройства не пройдет проверку, и пользователь получит сообщение об ошибке. Таким образом, мы блокируем доступ конкретному устройству.

Ну а если пароль пользователя скомпрометирован и стал известен злоумышленнику? Ничто не помешает ему выполнить повторную регистрацию. Один из вариантов противодействия такому сценарию – использование сервиса многофакторной аутентификации (MFA) Microsoft Azure для регистрации устройства. В этом случае при регистрации устройства пользователю кроме ввода пароля необходимо будет пройти дополнительную проверку – ответить на входящий звонок на его мобильный телефон, либо ввести полученный по SMS код, либо использовать специальное приложение (Multi-Fator Auth), которое опять же есть в online store Microsoft, Google и Apple.

Но это уже тема отдельного разговора.

Итак, сервис регистрации устройств, появившийся в Windows Server 2012 R2, поможет обеспечить дополнительный уровень безопасности при удаленном подключении к корпоративным приложениям с личных мобильных устройств, не включенных в домен AD и работающих под управлением различных ОС.

Детали по установке и настройке ADFS и DRS можно найти, например, здесь:

https://blogs.technet.com/b/keithmayer/archive/2013/11/08/why-r2-step-by-step-solve-byod-challenges-with-workplace-join.aspx

Особенности настройки для устройств iOS, создание политик условного доступа, развертывание WAP и пр.:

https://technet.microsoft.com/en-us/library/dn280939.aspx

Главная идея

Давайте представим себе, что мобильным сотрудникам организации необходим доступ к определенном набору бизнес-приложений. В идеале из любого места, где бы они не находились, и с любого устройства, какая бы операционная система на нем не использовалась. Пожалуй, максимальное приближенное к идеалу решение мы получим, развернув терминальный сервер, установив на нем необходимые приложения и опубликовав их средствами службы Remote Desktop Services. RDP-клиент сейчас доступен для всех основных платформ: Android, iOS, Windows, Windows Phone, поэтому практически можно говорить о «любом устройстве». Ну а для «любого места» сделаем оговорку – любое, где есть подключение к Интернет. Такое решение знакомо и понятно ИТ-специалистам, обеспечивает необходимый уровень безопасности, поскольку серверы и приложения контролируются и обновляются централизованно, наконец, оно достаточно универсально.

Но у всего есть обратная сторона. Очевидными недостатками предложенного подхода могут стать стоимость и масштабируемость. В зависимости от сложности и ресурсоёмкости публикуемых приложений и количества пользователей, которые к ним подключаются, может понадобиться не один сервер, а несколько, да с хорошей СХД, и цена вопроса может поставить крест на всей красивой задумке. Но даже если мы имеем/приобрели нужные мощности, сможем ли при необходимости обслуживать большее количество пользователей/приложений? Как быстро можно увеличить ёмкость решения и, опять же, за какую цену?

Теперь давайте представим, что описанное решение реализовано не в локальной ИТ-инфраструктуре организации, а в облаке; масштабируется по запросу, причем очень быстро; обеспечивает SLA; оплачивается по потреблению. Ровно это и предлагает услуга (сервис) Microsoft Azure RemoteApp. С технической точки зрения в Microsoft Azure поднимается одна или несколько ВМ с Windows Server 2012 R2 и ролью RDS. Образ, на основе которого создаются ВМ, готовите вы у себя в локальной сети. В этот образ вы добавляете нужные вам приложения и загружаете образ в Microsoft Azure. Таких образов можно создать столько, сколько необходимо. На портале управления Microsoft Azure останется указать, какие приложения сделать доступными (опубликовать) и для кого (дать доступ пользователям организации). А если в качестве публикуемых бизнес-приложений выступают компоненты Microsoft Office, то и образ готовить не надо, Microsoft Azure сделает все за вас. Звучит заманчиво? Давайте посмотрим, как это работает.

Варианты развертывания

Существует два варианта развертывания Microsoft Azure RemoteApp: облачное и гибридное.

В случае облачного развертывания поднимаемые в Microsoft Azure ВМ никак не связаны с вашей локальной инфраструктурой. Ну, почти никак. То есть подразумевается, что бизнес-приложения внутри ВМ для своей работы не требуют локальной Active Directory, либо каких-то других компонент локальной сети.

Возникает вопрос, какие пользователи смогут подключаться к опубликованным таким образом приложениям? Как видно из рисунка, для аутентификации можно использовать Microsoft account, либо записи локальной Active Directory. В последнем случае некая связь с локальной инфраструктурой все же имеется, и она предполагает синхронизацию каталога AD организации с Microsoft Azure. Как настраивается такая синхронизация я подробно описываю во втором модуле курса «Корпоративные устройства. Как управлять гибридными учетными данными».

При использовании облачного варианта развертывания вы можете загрузить в Azure свой образ ВМ с установленными приложениями или выбрать готовый образ. На момент написания статьи в Microsoft Azure RemoteApp доступны два готовых образа: с Windows Server 2012 R2 и с Windows Server 2012 R2 и предустановленными приложениями Office 365 (у вас должна быть подписка на Office 365). Ваш образ вы обновляете самостоятельно, для готового образа поддерживается автоматическое обновление (сервис-паки, фиксы и пр.).

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

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

Облачное развертывание приложений Office 365

Теперь давайте предположим, что нам необходим удаленный доступ к офисному пакету, и шаг за шагом выполним облачное развертывание Microsoft Azure RemoteApp. Это самый простой и наглядный способ познакомиться с новым сервисом облака Microsoft.

Облачное развертывание состоит из 4 шагов:

1. Создание коллекции RemoteApp (RemoteApp collection)
2. Настройка синхронизации Active Directory (необязательно)
3. Публикация приложений
4. Конфигурация доступа пользователей

Создание коллекции RemoteApp (RemoteApp collection)

Заходим на портал управления Microsoft Azure, выбираем раздел REMOTEAPP, в левом нижнем углу нажимаем NEW.

Для облачного развертывания выбираем QUICK CREATE (CREATE WITH VPN, соответственно, для гибридной модели). Необходимо указать имя создаваемой коллекции, выбрать регион, план и образ. В данном случае выбран готовый образ с предустановленным Office 365.

План доступен двух видов, базовый и стандартный. Базовый предполагает запуск сравнительно легких приложений, например, веб-приложений, интерфейсных приложений для ввода данных и пр. Стандартный план лучше подойдет для более тяжеловесных приложений, например, Microsoft Office. Планы отличаютсяпо цене и максимальному количеству подключаемых пользователей, 400 пользователей для базового плана, 250 – для стандартного.

Создание коллекции занимает около получаса. Как только в колонке STATUSвы увидите значение “Active”, коллекцией можно начинать пользоваться.

Настройка синхронизации Active Directory (необязательно)

Напомню, что для облачного варианта развертывания можно использовать аутентификацию на основе Microsoft Account, либо доменных учетных записей. В последнем случае необходимо настроить синхронизацию локальной AD и Azure Active Directory. Не буду сейчас подробно останавливаться на этом процессе, детали можно посмотреть здесьили в упомянутом выше курсе по управлению гибридными учетными данными.

Публикация приложений

Щелкаем по созданной коллекции и на странице Quick Start видим дальнейшие шаги, которые необходимо предпринять.

На рисунке видно, что и публикация, и конфигурация доступа уже выполнены. Это связано с тем, что при развертывании коллекции мы выбрали готовый образ. Как следствие, мастер Microsoft Azure поднял ВМ, опубликовал офисные приложения и предоставил к ним доступ учетной записи, от имени которой производилось развертывание.

Тем не менее, вы всегда можете перейти в раздел PUBLISHINGи просмотреть/изменить список опубликованных приложений.

Конфигурация доступа пользователей

Точно также в разделе USER ACCESSесть возможность отредактировать список пользователей, которым предоставлен доступ к приложениям. В моем примере я добавил одного пользователя из синхронизированного каталога AD.

Вот в общем-то и все! Остается проверить, что приложение действительно доступно и корректно работает. Для этого по ссылкена нужное устройство скачивается клиент для соответствующей платформы…

… и запускается.

Щелкнув Get Started, вводим в окне аутентификации нужные учетные данные и видим список доступных приложений.

Запустив любое из них, например Excel, видим подключение по RDP, а затем окно приложения, которое практически ничем (ну кроме иконки) не отличается от приложений на самом устройстве, хотя запущено в RDP-сеансе из облака Microsoft Azure.

SLA для RemoteApp обеспечивается на уровне 99,9%.

Мы рассмотрели самый простой вариант использования Microsoft Azure RemoteApp. Шаги по настройке гибридного сценария, использованию других платформ для запуска клиентов и прочие детали можно посмотреть в курсе «Использование приложений в любое время в любом месте с помощью Azure RemoteApp» на портале MVA. Кроме того, в нижней части страницыс ценами вы найдете FAQ по RemoteApp.

Технология довольна проста в настройке и использовании. Пробуйте, экспериментируйте, пишите ваши отзывы.

Начнем с гипервизора.

Hyper-V

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 Clustering

Обновление кластера без простоя

Кросс-платформенная миграция служит предпосылкой для обновления 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.

Remote Desktop Services

Поддержка OpenGL и MultiPoint Services

Remote Desktop Services поддерживает OpenGL 4.4 и OpenCL 1.1 API. Вы также можете выделять большее количество видеопамяти, что важно в различных сценариях VDI. Пока не успел сам попробовать, поэтому не могу написать точно «сколько в граммах».

Кроме того, роль MultiPoint Services теперь является частью продукта, интегрирована с RDSH и обеспечивает функциональные возможности Windows MultiPoint Server для совместного использования одного компьютера несколькими пользователями.

Storage Services

Storage Replica

Storage Replica (SR) – новая возможность, реализующая блочную синхронную репликацию между серверами. Благодаря SR можно реализовать различные сценарии катастрофоустойчивости, расширить возможности failover-кластеров по обеспечению высокой доступности приложений и служб. Синхронная репликация позволяет зеркалировать данные на сконфигурированных серверах, предотвращая потери на уровне файловой системы. Асинхронный режим, который также возможен для SR, не гарантирует 100% сохранность данных, однако применим во многих сценариях, когда компоненты высокодоступной системы располагаются в удаленных сайтах. Технических деталей по SR пока нет, но если не терпится, можно поэкспериментировать с новой компонентой и соответствующими командлетами:

Замечание для тех, кто планирует посмотреть на новый гипервизор. В текущей сборке Hyper-V не запустится, если процессор не поддерживает SLAT. Проверить этот момент можно, например, с помощью утилиты Coreinfo.exe (с ключом -v) из набора Sysinternals Suite. Например, вот в этом процессоре поддержка SLAT отсутствует, как следствие, Hyper-V работать не будет.

Это не все, но для первого обзора, мне кажется, можно остановиться.

Хотя нет, еще один момент. Плитки. Их по умолчанию нет. Но вы можете включить…, если захотите. :)

Удачных экспериментов, которые, я надеюсь, вы не станете проводить в production-среде. :).

Общие вопросы

Обзор новых возможностей 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 существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:

• в VMM это VM Network;
• в PowerShell это Routing Domain;
• во многих статьях и блогах это Tenant или Tenant Virtual Network.

Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. А вот если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).

Варианты реализации шлюза

HNV-шлюз может представлять собой либо готовое аппаратное решение, либо хост на базе Windows Server 2012 R2. На текущий момент на рынке доступны три аппаратных решения:

• от nAppliance
• от Iron Networks
• от F5

В этом посте я сосредоточусь на создании 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-шлюз высокодоступным можно найти здесь.

Основные шаги по созданию шлюза включают в себя следующее:

• настройка логических сетей и сетей ВМ;
• настройка хоста для роли шлюза;
• подготовка ВМ для шлюза;
• добавление шлюза в VMM;
• настройка шлюза для конкретных сетей ВМ

Давайте по порядку.

Настройка логических сетей и сетей ВМ

Этот пункт довольно подробно описан в одном из предыдущих постов, поэтому покажу лишь, как логические и виртуальные сети выглядят у меня в лабораторном свечном ЦОД-ике 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 серии состоится 20 мая. Подключайтесь!

К концу недели ожидаем публикацию материалов от 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

Динамический контроль доступа: управление ресурсами по-новому

Динамический контроль доступа: как работать с утверждениями

Динамический контроль доступа: что собой представляют ресурсы

Динамический контроль доступа: списки свойств ресурсов и классификация файлов

Динамический контроль доступа: работа с централизованными правилами и политиками доступа

Все настройки покажу на примере планшета 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 здесь(на англ.).

Надеюсь, материал был полезен.

Спасибо!