Продолжаем знакомиться с новинками флагманской серверной платформы Microsoft – Windows Server 2012 R2. Мы уже рассказывали Вам о новых технологиях Work Folders и Web Application Proxy. Сегодня же мы поговорим о новом функционале гипервизора Hyper-V 4.0 в области обеспечения высокой доступности сервисов – общих VHDX файлах или Shared VHDX. Благодаря технологии Shared VHDX несколько виртуальных машин могут одновременно использовать один общий виртуальный жесткий диск формата VHDX. Тем самым появилась возможность организации гостевых кластеров (на базе только виртуальных машин) без необходимости использования внутри виртуальной машин iSCSI или FC.
Примечание. Напомним, что и раньше на базе Hyper-V можно было строить гостевые кластера, однако такой сценарий предполагал необходимость подключения виртуальной машины к СХД через iSCSI и Virtual Fibre Channel (появившийся в Windows Server 2012 и предоставляющий возможность подключения виртуальной машины через виртуальный HBA модуль непосредственно к хранилищу FC). Таким образом, виртуальной машине давался прямой доступ к хранилищу, что особенно неудобно для хостинг-провайдеров и поставщиков других облачных решений.
Общие VHDX позволяют абстрагироваться от особенностей реализации системы хранения данных, скрывая от администратора ВМ на каком конкретно дисковом массиве и LUN находятся его файлы.
Использование Shared VHDX дисков сохраняет возможность пользования всеми «фичами» Hyper-V: Live Migration, Storage Live Migration и Dynamic Memory.
Системные требования и ограничения технологии Shared VHDX
- Функция Shared VHDX будет работать на Hyper-V версии Windows Server 2012 R2. То же самое касается узла файлового кластера при совместном использовании общих VHDX дисков на Scale-Out File Server.
- В качестве гостевой ОС можно использовать Windows Server 2012 R2 или Windows Server 2012 с последней доступной версией интеграционных компонент Hyper-V.
- Общий диск должен быть обязательно в формате VHDX (формат VHD в подобной конфигурации не поддерживается). В то же время сама гостевая ОС может быть усыновлена как на VHD, так и VHDX диск.
- Поддерживаются виртуальные машины как первого(Generation 1), так и второго поколения (Generation 2).
Возможные конфигурации Shared VHDX
Общие VHDX диски в Windows Server 2012 R2 можно использовать в двух различных конфигурациях:
- Shared VHDX на кластерном CSV. Файлы общих VHDX дисков находятся на CSV томе физического кластера. Том Cluster Shared Volume можно организовать на любом файловом хранилище, которое поддерживается службой кластеризации Windows: iSCSI, FC или Shared SAS
- Shared VHDX в общей папке файлового кластера. Общие VHDX диски располагаются в сетевом каталоге, расположенном на файловом кластере Scale-Out File Server. Отметим, что кластер Scale-Out File Server сам по себе также требует наличия CSV-тома.
Высокая доступность общих VHDX дисков в обоих случаях реализуется за счет хостовой кластеризации, создаваемый на базе этих дисков гостевой кластер обеспечивает высокую доступность приложений и сервисов внутри виртуальных машин.
Настройка Shared VHDX на Windows Server 2012 R2
Перейдем непосредственно к примеру настройки Shared VHDX в Window Server 2012 R2. Естественно, прежде всего, следует создать сами VHDX файлы виртуальных дисков и разместить их по одному из двух описанных выше сценариев.
Созданный VHDX диск необходимо подключить к виртуальной машине с помощью консоли управления Hyper-V или командой PowerShell:
Откройте консоль Hyper-V и в свойствах виртуальной машины добавьте новый диск типа SCSI (SCSI Controller -> Hard Drive -> Add) и укажите путь к vhdx файлу. Затем в расширенных свойствах (Advanced Features)нового диска отметьте опцию Enable Virtual Hard Disk Sharing.
Указанные действия нужно выполнить на всех виртуальных машинах, которые будут участвовать в создаваемом кластере.
Те же самые операции можно выполнить с помощью PowerShell.
- Создаем VHDX диск:
New-VHD -Path D:\CSV\SharedVol.VHDX -Fixed -SizeBytes 100GB
- Добавляем созданный VHDX в виртуальную машину с именем msk-sql01:
Add-VMHardDiskDrive -VMName msk-sql01- D:\CSV\SharedVol.VHDX -ShareVirtualDisk
Внутри виртуальной машины VHDX будет выглядеть как обычный SAS диск. На любой из виртуальных машине кластера, которым презентован данный диск, его необходимо инициализировать и отформатировать в соответствии с вашими потребностями.
С помощью PowerShell новый диск можно инициализировать и отформатировать следующей командой:
Get-Disk | Where PartitionStyle –EQ ‘Raw’ | Initialize-Disk –PassThru | New-Partition –UseMaximumSize | Format-Volume -FileSystem NTFS
Далее новый диск нужно будет добавить в кластер с помощью консоли Failover Cluster Manager.
А затем развернуть кластеризуемую службу, например SQL Server 2012.
Shared VHDX диски помогают организовать более простую и эффективную схему гостевой кластеризации, скрывая архитектуру СХД от администратора гостевого кластера, уменьшая временные затраты системного администратора, необходимые на настройку и конфигурирования iSCSI / FC и снижая административные издержки на управления ролями iSCSI Target.
В предыдущем посте, посвященном обзору Windows Server 2012 R2, я упоминал новую возможность Hyper-V – использование общих VHDX-файлов (Shared VHDX) для создания гостевых кластеров. Сегодня я хотел бы подробнее остановиться на этой теме и обсудить особенности настройки и применения Shared VHDX.
Гостевая кластеризация
Для начала кратко о том, зачем вообще нужна гостевая кластеризация. Большая часть приложений и сервисов, используемых в современной ИТ-инфраструктуре, может быть запущена внутри виртуальных машин (ВМ). Виртуализация дает целый ряд очевидных и не очень преимуществ, перечисление которых выходит за рамки поста. Чем более критичное для компании приложение крутится внутри ВМ, тем более важной становится задача обеспечения высокой доступности такой ВМ.
Обеспечить высокую доступность ВМ можно разместив ее на физическом (хостовом) кластере, в данном контексте – кластере Hyper-V. Выход из строя физического узла кластера, на котором была запущена ВМ, приводит к автоматическому восстановлению ВМ на другом узле кластера. Эта процедура отработки отказа может привести пусть и к кратковременной, но потере связи с ВМ и приложением внутри нее.
Другой метод повышения доступности – объединение в Failover Cluster двух или более ВМ, то есть создание гостевого кластера в том смысле, что кластер создается на базе гостевых ОС. В этом случае мы уже говорим о высокой доступности не ВМ как таковых, а приложения (или приложений) внутри гостевого кластера.
Разумеется, для большей надежности можно сочетать хостовую и гостевую кластеризацию.
Гостевая кластеризация, впрочем как и хостовая, предполагает наличие некоторого общего хранилища. Применительно к виртуальным машинам таким хранилищем до выхода Windows Server 2012 мог выступать iSCSI-storage.
В Windows Server 2012 благодаря Virtual Fibre Channel появилась возможность подключать ВМ через HBA-адаптер хоста непосредственно к FC-storage.
Однако в любом случае для построения гостевого кластера необходимо было предоставить ВМ прямой доступ к хранилищу. Во многих сценариях, например для хостинг-провайдеров, такой вариант является очень неудобным. Общие VHDX-файлы как раз и позволяют эту проблему решить, поскольку абстрагируют ВМ от особенностей реализации СХД. Для создания гостевого кластера к виртуальным машинам подключается нужное количество Shared VHDX, которые и представляют собой общее кластерное хранилище. А где физически, на каком конкретно СХД и LUN-е эти файлы располагаются – это уже дело провайдера.
Поддерживаемые конфигурации и настройка Shared VHDX
С точки зрения реализации описанного подхода можно выделить две основные конфигурации использования Shared VHDX. В первой конфигурации общие VHDX-файлы располагаются на CSV-томе физического кластера. CSV-том, в свою очередь, может быть реализован на любом поддерживаемом службой кластеризации Windows Server блочном хранилище (Fibre Channel, iSCSI, Shared SAS).
Во второй конфигурации VHDX-файлы располагаются в общей папке файлового кластера Scale-Out File Server. Последний, замечу, также предполагает наличие CSV-тома. Как видно, и та, и другая конфигурация в итоге приводят к сочетанию хостовой и гостевой кластеризации. Хостовая кластеризация повышает доступность общих VHDX, создаваемый затем поверх гостевой кластер обеспечивает высокую доступность сервисов и приложений внутри ВМ.
Для настройки Shared VHDX прежде всего, конечно, необходимо создать один или несколько VHDX-файлов и расположить их, используя одну из перечисленных выше конфигураций. Затем подключить Shared VHDX можно в консоли Hyper-V, командлетами PowerShell или с помощью сервисного шаблона (service template) в System Center 2012 R2 Virtual Machine Manager.
В консоли Hyper-V это делается путем добавления нового SCSI-диска: в свойствах ВМ выбираете SCSI Controller, затем Hard Drive, нажимаете кнопку Add, указываете путь к VHDX-файлу, после чего выбираете Advanced Features и помечаете соответствующий чекбокс.
Повторяете процедуру для всех ВМ, которые планируется объединить в кластер.
Тоже самое можно сделать в PowerShell следующими командлетами:
New-VHD -Path C:\ClusterStorage\Volume1\Shared.VHDX -Fixed -SizeBytes 30GBAdd-VMHardDiskDrive -VMName Node1 -Path C:\ClusterStorage\Volume1\Shared.VHDX -ShareVirtualDiskAdd-VMHardDiskDrive -VMName Node2 -Path C:\ClusterStorage\Volume1\Shared.VHDX –ShareVirtualDiskВ VMM 2012 R2 в сервисном шаблоне в разделе Hardware Configuration необходимо также добавить SCSI-диск, указать путь к VHDX-файлу и пометить чекбокс Share the disk across the service tier. При развертывании ВМ на основе такого шаблона VMM подключит указанный файл в качестве Shared VHDX.
Какой бы вариант вы не выбрали, внутри ВМ подключенный VHDX будет выглядеть как обычный SAS-диск.
Требования к Shared VHDX
Необходимо помнить следующие требования к Shared VHDX:
- Файлы должны быть обязательно VHDX, формат VHD для shared-конфигурации не поддерживается. При этом сама гостевая ОС вполне может быть установлена на VHD-диск.
- На хостах Hyper-V, а в случае использования Scale-Out File Server и на узлах файлового кластера, должна быть установлена версия Windows Server 2012 R2.
- Гостевой ОС может быть Windows Server 2012 R2 или Windows Server 2012 с последней версией интеграционных компонент.
- Поддерживаются как ВМ первого поколения (Generation 1), так и второго (Generation 2).
Диагностика и тестирование
Для диагностики возможных проблем в Performance Monitor добавлен новый объект Hyper-V Shared VHDX с набором различных счетчиков, которые вы можете анализировать на хостах Hyper-V.
Кроме того, добавлены новые журналы, просмотр которых возможен, как обычно, с помощью Event Viewer,
либо PowerShell:
Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/OperationalGet-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/ReservationНаконец, для целей тестирования, изучения, разработки есть возможность использовать «специальную» конфигурацию Shared VHDX. Для этой конфигурации достаточно одного физического хоста с Windows Server 2012 R2 и поднятой ролью Hyper-V, на котором и можно расположить общие VHDX-файлы, не создавая кластеры с CSV-томами и пр. Чтобы реализовать подобный вариант вам нужно:
- Установить службу Failover Clustering
Install-WindowsFeature Failover-Clustering - Вручную подключить фильтр Shared Virtual Disk для раздела, на котором будут располагаться общие VHDX-файлы, например для диска D: это будет выглядеть как
FLTMC.EXE attach svhdxflt D:
Но помните, что это неподдерживаемая конфигурация и применять ее в реальной среде не следует.
Таким образом, механизм общих VHDX-файлов помогает реализовать более эффективную схему гостевой кластеризации и, в конечном итоге, повысить доступность критически важных приложений и сервисов вашей инфраструктуры. Особенно полезной эта технология может оказаться для частных облаков и хостинговых сценариев.
Надеюсь, материал был полезен.
Спасибо!
Статья о второстепенных новых возможностях, в том числе улучшениях в механизмах хранения данных и сетевого взаимодействия, шлюзе виртуализации сети и, наконец, нововведениях, предназначенных для виртуальных машин с системой Linux
Первую часть статьи «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
Вопросы о VHDX
VHDX на локальном хранилище Windows Server 2012 R2
В. Можно ли задействовать файлы VHDX на локальном хранилище в Windows Server 2012 R2?
О. Нет. Для функциональности общего VHDX, которая открывает доступ к VHDX-файлу нескольким виртуальным машинам, обеспечивая общее хранилище при кластеризации гостевых систем, требуется файл VHDX, который хранится в одном из двух мест:
- общий том кластера (CSV);
- масштабируемый файловый сервер (SoFS) SMB 3 Windows Server 2012 R2.
Последнее означает, что внутреннее хранилище общего ресурса SMB — общий том кластера. Таким образом, общий ресурс SMB 3, отличный от SoFS, не может быть использован, равно как и масштабируемый файловый сервер SMB 3, размещенный на Windows Server 2012.
Причина обязательного присутствия CSV в том, что программный код для общего доступа к файлу VHDX и арбитража доступа к общим блокам реализован как часть CSV-уровня в Windows Server 2012 R2.
Ручная загрузка драйвера Shared VHDX в Windows Server 2012 R2
В. Существует ли способ принудительно загрузить драйвер общего файла VHDX на томе, который не является общим томом кластера?
О. В ответе на предыдущий вопрос отмечалось, что общий VHDX поддерживается только на общем томе кластера (CSV) или масштабируемом файловом сервере (SoFS), выполняемом в среде Windows Server 2012 R2. Это верно для поддерживаемых сценариев.
Можно принудительно загрузить и присоединить драйвер фильтра общего VHD к тому, который не является общим томом кластера. Но такая загрузка просуществует только до того момента, пока диск не будет переведен каким-нибудь образом в автономный режим. После этого придется заново повторить загрузку и присоединение. Обратите внимание, что этот метод не поддерживается и даже не тестировался компанией Microsoft. Его следует использовать только в простых лабораторных сценариях при отсутствии общего тома кластера.
1. Установите функцию отказоустойчивой кластеризации с помощью диспетчера сервера или Windows PowerShell:
Install-WindowsFeature Failover-Clustering
2. Выполните следующую команду, указав том, к которому присоединяется фильтр общего VHDX:
FLTMC.EXE attach svhdxflt :
Динамическая миграция с использованием общего файла VHDX
В. Как выполнить динамическую миграцию без кластеров и общих дисков (shared-nothing live migration) при использовании общего файла VHDX в Windows Server 2012 R2?
О. К сожалению, выполнить динамическую миграцию виртуальных машин без кластеров и общих дисков с использованием общего виртуального жесткого диска (VHDX) нельзя. Чтобы изменить местонахождение общего файла VHDX, необходимо закрыть виртуальные машины, а затем переместить файлы.
Изменение размеров кластерного файла VHDX
В. Как выполнить динамическое изменение размеров кластерного VHDX-файла?
О. В Windows Server 2012 R2 появилось несколько удачных дополнений к VHDX. Одно из них — возможность динамически изменить размер VHDX-файла, присоединенного через SCSI-контроллер на виртуальной машине; другое — совместное использование VHDX, присоединенного через SCSI-контроллер, несколькими виртуальными машинами, при условии, что VHDX-файл хранится на общем томе кластера (CSV) или масштабируемом файловом сервере (который использует CSV). Благодаря совместному использованию VHDX-файла несколькими виртуальными машинами становятся доступными новые возможности кластеризации гостевых систем (кластер создается из виртуальных машин) с общим хранилищем без применения iSCSI или виртуального Fibre Channel.
В Windows Server 2012 R2 невозможно динамически изменять размер VHDX-файла, отмеченного как общий. Чтобы изменить размер VHDX-файла, необходимо закрыть все виртуальные машины, использующие VHDX-файл, изменить размер, а затем перезапустить виртуальные машины.
Работа общего файла VHDX c Windows Server 2008 и Server 2008 R2
В. Будет ли общий виртуальный жесткий диск (VHDX) работать с Windows Server 2008 и Server 2008 R2?
О. Общий файл VHDX поддерживается для гостевых операционных систем, функционирующих с Windows Server 2012 и Windows Server 2012 R2 (должны быть активными службы интеграции Hyper-V Windows Server 2012 R2). В гостевой операционной системе общий VHDX выглядит как общее хранилище SAS, поэтому ничто не мешает ему работать с Windows Server 2008 и Windows Server 2008 R2. Я выполнил успешное тестирование с использованием Windows Server 2008 R2 со службами интеграции Hyper-V Windows Server 2012 R2. Однако такой подход не поддерживается производителем.
The VHDX format includes performance-enhancing features and capabilities that let virtual servers recover VMs with little to no data loss.
By
- Stephen J. Bigelow,
Published: 20 Nov 2013
What is a virtual disk and what are the characteristics of a virtual disk under Windows Server 2012 R2?
A virtual disk is essentially a single file that is placed on a physical hard drive. The virtual disk file is designed to capture the complete state of the virtual machine residing in server memory and represent that content in an established disk file format. Windows Server 2012 R2 and Hyper-V employs the extended virtual hard disk (VHDX) file format, so files of virtual hard disks can be identified with a .VHDX extension.
Virtual hard disks are critical to virtualization. When a server powers on, each VM is loaded into server memory and launched from its corresponding VHDX file. As the VM operates, the VHDX file can be updated to reflect data or state changes. The VHDX file can be copied to remote storage to provide a backup or disaster recovery copy of the VM. A VHDX file can also be migrated or copied to other servers, allowing VMs to migrate or duplicate within the environment (as software licensing permits). Virtual hard disks are also well suited for centralized storage (rather than existing on each local server).
The virtual hard disk format has evolved to reflect changing needs of virtual machines and data center resources. One notable change is the increase in VHDX size from 2 TB to 64 TB, allowing for enormous virtual machines and data elements. This can make virtual disks better suited for applications such as databases or in-memory analytics.
Even with well-designed, redundant, battery and backup power, the unexpected loss of utility power always carries the potential for server crashes that can corrupt storage data — especially data that changes regularly, such as virtual disk files. The VHDX format now logs all changes to the VHDX metadata. Windows Server 2012 R2 allows the creation of differencing disks so that one VHDX file can record the changes that take place on another. This tracks all changes so that unwanted or problematic changes can be reversed. This combination of capabilities allows the virtual server to recover its VMs with little (if any) data or state loss.
The VHDX format also introduces a variety of performance-enhancing features. For example, the VHDX file can be aligned with sectors on the physical hard drive to optimize performance on large drives, and file data can be represented more efficiently for smaller effective file sizes.
Dig Deeper on
-
What is a virtual hard disk (VHD)?
By: Rahul Awati
-
How PowerShell can automate Hyper-V deployments
By: Stuart Burns
-
Virtual Machine Disk format (VMDK)
By: Rahul Awati
-
What is a virtual hard drive?
By: Brien Posey
The most common question on clusters is do I need shared storage ? Yes you do oh such a huge cost eh are you using windows server 2012 R2 no not yet.
Well you should use 2012R2 one of the best options is Shared VHDX
Hyper-V V3.0 ( windows server 2012 R2 )makes it possible to share a virtual hard disk file between multiple virtual machines. Sharing a virtual hard disk file (.vhdx) provides the shared storage that is necessary for a Hyper-V guest failover cluster.
Sharing a virtual hard disk file (.vhdx) means that you can create and manage a guest failover cluster to protect the application services running inside your virtual machines. Before Windows Server 2012 R2, if you wanted to create a Hyper-V guest failover cluster, you needed to expose your storage topology to the virtual machine.
Starting in Windows Server 2012 R2, you can deploy a Hyper-V guest failover cluster that is no longer bound to your storage topology. You can implement a guest failover cluster by using a shared virtual hard disk, Fibre Channel, Server Message Block (SMB), Storage Spaces, or ISCSI storage options. Shared virtual hard disks are only available in Windows Server 2012 R2. Hyper-V makes it possible to share a virtual hard disk file between multiple virtual machines. Sharing a virtual hard disk file (.vhdx) provides the shared storage that is necessary for a Hyper-V guest failover cluster.
Using a shared virtual hard disk is ideal for the following situations:
- SQL Server database files.
- File server services running within a virtual machine.
- Database files that reside on shared disks.
In this scenario I have a 64 node Cluster based on Shared VHDX. Let me show you how you should start.
First we need some virtual disk files VHDX and the quickest and easiest way to do this is by powershell
If you run this line you will create 10 Virtual disk on the M drive with a fixed size of 4 GB. if you want other options use the get-help New-VHD
1..10 | % { New-VHD -Path m:\ShareData$_.VHDX -Fixed -SizeBytes 4GB }
This is Cool in a few seconds several disks. yes but what now well If you have a cluster already then you can add the disk to the VM and use them if not you can create a cluster.
But Robert adding the disk is so much work, I know. Imaging you have 64 nodes this will take days yes how fun is that User PowerShell
In the following line you can easy add the disk to the VM
1..10 | % { $p = «m:\shareData» + $_ + «.VHDX» ; 10..66 | % { $v = «Demo» + $_; Write-Host $v, $p; Add-VMHardDiskDrive -VMName $v -Path $p -ShareVirtualDisk } }
But you can also share a disk in the GUI and the best part is it can be done live.
As you can see several steps are needed to do this. just with one line in PowerShell it is done.
Now that We added the Disks We can use the disks.
Easy as Get-ClusterAvailableDisk | Add-ClusterDisk or in the GUI
Now that the disks are in place We can create a a sample File server that is using this disk.
I installed already the file server role on all the nodes. not by hand
1..9 | % { Install-WindowsFeature -computername Demo0$_ File-Services, FS-FileServer, Failover-Clustering }
1..9 | % { Install-WindowsFeature -computername Demo0$_ RSAT-Clustering -IncludeAllSubFeature }
So the first nine servers are file servers. but keep in mind if you do this you have to adjust the ownership, creating a file server every node will own this and if not all the nodes have the FS role installed you will get in trouble !
Now you can add the share to the fileserver. Remember do this in the Cluster Manager and not on the share it self
Now we have a File server on a shared VHDX isn’t that cool.
\\DemoFS01\Fileshare01
Robert Smit is Senior Technical Evangelist and is a current Microsoft MVP in Clustering as of 2009.
Robert has over 20 years experience in IT with experience in the educational, health-care and finance industries.
Robert’s past IT experience in the trenches of IT gives him the knowledge and insight that allows him to communicate effectively with IT professionals
who are trying to address real concerns around business continuity, disaster recovery and regulatory compliance issues. Robert holds the following certifications:
MCT — Microsoft Certified Trainer, MCTS — Windows Server Virtualization, MCSE, MCSA and MCPS. He is an active participant in the Microsoft newsgroup community and is currently focused on Hyper-V, Failover Clustering, SQL Server, Azure and all things related to Cloud Computing and Infrastructure Optimalization.
Follow Robert on Twitter @ClusterMVP
Or follow his blog https://robertsmit.wordpress.com
Linkedin Profile Http://nl.linkedin.com/in/robertsmit
Robert is also capable of transferring his knowledge to others which is a rare feature in the field of IT. He makes a point of not only solving issues but also of giving on the job training of his colleagues.
A customer says » Robert has been a big influence on our technical staff and I have to come to know him as a brilliant specialist concerning Microsoft Products. He was Capable with his in-depth knowledge of Microsoft products to troubleshoot problems and develop our infrastructure to a higher level. I would certainly hire him again in the future. »
Details of the Recommendation: «I have been coordinating with Robert implementing a very complex system. Although he was primarily a Microsoft infrastructure specialist; he was able to understand and debug .Net based complext Windows applications and websites. His input to improve performance of applications proved very helpful for the success of our project
View all posts by Robert Smit [MVP]