Настройка Hyper-V Server 2012 R2

В связи с постоянно растущим интересом ИТ-специалистов к сфере серверной виртуализации в целом, так и решениям на базе ПО от Microsoft в частности, сегодня я начинаю цикл статей, посвященных замечательному продукту Microsoft Hyper-V Server 2012 R2. Хочу отметить, что все нижеизложенное основывается на реальном опыте использовании группы серверов Hyper-V Server 2012 R2 в production-среде. В данной статье я максимально подробно расскажу о первоначальной настройке среды Hyper-V Server 2012 R2. Кстати, Hyper-V Server 2012 R2 можно скачать с официального сайта Technet Microsoft.

Содержание:

1. АВТОМАТИЧЕСКИЙ ЗАПУСК POWERSHELL ПРИ ВХОДЕ В СЕАНС

2. НАСТРОЙКА СЕТЕВЫХ АДАПТЕРОВ

3. ОТКЛЮЧАЕМ IPV6 НА СЕТЕВОМ ИНТЕРФЕЙСЕ

4. НАСТРОЙКА МЕЖСЕТЕВОГО ЭКРАНА (ADVANCED FIREWALL)

5. ВЗАИМОДЕЙСТВИЕ С SERVER MANAGER

6. СОЗДАНИЕ ДИСКОВОГО ХРАНИЛИЩА ДЛЯ ВИРТУАЛЬНЫХ МАШИН

7. НАСТРАИВАЕМ ПАРАМЕТРЫ ГИПЕРВИЗОРА

8. СОЗДАЕМ ВИРТУАЛЬНЫЙ КОММУТАТОР

Для удаленного управления Hyper-V Server 2012 R2 можно использовать ОС Windows Server 2012 R2 Standard или Datacenter, а также Windows 8.1.

В случае использования Windows Server 2012 R2 Standard или Datacenter необходимо установить консоль Hyper-V Manager. Это можно сделать в Server Manager или при помощи командлета PowerShell Install-WindowsFeature -Name 'RSAT-Hyper-V-Tools'

В 64 битных версиях ОС Windows 8.1 Pro и Enterprise для установки Hyper-V Manager можно использовать средство настройки компонентов Windows.

Для остальных версий Windows 8.1 необходимо установить Remote Server Administration Tools (RSAT), которую также можно скачать на официальном сайте Microsoft.

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

В моем случае я буду использовать наипростейший вариант - локальная подсеть 192.168.1.0/24 с двумя машинами: Hyper-V Server 2012 R2 с IP-адресом 192.168.1.5 в качестве хоста виртуализации и Windows Server 2012 R2 Standard R2 с IP 192.168.1.6 в качестве хоста управления. Обе машины не являются участниками домена и входят в рабочую группу TESTLAB.

Итак, после завершения вполне себе интуитивной установки Hyper-V Server 2012 R2 перед нами предстает рабочий стол с двумя окнами, стандартная командная строка cmd.exe и окно скрипта sconfig.cmd:

Данный скрипт позволяет произвести первоначальную настройку сервера:
– сменить имя сервера
– сменить имя рабочей группы или ввести сервер в домен
– добавить локального администратора
– включить удаленный доступ к серверу, что позволить управлять им с помощью Server Manager, консолей MMC, PowerShell, подключаться по RDP, проверить доступность с помощью pingили tracert
– настроить Windows Update и устанавливать обновления
– настроить сетевые карты сервера
– настроить время на сервере

Также настройку времени на сервере можно выполнить с помощью команды controltimedate.cpl, а настройку региональных параметров - с помощью команды control intl.cpl. При этом будут запущены привычные консоли Панели Управления.

АВТОМАТИЧЕСКИЙ ЗАПУСК POWERSHELL ПРИ ВХОДЕ В СЕАНС

Когда вышла первая версия Hyper-V Server 2008, PowerShell в нем официально не поддерживался, и, единственным способом настройки и получения информации с сервера были утилиты командной строки, такие как net, netsh, wmic, и множество других. Они не обладали единообразным интерфейсом и способом использования, что в итоге увеличивало порог вхождения для администратора и влияло на производительность работы. Но время не стоит на месте и, начиная с Hyper-V Server 2008 R2, Microsoft внедряет поддержку PowerShell, а в Hyper-V Server 2012 PowerShell можно использовать сразу после установки системы. Более того, в Hyper-V Server 2012 включен модуль PowerShell для взаимодействия с Hyper-V, а в Hyper-V Server 2012 R2 количество командлетов для работы с Hyper-V превысило значение 170. Точное значение можно посмотреть с помощью Get-Command -ModuleHyper-V | Measure-Object.

Зайдем в оболочку PowerShell и запустим командлет New-ItemProperty, который создаст новый ключ в реестре HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\run.

New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\run -Name PowerShell -Value "cmd /c start /max C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -noExit" -Type string

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

НАСТРОЙКА СЕТЕВЫХ АДАПТЕРОВ

Если сетевые адаптеры до этого не были настроены с помощью sconfig.cmd, сделаем это с помощью командлетов PowerShell.

Смотрим текущую конфигурацию IP на сетевых интерфейсах. В моем случае адресация назначена службой APIPA, так как в сети нет DHCP сервера.

Get-NetIPConfiguration

Назначаем статическую адресацию, маску сети, шлюз по умолчанию и адреса DNS серверов. InterfaceIndex сетевого адаптера берем из вывода предыдущего командлета.

New-NetIPAddress -InterfaceIndex 13 -IPAddress 192.168.1.5 -DefaultGateway 192.168.1.1 -PrefixLength 24

Set-DnsClientServerAddress -InterfaceIndex 13 -ServerAddresses 192.168.1.2,192.168.1.3

ОТКЛЮЧАЕМ IPV6 НА СЕТЕВОМ ИНТЕРФЕЙСЕ

Если использование IPv6 на сетевом интерфейсе пока не планируется, имеет смысл отключить его на интерфейсе для уменьшения «attacksurface».

Проверяем текущую настройку IPv6 на интерфейсе. Имя интерфейса берем из вывода командлетов Get-NetAdapter или Get-NetIPConfiguration.

Get-NetAdapterBinding -InterfaceDescription "Microsoft Hyper-V Network Adapter" | Where-Object -Property DisplayName -Match IPv6 | Format-Table –AutoSize

Отключить поддержку IPv6 на сетевом адаптере можно командлетом Disable-NetAdapterBinding. Данное действие будет аналогично снятию галки «Internet Protocol Version 6 (TCP/IPv6)» в настройках адаптера в графическом интерфейсе Windows.

Disable-NetAdapterBinding -InterfaceDescription "Microsoft Hyper-V Network Adapter" -ComponentID ms_tcpip6

Настройка межсетевого экрана (Advanced Firewall)

С внедрением PowerShell в Hyper-V Server появился удобный способ управления правилами межсетевого экрана, взамен устаревающего netsh. Просмотреть список комадлетов можно с помощью Get-Command.

Get-Command -Noun *Firewall* -Module NetSecurity

В качестве примера включим возможность традиционного управления межсетевым экраном через оснастку MMCс хоста управления. Для начала получим список правил, относящихся к удаленному управлению межсетевым экраном.

Get-NetFirewallRule | Where-Object -Property DisplayName -Match "firewall" | Format-List -Property Name, DisplayName, Enabled

Включаем оба правила.

Enable-NetFirewallRule -Name RemoteFwAdmin-In-TCP,RemoteFwAdmin-RPCSS-In-TCP

Теперь можно попробовать подключиться к оснастке MMC управления межсетевым экраном с хоста управления.

ВЗАИМОДЕЙСТВИЕ С SERVER MANAGER

Если гипервизор и хост управления не являются частью домена, а находятся в рабочей группе, как в нашем случае, то при попытке добавить сервер Hyper-V в Server Manager на удаленном хосте возникнет ошибка согласования WinRM.

Решается проблема довольно просто – достаточно добавить на Hyper-V Server в доверенные узлы WinRM на хосте управления и обновить текущее состояние в ServerManager.

Set-Item wsman:\localhost\Client\TrustedHosts HYPER-V01 -Concatenate –Force

Создание дискового хранилища для виртуальных машин

Теперь настало время создать хранилище файлов виртуальных машин и файлов виртуальных дисков. Для хранения данных будем использовать отдельный раздел на физическом диске. Для начала посмотрим список командлетов PowerShell, которые используются для управления носителями. Как обычно будем использовать для этого командлет Get-Command. Во втором случае мы получим список командлетов, служащих для получения информации.

Get-Command -Module Storage

Get-Command -Verb *Get* -Module Storage

Просмотрим список физических дисков на сервере.

Get-Disk

Создаем новый раздел на диске максимально возможного размера, назначаем букву D. Используем id из Get-Disk. После этого форматируем раздел в NTFS и указываем его метку.

New-Partition -DiskNumber 0 -DriveLetter D –UseMaximumSize

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "VMStore"

Убедимся в правильности проделанных нами операций с помощью оснастки MMC Disk Management на удаленном хосте, для этого включим соответствующие правила на межсетевом экране.

Enable-NetFirewallRule RVM-VDS-In-TCP,RVM-VDSLDR-In-TCP,RVM-RPCSS-In-TCP

Как мы видим, наш только что созданный диск прекрасно отображается в Disk Management.

Создадим папку на нашем разделе, где будем хранить настройки и файлы дисков виртуальных машин. Командлет New-Item позволяет создавать вложенные пути, так что нет необходимости запускать его два раза для каждой папки.

New-Item -Path "D:\Hyper-V\Virtual Hard Disks" -Type Directory

Создадим папки D:\Distrib и D:\ImportedVM, которые будем соответственно использовать для хранения дистрибутивов ОС и импортированных ВМ с других хостов виртуализации.

New-Item -Path D:\Distrib -ItemType Directory

New-Item -Path D:\ImportedVM -ItemType Directory

Для создания шары используем командлет New-SmbShare, с помощью которого дадим полный доступ по сети для группы локальных администраторов сервера.

New-SmbShare -Path D:\Distrib -Name Distrib -Description "OS Distributives" -FullAccess "BUILTIN\Administrators"

New-SmbShare -Path D:\ImportedVM -Name ImportedVM -Description "Imported VMs" -FullAccess " BUILTIN\Administrators"

Проверяем с помощью PowerShell и с помощью ServerManager с хоста управления.

Get-SmbShare -Name Distrib,ImportedVM | Format-List

Get-SmbShareAccess -Name Distrib,ImportedVM | Format-List

Общий список командлетов, относящихся к SMB (ServerMessageBlock), как обычно можно получить с помощью командлета Get-Command.

Get-Command -ModuleSmbShare

В заключение этой темы добавлю только то, что если на сервере не используется физический или логический RAID, то для повышения производительности и надежности работы с хранилищем ВМ целесообразно использование технологии Storage Pools (к примеру, такие командлеты, как New-StoragePool, New-Volume). Более подробнее об использовании Storage Pools совместно с Hyper-V я напишу в одной из будущих статей.

НАСТРАИВАЕМ ПАРАМЕТРЫ ГИПЕРВИЗОРА

Приступим к настройке параметров гипервизора. Основные параметры Hyper-V можно получить с помощью командлета Get-VMHost.

Get-VMHost | Format-List

Как мы видим из вывода командлета, пути ВМ и виртуальных дисков сейчас размещаются на одном разделе с ОС, что нас не устраивает ни с точки зрения скорости работы, ни с точки зрения надежности. Пропишем пути к созданным в прошлом разделе папкам с помощью командлета Set-VMHost.

Set-VMHost -VirtualMachinePath D:\Hyper-V -VirtualHardDiskPath 'D:\Hyper-V\Virtual Hard Disks'

Проверим с помощью PowerShell…

Get-VMHost | Format-List

… и с помощью Hyper-V Manager.

Как я упоминал выше, в Hyper-V Server 2012 R2 возможно использование EnhancedSessionMode для ВМ, что позволит пробросить в ВМ локальные диски, принтеры, звук, использовать буфер обмена и многомониторные конфигурации. Давайте включим его.

Set-VMHost -EnableEnhancedSessionMode 1

СОЗДАДИМ ВИРТУАЛЬНЫЙ КОММУТАТОР

Виртуальный коммутатор Hyper-V (Hyper-V Extensible Switch) предназначен для организации сетевого взаимодействия между различными ВМ, между ВМ и хостом виртуализации, между ВМ и внешней средой. На самом деле у Hyper-V Extensible Switch обширное количество возможностей, много вкусного появилось в версии 2012 R2. Так что сейчас не будем углубляться в эту тему, и создадим простейший External Switch, который привязывается к сетевой карте Hyper-V Server, и организует взаимодействие ВМ с физической сетью.

Для начала проверим поддержку SR-IOV (Single-Root Input/Output (I/O) Virtualization).

Get-VMHost | Select-Object -Property "Iov*" | Format-List или

Get-NetAdapterSriov

В моем случае поддержки SR-IOV нет. Это связано с тем, что я немного схитрил, и в данной демонстрации у меня Hyper-V сервер запущен не на живом железе, а в виртуальной среде.

Получим список подсоединенных сетевых адаптеров

Get-NetAdapter | Where-Object -PropertyStatus -eqUp

Привязываем виртуальный свитч к сетевому адаптеру и при наличии SR-IOV включим его поддержку.

Внимание: Включить или отключить поддержку SR-IOV после создания свитча будет невозможно, для изменения этого параметра необходимо будет пересоздавать свитч.

New-VMSwitch -Name "Extenal_network" -NetAdapterName "Ethernet 2" -EnableIov 1

В моем случае Hyper-V выдает ошибку, опять же связанную с тем, что гипервизор сам запущен в виртуальной среде. На живом железе командлет создаст External Switch с именем «External_network» и привяжет его к сетевому адаптеру Ethernet 2. Виртуальный свитч также появится в списке сетевых адаптеров и на него будет перепривязаны все сетевые параметры физического адаптера Ethernet 2

Проверить можно с помощью командлетов Get-VMSwitch и Get-NetIPConfiguration –Detailed.

На этом этапе первоначальная настройка Hyper-V Server 2012 R2 закончена, и все готово для создания нашей первой виртуальной машины. Но об этом мы поговорим в следующей статье, использовать будем, естественно, PowerShell.

До скорых встреч!

Установка терминального сервера Windows server 2012 r2

Хотите купить Windows Server 2012 r2? Тогда вам сюда!

Сразу скажу, что решение от Microsoft сильно удивило меня своей продуманной стратегией, которая отражена на картинке ниже. Похожесть на решение от Citrix тоже бросается в глаза, но почему бы не тянуться за лидером… Итак, начну с того, что теперь вся эта концепция называется виртуализация рабочих мест. По идее разработчиков, на рабочем месте сотрудника должно находиться как можно меньше корпоративной информации, запускаться как можно меньше программ. В идеале вместо системного блока с обратной стороны монитора крепится тонкий клиент , через который на экран передается изображение с серверов. В таком случае вероятность потери данных или поломки чего-либо на рабочем месте сводится к минимуму.

Куда подключаться пользователь?

Существуют два способа подключения к виртуальному рабочему столу, которые мы сейчас с вами и рассмотрим. Первый сценарий называется RD Virtualization host - его принцип заключается в том, что подключение к виртуальной машине для каждого пользователя производится по протоколу RDP 7.1 или выше. Сама виртуальная машина при этом запускается на гипервизоре Hyper V, установленном на сервере. Из особенностей этого сценария подключения к виртуальному рабочему столу можно отметить, что все информация находится в профиле пользователя, а использование технологии RemoteFX от Microsoft позволяет существенно повысить быстродействие работы виртуальной машины. Технология RD Virtualization Host встроена в операционные системы Windows 7 и 8, а значит, у вас нет необходимости приобретать лицензию на RDP. Но для получения права на использование данного метода подключения к виртуальной машине, необходимо на каждого пользователя приобретать подписку за 110$ в год.

О следующем сценарии как раз-таки и пойдет речь в данной статье. Он называется RD Sessionhost, и при выполнении данного сценария, все процессы, которые пользователи видят на своем мониторе, на самом деле происходят на сервере Remote Desktop host. При этом у пользователя на выбор есть два способа удаленного запуска приложений: либо через браузер, либо через ярлыки на рабочем столе. При этом вы сможете использовать и самое стандартное подключение к удаленному рабочему столу сервера. При этом работа с Windows server 2012 r2 будет интуитивно понятна, как как по интерфейсу он в целом похож на Windows 8.

Установка

Для установки используется свежеустановленная Windows server 2012 Beta и статья-руководство на technet. Как обычно, все идет не так как написано в мануале.

1.. Входим в Server Manager. Справа вверху выбираем Manage -> Add Roles and Features. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation

2.. Для одного сервера, выбираем Quick Start. Мастер обещает установку сервиса удаленных рабочих столов, настройку Collection и RemoteApp programs.

3.. Выбираем, что наши пользователи будут подключаться к серверу (собственным сессиям на сервере), а не к собственным виртуальным машинам.

4.. По сценарию на наш сервер будут добавлены следующие серверные роли:

RD Connection Broker – контроль подключений пользователей, определяет для какого пользователя на каком сервере будет открыта сессия или запущено приложение

Web Access – доступ к приложениям через веб браузер

RD session Host – сервер, на котором будут опубликованы приложения и на который пользователи смогут подключаться через удаленный рабочий стол.

Если инфраструктура у вас большая или вам нужна отказоустойчивость, то необходимо дублировать серверы с данными ролями, изначально решение создавалось как кластерное.

5.. После чего начинается «автоматическая» настройка ролей, которая кончается ошибкой настройки Session collection и отменой установки RemoteApp programs. Наверное, в ходе работы мастера должны запускаться другие диалоги настроек, но пока не работает. После установки первой роли сервер перезагружается и включается триальный период работы RDP сервера 120 дней.

6.. Чтобы завершить установку в ручную, выбираем в Server Manager вкладку управления ролью Remote Desktop Services

7.. Там видим еще одно графическое представление плана установки. Первые два пункта у нас выполнены.

8.. Кликаем по третьему пункту, Create session collection. Запускается мастер создания.

9.. Придумываем название для Session Collection

10.. Выбираем наш сервер, в качестве RD session Host

11.. Выбираем группы или отдельных пользователей, которые смогут подключаться к нашему серверу по протоколу RDP

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

13.. Вот теперь установка закончилась удачно.

14.. Нам осталось опубликовать приложения, слева вверху выбираем созданную ранее Collection 1

15.. Находим раздел REMOTEAPP PROGRAMS и выбираем Publish RemoteApp programs.

16.. Появляется выпадающий список программ, которые доступны на сервере. Среди них нет Internet Explorer, но его можно добавить здесь же в ручном режиме, если нажать на Add. Выбираем понравившиеся приложения галочками.

17.. Подтверждаем, что не ошиблись в выборе.

18.. Дальше сам Windows server 2012 r2 подсказок не дает. Как бы понятно, что нужно подключиться, но что для этого нужно сделать… обращаемся к статье на TechNet.

19.. Открываем браузер на компьютере пользователя, и заходим по адресу, в моем случае, https://rdp2012.azon.local/RDweb вводим данные пользователя, который входит в группу Пользователи домена.

20.. После авторизации попадаем на страницу с опубликованными приложениями.

21.. Также есть возможность подключиться к серверу, но нужно знать его имя. Не очень удобно.

22.. Приложения, как положено, открываются в отдельных окнах, что создает ощущение, как будто вы запустили программу на своем компьютере.

23.. Для проверки плавности хода курсора рисую мышкой круг, очень хорошо. Вообще, протокол RDP 7.1 избавлен от проблем прошлых версий. Я, например, подключаюсь по нему к своей рабочей машине. Браузер с flash, почта, редакторы работают шустро.

На этом первую часть статьи, можно считать законченной. Во второй части будем настраивать Сценарий RD Virtualization host.

Высокая доступность В Hyper-V

Failover Cluster, который будет рассматриваться в этой статье - это компонент Windows server 2008 R2 Enterprise или Datacenter, который позволяет настраивать отказоустойчивые кластеры различных служб, в том числе, и виртуальных машин.

Высокая доступность или High Availability, обеспечивает быстрый перезапуск виртуальной машины, после выхода из строя сервера Hyper-V, на котором она была запущена. Где должна перезапуститься виртуальная машина после аварии сервера, настраивает администратор. Обычно, это один из запасных серверов Hyper-V.

Другими словами, высокая доступность защищает от аппаратных сбоев оборудования Hyper-V сервера. Это может быть сбой питания, выход из строя сетевых карт, дисков, процессоров, памяти и т.д. Но есть и частные случаи программной отказоустойчивости, когда ВМ перестают отвечать (зависают), то происходит автоматическая перезагрузка средствами Failover Cluster.

Для настройки Failover Cluster лучше всего подойдут серверы идентичной конфигурации. После того, как они станут членами кластера их можно называть нодами кластера. Процессоры в серверах могут различаться, для их совместимости в Hyper-V есть функция Processor Compatibility mode, но лучше, по возможности, этого избегать. Про настройку сети и систем хранения мы поговорим отдельно, позже.

Quick Migration:

Остановка виртуальной машины (Save, Сохранить). Естественно, виртуальная машина становится недоступной. Оперативная память виртуальной машины сохраняется в файл с расширением .vsv
Регистрация виртуальной машины на другом сервер Hyper-V, по сути это просто передача прав на ВМ.
Передача прав на файлы виртуальной машины, которые хранятся на системе хранения
Возобновление работы виртуальной машины уже на новом сервере Hyper-V, виртуальная машина переехала

Live Migration:

Все страницы памяти виртуальной машины переносятся с одного сервера Hyper-V на другой
Страницы памяти виртуальной машины, которые успели измениться или добавиться за время первого шага, снова переносятся
Файлы виртуальной машины меняют владельца
Виртуальная машина регистрируется на новом сервере Hyper-V

Так что же выбрать Live или Quick Migration? У Live Migration почти нет простоя при переносе виртуальной машины, вся сложность в большой генерации трафика на 1-2 шаге работы, Microsoft рекомендует выделять отдельный сетевой интерфейс для такой миграции. Так же Hyper-V не умеет мигрировать больше одной виртуальной машины средствами Live Migration. Quick Migration более простой и менее требовательный, но работает с неминуемым простоем в работе виртуальной машины.

Еще одно важное понятие Quorum – кворум, одельное место на системе хранения данных, куда записывается информация для нод кластера. Основное это – какая нода в данный момент владеет виртуальной машиной и какой ноде переходит управление в случае аварии. Если администратор не создаст кворум, то функции Failover Cluster будут работать только в ручном режиме. Файловая система Quorum – NTFS.

Общее хранилище при использовании кластера

Failover Cluster может функционировать только при использовании внешнего хранилища (СХД – системы хранения данных). На нем будут храниться файлы виртуальных машин и это очень логично. Ведь если вы будете хранить их на локальных дисках сервера и он неожиданно выйдет из строя, то быстро восстановить работу не получится. Поэтому нужно разделение дисковой системы и вычислительной. Microsoft поддерживает несколько типов таких хранилищ, основные это FC (Fiber Channel –оптическое соединение) и iSCSI (Internet Small Computer System Interface). С помощью коннектора встроенного в Windows server подключается LUN с СХД. Принцип работы очень похож на подключение сетевого диска.

Clustered Shared Volumes (CSV)

Для работы Failover Cluster необходимо, чтобы несколько нод могли получить доступ к дискам виртуальных машин, которые хранятся на СХД. Чтобы осуществить это обычного NTFS недостаточно и нужно использовать дополнительный функционал CSV. Без использования CSV в Failover Cluster один LUN на системе хранения можно будет выделить только одной виртуальной машине.

Настройка Failover Cluster

Настройку Failover Cluster между несколькими хостами Hyper-V можно разделить на несколько простых шагов:

Настройка сети
Настройка сети заключается в разделении трафика на две сети: сеть передачи данных (между серверами и системами хранения данных) и общая сеть компании (к ней подключены виртуальные машины, компьютеры администраторов и пользователей). На картинке изображена типовая сетевая схема, рекомендуемая для совместной работы Hyper-V и Failover Cluster. Отдельные сетевые интерфейсы задействованы в сети передачи данных, отдельные в общей сети компании. Hyper-V хосты, как минимум, должны быть подключены к Active Directoy и DNS, а при настройке должен использоваться доменный аккаунт (например, Администратор домена).
Схема на картинке приведена без дублирования подключений и потому не отказоустойчивая, рассматривать ее как шаблон не стоит.
Установка ролей и компонентов.
Для настройки Failover Cluster на хостах Hyper-V должны быть добавлены следующие роли и компоненты:
Роль Hyper-V
Компонент Failover Clustering
Компонент Multi-Path I/O
Подключение общей СХД
Еще раз повторюсь, что СХД для работы Failover Cluster обязательный пункт, в отдельной статье я расскажу как настроить и подключить к Hyper-V систему хранения на базе FreeNAS. В результате у нас на каждом Hyper-V сервере будут подключены 2 раздела с системы хранения: кворум и раздел для хранения виртуальных машин.
Проверка возможности установить кластер
Процедура проверки запускается из оснастки управления компонентами сервера Windows 2008. Во время работы мастера будут протестированы Hyper-V хосты, а после вы получите HTML отчет с перечислением всех проведенных тестов и набором рекомендаций.
Создание кластера
Для создания кластера нужно запустит мастер, указать имя кластера, указать серверы, серверы кластера(будущие ноды). После создания вы увидите свой кластер в оснастке и сможете
Включение CSV
Добавление ВМ в кластер

Hyper V 3. Вступление

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

Почему возникло желание рассмотреть эту тему? Очень просто, в Hyper V 3, что называется «из коробки», работают такие функции как миграция виртуальных машин между серверами через общий storage, миграция файлов виртуальных машин между разными LUN-ами, миграция ВМ без системы хранения (просто на локальных дисках серверов) и, наконец, репликация виртуальных машин. Все вышеперечисленное предоставляется компанией Microsoft абсолютно бесплатно. Вы просто скачиваете с сайта Hyper-V server 2012, устанавливаете на свой сервер, подключаетесь удаленно, и все, можно пользоваться. Естественно, во время миграции виртуальная машина не выключается.

Почему же компания VMware просит за тот же функционал деньги? Не хочу спорить, хорошо это или плохо. Придерживаюсь другой точки зрения.

Есть технологии, которые в автоматическом режиме экономят деньги компании. Все происходит без участия администратора, который после первоначальной настройки, только контролирует процесс, просматривая логи по утрам. Сейчас речь идет о высокой доступности, автоматическом распределении нагрузки между серверами, автоматическом распределении нагрузки между LUN-ами систем хранения, непрерывная доступность(Fault Tolerance). Может еще что-то, главное суть, администратора нет на рабочем месте а отказоустойчивость работает. Это вполне может стоить денег и это логично.

Все, что администратор делает руками (мышкой, клавиатурой) без сомнения может влиять на отказоустойчивость, но не в автоматическом режиме. Например, посмотрел администратор данные мониторинга и решил, что пора мигрировать другие виртуальных машины с хоста Х и оставить там ВМ с MSSQL сервер в гордом одиночестве. И остальные тому подобные ручные действия, по моему мнению они должны оставаться бесплатными. А вот, когда администратору надоест ручной труд или начальству надоест искать его, когда перестает работать все вокруг, тогда и бюджет выделить не жалко.

Компания Microsoft, видимо, придерживается такой же позиции, поэтому разрешите представить вам Hyper-V 3, который, очевидно, станет фаворитом серверной виртуализации, когда выйдет из беты.

Hyper V 3. Возможности

Ниже я кратко опишу его возможности, постепенно добавлю ссылки на статьи с более подробным описание каждой из них. Кто интересуется лицензированием и стоимостью Windows server 2012, статья тут.

♦ Live Migration without shared storage – живая миграция виртуальной машины с локальных дисков одного хоста на другой без простоя в работе (описание)
♦ Live Migration with SMB Shared Storage – живая миграция виртуальной машины с хоста на хост без простоя. Файлы ВМ хранятся в общем хранилище (описание)
♦   Storage Migration – перенос файлов ВМ с одной системы хранения на другую без простоя в работе виртуальной машины
♦   Virtual Machine Replication – асинхронная репликация виртуальной машины с основного хоста (primary) на другой хост с ролью Hyper-V.(описание)
♦   Failover Cluster – технология высокой доступности, если один из хостов выходит из строя, виртуальная машина перезапускается на другом хосте кластера
♦   Single Root I/O Virtualization – контроль ввода-вывода на отдельных устройствах PCI Express. Например, для сетевой карты, чтобы трафик при миграции не занимал весь канал, который используют другие виртуальные машины.
♦   NIC Teaming and load balancing – объединение сетевых интерфейсов (агрегация) для обеспечения отказоустойчивости
♦   Новый формат диска виртуальной машины VHDX и возможность использовать SMB шару в качестве общего хранилища
♦   Новый Virtual Switch
♦   Virtual Fibre Channel for Virtual Machines – виртуальный FC HBA адаптер в виртуальной машине

Функционал, который добавляется, если установить средство централизованного управления от Microsoft Virtual Machine Manager 2012.

♦   Общая консоль для управления всеми виртуальными машинами в сети, причем доступны не только ВМ запущенные на платформе Hyper V 3, можно подключаться к VMware и Citrix XenServer
♦   Автоматическое распределение нагрузки между хостами
♦   Все ресурсы имеющихся хостов в VMM2012 видны, как общая фабрика (Fabric) ресурсов. Мы же, запуская виртуальную машину, выделяем ей ресурсы фабрики.
♦   Встроенный конвертер P2V и V2V
♦   Возможность объединения с сервером мониторинга Microsoft System Center Operations Manager
♦   Создание библиотек и шаблонов, для быстрого развертывания виртуальных машин
♦   Портал самообслуживания
♦   Возможность создания частного облака, тут надо разбираться, тема необычная.

Возможные решения на Hyper-V 3.0

Нужно отметить, что роль Hyper-V 3.0 на данный момент можно получить тремя путями:

Купить Windows server 8 после релиза, про стоимость пока ничего неизвестно
Скачать Hyper-V Server 8 после релиза, абсолютно бесплатный продукт, но управлять им нужно будет с компьютера администратора через RSAT
Купить Windows 8 после релиза, туда тоже встроена нужная роль, правда, с некоторыми ограничениями

Так какие решения можно строить на основе Hyper-V 3? Будем двигаться от простых к сложным, рационально оценивая потребности каждого.

Один сервер

У вас маленькая компания, из серверного оборудования всего один сервер. Большого простора здесь нет, но есть основная возможность виртуализации, запуск виртуальных машин. Имеет смыл укомплектовать сервер большим количеством оперативной памяти и жесткими дисками, которые подойдут для ваших нужд. Например, для базы 1с многие администраторы сейчас используют SSD диски, избавляясь таким образом от тормозов. Для виртуальных машин этот способ тоже сработает, надо лишь положить файлы ВМ на эти диски. Чтобы SSD диски (и другие тоже) работали как надо, необходим мощный RAID контроллер. Я советую рассмотреть диски и контроллеры производства Intel, а если нет сервера, то и сервер стоит выбрать Intel. 100% совместимость оборудования между собой и с виртуализацией Microsoft.

Два сервера (и более)

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

Но наиболее важным моментом, которым будут пользоваться администраторы – это репликация. Виртуальная машина работает на одном сервере, а на другом хранится ее полная независимая реплика, всегда готовая к запуску. В случае аварии с одним из серверов и невозможности (нежелании) восстановить данные с него, вы сможете запустить реплики виртуальных машин и продолжить работу. Как часто нужно делать репликацию, решать вам. Чем чаще, тем актуальнее у вас будет реплицированная виртуальная машина, и тем меньше данных вы рискуете потерять в случае аварии.

У компании StarWind есть решение для обеспечения высокой доступности между двумя хостами Hyper-V, но для работы такой схемы нужно соединить серверы по 10Gbe/s каналу передачи данных для online синхронизации.

Решение, построенное на двух серверах IBM и Hyper V 3.0

Решение для 1С, постоенно на двух серверах Intel с SSD дисками и Hyper V 3.0

Два сервера (и более) и СХД

Система хранения данных с дисками стоит, примерно, как два сервера. С ней вы можете более рационально распределять дисковые ресурсы между серверами, а также хранить файлы виртуальных машин в общедоступном месте. Такая архитектура позволяет использовать технологию «высокой доступности» после настройки Microsoft Failover Cluster.

Как это работает? На каждом сервере мы включаем компонент(feature) Failover Cluster, после этого создаем кластер и добавляем виртуальные машины, которые кластер будет защищать. Естественно, файлы этих виртуальных машин должны находиться на общем файловом хранилище. После настройки кластера управлять виртуальными машинами, находящимися в нем, мы уже будем через оснастку Failover Cluster Manager. В случае аварии с одним из серверов, виртуальные машины в автоматическом режиме перезапускаются на другом хосте кластера. Для гостевой операционной системы внутри ВМ это выглядит, как будто ее внезапно выключили, а затем включили. То, что она включилась на другом сервере, никак не отразится на ее работе.

Репликация тоже может пригодиться, даже при наличии системы хранения. Дело в том, что SSD диски для СХД пока что еще очень дороги (сравнимы со стоимостью самой СХД без дисков) поэтому базы 1с можно запускать на локальных дисках сервера и делать резервную репликацию на СХД. Еще одна возможность использования репликации встроенной в Hyper-V 3 – это создание реплики ВМ, работающей на СХД, на локальные диски сервера. Тогда в случае выхода из строя дискового массива (а такое тоже может быть) можно будет продолжить работу без него.

Конечно, доступна миграция самих виртуальных машин и их дисков.

"Много серверов" и несколько СХД

Концепция Microsoft в направлении виртуализации нацелена на создание частного облака. Облако здесь – это пул ресурсов, которые мы можем распределять между виртуальными машинами. По задумке Microsoft администратор не должен размышлять над тем, откуда берутся ресурсы, на каком сервере в данный момент работает ВМ и на LUN-е какого хранилища лежат ее файлы. Мы то понимаем, что это почти нереальная ситуация… Это какой масштаб должен быть у инфраструктуры? Поэтому «много серверов» понятие относительное, для каждого администратора оно свое.

Так вот, чтобы управлять структурой в которой «много серверов», Microsoft советует использовать Virtual Machine Manager 2012, а лучше System Center 2012, в составе которого присутствует VMM 2012.

StarWind Native SAN for Hyper-V

Последняя версия 5.8 описание

Основным продуктом компании StarWind является софт для построения отказоустойчивой системы хранения данных, работающей по протоколу iSCSI. В новом решении для малого бизнеса, компания объединила это решение с технологией виртуализации Microsoft Hyper-V. В итоге получился отказоустойчивый кластер из двух серверов, полностью дублирующих информацию друг друга во время работы. Active-active – это значит, что во время нормальной работы используются ресурсы обоих серверов и лишь в случае аварии оставшийся в живых берет на себя всю нагрузку. Данные во время работы хранятся на локальных дисках серверов и реплицируются в реальном времени, поэтому у вас ВСЕГДА будет полная копия ВСЕХ данных на каждом сервере. Для малого бизнеса это решение идеально и вот почему:

Вы получаете отказоустойчивость корпоративного уровня без покупки отдельной системы хранения
Решение может быть построено на малошумных серверах и находится непосредственно в офисе, отдельная серверная комната не нужна
Не требует покупки дополнительного ПО для виртуализации, только лицензия StarWind
Решение полностью совместимо с такими популярными продуктами Microsoft как MS SQL server, Exchange server, SharePoint server
Функция дедупликации, которая входит в лицензию StarWind, позволит экономить дисковое пространство

Логика работы решения StartWind Native SAN for Hyper-V

Запуск виртуальных машин. Если у вас был опыт запуска виртуальных машин в Hyper-V, то вы наверняка знаете, что жесткие диски ВМ сохраняются в виде файлов с расширением .VHD, которые хранятся на локальных дисках сервера. В Windows server 2008 встроен iSCSI инициатор, который позволяет монтировать разделы (LUN-ы) с систем хранения данных, как сетевые диски. На этих дисках также можно сохранять файлы виртуальных машин.

StarWind Native SAN, после установки в систему Windows server 2008, запускает локальную службу iSCSI и позволяет отдавать свободное место с жестких дисков сервера в качестве LUN. Этим могут пользоваться серверы в сети или, как в нашем случае, сам сервер, на котором установлен StarWind. То есть, сервер подключается сам к себе, к своим же дискам. Спросите зачем это нужно? Читайте дальше.

LUNiSCSI. Когда вы создаете LUN на сервере через StarWind, он сохраняется на локальном диске как файл-образ с расширением .img с заданным вами объемом. На втором сервере, создается точно такой же файл или несколько файлов, если LUN у нас не один. Каждый сервер подключается к своему файл-образу через iSCSI инициатор, сохраняет в нем файлы виртуальных машин и может запускать эти виртуальные машины. То же может делать и второй сервер.

Репликация данных. Как вы догадываетесь, описанная выше схема затевалась, чтобы создать отказоустойчивый кластер. В реальном времени, на уровне блоков данных, StarWind Native SAN синхронизирует файл-образы с первого и второго серверов по 10 Gbit каналу связи, поэтому в любой момент времени у нас есть полная копия всех файлов виртуальных машин на каждом сервере.

Active-Activeкластер. Причем, на каждый сервер работает с файлами виртуальных машин, которые хранятся именно на его локальных дисках в файле-образе. Никаких заметных задержек при такой схеме работы не наблюдается, т.к. обращение по сути идет напрямую к RAID сервера.

Что значит Active-Active кластер, это означает, оба сервера у вас используются для работы виртуальных машин. А не как это, обычно, бывает – один ждет аварии второго, чтобы начать работу.

В случае аварии. Аварией можно считать выход из строя одного из серверов. В этом случае срабатывает Microsoft Failover cluster (настраивается вместе с ролью Hyper-V), и виртуальные машины, работавшие на сломавшемся сервере, автоматически перезапускаются на оставшемся в строю.

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

Стоимость решения

Стоимость решения составляет 350 тысяч рублей (без учета лицензий Microsoft)

В решение входят 2 сервера (Supermicro 1U, 4x1Tb HDD, 1xCPU Xeon E5645 6core, RAM 16Gb, все необходимы сетевые карты и патчкорды)

Лицензия StarWind Native SAN for Hyper-V на 1Tb iSCSI хранилище.