Гипервизор VMware ESX позволяет настроить несколько параметров при создании виртуальных дисков (файлов VMDK) для виртуальных машин. Особенно важно учесть размер блока при форматировании группы хранения ESX, в противном случае, возможно, придется создавать резервные копии всех существующих виртуальных машин и повторно форматировать группу хранения. Эти параметры настройки диска оказывают значительное влияние на функциональность, производительность и управляемость.

Создание диска

При добавлении нового диска в виртуальную машину на сервере VMware ESX вам предлагается один из вариантов: создание нового виртуального диска, использование существующего диска или подключение физического диска. Первые два варианта не требуют пояснений. Когда подключаемый физический диск входит в состав хранилища SAN, файлы не инкапсулируются в файл VMDK. Если вы будете просматривать содержимое логического раздела (LUN) хранилища SAN, то увидите отдельные файлы, а не просто один файл VMDK, все содержимое которого инкапсулировано в формат диска виртуальной машины.

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

Вариант подключения физического диска можно использовать в физическом или виртуальном режиме. В виртуальном режиме система рассматривает подключенный физический диск как обычный файл VMDK с соответствующим набором функций, таких как создание снимков и клонирование виртуальной машины, вам предоставляется выбор между «тонким» (thin) и «полным» (thick) типом диска. Если вы выберете тип thick, то при создании диска ESX сразу выделит в группе хранения его полный объем. Когда вы используете тип диска thin, выделяется ровно столько места, сколько использует диск виртуальной машины. Диски типа thin экономят место на диске, но производительность ухудшается, и при этом повышается вероятность ситуации нехватки дискового пространства в группе хранения ESX.

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

Если вы планируете использовать тип thin для дисков виртуальной машины, я бы предложил задействовать его только для хранения основных образов виртуальной машины, но не для создания дисков с данными. Если вы создадите несколько виртуальных машин с «тонкими» дисками размером 1 Тбайт и пользователи начнут сохранять данные на этих дисках, то место в группе хранения ESX может быстро закончиться.

Интерфейсы и контроллер

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

При создании дисков следует выбрать тип контроллера SCSI. Операционная система Windows определяет, какой тип контроллера SCSI использовать, основываясь на совместимости и показателях производительности. В таблице 1 показано, какие типы контроллеров используют те или иные версии Windows.

 

Таблица 1. Типы контроллеров SCSI в различных версиях Windows
Типы контроллеров SCSI в различных версиях Windows

В дополнение к контроллерам SCSI из таблицы 1 вы также можете задействовать драйвер VMware Paravirtual. Однако использовать драйвер Paravirtual следует только при выполнении следующих условий:

  • драйверы хранятся в сети SAN, устройства DAS не используются;
  • виртуальной машине требуется пропускная способность более 2000 операций ввода-вывода в секунду;
  • виртуальная машина должна работать под управлением системы Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 или Red Hat Enterprise Linux (RHEL) 5;
  • жесткий диск не должен быть загрузочным;
  • виртуальная машина не отказоустойчива;
  • виртуальная машина не должна использоваться в качестве части кластера Microsoft.

Обычно использование драйвера VMware Paravirtual увеличивает пропускную способность диска на 10% и на 15% уменьшает загрузку центрального процессора по сравнению с использованием контроллера LSI Logic SCSI в случаях, когда файл VMDK хранится в сети SAN.

Постоянные против непостоянных

После выбора интерфейса диска (IDE или SCSI) и типа контроллера вам предоставляется возможность создать независимый диск. Вы можете использовать независимый диск, если хотите, чтобы на него никак не влияло создание снимков.

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

Размер блока группы

Администраторов, не знакомых с ESX, часто вводит в заблуждение параметр, определяющий размер блока при форматировании группы хранения. Размер блока определяет максимальный размер файла VMDK, который можно создать в группе хранения. Размер блока не зависит от общего размера группы хранения. В таблице 2 показана зависимость между размером блока и размером файла в группе хранения.

 

Таблица 2. Зависимость размера файла группы хранения от максимального размера блока
Зависимость размера файла группы хранения от максимального размера блока

Размер блока равен по умолчанию 1 Мбайт, так что вы можете создать VMDK файл размером 256 Гбайт за вычетом 512 байт. Если вы хотите создать VMDK файл размером более 256 Гбайт, вам нужно сделать резервную копию данных, отформатировать группу хранения с использованием большего размера блока и восстановить файлы VMDK, что не доставляет особого удовольствия при работе в производственной среде.

Если вы хотите сохранить возможность делать снимки виртуальной машины, убедитесь, что создаете файл VMDK на 2 Гбайт меньше, чем максимально допустимый файл в группе хранения. Например, если вы отформатировали хранилище с размером блока в 1 Мбайт, вам не следует создавать файл более 254 Гбайт. Если вы создадите файл VMDK размером 256 Гбайт в группе хранения, то при попытке сделать снимок виртуальной машины произойдет ошибка, связанная с тем, что файл VMDK превышает максимальный размер файла в группе хранения. Когда снимок будет создан, начальный файл VMDK создаст файл заглушки размером 2 Гбайт. Таким образом, при попытке сгенерировать снимок виртуальной машины с файлом VMDK на 256 Гбайт система ESX попытается создать файл VMDK размером 258 Гбайт, и создание снимка закончится неудачей.

Выбирайте с осторожностью

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

Алан Сугано (asugano@adscon.com) — президент компании ADS Consulting Group, специализирующейся на разработках в области Microsoft.NET, SQL Server и сетевых технологиях

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF