Что нового в Windows Server 2012 R2 Hyper-V. Часть 2

Первую часть статьи «Windows Server 2012 R2 Hyper-V» я посвятил основным улучшениям в гипервизоре Hyper-V, таким как виртуальные машины второго поколения, новый механизм активации, динамическое клонирование виртуальных машин, режим расширенного сеанса, повышение мобильности и усовершенствования механизма репликации. В этой статье речь пойдет о второстепенных новых возможностях, в том числе улучшениях в механизмах хранения данных и сетевого взаимодействия, шлюзе виртуализации сети и, наконец, нововведениях, предназначенных для виртуальных машин с системой Linux.

Динамическое изменение размеров дисков VHDX

В системе Windows Server 2012 впервые использовалась вторая версия формата Virtual Hard Disk (VHD) —VHDX—обеспечивающая не только повышение производительности по сравнению с форматом VHD благодаря использованию динамического режима по умолчанию, но и увеличение максимального размера отдельного файла VHDX с 2 до 64 Тбайт. Таким образом, размер больше не является ограничивающим фактором при использовании дисков VHD или оправданием для применения транзитных хранилищ. Из любопытства на каждой презентации на тему системы Windows Server и гипервизора Hyper-V я спрашивал у присутствующих, c каким максимальным объемом тома NTFS они работали. Самый большой объем тома NTFS, о котором я слышал, был равен 20 Тбайт (второе место занимает том объемом 14 Тбайт). Таким образом, самые большие дисковые тома, с которыми я сталкивался, можно записать несколько раз в файл VHDX. После того, как в инструмент CHKDSK в системе Windows Server 2012 были внесены изменения, снижающие максимальное время простоя во время исправления файловой системы до 8 секунд, я подумал, что скоро мы будем наблюдать расширение томов NTFS. Однако объем в 64 Тбайт будет достаточным еще долгое время.

Даже принимая во внимание огромное преимущество в производительности динамических дисков VHDX, многие организации предпочитают использовать файлы VHDX фиксированного размера, в которых все пространство предоставляется сразу при создании. Причины для этого есть различные, но среди них можно выделить риск нехватки физического пространства в хранилище (ведь динамическое диски растут, если не настроено соответствующее средство мониторинга), возможное повышение фрагментации при использовании динамических дисков, а также сокращение разницы в производительности между фиксированными и динамическими дисками по мере увеличения емкости. Тем же самым организациям требуется возможность при необходимости менять размер файлов VHDX, делая их больше, но в системе Windows Server 2012 подобная операция требовала выключения виртуальной машины, использующей файл VHDX. Это ограничение исчезает в системе Windows Server 2012 R2 Hyper-V с появлением механизма оперативного изменения размера файлов VHDX, позволяющего не только увеличивать размер файла VHDX, но и уменьшать его, основываясь на количестве нераспределенного пространства в файле VHDX.

Механизм динамического изменения размера файла VHDX требует, чтобы файл VHDX был прикреплен к контроллеру SCSI виртуальной машины. В виртуальных машинах первого поколения данный механизм может быть применен только к дополнительному диску, но не к системному или загрузочному тому. Для виртуальных машин второго поколения, использующих только контроллер SCSI, данный механизм позволяет менять размер любого прикрепленного файла VHDX. Конкретная операция изменения размера может быть выполнена из графического интерфейса или через команды PowerShell. После того, как файл VHDX, прикрепленный к виртуальной машине, будет расширен, дополнительное нераспределенное место будет отображено в диспетчере Disk Manager, в результате чего можно будет создавать новые тома в новом дисковом пространстве или расширять существующие тома. Если на диске VHDX есть нераспределенное место (то есть место, не используемое томами), файл VHDX может быть динамически сокращен на соответствующий объем. Если вы хотите еще раз сократить файл VHDX, необходимо сначала создать дополнительное нераспределенное пространство внутри файла VHDX или удалить дисковые тома виртуальной машины. Имейте в виду, что динамическое изменение размеров дисков VHDX работает кроме гостевых систем Windows еще и с гостевыми системами Linux.

Общие файлы VHDX

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

• использование протокола iSCSI посредством инициатора iSCSI, встроенного в операционную систему (для систем Windows Server 2008 R2 Hyper-V);
• использование виртуального адаптера Fibre Channel для доступа к устройствам LUN, подключенным к сети Fibre Channel (Windows Server 2012 Hyper-V);
• использование общих папок SMB 3.0 (Windows Server 2012).

Проблема всех этих подходов заключается в том, что у виртуальных машин есть информация о структуре хранилищ, и машины напрямую обращаются к ней. Во многих ситуациях такая схема не идеальна — особенно для организаций, предоставляющих услуги хостинга. Кроме того, она нарушает абстрагирование между виртуальной машиной и физическими ресурсами, а также ограничивает возможности самообслуживания для пользователей виртуальных машин, так как у них нет необходимых прав или, возможно, достаточных знаний для создания на устройствах SAN томов LUN и последующего их использования через протокол iSCSI или виртуальный адаптер Fibre Channel.

В системе Windows Server 2012 R2 появились общие диски VHDX — механизм, который, как следует из названия, позволяет совместно использовать файл VHDX нескольким виртуальным машинам, для которых файл VHDX представляет собой общее хранилище, а, значит, может использоваться в качестве кластерного хранилища для этих виртуальных машин. Общие диски VHDX могут быть использованы виртуальными машинами как первого, так и второго поколения, но должны подключаться к машинам через контроллер SCSI. Кроме того, общий файл VHDX должен храниться на дисках Cluster Shared Volumes (CSV) или должен быть доступен через хранилище SMB 3.0 на масштабируемом файловом сервере (Scale-Out File Server), использующем диски CSV. Это связано с тем, что код, обеспечивающий совместную работу, на самом деле является частью системы CSV, а не обычной файловой системы. Если вы хотите попробовать использовать общие диски VHDX без системы CSV, то можете принудительно загрузить драйвер CSV, но данный подход не поддерживается и будет работать до первой перезагрузки. Данный процесс описан во врезке «Вопросы о VHDX».

Настроить совместное использование файла VHDX очень просто. На показано на приведенном в статье экране, вы просто устанавливаете флаг Enable virtual hard disk sharing на вкладке Advanced Features окна параметров диска VHD. В оболочке PowerShell добавляется параметр -ShareVirtualDisk в команде Add-VMHardDiskDrive.

Экран. Совместное использование файла VHDX

Имейте в виду, что при использовании общих дисков VHDX вы больше не сможете создавать контрольные точки виртуальных машин, выполнять резервное копирование на уровне хост-сервера Hyper-V, задействовать механизм QoS для хранилищ (о котором я расскажу ниже) или механизм Hyper-V Replica. Ни одна из этих технологий не работает, если несколько виртуальных машин подключены к одному и тому же хранилищу.

Механизм QoS для хранилищ и измерение ресурсов

С небывалым ростом виртуализуемых рабочих нагрузок, с изменением схемы предоставления услуг виртуализации, с появлением единых развертываний, используемых различными пользователями, бизнес-группами и в некоторых случаях различными владельцами, стало актуальным такое положение, при котором различные пользователи будут получать соответствующую часть общих ресурсов – или, по крайней мере, то количество ресурсов, за которое они заплатили. Уже давно реализована возможность применить механизм гарантированного обслуживания Quality of Service (QoS) к ресурсам процессора, памяти или сети. В системе Windows Server 2012 R2 такая возможность появилась для хранилищ.

Вы можете активировать механизм QoS и указать минимальное и максимальное количество операций ввода-вывода в секунду (IOPS) на вкладке Advanced Features для диска VHD. Эти два значения оказывают совершенно различное влияние. Максимальное количество IOPS — это жесткое ограничение, накладываемое на диск VHD. Минимальное количество IOPS – это не гарантируемое значение, так как хост-сервер Hyper-V не обязательно является единственным пользователем хранилища, на котором могут выполняться и другие рабочие нагрузки, поэтому гипервизор Hyper-V не может гарантировать наличие определенного количества операций IOPS. Используется альтернативный подход, при котором, если количество IOPS, доступное для диска VHD, падает ниже значения минимального количества IOPS, создается журнал событий, а также событие Windows Management Instrumentation (WMI), уведомляющее администратора Hyper-V о том, что минимальное значение количества IOPS не обеспечивается, и необходимо принять соответствующие меры.

В системе Windows Server 2012 R2 усовершенствован механизм измерения ресурсов, который теперь позволяет собирать метрики параметров виртуальных машин и добавлять информацию о хранилище, такую как:

• среднее количество IOPS;
• средняя задержка;
• количество записанных данных;
• количество прочитанных данных.

Поддержка устранения дублирования в сценариях VDI

В системе Windows Server 2012 впервые появилась встроенная технология устранения дублирования (дедупликации) на уровне блоков. Однако она не работала для заблокированных файлов, находящихся в эксклюзивном использовании, таких как диски VHD, применяемые виртуальными машинами Hyper-V. Это ограничение было снято в системе Windows Server 2012 R2, а значит, теперь используемые диски VHD могут быть дедуплицированы. Единственная рабочая нагрузка, дедупликация которой поддерживается на данный момент, — это виртуальная машина, используемая как часть развертывания Virtual Desktop Infrastructure (VDI) (то есть с установленной клиентской операционной системой). Хотя дедупликация файлов VHD, используемых виртуальными машинами с серверными операционными системами, не блокируется, данный подход не поддерживается. Необходимо тщательно обдумывать попытки выполнить дедупликацию неподдерживаемых типов рабочей нагрузки. Некоторые серверные рабочие нагрузки оптимизируют размещение данных на диске. Если другой процесс будет выполнять дедупликацию блоков на диске, не уведомляя об этом рабочие процессы сервера, может пострадать производительность.

Виртуальное масштабирование на стороне приема

Сетевые адаптеры с полосой пропускания 10 Гбит/с становятся все более распространенными, и бывают случаи, когда такая полоса требуется виртуальным машинам. Виртуальные машины обычно обращаются к внешней сети через сетевые адаптеры, добавленные к виртуальной машине и привязанные к внешнему виртуальному коммутатору, который в свою очередь привязан к сетевому адаптеру или группе сетевых адаптеров. Сетевые взаимодействия требуют большого объема ресурсов процессора. Одно ядро процессора может легко управлять рабочими процессами в сетевом соединении шириной 1 Гбит/с. Однако единственное ядро становится узким местом при работе с соединением шириной 10 Гбит/с — обычно обеспечивается скорость около 3-4 Гбит/с.

Решением проблемы, связанной с ограниченной производительностью одного ядра, для физических систем является технология Receive Side Scaling (RSS — масштабирование на стороне приема). Принцип работы механизма RSS заключается в обработке входящего трафика по алгоритму, разделяющему различные потоки трафика, которые в дальнейшем могут быть обработаны разными ядрами процессора, чтобы обеспечить полное использование полосы пропускания.

Виртуальная технология RSS (vRSS) предоставляет ту же возможность для виртуальных машин, которые теперь могут использовать несколько виртуальных процессоров (vCPU) для обработки входящего сетевого трафика и снятия ограничений скорости, действовавших ранее. Имейте в виду, что виртуальные сетевые адаптеры, созданные на хост-сервере Hyper-V, не могут использовать технологию vRSS и ограничены той полосой пропускания, которую может обеспечить единственное ядро процессора.

Управление полосой пропускания SMB

Хотя протокол SMB ранее использовался только как средство доступа к общей файловой папке для хранения документов, версия SMB 3.0 – это полноценный корпоративный протокол для работы с файлами, который может применяться для хранения виртуальных машин, баз данных SQL Server и других ресурсов. Кроме того, механизм динамической миграции в системе Windows Server 2012 R2 может применять протокол SMB, чтобы задействовать преимущества сетевых адаптеров с поддержкой технологии Remote Direct Memory Access (RDMA) через механизм SMB Direct. Следовательно, единый протокол SMB теперь может использоваться различными типами трафика, и механизм QoS существующей сети будет применяться ко всему трафику SMB.

В системе Windows Server 2012 R2 появился новый детализированный механизм управления полосой пропускания протокола SMB, который позволяет применять отдельные политики QoS к различным типам трафика SMB. Политики могут быть применены к следующим типам трафика: динамическая миграция, виртуальная машина и трафик «по умолчанию» (все остальное).

Для использования механизма управления полосой пропускания SMB необходимо сначала добавить функцию SMB Bandwidth Limit (FS_SMBBW). После этого можно использовать команду Set-SMBBandwidthLimit оболочки PowerShell для настройки ограничений для различных типов трафика SMB:

Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 4GB

Многоабонентский шлюз Hyper-V для виртуализации сети

Виртуализация сети и программно управляемые сети Software-Defined Networking (SDN) как правило являются актуальными темами для большинства организаций. Возможность абстрагировать сетевое взаимодействие с точки зрения виртуальной машины от физического сетевого оборудования привлекательна, но многие организации столкнулись с некоторыми трудностями, пытаясь начать работать с этой технологией. Хотя система Windows Server 2012 предоставляет полнофункциональное решение для виртуализации сетей, которое позволяет задать множество сетей, используя схемы IP-адресации, отличные от схемы физического сетевого оборудования и даже перекрывающие друг друга, при этом в системе нет встроенного механизма для фактического соединения этих виртуальных сетей с другими сетями или даже с Интернетом. Решение заключалось в использовании маршрутизаторов сторонних производителей для соединения виртуальных сетей с другими сетями.

В системе Windows Server 2012 R2 появился механизм Hyper-V Network Virtualization (HNV) Gateway (шлюз Hyper-V для виртуализации сети), предусматривающий в качестве решения программный шлюз. Доступны три режима работы шлюза:

• Перенаправляющий шлюз Forwarding Gateway. Перенаправляющий шлюз можно использовать, если схема IP-адресации виртуальной сети фактически является расширением существующей схемы IP-адресации, и к ней будет осуществляться маршрутизация из других сетей. Шлюз просто перенаправляет пакеты между физическим сетевым оборудованием и виртуальной сетью. Шлюз HNV в режиме перенаправления поддерживает только одну единственную виртуальную сеть. Таким образом, если вы хотите перенаправлять пакеты для 10 виртуальных сетей, вам понадобится 10 отдельных шлюзов HNV.
• Шлюз с трансляцией сетевых адресов, Network Address Translation (NAT) Gateway. Если для схем IP-адресации, используемых в виртуальных сетях, не будет осуществляться маршрутизация на физических устройствах, или если у вас есть виртуальные сети с перекрывающими друг друга схемами IP-адресации, тогда между физическими устройствами и виртуальной сетью должен использоваться механизм NAT. Шлюз HNV в режиме NAT может поддерживать до 50 виртуальных сетей.
• Шлюз «сайт-сайт», Site-to-site (S2S) Gateway. Шлюз S2S организует подключение из виртуальной сети в другую сеть через соединение VPN. В большинстве корпоративных окружений уже существует возможность IP-соединений между площадками, и данная функция не будет востребована. Однако рассмотрим сценарий хоста, в котором владелец хочет обмениваться данными со своей локальной сетью. Шлюз HNV S2S может использоваться для подключения виртуальной сети владельца к его физической сети. Один шлюз может поддерживать 200 туннелей VPN. Из одной виртуальной сети можно установить несколько соединений S2S, чтобы обеспечить избыточность на случай обрыва соединения. Если необходимо установить соединение между локальной виртуальной сетью и виртуальной сетью Windows Azure, я бы выбрал режим S2S.

Хотя механизм шлюза встроен в систему Windows Server 2012 R2, для реального использования данной возможности необходимо задействовать диспетчер System Center Virtual Machine Manager (VMM) 2012 R2. И если подходить к вопросу реалистично, то диспетчер VMM 2012 R2 в принципе необходим для использования технологии виртуализации сети. Для настройки и обслуживания окружения виртуализации сети можно использовать оболочку PowerShell, но временные затраты на обновление таблиц политик при перемещении виртуальных машин между серверами, а также их добавлении или удалении, очень велики. Поэтому я не рекомендую применять данный подход.

Поддержка системы Linux: динамическая память и резервное копирование с согласованием файлов

Платформа Windows Server 2012 сделала огромный шаг в сторону системы Linux. Система Linux стала операционной системой первого класса для гипервизора Hyper-V, а все возможности Hyper-V доступны пользователям Linux. Кроме того, компания Microsoft заложила множество ресурсов в ядро системы Linux, и в результате службы Hyper-V Integration Services стали частью ядра Linux, так что нет необходимости загружать их отдельно. Однако некоторые ключевые возможности, предоставленные пользователям Windows, не были доступны пользователям Linux. Система Windows Server 2012 R2 устраняет этот пробел (хотя несколько прорех еще остается). Ниже описаны ключевые улучшения для системы Linux.

• Усовершенствована поддержка видео и мыши, решена распространенная ранее проблема с двойным указателем мыши.
• Поддержка технологии динамической памяти Dynamic Memory, позволяющей добавлять и убирать память из виртуальных машин Linux в «горячем режиме», аналогично тому, как эта технология работает для пользователей Windows.
• Оперативное резервное копирование, обеспечивающее создание резервных копий с согласованием файлов. В этом подходе по-прежнему есть отличие от систем Windows, в которых реализована возможность резервного копирования с согласованием приложений посредством службы Volume Shadow Copy Service (VSS), позволяющая удостовериться, что на момент резервного копирования у приложений были записанные на диске данные. У системы Linux нет концепции согласованности, аналогичной службе VSS, поэтому возможно резервное копирование только с согласованием файлов, реализуемое через драйвер снимка файловой системы. Специальных действий не требуется – вы просто создаете резервную копию виртуальной машины Linux с хост-сервера Hyper-V через службу Windows Backup или средство резервного копирования, например систему System Center 2012 R2 Data Protection Manager.

Гипервизор Hyper-V предназначен не только для рабочих нагрузок Windows, он отлично подходит и для рабочих нагрузок Linux. Платформа System Center 2012 R2 также обеспечивает поддержку для системы Linux в большинстве своих компонентов, в том числе в системах Configuration Manager, Operations Manager, Virtual Machine Manager, Data Protection Manager и Orchestrator.

Один из ведущих гипервизоров

Система Windows Server 2012 R2 Hyper-V включает в себя множество новых возможностей. Если рассматривать изменения в гипервизоре Hyper-V, начиная от системы Windows Server 2008 и заканчивая системой Windows Server 2012 R2, поражает скачок в масштабируемости и функциональности за такой относительно короткий промежуток времени. Неудивительно, что Hyper-V является одним из двух лидирующих гипервизоров с архитектурой x86.

Не забывайте о том, что компания Microsoft предлагает еще и бесплатную версию системы Hyper-V Server 2012 R2 (technet.microsoft.com/en-us/evalcenter/dn205299.aspx). Бесплатная версия может пригодиться в тех случаях, когда используются только системы Linux или рабочие нагрузки, состоящие исключительно из клиентских операционных систем, такие как VDI. Кроме того, бесплатная версия не требует приобретения лицензий для гостевых операционных систем Windows Server, которые являются частью лицензий Windows Server 2012 R2 Standard и Datacenter.

Экран. Совместное использование файла VHDX

Install-WindowsFeature Failover-Clustering

FLTMC.EXE attach svhdxflt :