Глава 4. Практический опыт хранилищ

Хранилище в Hyper-V это в первую очередь не про ёмкость; это про производительность. Перестаньте мыслить в терминах ёмкости таких, как гигабайты и терабайты данных и вычислять IOPS прямо сейчас, когда составляете таблицу опций хранилища Hyper-V. Конечно, вам всё ещё необходимо быть уверенным что у вас достаточно ёмкости. Однако, обычно это никак не влияет ни на архитектуру ни на стоимость при больших масштабах, так как высокая ёмкость дисковых устройств доступна по очень низкой цене. Существую очень различные подходы для проектирования виртуального хранилища.

В более ранних версиях Windows Server и других продуктов виртуализации, в качестве серверной основы хранения применялись системы NAS для сред меньшего размера и системы SAN корпоративного масштаба. Имея соединения Fibre Channel или iSCSI к серверным системам виртуализации, они предоставляли централизованное хранилище для всех узлов в кластере, обеспечивая такие возможности, как миграция в реальном времени ВМ и отказоустойчивость кластера.

Утрата узлов в кластере не влияла на целостность и доступность всех систем хранения. LUN (Logical Unit Numbers) систем SAN/ NAS выступали в роли локальных дисков или хостов Hyper-V. Первоначальные архитектуры появились с подходом одной ВМ на LUN, а затем свалились в в современные решения для Кластера совместно использующего тома, которые размещают множество ВМ в LUN. Системы SAN из NAS систем для небольших установок Hyper-V всё ещё наиболее используемые архитектуры хранения в наши дни и полностью поддерживаются самой последней версией Hyper-V. Применение совместно используемых томов кластера было сильно улучшено и является вариантом развёртывания по умолчанию для томов хранения Hyper-V в SAN.

Более современные подходы используют имеющиеся на борту возможности управления хранением Windows Server. Усиление производительности SMB3 и опций доступности Пространств хранения (Storage Spaces) подключаемыми JBOD (just a bunch of disks, простого массива дисков), или непосредственно подключаемых устройств хранения позволяет вам создавать IOPS для Hyper-V в широком диапазоне при относительно низкой стоимости. Пространства хранения (Storage Spaces) Microsoft позволяют вам использовать наилучшие функции, известные вам в SAN, всего лишь с одной или более серверных систем, работающих под Windows Server. Вы можете применять традиционные LUN за SOFS (Scale-Out File Servers, файловыми серверами внешнего масштабирования) или применять Пространства хранения (Storage Spaces) с жёсткими дисками, подключаемыми к узлам хранения. Эти жёсткие диски присоединяются к системе как JBOD или подключаются внутри к вашей системе без использования аппаратных контроллеров RAID.

Доступность на уровне хранения осуществляется на программном уровне самим Windows Server. Пространства хранения (Storage Spaces) предлагают масштабируемую производительность; причём это не только для малых решений бизнеса. ВМ больше не помещаются в LON; вместо этого они с выгодой для себя применяют Пространства хранения и совместно применяемые тома кластера. Мы увидим позже в этой главе что две существующие сегодня в Windows Server 2016 модели для реализации программно управляемого хранилища Hyper-V - модели рассредоточения и гиперконвергентности.

Модель рассредоточения пользуется преимуществами SOFS при нескольких файловых серверах. Эти файловые сервера могут подключаться к обычным совместно используемым JBOD или с обычными внутренними устройствами хранения с применением Непосредственно подключаемых пространств хранения (Storage Spaces Direct). С другой стороны, в гиперконвергентной модели гипервизоры также являются узлами хранения. Гипервизоры подключаются к устройствам хранения, либо JBOD, или внутренних для системы и получают преимущества от применения Непосредственно подключаемых пространств хранения чтобы сделать уровень хранения более высокодоступным (позже в этой главе мы обсудим Непосредственно подключаемые пространства хранения).

Для обоих решений нет необходимости в дорогостоящих SAN или даже RAID контроллерах для достижения высокой доступности и хорошей производительности. Пространства хранения (Storage Spaces) выстраивают законченную абстракцию виртуализации хранения присоединённых дисков, которые даже способны автоматически предоставлять многоуровневое хранение (tiering) с применением SSD и классических жёстких дисков в одном и том же JBOD для оптимальной производительности.

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

Одним из самых критичных обсуждений в процессе проектирования хранения для Hyper-V является вопрос следует ли застрять на традиционной модели SAN или запрыгнуть в вагон архитектуры Пространств хранения (Storage Spaces) Microsoft. Оба решения могут выполнять основную работу, т.е. предоставлять IOPS для ВМ без каких - либо проблем. Выполнив множество проектов, применяющих обе архитектуры, приведу некоторое руководство из реального мира, которое я применяю при проектировании хранения.

Наипервейший и наиважнейший принцип проектирования: не используйте системы без избыточности в промышленных решениях для кластеров Hyper-V - не должно быть никаких единственных узлов аппаратного хранения и никаких общих точек отказа в вашем проекте хранения. Если вы не можете удовлетворить этим требованиям, не планируйте высокую доступность для Hyper-V. Вместо этого планируйте восстановление после сбоев. Выведите из кластера свои серверы Hyper-V и реплицируйте ВМ между своими узлами в небольшой установке или между кластерами меньшего размера в более крупных средах через Реплики Hyper-V. Сказав это, давайте сосредоточимся на выборе решения.

Технически существует возможность применять SOFS вместе с SAN. Однако при адаптации производителей к протоколам SMB3 это неэффективный сценарий игры вдолгую в большинстве случаев, и мы сосредоточимся на использовании Пространств хранения (Storage Spaces) с совместно используемыми JBOD и Непосредственно подключаемыми пространствами хранения (Storage Spaces Direct) с прямым подключением хранилищ. Существует несколько архитектур для SAN, которые вам следует усилить, в частности, SAN Fibre Channel, в которых Hyper-V хосты могут иметь только адаптеры Ethernet. Опора на SOFS как на общую точку входа для среды хранения уменьшает сложность вашей конфигурации вычислительных узлов через размещение требований всех производителей хранилищ на узлах хранения в вашем кластере SOFS. Вы также можете помещать в одном кластере SOFS несколько SAN и предоставлять согласованное управление представление опыта хранения для платформы виртуализации, что даст вам возможность применять любое разнообразие аппаратных средств производителей систем хранения. Однако, в большинстве случаев применения Windows Server 2016, когда вы хотите продолжить с Пространствами хранения, ваши жёсткие диски будут размещены в совместно используемых JBOD или будут напрямую подключаться к узлам хранения и больше не будут располагаться в SAN.

В то время, как системы SAN присутствуют на протяжении примерно 15 лет, Пространства хранения (Storage Spaces) появились только в Windows Server 2012. Если вы работаете в большой компании и имеете в своём распоряжении архитектуру SAN по всей своей компании, содержащую различные приложения, операционные системы и требования, закрепитесь за SAN. Если вы сопровождаете единообразную архитектуру хранения во всех этих различных областях и опробовали процессы, построенные вокруг них, не меняйте их для Hyper-V. Убедитесь, что вы используете приспособленную для SAN Hyper-V с Fibre Channel или iSCSI и продолжайте использовать её.

Для всех прочих подходов проектирования стартуйте с начального плана применения Пространств хранения (Storage Spaces). Если вы обнаружите какую- либо причину не применять его, переключитесь на основанное на SAN решение, однако ваш первичный подход долже включать Пространства хранения из- за его меньшей стоимости. Не беспокойтесь о производительности. Пространства хранения способны предоставлять более миллиона IOPS поверх NIC с 10GbE, если вам это действительно требуется (http://bit.ly/2aOgNTK). Пространства хранения предлагают конфигурации кластера Активный/ Активный, усиливающин производительность всех узлов хранения кластера с дополнительными преимуществами прозрачной отказоустойчивости. Всё это выполняется возможностями Windows Server 2016; не требуются никакие добавления сторонних разработчиков. Как уже было сказано, это всё также управляется Windows Server, привлекая все хорошо известные инструменты управления, такие как Server-Manager и PowerShell. Таким образом проще интегрировать Пространства хранения в существующей среде Microsoft, чем при использовании SAN, причём гораздо проще управлять Пространствами хранения, чем SAN.

Более подробными причинами не применять Пространства хранения (Storage Spaces) в процессе проектирования являются расширенные требования. Пространства хранения предоставляются вам с голым железом для Hyper-V и базами данных SQL. Если вам нужно хранилище для других целей, другой операционной системы или дополнительных возможностей на уровне хранения, таких как дедупликация для серверного применения, тогда Пространства хранения будут не верным решением для вас.

Если вы хотите недорогого и быстрого решения хранения на базе Windows с возможностями SAN, включая дедупликацию данных, динамическое выделение, а также аппаратную ODX (Offloaded Data Transfer, разгруженный обмен данными), вашей правильной дорогой будут Пространства хранения Microsoft. Однако, если вы в настоящее время применяете SAN а они не предлагают возможностей SMB3, может оказаться хорошим вариантом использовать SOFS совместно с существующей SAN.

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

Перед разговором о Пространствах хранения (Storage Spaces), я бы хотел обсудить ReFS. В настоящее время Hyper-V поддерживает две файловые системы, классическую NTFS и более новую ReFS (Resilient File System). До выхода Windows Server 2016 я рекомендую чтобы вы применяли NTFS, так как ReFS недостаток некоторых ключевых возможностей и большинство приложений резервного копирования имеют с ней проблемы. В настоящее время, в Windows Server 2016, Microsoft привнёс целый ряд новых свойств в ReFSv2, такие как ускоренные операции VHDX. Эти возможности позволяют нам ускорять операции в подобных сценариях:

Когда вы расширяете VHD(X), расположенный в разделе NTFS, файловая система заполняла нулями новые блоки. В ReFS новые блоки вместо этого являются метаданными. Благодаря ReFS теперь вам потребуется от 1 до 5 секунд для создания большого VHDX вместо многих минут в NTFS.

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

Однако, при форматировании CSV в ReFS, этот последний будет работать в переназначенном вводе/ выводе. Это означает, что каждый ввод/ вывод отправляется через вашу сетевую среду. Эта операция не оказывает влияния на производительность в реализация Непосредственно подключаемых пространств хранения, так как требуются адаптеры RDMA. Однако в прочих реализациях, таких как NAS или SAN они могут глубоко влиять на вашу производительность.

По этой причине я настоятельно рекомендую чтобы вы применяли ReFS для хранения ВМ в Windows Server 2016, когда же вы реализуете непосредственно подключаемые пространства хранения во всех прочих реализациях, продолжайте применять NTFS.

В Hyper-V является хорошей практикой форматировать тома блоками с размером 64кБ для оптимальной производительности. Выравнивание разделов обрабатывается автоматически, поэтому вам не приходится беспокоиться об этом в самых последних версиях Hyper-V.

Способом улучшить SOFS является применение Пространств хранения (Storage Spaces) с многоуровневым хранением. Наличие некоторого совместно используемого JBOD с SSD и HDD, подключённого к вашим SMB3 файловым серверам делает доступной великолепную производительность ввода/ вывода. Часто читаемые данные будут кэшироваться в ваших SSD, а данные долгого времени хранения будут архивироваться на HDD по умолчанию, без какой- либо необходимости ручного редактирования, что будет иметь результатом великолепную поддержку ускорения производительности.

В Windows Server 2016, применяющие JBOD Пространства хранения должны быть рассмотрены для применения когда у вас уже имеется оборудование (файловые серверы и совместно используемые JBOD). Если вы не желаете инвестировать средства в хранилище, поскольку у вас уже имеется оборудование, Пространства хранения с совместно используемым JBOD является путём, которого следует придерживаться. Если же вы планируете приобретение нового оборудования, я рекомендую вам применять Непосредственно подключаемые пространство хранения (Storage Spaces Direct), которые не требуют совместно применяемого JBOD. Более того, чтобы обеспечить высокую доступность, для файлового сервера необходимо выделить два порта SAS. Таким образом, общее число файловых серверов ограничивается общим числом портов SAS в совместно применяемом JBOD. Например, если вы приобрели совместно используемый JBOD с шестью портами SAS, вы можете подключить только три файловых сервера. Я не рекомендую вам применять SAS для коммутации между файловыми серверами и совместно использовать JBOD по причинам производительности.

Чтобы создать Пространства хранения с множеством уровней (tiering) при помощи PowerShell, выполните следующие шаги:

$PhysicalDisks = Get-PhysicalDisk -CanPool $True `
New-StoragePool -FriendlyName VMStore01 `
    -StorageSubsystemFriendlyName"Storage Spaces*" `
    -PhysicalDisks $PhysicalDisks
 	   

Установите атрибуты SSD и HDD следующим образом:

$tier_ssd = New-StorageTier -StoragePoolFriendlyName VMStore01 `
    -FriendlyName SSD_TIER `
    -MediaType SSD
$tier_hdd = New-StorageTier -StoragePoolFriendlyName VMStore01 `
    -FriendlyName HDD_TIER `
    -MediaType HDD
 	   

Теперь вы выполнили все установки для великолепной производительности Пространств хранения, которую вы можете использовать либо в совместных ресурсах SMB3, либо в комбинации с SOFS.

Если вы не желаете целиком довериться (по моему мнению очень хорошо работающее) автоматическое кэширование (tiering), вы можете также вручную помечать файлы с частым доступом в уровень SSD применяя следующее:

Set-FileStorageTier -FilePath d:\Fastfiles\fast.file `
    -DesiredStorageTier $tier_ssd
 	   

В Windows Server 2016 мы можем использовать непосредственно подключаемые устройства хранения, такие как JBOD или внутренние для ваших узлов хранения для создания рения хранения с высокой доступностью. Такие устройства хранения могут подключаться через SATA, NVMe или SAS. Устройства хранения могут быть SSD или HDD. Для поддержки высокой доступности Непосредственно подключаемые пространства хранения (Storage Spaces Direct) усиливают свойства отказоустойчивого кластера (Failover Cluster) Windows.

В кластере необходимо минимум два узла, однако при этом будут доступны не все функции Непосредственно подключаемых пространств хранения. Для использования виртуальных дисков с множественным демпфированием (Multi-Resilient, которые мы обсудим позже в этой главе), вам необходимо минимум четыре узла. Если вам нужно это свойство для получения максимальной производительности в данном решении, я рекомендую чтобы вы реализовали, по крайней мере, кластер из четырёх узлов. Непосредственно подключаемые пространства поддерживают кластер с максимумом в 16 узлов.

Что касается вашей сетевой среды, требуются сетевые адаптеры с, по крайней мере, 10Gb/s адаптерами, причём с поддержкой возможностей RDMA (Remote Direct Access Memory), DCB (DataCenter Bridging), а также PFC (Priority Flow Control). RDMA должен быть либо RoCE (RDMA over Converged Ethernet) Стек протоколов Mellanox OFED}, либо iWARP (internet Wide Area RDMA) {Прим. пер.: см. Стек протоколов Intel}. Чтобы построить конвергентность сети с управляемым сетевой средой, миграцией в реальном времени или сетями ВМ, я рекомендую чтобы вы применяли RoCE. Такие производители, как Mellanox, поддерживают эти виды возможностей действительно замечательно. По своему опыту я рекомендую Mellanox, много документации Microsoft объясняет реализацию сетевых адаптеров Mellanox, следовательно они хорошо поддерживаются Microsoft.

В отличие от HBA Fibre Channel или iSCSI у вас нет необходимости устанавливать MPIO для поддержки высокой доступности. Вместо этого Непосредственно подключаемые пространства хранения усиливают многоканальность SMB, что автоматически настраивается в Windows Server 2016 для использования всей полосы пропускания каждого сетевого адаптера, вовлечённого в обмен данными хранилища.

Если вы желаете реализовать гиперконвергентную модель, Microsoft рекомендует узлы с по крайней мере 128ГБ оперативной памяти и двухразъёмные современные ЦПУ, такие как Intel Xeon семейств E5 v3 или v4. Это обусловлено тем, что память и ЦПУ будут активно потребляться виртуальными машинами, а также необходимы для нужд хранилища.

Что касается контроллеров хранения, вам нужны простые HBA (Host Bus Adapter) для SAS или SATA устройств без функциональности RAID. Если вы используете HBA с функциональностью RAID, вы можете ухудшить производительность так как ваши контроллеры хранения будут перехватывать ввод/ вывод между операционной системой и устройствами хранения. {Прим. пер.: Кроме того, скорее всего, будут недоступны функции отслеживания состояния дисковых устройств и их диагностики, например, S.M.A.R.T.}

Как уже обсуждалось ранее, Непосредственно подключаемые пространства хранения (Storage Spaces Direct) могут быть развёрнуты в разукрупнённой модели. Это означает, что вы реализуете некоторые файловые серверы с их собственными устройствами хранения. В последствии Непосредственно подключаемые пространства хранения используются для агрегации устройств хранения, таких как HDD или SSD и после этого создают некоторое кластерное совместно используемое хранилище для хранения виртуальных машин. Благодаря использованию Непосредственно подключаемых пространств хранения у вас нет необходимости применения совместно используемых устройств JBOD, однако вы можете подключать по одному JBOD к узлу или применять внутренние устройства хранения, подключаемые с применением SATA, SAS или PCI Express {Прим. пер.: а также NVMe} портов.

Когда ваше решение реализовано, вы развёртываете SOFS с тем, чтобы Hyper-V узлы могли осуществлять доступ к хранилищу при помощи протокола SMB3.

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

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

Для реализации такого решения хранения просто следуйте данным этапам:

Теперь ваш кластер файловых серверов готов для хранения виртуальной машины VHDX. При создании ВМ из гипервизора просто определяйте совместно используемый путь вместо имени локального хранилища.

В отличие от разукрупнённой модели, ваши устройства хранения помещаются внутри самих узлов Hyper-V. Это означает, что когда вы добавляете узел в свой кластер, вы добавляете ресурсы вычислений и хранения. Это решение великолепно для гибкости, масштабируемости и работы в автоматическом режиме. Гиперконвергентную модель следует применять когда вы хотите размещать частное облако в своём центре обработки данных. Благодаря её гибкости и простоте вы можете добавлять узлы по запросу, как практически любой поставщик Облачных решений.

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

Как вы можете видеть, Hyper-V и хранилище устанавливаются на одних и тех же узлах. Если у вас имеется быстрая сетевая среда с более чем 10Gb/s, вы сможете объединить все сетевые среды (мы обсудим сетевую конвергенцию в Главе 5, Практический опыт сетевой среды).

Расположенные в каждом узле устройства хранения объединяются в пул хранения. Это возможно благодаря функциональности Непосредственно подключаемых пространств хранения (Storage Spaces Direct).

Каждый узел работает как гипервизор и как узел хранения. Поэтому позаботьтесь о своих ЦПУ и объёме оперативной памяти на каждом узле. Microsoft рекомендует по крайней мере сервера с двумя разъёмами ЦПУ под Intel Xeon семейства E5 v3 или v4 с минимальным объёмом памяти 128ГБ.

Это решение очень просто развернуть:

На данном этапе у вас имеется совместно используемый в кластере том готовый к хранению ваших виртуальных машин. Это решение проще в развёртывании чем разукрупнённая модель поскольку у нас нет необходимости в роли кластера SOFS.

Для реализации Непосредственно подключаемых пространств хранения (Storage Spaces Direct) Microsoft поддерживает множество различных устройств хранения. Вы можете смешивать NVMe SSD с SATA SSD, или SATA SSD с SATA HDD, и даже смешивать NVMe SSD с SATA SSD и SATA HDD (мы обсудим такую специальную конфигурацию в разделе Виртуальные диски с множественным демпфированием).

Непосредственно подключаемые пространства хранения требуют производительные и ёмкие устройства хранения. Наиболее предпочтительные производительные устройства, такие как SSD или HDD будут настраиваться как устройства кэширования. Прочие будут применяться в качестве ёмкостных и будут хранить виртуальные машины. Microsoft поддерживает следующие конфигурации. В зависимости от настроек устройств хранения изменяется поведение кэширования. Это обусловлено тем, что устройства HDD нуждаются в кэшировании чтения, в то время как SSD достаточно быстры и требуют только кэширования записи. Особый случай с конфигурацией трёх устройств хранения будет обсуждён в следующем разделе. Приводимая ниже таблица поясняет все поддерживаемые конфигурации в Непосредственно подключаемых пространствах хранения и соответствующее поведение кэширования:

Конфигурация хранилища	Устройства кэширования	Устройства ёмкости	Поведение кэширования
SATA SSD + SATA HDD	Все SATA SSD	Все SATA HDD	Чтение + Запись
NVMe SSD + SATA HDD	Все NVMe SSD	Все SATA HDD	Чтение + Запись
NVMe SSD + SATA SSD	Все NVMe SSD	Все SATA SSD	только Запись
NVMe SSD + SATA SSD + SATA HDD (необходимо 4 узла)	Все NVMe SSD	Все SATA SSD Все SATA HDD	Запись для SATA SSD Чтение + Запись для SATA HDD

Устройства хранения ёмкости связываются с устройствами кэширования карусельным образом (round-robin). Если некоторое кэширующее устройство отказывает, все остальные автоматически настраиваются на устройства хранения ёмкости. Из - за использования карусельного алгоритма Microsoft также рекомендует чтобы число устройств хранения ёмкости было кратным общему числу кэширующих устройств (например, два кэширующих устройства на 10 устройств хранения ёмкости). Microsoft рекомендует устанавливать по крайней мере два кэширующих устройства и четыре устройства хранения объёма в каждом сервере. {Прим. пер.: подробности преимуществ NVMe обсуждаюися в разделе NVMe в нашем переводе "ZFS для профессионалов"}

Начиная с четырёх узлов в вашем кластере Непосредственно подключаемых пространств хранения, у вас появляется возможность создания Виртуального диска с множественной отказоустойчивостью (Multi-Resilient virtual disk). Это означает, что вы реализуете уровень кэширования в устройствах NVMe и уровень хранения объёма в устройствах SSD и HDD. Уровень хранения объёма может состоять из устройств хранения различного типа благодаря привнесению Microsoft Виртуальных дисков с множественной отказоустойчивостью. {Прим. пер.: подробности преимуществ NVMe обсуждаюися в разделе NVMe в нашем переводе "ZFS для профессионалов"}

Благодаря этой функциональности вы можете создавать виртуальный диск с уровнем зеркала и уровнем контрольных сумм (parity). Уровень зеркала размещается на SSD, а уровень контрольных сумм размещается на HDD. Благодаря ReFS, ваши данные всегда будут записываться на ваш уровень зеркала. Когда уровень зеркала заполняется, ReFS перемещает наименее часто используемые данные (также называемые холодными данными, cold data) с уровня зеркалирования на уровень хранения объёма. Если данные, размещаемые на вашем уровне хранения объёма должны быть изменены, ReFS признаёт ваши данные на уровне хранения объёма недействительными и записывает новые на уровень зеркала. Эта способность ReFS называется ReFS real-time tiering (кэшированием ReFS в реальном времени).

Благодаря этой функциональности вы можете оптимизировать производительность, так как ваши данные всегда записываются на уровне зеркала на такие быстрые устройства как SSD. С другой стороны, вы получаете максимальную ёмкость с применением контрольных сумм отказоустойчивости (parity resiliency) HDD. Если вы реализовали кластер из четырёх узлов и вам необходима высокая производительность, я рекомендую именно такой вид решения.

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

Существуют различные опции настройки для виртуальных жёстких дисков, начиная с самого формата таких дисков. В настоящее время Hyper-V поддерживает классический формат VHD и более новый формат VHDX. VHDX диски более предпочтительны во многих случаях, начиная с их увеличенного размера, вплоть до 64ТБ, через их более лучшии параметры производительности и надёжности и вплоть до более предпочтительных возможностей управления, таких как изменение размеров дисков обоими способами. Единственной причиной применения файлов VHD на сегодняшний день является их обратная совместимость с версиями Hyper-V, предшествующими 2012. Если вам это не требуется, Не применяйте файлы VHD. Если вы всё ещё используете файлы VHD, преобразуйте их при помощи PowerShell когда находитесь в неработающем состоянии:

Convert-VHD -Path d:\VM01.vhd -DestinationPath d:\VM01.vhdx
 	   

После установки необходимого формата вашего виртуального диска, следующим решением будет решение о типе виртуального диска. Hyper-V поддерживает три типа виртуальных жёстких дисков:

Фиксированные диски выделяют своё максимальное пространство хранения при создании. Этот размер фиксированного диска остаётся одним и тем же всё время. Так как всё доступное пространство выделяется на момент создания, фиксированный диск предлагает надёжность и великолепную производительность.

Динамичные диски создаются только со своей заголовочной информацией и выделяют дополнительное пространство по мере того как дополнительные данные записываются на эти диски. Из- за их постоянного роста, постоянного исправления на большее пространство хранения, а также изменения метаданных всего виртуального диска, динамичные диски имеют небольшие уступки в производительности по сравнению с фиксированными дисками. Однако, в текущей версии Hyper-V в этом разделе также присутстсвуют великолепные улучшения. Динамичные диски всё ещё медленнее фиксированных, но эта разница на сегодняшний день значительно ниже. Сущесвуют результаты замеров производительности с с примерно от 3 до 5 процентов разницы с фиксированными дисками в сценариях из реальной практики. Это небольшое падение производительности не сопоставимо в соотношении с падением управляемости и стоимости при использовании фиксированных дисков в большинстве пользовательских вариантов. По моему мнению, динамичные диски должны быть параметром по умолчанию для ваших рабочих нагрузок, включая промышленные системы, пока требования поддержки ваших приложений не потребуют другого. Имейте в виду, что Hyper-V поддерживает динамичное выделение в хранилище; объединение его с динамичными дисками позволяет вам иметь очень гибкий подход для дисков Hyper-V.

Диски с приращениями применяют подход связанных дисков на основе взаимодействия родитель/ потомок. Диск с приращениями создаётся как связанный с родительским диском, обычно содержащим обобщённый образ sysprep. ВМ основанные на диске потомка затем будут записывать все последующие изменения и индивидуальные записи в виде дочернего диска. Такие сценарии развёртывания очень быстрые и они дают великолепные возможности для лабораторных сред и реализаций VDI. Диски с приращениями приходят с воздействием на высокую производительность и большей сложностью управления; таким образом, их не следует применять в развёртывании серверов промышленного применения.

Вы можете преобразовывать тип своего диска в PowerShell, причём даже при одновременном преобразовании самого формата диска:

Convert-VHD -Path d:\VM01.vhd`
   -DestinationPath d:\VM01.vhdx `
   -VHDType dynamic
 	   

Существует также и четвёртый доступный тип диска в Hyper-V, а именно, пробрасываемый (pass- trough) диск. Пробрасываемые диски (сырые) не являются виртуальными жёсткими дисками. Они применяют некий физический том без виртуального контейнера в промежутке. В прошлом это было замечательным способом достижения производительности. В последних версиях Hyper-V пробрасываемые диски не предоставляют преимуществ, однако вместо этого имеют определённые недостатки, такие как ограниченные мобильность и управляемость. Таким образом, больше не применяйте пробрасываемые диски. Преобразуйте их выполнив следующую команду:

New-VHD -Path "D:\VMS\Converted.VHDX"
    -Dynamic -SourceDisk 5
 	   

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

Наиболее частый вопрос для совместно используемых томов (CSV, Cluster shared volumes) состоит в том, сколько CSV вам нужно и насколько огромными они могут стать по мере заполнения данными. Как уже упоминалось ранее, хорошим высеченным на камне правилом является создание одного CSV для каждого узла кластера; в больших средах с более чем восемью узлами, по одному CSV на два или четыре узла. Общее число ВМ на CSV не ограничивается. Обычно мне не приходилось видеть более 50 ВМ на CSV для ВМ сервера и 100 ВМ для клиентских ВМ в средах VDI. Однако в данном случае не думайте об устройствах, планируйте IOPS. Равномерно распределяйте общие IOPS между своими CSV. Начните с по крайней мере двух CSV для расщепления нагрузки между своими двумя контроллерами хранения. Не обязательно проектировать CSV, вместо этого проектируйте поведение SAN и того, как он управляет своими дисками. Если вы используете только один CSV, может так случиться, что ваш SAN разместит всё имущество этого LUN на отдельном контроллере и может создать узкое место для производительности.

Изменения метаданных могут происходить только в координаторе CSV, поэтому убедитесь что вы используете координатора CSV при применении изменений, таких как расширение дисков или перемещение файлов в CSV. Для идентификации своего координатора CSV воспользуйтесь следующим cmdlet:

Get-ClusterSharedVolume
 	   

Помимо этого определите своего координатора в колонке Node. Этот cmdlet также применяется для управления всеми связанными настройками вокруг CSV. Такой координатор также называется владельцем узла в вашей консоли Менеджера отказоустойчивого кластера (Failover Cluster Manager).

CSV может быть переименован на уровне вашей файловой системы (http://bit.ly/1lA6nS7), а также на уровне вашего объекта кластера (http://bit.ly/1vxAUFF). Это необходимо сделать до исполнения какой- либо ВМ из CSV:

Для оптимальной производительности CSV убедитесь чт вы выполнили дефрагментацию своих виртуальных жёстких дисков перед перемещением их в CSV путём добавления образов диска к ВМ, создания контрольных точек, а также того, что память ВМ использует пространство ваших CSV. Когда ВМ включается, она создаёт файл, равный по объёму её оперативной памяти в папке этой ВМ в общем CSV при действии автоматического останова ВМ по её сохранению. Планируйте заполнение вашего CSV максимально на 75 процентов от его ёмкости чтобы позволить росту всех этих файлов. Если вы желаете узнать сколько свободного пространства доступно в вашем CSV, изучите все зависимости, существует великолепный сценарий PowerShell, доступный по ссылке http://bit.ly/1mloKQC.

Совместно используемые тома можно шифровать при помощи Bitlocker; они получат проседание в производительности примерно 20- 30 процентов. Шифрование ваших CSV при помощи Bitlocker не только увеличит физическую безопасность ваших данных, это также отличный способ уменьшения риска утраты данных в случае замены жёсткого диска по какой бы то ни было причине.

Следует рассмотреть некоторые дополнительные соображения относительно CSV. Убедитесь что ваши сетевые адаптеры, применяемые для CSV, имеют клиента для сетевой среды Microsoft, а также что включены совместное использование файла и печати для сетевой среды Microsoft. В большинстве случаев также предполагается, что вы также активировали Фильтр производительности Виртуального адаптера Отказоустойчивого кластера Microsoft (Failover Cluster Virtual Adapter Performance Filter). Однако если вы используете для своей виртуальной машины гостевой кластер, эти установки следует отключить на уровне хоста, дабы избежать проблем с резервным копированием и параметрами кластера.

Включение кэширования CSV предоставляет кэширование на уровне блоков только для чтения, операций небуферированного ввода/ вывода по выделению системной памяти (ОЗУ) в качестве кэша. В качестве кэша CSV может быть использовано 80 процентов от общего объёма физической оперативной памяти. Хорошей практикой в кластерах Hyper-V является использование кэширования вашего CSV. Я наблюдал наилучшие соотношения производительность/ стоимость в районе 512-1024 МБ; однако оно не должно превосходить 2ГБ. Для настройки кэша в поднимаемом приглашении до 512 МБ данных и применении этого значения по умолчанию для ваших файлов CSV воспользуйтесь следующей командой:

(Get-Cluster).BlockCacheSize = 512
 	   

До появления Windows Server 2016 были доступны только стандартные контрольные точки. Такой вид контрольных точек не поддерживался для всех гостевых рабочих нагрузок, таких как Active Directory. Это именно та причина, по которой стандартные контрольные точки не рекомендовались для промышленного использования и рекомендовались к применению только в сценариях разработок и тестирования. Стандартные контрольные точки применяют технологию сохранения состояния для захвата настроек вашего оборудования, ваших данных и вашего состояния.

Microsoft выпустил в своём Windows Server 2016 контрольные точки для использования в промышленных средах, которые основаны на VSS гостевой ОС Windows и буферов файловой системы для гостевой ОС Linux. Все промышленные рабочие нагрузки поддерживаются и это способ вхождения в Windows Server 2016 в вашу промышленную сферу.

В Windows Server 2016 промышленные контрольные точки являются параметром по умолчанию. Вы можете изменить это в настройках своей ВМ если вы не хотите использовать преимущества промышленных контрольных точек:

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

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

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

Checkpoint-VM
   -Name Test
   -SnapshotName Snapshot1
 	   

Существует ряд практических соображений, связанных с контрольными точками, и они таковы:

Windows Server 2016 с Hyper-V предлагает встроенную дедупликацию без каких бы то ни было дополнительных затрат. Это великолепный способ уменьшения отпечатка ёмкости вашего хранилища при очень маленькой настройке. Однако дедупликация данных всё-таки потребляет стоимость - она требует дополнительной ёмкости ввода/ вывода. По этой причине на файловом сервере общего назначения это не будет иметь действия пока горячие данные не достигнут определённого возраста изменения файла. Помимо провала в вводе/ выводе, тома с активной дедупликацией будут более легко подвергаться фрагментированию, что будет приводить к более длительному выполнению отдельных файловых операций на томах с дедупликацией. Во избежание значительных провалов в производительности Hyper-V принимает некоторые меры предосторожности, а именно: каждый блок, на который существует более 100 ссылок записывается второй раз.

Опыт реального применения говорит нам, что общая прибыль от сохранённого пространства превосходит стоимость затрат на производительность файловых серверов, серверов библиотек, а также хостов VDI Hyper-V. Выполнение дедупликации данных Windows в работающей ВМ с серверными нагрузками не поддерживается. Перед применением дедупликации вам следует проверить какой объём пространства сохранит её выполнение в томе при помощи команды PowerShell после того, как свойство дедупликации включено:

ddpeval.exe <Path>
 	   

Включите свойство дедупликации выполнив следующий cmdlet на уровне своего хоста:

Install-windowsFeature FS-Data-Deduplication
 	   

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

Enable-DeDupVolume D:
 	   

Настройте возраст файла необходимый для вызова дедупликации. Это непосредственно влияет на необходимые IOPS хранения:

Set-DedupVolume -Volume D: -MinimumFileAgeDays 5
 	   

Запустите задание дедупликации на определённом томе:

Start-DedupJob D: -Type Optimization
 	   

Чтобы создать расписание дедупликации на постоянной основе, которое будет выполнять дедупликацию данного диска в окне в 10 часов в течение недели, воспользуйтесь следующей командой:

New-dedupschedule -Name "Dedup01" -Type Optimization -Days Sat, Wed - Start 23:00 -DurationHours 10
 	   

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

Если у вас уже имеется включённая дедупликация на вашей платформе хранения под Hyper-V, оставьте её там. Будет намного более эффективным выполнять её на уровне оборудования/ системы хранения. Существует также небольшое дополнительное сохранение пространства при выполнении дедупликации на уровнях оборудования и системы хранения одновременно. Однако, обратной стороной, такой как большее использование ресурса, сверх обычного, поэтому активируйте дедупликацию только на одном уровне.

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

Enable-DedupVolume C:\ClusterStorage\Volume1 -UsageType HyperV
 	   

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

Microsoft расширил понятие Storage QoS (Storage Quality of Service, Качества обслуживания хранения) в Windows Server 2016. В Windows Server 2012 R2 политика Качества обслуживания хранения применялась для VHDX. Понятие Качества обслуживания хранения не противоречило лежащему в основе решению хранения. Это решение було прекрасным для отдельного Hyper-V, однако когда у вас в кластере имеются десятки узлов Hyper-V,общающихся с одной и той же системой хранения, это не работает достаточно хорошо, так как каждый узел Hyper-V не осведомлён о том что они используют одну и ту же полосу пропускания.

Благодаря расширению Качества обслуживания хранения (называемого Качеством обслуживания распределённого хранения, Distributed Storage QoS), политики теперь хранятся в общей базе данных кластера. Вы теперь способны создавать политики для установки минимального и/ или максимального IOPS и применять эти правила к отдельным или ко множеству виртуальных машин/ виртуальных жёстких дисков. Благодаря этому расширению определённый Hyper-V в кластере применяющий одну и ту же систему хранения может учитывать общие политики Качества обслуживания хранения.

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

Качество обслуживания распределённого хранилища в Windows Server 2016 поддерживает только следующие два сценария:

Даже если вы не находитесь в среде со множеством арендаторов, вам следует рассматривать эту функциональность. Некоторые службы с интенсивным вводом/ выводом, такие как сервер SQL требуют минимума IOPS для работы в хороших условиях по сравнению с неким файловым сервером. При Качестве обслуживания распределённого хранения вы можете гарантировать что ваш сервер SQL всегда имеет свой минимум требующихся IOPS.

Чтобы реализовать Качество обслуживания распределённого хранения, вам необходимо создать определённую политику и применить её к VHDX:

$CimSession = New-CimSession -ComputerName Cluster-HyperV
New-StorageQosPolicy -Name bronze -MinimumIops 50 -MaximumIops 150 -CimSession
$CimSession
Get-VM -Name VM01 -ComputerName Cluster-HyperV |
Get-VMHardDiskDrive |
Set-VMHardDiskDrive -QoSPolicyID (Get-StorageQosPolicy -Name Bronze -CimSession $CimSession).PolicyId
 	   

Вот соответствующий вывод:

При работе с системами хранения SAN с высокой доступностью вам не только требуются чтобы сами системы хранения исключали единую точку отказа, но также и её связность. Таким образом, наилучшей практикой является наличие множества соединений между вашей инфраструктурой хранения SAN и вашими серверными системами Hyper-V. Множество путей ввода/ вывода гарантирует что избыточные пути между этими системами обнаруживаются и все соответствующие диски обнаруживаются и регистрируются только один раз. {Прим. пер.: подробности обсуждения этой проблемы см. в разделе Множество путей SAS в нашем переводе "ZFS для профессионалов"}

Существенным является гарантирование бесшовного управления диском. При активном MPIO путь к вашему хранилищу SAN может потеряться без какого либо прерывания для ваших виртуальных машин. SMB3 обрабатывает это с применением многоканальности SMB, для всех прочих архитектур хранения следуйте следующим шагам для включения MPIO посредством PowerShell:

Enable-WindowsOptionalFeature -Online -FeatureName MultiPathIO
 	   

Эти настройки действительны для вашего модуля MPIO по умолчанию в Windows Server 2016 и предоставляют оптимальную производительность. Если вы применяете специфичное для производителя DSM, убедитесь что вы изучили его документацию для оптимальной настройки. Если у вас имеется DSM хранения, поддерживаемое Hyper-V от вашего производителя хранения, вам следует предпочесть его в сравнении с прочими.

Microsoft Windows Server содержит таргет iSCSI для предоставления LUN iSCSI из программного обеспечения Windows Server вместо iSCSI SAN. Это делает для вас возможным предоставлять центральное хранилище с любым подключённым к нему хранилищем серверу исполняющему таргет iSCSI. Такой таргет iSCSI поддерживается в промышленных средах. Однако, поскольку существуют существенные штрафы в производительности в сравнении с естественными системами iSCSI SAN, они более предпочтительны для целей исследований и демонстраций.

Таргет iSCSI должен работать не выделенной машине и никогда в хосте Hyper-V или ином вовлечённом в промышленную нагрузку размещения сервере. Для создания и настройки таргета iSCSI применяйте PowerShell. Активируйте необходимые функции при помощи следующих команд:

Add-WindowsFeature -Name FS-iSCSITarget-Server
Add-WindowsFeature -Name iSCSITarget-VSS-VDS
 	   

Создайте новый LUN:

New-IscsiVirtualDisk -Path d:\VHD\LUN1.vhdx -Size 60GB
 	   

Создайте новый таргет iSCSI:

New-IscsiServerTarget -TargetName Target1 -InitiatorId IPAddress:192.168.1.240,IPAddress:192.168.1.241
 	   

Назначьте данный LUN iSCSI его таргету:

Add-IscsiVirtualDiskTargetMapping -TargetName target1 Path d:\VHD\LUN1.vhdx -Lun 10
 	   

Присоедините таргет iSCSI через свой инициатор iSCSI на ваших хостах Hyper-V:

Connect-IscsiTarget -NodeAddress <targetIQN>
 	   

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

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

Теперь продолжим Главой 5, Практический опыт сетевой среды изучение сетевой среды. Если вы желаете узнать дополнительные подробности о хранилищах, существуют определённые дополнительные советы по настройке в Главе 7, Настройка производительности Hyper-V.