Vmware форматы виртуальных дисков
Недавно я столкнулся с ситуацией, когда на виртуальном диске в виртуальной машине vSphere начало заканчиваться место, а типичная операция по расширению дискового пространства оказалась невозможной. В моем случае это было связано с интерфейсом подключения диска — IDE.
Статьи, которые можно найти в этой связи в Интернет, например:
VMware Knowledge Base
Аналог, с картинками
к сожалению неполны.
Следование данным статьям приводит к неработоспособности виртуальной машины. После более детальных изысканий, был найден работающий путь, дополняющий вышеуказанные статьи. Для того, чтобы статья предоставляла цельное решение проблемы, здесь будет изложен переработанный и дополненный способ конвертации.
Отступления
1. Чтобы не загромождать статью, я буду везде опускать слово «виртуальный», которое будет применяться к диску и к машине.
2. Я буду использовать специфическую терминологию/названия, типичные для vSphere.
3. Невозможность расширения диска может быть вызвана несколькими причинами: наличие снапшотов данного диска (при этом в менеджере снапшотов они могут быть не видны), отсутствие места для расширения, включенное питание машины и т.д. Здесь описывается ситуация, когда снапшотов нет, место есть, питание выключено, но диск IDE.
4. Существует теоретическая/(не проверял) возможность конвертации диска с помощью VMware Converter. Я ее не использовал по двум причинам: это достаточно «тяжелый» софт и я встречал упоминания о невозможности загрузки машины после конвертации
5. Операции производились на vSphere + ESXi v4.1U2. Я не гарантирую работоспособности метода на других версиях (но в принципе должно работать, ничего сверхспецифичного).
6. Внутри машины установлена неонка WinXP 32bit, и часть действий на это рассчитана, если у вас стоит другая ОС имейте это в виду.
7. Формат диска Thick
8. У вас есть свежий бэкап данной машины (в процессе экспериментов я восстанавливался где-то раз 5).
Начали
Итак, наша машина выключена, у нас открыт vSphere Client.
Заходим в свойства машины, и добавляем SCSI Device. В качестве скази девайса у меня был сидиром, у которого рекомендуется сразу же поменять Virtual Device Node с SCSI(0:0) на SCSI(0:1), т.к. впоследствии на SCSI(0:0) мы повесим наш сконвертированный диск.
Скази девайс добавляется вместе со скази контроллером (SCSI Controller), у которого необходимо сменить тип с BusLogic Parallel на LSI Logic Parallel.
Сохраняем настройки и включаем машину.
Ставим драйвер для контроллера, который можно найти на сайте производителя: LSI Support.
Ищем драйвер для своей ОС, для LSI20320-R
После установки драйвера, хорошо бы проверить, что контроллер и скази девайс появились в оборудовании машины и установлены корректно.
Выключаем виртуальную машину.
В вышеприведенных ссылках, рекомендуют заменить одну строчку в файле %vm-name%.vmdk (ddb.adapterType) чтобы в дальнейшем все заработало. У меня это не сработало (машина не загружается вообще — не виден даже MBR).
После определенных изысканий была найдена проблема — разная геометрия дисков IDE и SCSI.
Таким образом необходимо выяснить геометрию SCSI диска с точно таким же размером как наш IDE диск.
Это можно сделать разными способами, лично я использовал VMware vSphere PowerCLI (см. подвал).
Итак, подключаемся к ESX(i) хосту и выясняем размер диска машины:
Т.о. мы получили размер в килобайтах. Теперь выясним название скази контроллера нашей машины (это понадобится для создания скази диска):
Создаем скази диск, аналогичного размера:
PowerCLI > New-HardDisk -Datastore datastoreXX -StorageFormat Thick -CapacityKB 10485760 -Controller "SCSI controller 0" %vm-name%
При создании, будет выведена табличка, в которой среди прочего будет прописан путь к созданному диску, а также его название.
Немного теории:
В VMware виртуальный диск в простейшем случае состоит из двух файлов:
%vm-name%.vmdk — файл описания диска
%vm-name%-flat.vmdk — собственно сам диск (содержимое)
Кстати, Datastore Browser представляет их в виде одного файла, но если этот файл скачать, например, на локальную машину, то фактически получим два файла, как и должно быть (в теории может быть и больше, если использовался split).
На данный момент нас интересуют файлы описания старого IDE диска и новосозданного SCSI диска. Я пользовался SSH и WinSCP для их извлечения.
Для моего размера диска увидим следующее:
Сначала обратим внимание на вторую строчку, на цифры после RW, это размер дисков (в моем случае в 512b блоках). Числа должны совпадать, если они не совпадают, нет смысла читать дальше.
Далее сразу же бросается в глаза различие цилиндров и головок. Ну и тип адаптера.
Теперь редактируем файл описания старого IDE диска, меняем соответственно число цилиндров, головок и тип адаптера. Не рекомендую просто переписывать файл описания, таковым от нового скази диска, т.к. информации у старого IDE диска в этом файле больше.
Все что нам нужно было от тестового скази диска мы получили, поэтому его можно удалить (например с помощью Remove-HardDisk).
Теперь заходим в свойства виртуальной машины и удаляем IDE диск из состава машины.
будьте предельно внимательны, диск удаляем только из виртуальной машины (Remove from virtual machine), но не удаляем файлы с диска!
Сохраняем изменения, и опять заходим в свойства виртуальной машины. Добавляем жесткий диск, выбираем пункт «Использование существующего диска» (Reuse existing virtual disk) и указываем на файл с нашим диском.
В дополнительных свойствах, проверяем что диск встал на SCSI(0:0).
В данный момент можно удалить скази сидиром, если он не нужен, и проверить настройки IDE сидирома (если он есть). IDE сидиром необходимо установить на канал IDE(0:0) или IDE(1:0) (мастером), иначе машина откажется запускаться.
В целом это все. Можно еще зайти в БИОС виртуальной машины, проверить порядок загрузки.
Виртуальную машину можно запустить, при первой загрузке будет установлен драйвер на диск.
Всем привет! Сегодня расскажу про форматы файлов виртуальной машины Vmware ESXI. Если вы откроете диск на, котором лежит ваша виртуальная машина, то вы найдете там набор файлов, понимание того, что за что отвечает даст вам понимание того, как потом ремонтировать вашу VM. Данный знания вам окажутся полезным, при модификации конфигурационного файла или же при конвертировании в OVF формат, либо же избавление от SWAP файла (Файла подкачки). Думаю, что это будет интересно.
Структура файлов в ESXI виртуальной машине
Откроем ваш datastore с нужной виртуальной машиной через правый клик и выбор пункта меню Browse.
Переходим в папку с вашей виртуальной машиной (VM) и видим некоторый набор файлов.
Описание форматов файлов виртуальной машины ESXI
Хочу отметить, что flat вы через vCenter сервер не увидите, так сделано.
для этого придется вам включить ssh и подключиться либо через WinSCP или же, через ssh клиента. И вот там вы уже их обнаружите.
- *.vmx - Главный конфигурационный файл, содержит все настройки и сведения, о добавленном железе.
- *.vswp - Файл подкачки
- *.nvram - Постоянная память RAM: содержит текущие настройки виртуальной BIOS
- vmware.log - логи виртуальной машины
- *.vmtx - файл шаблона
- rdm.vmdk - RDM диск (Например LUN отданный виртуалке на прямую)
- *.vmdk - Описание параметров виртуального диска
- *flat.vmdk - Это расширение используется для файлов данных монолитных (не растущих) неразделённых дисков (preallocated monolithic disks)
- .vmem - Файл подкачки виртуальной машины
- *0000000*.vmdk - Этот файл содержит изменения, произошедшие с момента создания снапшота X
- *.vmsn - Содержит текущие данные снапшота, nvram и копию vmx-файла
- *.vmsd - Параметры текущего снапшота
- *.vmss - Содержит RAM приостановленной (suspended) виртуальной машины
Всем привет сегодня рассмотрим, в чем разница виртуальных дисков у Vmware ESXi 5.5, разберем каждый тип диска и где его лучше применять. Виртуальные машины на платформе VMware vSphere размещаются на хранилищах Fibre Channel, iSCSI, NAS/NFS или локальных дисках серверов ESX. Диски виртуальных машин могут располагаться на томах в файловой системе VMFS (Virtual Machine File System), NFS (Network File System) или на томах RDM (Raw Device Mapping). При этом на томах VMFS и NFS виртуальные диски машин хранятся в формате vmdk, а на томах RDM виртуальная машина хранит свои данные напрямую на LUN. Сегодня мы поговорим о том, в каких форматах могут быть виртуальные диски машин в VMware vSphere, к которым обращаются серверы VMware ESXI 5.x.x
Independent, Persistent, Non-Persistent диски
И так теперь у вас есть виртуальная машина, если вы зайдете в ее свойства то сможете обнаружить, что для каждого виртуального диска есть еще дополнительные опции
- Independent
- Persistent
- Non-Persistent
давайте смотреть, что каждый из них означает. Вот такая картинка идет по умолчанию для виртуального диска. Что это подразумевает, а то, что у вас в конфигурации стандартный виртуальный диск, на нем можно делать снапшоты ESXI, это дает возможность делаться дельте диска и данные уже писать в него. Если откатывать снапшот, то вы получите диск на момент снятия.
Independent, Persistent, Non-Persistent диски-01
Если у нас стоит Independent и Persistent. В такой конфигурации это означает, что вы не сможете создать снапшот, так как все изменения сразу пишутся на диск. При попытке его создать вас пошлют с ошибкой Cannot take a memory snapshot, since the virtual machine is configured with independent disks. Некий такой механизм защиты от снапшота,
Independent, Persistent, Non-Persistent диски-02
И последний вариант это Independent > Non-Persistent. Тут тоже не работают снапшоты. Диск необходим вот для чего. Предположим у вас есть какой, то публичный или тестовый стенд, где все что то могут поставить, до этого вы его подготовили в эталонный вид и поставили тип диска Non-Persistent, далее все начинаю херачить и ломать эту машинку, ставить там свой софт и тестить его, в итоге, у вас же нет снапшота, а откатиться хочется, этот тип диска и позволяет это сделать путем обычной перезагрузки. Хороших примеров его использования полно, главный принцип один раз настроили, что то пошло не так ребутнули и все счастливы.
Периодически я слышу от практикующих инженеров странное: VMDK, VHD и VHDX – абсолютно разные форматы виртуальных дисков, чуть ли не закрытые, а конвертировать из одного в другое – долго и больно. Сегодня наглядно покажу, что это не так, разберу, как эти форматы соотносятся друг с другом и как делать быструю конвертацию при миграции с Hyper-V на VMware и обратно.
Немного теории. C точки зрения свойств, виртуальные диски делятся на два типа:
- тонкие (thin disk, dynamic disk) и
- толстые (thick disk, fixed disk). Все остальное — разностные, thick provisioned lazy- zeroed – лишь вариации на тему.
Форматы дисков
RAW – «сырой» образ любого диска. Это обычный контейнер, который не содержит никаких специфических заголовков и футеров и представляет образ диска «как есть». Если мы откроем такой образ HEX-редактором, то сразу увидим заголовки GPT/MBR и/или файловой системы. Точно такой же образ получается через команду dd в Linux. RAW в этом плане абсолютно честен с нами.
Начало файла RAW.
Конец файла RAW.
VMDK. VMware ESXi – обыкновенный RAW, где геометрия диска описывается в обычном текстовом файле-описателе (дескрипторе). Именно его имя мы видим в vSphere Console, когда подключаем виртуальный диск к виртуальной машине или просматриваем содержимое каталога на Datastore. VMware ESXi ничего не делает с образом. Совсем. Диск покоится себе и расширяется по мере необходимости. В лучших традициях VMware формат описателя очень простой:
И он не только простой, но и функциональный: достаточно сделать пометки в файле-описателе, чтобы расширить виртуальный диск до каких угодно поддерживаемых значений. Это позволяет заполнить диски нулями или пометить его как тонкий, без необходимости держать информацию о геометрии в заголовках диска.
Ниже представлены некоторые стандартные значения всех разделов дескриптора:
Описание всех значений можно посмотреть в спецификации формата: VMware Virtual Disk Format 1.1
VHD. Толстый VHD – тот же самый RAW, но с 512-байтным футером, где описывается геометрия диска. Какого-то отдельного файла-описателя у виртуальной машины Microsoft Hyper-V нет. Описание геометрии диска занимает 4 байта. Собственно, отсюда ограничение на размер диска в 2 Тб.
Футер. Последние 512 байт диска.
Самое интересное, что если создать файл-описатель и подсунуть в ESXi VHD-диск с футером, то гипервизор VMware проигнорирует этот футер и примет VHD как родной.
При Storage vMotion с конвертацией диска в тонкий он просто отрежет этот футер, и на выходе мы получим тот же RAW без нулей в конце. А при конвертации в толстый диск – честный RAW. Это я и собираюсь продемонстрировать чуть позже.
VHDX. Вся информация о геометрии диска хранится в первых 4096 Кбайтах виртуального диска – в области заголовка.
Общая схема толстого диска VHDX.
Что представляет из себя эта область? В ней содержатся две копии заголовков со своими логами, BAT и область метаданных общие.
Логическая структура заголовка диска.
В единицу времени только одна копия заголовка активна. Это обеспечивает определенный уровень отказоустойчивости заголовка в случае незапланированных прерываний операций чтения/записи. После каждой операции I/O копия реплицируется, и происходит переключение на нее.
Макет области заголовка.
Для конвертации VHDX в RAW нам всего-то нужно отрезать первые 4096 KB.
Начало данных на 5 МБ.
Внимательный читатель, конечно же, скажет: ок, Женька, а слабо RAW конвертнуть в VHDX? На что я отвечу: зависит от файловой системы и от того, насколько она позволяет записывать данные в начало файла. Вручную на файловой системе NTFS это можно сделать, сместив в MFT начало файла на 4 Мб вперед и дописав в это место заголовок.
По этому же принципу работает утилита vhdxtool.exe. Однако при этом преобразовании мы не получим красивую картинку в виде 4 Мбайт заголовка и RAW. Диск будет виден и даже будет корректно работать как VHDX, но будет и много «мусора» из нулей, появившихся из-за манипуляций со смещениями (offsets). Диск будет не оптимизирован. ВМ с таким диском рекомендуется смигрировать на другой том или оптимизировать через командлеты Convert-VHD или Optimize-VHD. Если этого не сделать, диск будет занимать больше места, чем должен, и, возможно, медленнее работать.
Однако в сценариях миграции с VMware на Hyper-V эта утилита незаменима, так как позволяет провести преобразование на месте, без необходимости побайтового считывания исходного диска и создания рядом копии. Все шероховатости будут сглажены при первом же Storage Live Migration.
Вывод: толстые диски форматов VMDK, VHD, VHDX на деле мало чем отличаются друг от друга. В их основе RAW c различными добавками. Тем же HEX-редактором или функциями ОС для работы с файловой системой мы можем за пару секунд превратить 10 Тб VMDK или VHDХ в диск целевого гипервизора.
Давайте на практике посмотрим, как VMware Exsi справится с VHD.
-
В качестве примера я создал образ Windows Server с помощью Convert-WindowsImage с инъекцией драйверов VMware и параметрами:
- OS Version: Windows Server 2019 Standard,
- Disk Type: Fixed,
- Disk Layout: GPT,
- Disk Size: 30GB.
Если не хочется фокусов, то можно воспользоваться инструментами ниже.
Исходный формат | Целевой формат | Инструменты | Пример команды |
VHD | VHDX | vhdxtool.exe | vhdxtool upgrade -f .vhd |
VMDK (RAW) | VHD | vhdtool.exe | vhdtool /convert .vmdk |
VMDK (RAW) | VHDX | vhdtool.exe vhdxtool.exe | vhdtool /convert .vmdk |
Подведем итоги. Различные форматы толстых виртуальных дисков не такие уж разные. В основе всего RAW с различными “добавками”.
Конвертация форматов виртуальных дисков — это не страшно, и, как я показал, иногда можно обходиться даже без нее.
Основной профит всего этого — сокращение времени миграции с Hyper-V на VMware и обратно и времени простоя ВМ при миграции. В DataLine мы такое практикуем с простоем ВМ менее 30 минут. Рекорд же — 40 секунд простоя ВМ при миграции между гипервизорами.
Только помните, что при миграции между разными гипервизорами одной конвертации недостаточно. Как минимум нужно предварительно поставить компоненты интеграции целевого гипервизора, удалить или отключить запуск компонентов исходного гипервизора, удалить виртуальные устройства исходного гипервизора и т.д. Но это уже совсем другая история, о которой я тоже могу рассказать.
Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.
Описание технологии VVOL
Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.
При таком подходе гранулярность операций сопровождения хранилища ВМ силами массива находится на уровне datastore (LUN или NFS-шара целиком), а не на уровне отдельных ВМ. Имеются в виду такие операции, как снапшоты, репликация, дедупликация, шифрование, QoS. Они выполняются на уровне СХД, а не средствами гипервизора, что позволяет осуществлять их быстрее, при этом разгружая вычислительные ресурсы хостов и сеть передачи данных. В первую очередь это касается блочного доступа с VMFS, некоторые модели файловых массивов (например, NetApp) дают гранулярность на уровне отдельных ВМ – например, СХД позволяет сделать снапшот отдельной ВМ, а не datastore целиком.
Описанная выше традиционная технология хранения ВМ в vSphere 6 по прежнему поддерживается, но в дополнение к ней была разработана концепция Virtual Volumes (VVOL), предполагающая объектное хранение ВМ на массивах, поддерживающих данную технологию, независимо от их типа (блочные или файловые).
VVOL – это объект, содержащий файлы ВМ, виртуальные диски и их производные. СХД с поддержкой VVOL получает возможность непосредственной работы с данными объектами за счет собственных аппаратных ресурсов. Как правило, каждый VVOL имеет уникальный GUID для идентификации. Нет необходимости заранее выделять пространство под VVOL, они создаются автоматом при выполнении операций с ВМ: создание, клонирование, снапшотинг.
vSphere (хосты ESXi и vCenter) ассоциирует с ВМ один или несколько VVOL:
• VVOL данных, соответствующий файлу виртуального диска (.vmdk);
• VVOL конфигурации — небольшая домашняя директория, содержащая метаданные ВМ (включая файл .vmx, файлы дескрипторы виртуальных дисков, log-файлы и т.п.). Данный тип VVOL форматируется в VMFS или NFS, в зависимости от типа СХД (блочная или файловая).
• Дополнительные VVOL могут создаваться для остальных компонент ВМ (например, VVOL для swap-файла или файла ОЗУ ВМ для снапшота) или производных виртуальных дисков (клоны, реплики, снапшоты).
Благодаря VVOL мы получаем гранулярность управления хранилищем на уровне отдельных ВМ и можем напрямую задействовать для этого ресурсы СХД. VVOL позволяют использовать гибкие возможности управления хранилищем на основе политик SPBM. Деление данных ВМ на VVOL нескольких типов позволяет размещать их на хранилища с разным уровнем сервиса: VVOL данных на производительный tier с высоким уровнем сервиса, VVOL с конфигурацией или второстепенным диском ВМ на более простые tier.
Для хранения VVOL не нужны классические LUNы или NFS-шары. VVOL хранятся на условно «сыром» пространстве СХД в объектах, называемых storage container. Storage container-ы это логические единицы пространства массива, их количество и ёмкость определяются конкретной СХД и инфраструктурой. Как минимум 1 storage container должен быть создан на СХД, нельзя растягивать 1 storage container на несколько физических массивов.
Storage container-ы логически группируют VVOL из соображений администрирования или управления: можно создавать отдельные storage container-ы для разных заказчиков, департаментов или групп ВМ. Один storage container может включать несколько профилей сервиса, таким образом, на одном и том же storage container могут размещаться ВМ с разными требованиями к обслуживанию и политиками хранения.
Для интеграции СХД с vSphere, для того, чтобы vCenter и гипервизоры могли работать с VVOL и подключиться к storage container необходимо развертывание и регистрация на vCenter специального storage provider-а на базе VASA (VMware APIs for Storage Awareness) для VVOL, который должен разрабатываться и предоставляться производителем СХД.
Для доступа хостов ESXi к VVOL используются логические прокси ввода-вывода, называемы protocol endpoints. ESXi использует protocol endpoints для установления data-path по требованию между ВМ и её VVOL. Каждый VVOL подключен к определенному protocol endpoints. Как правило, СХД требует небольшое количество protocol endpoints, поскольку 1 protocol endpoints может обслуживать множество ВМ (сотни и тысячи).
VVOL поддерживают основные протоколы СХД: Fibre Channel, FCoE, iSCSI, и NFS, аналогично традиционном хранилищам vSphere.
Для поддержки VVOL необходимо использование HBA-адаптеров и версий драйверов для них, адаптированных к работе с (поддерживающих) VVOL.
На стороне СХД происходит конфигурирование protocol endpoints – по одному или несколько на storage container. Protocol endpoints являются частью СХД и предоставляются хостам вместе с ассоциированными storage container-ами через storage provider. vSphere Web Client отображает protocol endpoints, подключенные к инфраструктуре, через T10-based LUN WWN для блочных массивов и IP/DNS для файловых. Protocol endpoints поддерживают мультипафинг только для SCSI-вариантов подключений (для NFS не поддерживается).
Storage container-ы подключаются к инфраструктуре в виде virtual datastore, эти сущности являются их прямым отображением в vSphere Web Client. Virtual datastore аналогичны обычным datastore vSphere, могут отображать VVOL по именам ВМ, их можно монтировать и размонтировать. Однако их конфигурирование, в т.ч. изменение размера осуществляется на уровне СХД за пределами vSphere. Virtual datastore могут использоваться совместно с обычными VMFS и NFS datastore, а также с Virtual SAN.
Размещение ВМ на virtual datastore (с использованием VVOL) требует наличия политик хранения (SPBM). Политика хранения ВМ (VM storage policy) содержит наборы правил по размещению и качеству сервиса для ВМ и гарантирует их выполнение. При отсутствии конкретных политик система будет использовать политику по умолчанию без ограничений, в этом случае массив самостоятельно выберет оптимальное размещение ВМ на свое усмотрение.
Преимущества и недостатки VVOL
Важными преимуществами технологии являются поддержка создания снапшотов и клонов отдельных ВМ на уровне и за счет ресурсов СХД, а также обеспечение таких сервисов как репликация, шифрование, дедупликация и сжатие отдельных виртуальных дисков. Отдельно следует отметить поддержку SPBM, которая открывает большой потенциал управления хранением ВМ на основе политик.
Продукты VMware поддерживающие VVOL:
• VMware vSphere 6.0.x
• VMware vRealize Automation 6.2.x
• VMware Horizon 6.1.x
• VMware vSphere Replication 6.0.x
Продукты VMware НЕ поддерживающие VVOL:
• VMware vRealize Operations Manager 6.0.x to 6.1.0
• VMware Site Recovery Manager 5.x to 6.1.0
• VMware vSphere Data Protection 5.x to 6.1.0
• VMware vCloud Director 5
Технологии VMware поддерживающие VVOL:
• High Availability (HA)
• Linked Clones
• Native Snapshots
• NFS version 3.x
• Storage Policy Based Management (SPBM)
• Storage vMotion
• Thin Provisioning
• View Storage Accelerator/Content Based Read Cache (CBRC)
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• vSphere Flash Read Cache
• vSphere Software Development Kit (SDK)
• vSphere API for I/O Filtering (VAIO)
• vMotion
• xvMotion
• VADP
Технологии VMware НЕ поддерживающие VVOL:
• Fault Tolerance (FT)
• IPv6
• Microsoft Failover Clustering
• NFS version 4.1
• Raw Device Mapping (RDM)
• SMP-FT
• Storage Distributed Resource Scheduler (SDRS)
• Storage I/O Control
Есть предположение, что VMware делает ставку на VVOL, их развитие, и в скором будущем технология станет совместима со всеми решениями вендора. Возможно, в перспективе VVOL станут основной технологией хранения VMware, которая приведет к постепенному уходу от устаревших традиционных хранилищ и прекращению их поддержки.
На момент публикации статьи из 200 (примерно) производителей систем хранения, продукты которых совместимых с vSphere (согласно VMware Compatibility Guide), лишь 18 поддерживают VVOL. Реальных отзывов о практическом использовании VVOL мне найти не удалось: ни в Интернетах, ни на форуме VMware VMUG (даже на буржуйском). Отсутствие совместимости VVOL c перечисленными выше технологиями на данном этапе заставит многих заказчиков отказаться от VVOL, поскольку несовместимая с VVOL технология или их набор зачастую могут оказаться важнее для многих инфраструктур.
Из этого можно сделать вывод, что теоретически технология VVOL очень интересная и полезная. Однако, на данном этапе её практичность и необходимость внедрения вызывают сомнения. Нужен положительный опыт применения в продакшене и нужна совместимость с другими важными фичами vSphere, пока этого нет.
Спасибо за внимание, на этом цикл статей по технологиям хранения vSphere 6 закончен. В следующей статье будут рассмотрены решения VMware для репликации и аварийного восстановления (DR): vSphere Replication и Site Recovery Manager (SRM).
Диски типа Thin (тонкие диски)
Эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски наименее производительны (выделение нового блока и его очистка), однако наиболее оптимальны для экономии дискового пространства на системе хранения данных. Чаще всего их используют в тестовых средах и стендах, где нужно по экономить дисковое пространство или же для разработки.
На слайде пример виртуальной машины с тремя дисками общего объема 140 ГБ, а по фату на датасторе используется 80 гб.
Хочу заметить, что не важно какой у вас диск Thick disks, Zeroed thick disks, Eager zeroed thick disks, thin, рано или поздно они при заполнении до одинакового размера будут по скорости идентичны
Диски типа Raw
Файловая система VMFS поддерживает схему Raw Device Mapping (RDM), которая представляет собой механизм для прямого доступа виртуальной машины к дисковой подсистеме (конкретному LUN) устройств хранения Fibre Channel или iSCSI. Этот тип виртуального диска доступен для создания из vSphere Client.
Если в сети хранения данных используется ПО для создания мгновенных снимков системами резервного копирования, которые запущены в виртуальных машинах, требуется прямой доступ к дисковой подсистеме устройств хранения. Кроме того Raw-диски используются для кластеров Microsoft Clustering Services (MSCS), включая кластеры типа «виртуальный-виртуальный» и «виртуальный-физический».
Но RDM не используется для повышения производительности - его производительность аналогична дискам vmdk в файловой системе VMFS.
RDM может обеспечиваться путем предоставления символьной ссылки в томе VMFS к разделу Raw (режим виртуальной совместимости). В этом случае файлы маппирования, относящиеся к конфигурации виртуальных машин, отображаются как файлы в томе VMFS в рабочей директории виртуальной машины. Когда том Raw открывается для записи, файловая система VMFS предоставляет доступ к файлу RDM на физическом устройстве и реализует через него механизм блокирования и контроля доступа. После этого операции чтения и записи идут напрямую к тому Raw, минуя файл маппирования.
Файлы RDM содержат метаданные, используемые для управления и перенаправления доступа к физическому устройству. RDM предоставляет возможности прямого доступа к дискам, при этом сохраняются некоторые возможности, присущие файловой системе VMFS. Схема взаимодействия виртуальной машины с устройством хранения посредством механизма RDM изображена на рисунке:
Описание типов виртуальных дисков vmdk виртуальных машин на VMware vSphere ESXI 5.x.x-01
Перед началом операций ввода-вывода виртуальная машина vmware посредством файла маппирования инициирует открытие тома Raw. Далее файловая система VMFS осуществляет разрешение адресов секторов физического устройства, а виртуальная машина начинает производить операции чтения-записи на физическое устройство.
Используя RDM возможно производить следующие операции:
- «горячая» миграция виртуальных машин посредством VMotion на томах Raw;
- добавлять новые тома Raw с помощью VI Client;
- использовать возможности файловых систем, такие как распределенное блокирование файлов, установка разрешений и именование;
Для RDM используются два режима совместимости:
- Режим виртуальной совместимости, который позволяет производить маппирование файлов виртуальных дисков, включая возможности создания мгновенных снимков системы хранения. При таком режиме выбирается том VMFS, на котором будет храниться файл маппирования и том, где находится файл конфигурации виртуальной машины.
- Режим физической совместимости, позволяющий приложениям получать низкоуровневый доступ к SCSI-устройствам, при этом наличие файла маппирования не требуется.
Использование функций VMotion, DRS и HA поддерживаются в обоих режимах совместимости.
Диски типа Thick (толстые диски)
Это тип дисков vmdk на томах VMFS или NFS, размер которых предопределяется заранее (при создании) и не изменяется в процессе наполнения его данными. Давайте добавим для примера новый виртуальный диск.
Никогда без веской необходимости не создавайте IDE диски, так как они не расширяются на лету и без геморроя и медленнее SCSI
Существует три типа дисков thick:
Thick disks
Все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Это может создавать потенциальные угрозы безопасности, поскольку виртуальная машина может получить доступ к данным на хранилище VMFS, которые ей не принадлежат. При обращении к блокам такого диска их содержимое предварительно не очищается со стороны ESX. Преимущество дисков типа thick - производительность и быстрота создания, недостаток - безопасность
Zeroed thick disks (lazy zeroed thick disks)
Все пространство такого диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. При первом обращении виртуальной машины к новому блоку происходит его очистка. Таким образом, эти диски более безопасны, однако при первом обращении к блоку - теряется производительность системы ввода-вывода на операцию очистки. При последующих обращениях - производительность идентична дискам типаEager zeroed thick. Этот тип диска создается по умолчанию через VMware vSphere Client для виртуальных машин. Преимущество дисков Zeroed thick disks - безопасность и быстрота создания, недостаток - производительность при первом обращении к блоку.
Eager zeroed thick disks
Все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки. Преимущество такого диска - производительность и безопасность, недостаток - долгое время создания.
Читайте также: