Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 3)

• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 2)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)

Введение

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

Ресурсы хранения

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

Вместимость

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

Когда вы создаете новый виртуальный жесткий диск для Hyper-V, вам предоставляется выбор между созданием виртуального жесткого диска фиксированного размера и динамически расширяемого виртуального жесткого диска, как показано на рис. Параметр size требует указанный объем физического хранилища сразу, тогда как параметр Dynamically Expanding использует пространство только по мере необходимости.

Рисунок A: Вы можете создать виртуальный жесткий диск фиксированного размера или динамически расширяемый.

Динамически расширяемые виртуальные жесткие диски считаются тонко подготовленными. Чтобы дать вам более конкретный пример, взгляните на файл VHDX, показанный на рисунке B. Этот виртуальный жесткий диск занимает всего около 4 МБ физического дискового пространства, хотя Hyper-V рассматривает его как виртуальный жесткий диск объемом 127 ГБ. Конечно, размер файла виртуального жесткого диска будет увеличиваться по мере добавления на него данных. Напротив, если бы я создал виртуальный жесткий диск фиксированного размера на 127 ГБ, он немедленно занял бы 127 ГБ дискового пространства.

Рисунок B: Этот виртуальный жесткий диск объемом 127 ГБ занимает всего около 4 МБ физического пространства для хранения.

Очевидно, что Thin Provisioning — отличный способ получить максимально возможную плотность виртуальных машин из вашего физического пространства хранения. На самом деле, вам может быть интересно, зачем вообще создавать виртуальный жесткий диск фиксированной длины. На самом деле для этого есть как минимум две причины.

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

Другая причина связана с темой, которую я буду много обсуждать на протяжении всей этой серии статей — ресурсы важнее обязательств. Ресурс сверх обязательства относится к предоставлению виртуальным машинам большего количества физических ресурсов, чем доступно на самом деле. Например, том, на котором я создал виртуальный жесткий диск на предыдущем рисунке, имеет размер примерно около 3 ТБ. Поскольку динамически расширяемый виртуальный жесткий диск вначале занимает около 4 МБ дискового пространства, я мог легко создать десять виртуальных жестких дисков по 2 ТБ. При этом я изначально использовал только около 40 МБ физического дискового пространства. Однако, если бы я начал добавлять много данных на эти виртуальные жесткие диски, в какой-то момент им не хватило бы места. Объем хранилища составляет всего около 3 ТБ, чего явно недостаточно для размещения 20 ТБ данных.

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

Производительность хранилища

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

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

На данный момент единственный способ избежать этой проблемы — разместить виртуальные машины с высоким спросом в выделенном хранилище, чтобы нагрузка IOPS была изолирована от других виртуальных машин. Однако именно здесь вступает в игру компромисс между производительностью и емкостью.

Представьте, например, что конкретной виртуальной машине требуется 8000 операций ввода-вывода в секунду, а каждый из ваших дисков может обеспечить 1000 операций ввода-вывода в секунду. Вы можете обеспечить необходимое количество операций ввода-вывода в секунду для виртуальной машины, создав чередующийся набор из 8 дисков. Проблема в том, что когда вы выделяете физические диски таким образом, вы выделяете полную емкость диска. Если каждый из этих 8 дисков имеет размер 3 ТБ, то вы выделили 24 ТБ физического хранилища для виртуальной машины (что может быть намного больше, чем ей нужно) просто для достижения необходимой производительности.

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

QoS — это имя протокола, используемого для резервирования пропускной способности сети. Microsoft позаимствовала идею (и название QoS) и создала систему резервирования IOPS. В Windows Server 2012 R2 можно будет зарезервировать определенный объем IOPS для виртуальной машины. Точно так же можно будет ограничить виртуальные машины с высокой нагрузкой, чтобы они не потребляли чрезмерное количество операций ввода-вывода в секунду.

Как вы можете видеть на рис. C, Storage QoS работает для каждого виртуального жесткого диска. Это означает, что можно будет устанавливать разные лимиты и резервирования даже в рамках одной виртуальной машины.

Рисунок C. Функция Storage QoS позволяет резервировать или ограничивать количество операций ввода-вывода в секунду для каждого виртуального жесткого диска.

Хотя Windows Server 2012 R2 еще не выпущена, функция Storage QoS должна позволить администраторам виртуализации гарантировать производительность, связанную с хранилищем для виртуальных машин, но без потери физической емкости хранилища в процессе, как это часто делалось в прошлом..

Вывод

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

• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 2)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)