Thin provision vmware что это
При создании новой виртуальной машины в гипервизоре VMware ESXi можно выбрать следующие варианты организации жесткого диска:
Thin Provision -"тонкий" диск, изначально не занимает на файловой системе VMFS места, разрастается до максимального размера по мере накопления информации.
Thick Provision Lazy Zeroed - "толстый" диск, резервирует свое максимальное пространство на VMFS сразу же при создании.
Thick Provision Eager Zeroed - тоже самое что и Thick Provision Lazy Zeroed, только в момент создания все пространство заполняется нулями, это замедляет процесс инсталляции но повышает производительность диска в эксплуатации.
Способы конвертации диска через GUI vSphere Client:
1. Толстый в тонкий(THICK to THIN) - при наличии "Storage VMotion", во время миграции на другой datastore можно в окне мастера поменять формат виртуального диска. Т.е. мигрируем туда и обратно. Либо, при отсутствии "Storage VMotion", клонируем виртуальную машину под другим именем и с изменением формата диска.
2. Тонкий в толстый(THIN to THICK) - также подойдет первый способ, но кроме него можно кликнуть правой кнопкой в окне "Datastore Browser" на соответствующем файле формата ".vmdk", и выбрать в контекстном меню команду "Inflate".
Способы конвертации диска используя консоль ESXi сервера или подключение по SSH:
1. Толстый в тонкий(THICK to THIN) - используя консоль, переходим в каталог с файлами виртуальной машины и выполняем команду:
В этом случае файл виртуального диска называется vm1.vmdk. Чтобы не ошибиться с выбором файла, его имя нужно уточнить в свойствах виртуальной машины("Edit Settings"), закладка "Hardware". Кликните на жесткий диск, и в поле "Disk File" будет указан путь к необходимому файлу ".vmdk".
2. Тонкий в толстый(THIN to THICK) - также как и в первом пункте, только используя другой параметр:
Нужно помнить, что при копировании виртуальной машины на файловую систему, отличную от VMFS, любой диск будет преобразован в толстый и займет свой максимальный объём.
В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с технологией Thin Provisioning. И несмотря на то что технология стала очень популярной и востребованной, толкового описания того как же это работает на низком уровне мне встретить до сих пор не удалось. В этой статье я попробую осветить наиболее «темные», на мой взгляд, стороны thin provisioning – технические основы данной технологии. То есть, то как именно хост взаимодействует с системой хранения данных. Эти технологии сейчас уже не являются эксклюзивом 3PAR, так как теперь это индустриальные стандарты, но так как технология thin provisioning впервые появилась в 3PAR, то позволю себе отдать все лавры именно этим массивам.
Зачем нужен thin provisioning
Для тех, кто пропустил предыдущие 10 лет, я всё же вкратце напомню, что такое thin provisioning и для чего он нужен, а остальные могут с чистой совесть пропустить этот раздел.
Thin provisioning – это технология виртуализации систем хранения данных, которая позволяет увеличить эффективность использования ресурсов системы хранения. Эта технология необходима для уменьшения использования дискового пространства, которое непосредственно не используется для хранения данных приложений. В частности файловые системы никогда в нормальных условиях не бывают заполнены на 100%. Однако всегда нужно иметь некий запас свободного места для обеспечения нормального функционирования файловой системы и для обеспечения готовности к росту данных. Это фактически не используемое пространство выделяют для всех логических томов на системе хранения данных. Логические тома, дисковое пространство для которых выделяется в полном объеме в момент создания на системе хранения, называют «тостыми». Такая модель использования дисковых ресурсов появилась вместе с первыми устройствами для хранения данных и жива до сих пор.
Для решения подобных проблем и были придуманы thin provisioning и thin reclamation о которых мы и поговорим более подробно.
Как работает thin provisioning
- В момент создания логического тома (LUN) на дисковом массиве не происходит полное выделение всего объёма тома. Инициализируется таблица соответствия LUN LBA -> Backend physical address. Администратор системы хранения указывает максимальный возможный размер тома и порог заполненности тома, при котором он получит предупреждение.
- Выделение новых блоков данных для логического тома происходит по мере заполнения тома.
- При освобождении сервером блоков данных он должен сообщить о освободившихся блоках системе хранения для возврата их в общий пул. Технология называется thin reclamation и описана далее.
- При запросе сервером размера тома (SCSI Read Capacity) система хранения отдаёт максимальный размер тома, который установил администратор СХД.
- Сумма максимальных объемов всех томов на системе хранения может превышать физически доступное пространство на системе хранения.
Исходя из вышесказанного, представить схему работы thin provisioning не составляет труда. При получении системой хранения команды SCSI Write (инкапсулированной в стек FC, SAS, iSCSI и пр.) она выделяет очередную порцию данных и записывает туда данные из SCSI Write. В случае с 3PAR блоки выделяются размером в 16К.
Как работает thin reclamation
А теперь обсудим гораздо более интересные и неочевидные моменты – каким образом хост взаимодействует с системой хранения для возврата освободившегося дискового пространства в общий пул. Взаимодействие хоста и системы хранения – крайне важный нюанс, так как только хост знает какие блоки можно удалять, а какие нет. Технология thin reclamation была впервые реализована на массивах 3PAR и сегодня является индустриальным стандартом, утвержденным Международным Комитетом по стандартизации в сфере информационных технологий (INCITS). Документ называется T10 SBC-3 и расширяет стандарт SCSI новыми командами для взаимодействия с системами хранения (эти команды были добавлены в восемнадцатой ревизии документа 23 февраля 2009 года). Аналогичный стандарт есть также для ATA/SATA устройств.
- UNMAP
- WRITE SAME
- GET LBA STATUS
UNMAP
Сообщает системе хранения о необходимости освободить одну или несколько групп последовательных LBA (Logical Block Address). Система хранения должна пометить данные LBA как свободные (unmapped, в терминах SCSI), освободить место на бекэнде и фоновым процессом затереть данные которые там ранее находились на тот случай, если эти блоки будут потом выделены другому хосту. В этой команде передаётся исключительно служебная информация в виде множества пар состоящих из «LBA Address» и «Number of Logical Blocks».
WRITE SAME
Если по каким-то причинам хост не желает использовать команду UNMAP он может получить похожий эффект с помощью команды WRITE SAME. Для этого предусмотрено битовое поле unmap. Если команда WRITE SAME с установленным битом unmap придет на массив с thin provisioning и том на массиве тонкий, то массив сделает тоже что и в случае с командой UNMAP. Отличается от команды UNMAP (42h) тем, что используя WRITE SAME нет возможности указать большое количество блоков для освобождения. Можно указать только одну пару «LBA Address» и «Number of Logical Blocks».
Также не стоит забывать, что команда WRITE SAME это в первую очередь команда для записи данных. В том случае, если бит unmap не установлен, система хранения не поддерживает thin provisioning или том толстый, то будет выполнена обычная операция записи данных по заданным LBA. Из этого следует, что в данных случаях SCSI READ обязан вернуть именно те данные, которые туда были записаны. Тут некоторые производители вроде того же Хьюлета хитрят и вместо последовательной записи однотипных данных (например нулей) помечают в метаданных логического тома эти блоки как выделенные но «заполненные нулями». Называется эта технология – zero detection.
GET LBA STATUS
Это сервисная операция (специфичная для устройства) и она использует код команды SERVICE ACTION IN (9Eh). Она позволяет узнать серверу:
1. Поддерживает ли том thin provisioning.
2. Статус определенного блока на системе хранения (выделены ли для него реальные ёмкости на бекэнде или нет).
3. Гранулярность thin provisioning для тома.
4. Лимиты (тревожный уровень и максимальный объем).
Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.
В качестве заключения.
Я очень рад, что Вы дочитали до последних строк! К сожалению, я ничего не сказал, про поддержку thin provisioning со стороны файловых систем, баз данных и ОС, не рассказал когда вообще имеет смысл ею пользоваться – а это очень интересная на мой взгляд, но к сожалению объемная тема. Возможно я вернусь к ней позже.
В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с технологией Thin Provisioning. И несмотря на то что технология стала очень популярной и востребованной, толкового описания того как же это работает на низком уровне мне встретить до сих пор не удалось. В этой статье я попробую осветить наиболее «темные», на мой взгляд, стороны thin provisioning – технические основы данной технологии. То есть, то как именно хост взаимодействует с системой хранения данных. Эти технологии сейчас уже не являются эксклюзивом 3PAR, так как теперь это индустриальные стандарты, но так как технология thin provisioning впервые появилась в 3PAR, то позволю себе отдать все лавры именно этим массивам.
Миграция с помощью Storage vMotion
С помощью Storage vMotion вы можете переносить виртуальную машину и ее файлы на диске из одного хранилища данных в другое во время работы виртуальной машины. С помощью Storage vMotion вы можете перемещать виртуальные машины из массивов для обслуживания или обновления. У вас также есть возможность оптимизировать диски для повышения производительности или преобразовать типы дисков, которые вы можете использовать для освобождения места.
Вы можете разместить виртуальную машину и все ее диски в одном месте или выбрать отдельные расположения для файла конфигурации виртуальной машины и каждого виртуального диска. Виртуальная машина не меняет хост выполнения во время миграции с помощью Storage vMotion. Во время миграции с помощью Storage vMotion вы можете изменить тип выделения диска.
Миграция с помощью Storage vMotion изменяет файлы виртуальных машин в целевом хранилище данных, чтобы они соответствовали инвентарному имени виртуальной машины. При миграции переименовываются все файлы виртуального диска, конфигурации, моментальных снимков и файлы .nvram . Если новые имена превышают максимальную длину имени файла, перенос не удастся, ох уж эти длинные пути и тут.
Storage vMotion имеет несколько применений для администрирования виртуальной инфраструктуры, включая следующие примеры использования.
- Обслуживание и реконфигурация хранилища. Вы можете использовать Storage vMotion для перемещения виртуальных машин с устройства хранения, чтобы обеспечить обслуживание или реконфигурацию устройства хранения без простоя виртуальной машины.
- Перераспределение нагрузки на хранилище. Вы можете использовать Storage vMotion для перераспределения виртуальных машин или виртуальных дисков по разным томам хранения, чтобы сбалансировать емкость или повысить производительность.
Сразу скажу, что процесс миграции между хранилищами концептуально одинаков в разных версиях vCenter, но интерфейсы имею разный вид и расположение кнопок
Зачем нужен thin provisioning
Для тех, кто пропустил предыдущие 10 лет, я всё же вкратце напомню, что такое thin provisioning и для чего он нужен, а остальные могут с чистой совесть пропустить этот раздел.
Thin provisioning – это технология виртуализации систем хранения данных, которая позволяет увеличить эффективность использования ресурсов системы хранения. Эта технология необходима для уменьшения использования дискового пространства, которое непосредственно не используется для хранения данных приложений. В частности файловые системы никогда в нормальных условиях не бывают заполнены на 100%. Однако всегда нужно иметь некий запас свободного места для обеспечения нормального функционирования файловой системы и для обеспечения готовности к росту данных. Это фактически не используемое пространство выделяют для всех логических томов на системе хранения данных. Логические тома, дисковое пространство для которых выделяется в полном объеме в момент создания на системе хранения, называют «тостыми». Такая модель использования дисковых ресурсов появилась вместе с первыми устройствами для хранения данных и жива до сих пор.
Как работает и зачем нужен thin provisioning-01
ля решения подобных проблем и были придуманы thin provisioning и thin reclamation о которых мы и поговорим более подробно.
Диски типа 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
Все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки. Преимущество такого диска - производительность и безопасность, недостаток - долгое время создания.
Постановка задачи
У меня в организации есть vCenter Server 7 на котором есть кластер из 24 ESXI хостов. Им презентованы общие датасторы. На одном из датасторов не правильно было спланировано дисковое пространство виртуальных дисков для одной из виртуальных машин, в итоге при заполнении дисков внутри гостевой операционной системы, мы поймали ошибку "There is no more space for virtual disk". Получилось, что суммарный выделенный объем виртуальных дисков превысил размер VMFS хранилища.
В моем примере 11-ое хранилище почти заполнено и там осталось всего 111 из 6 ТБ.
С данного датастора я хочу мигрировать один из виртуальных дисков, размером 2,2 ТБ на другой датастор.
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, далее все начинаю херачить и ломать эту машинку, ставить там свой софт и тестить его, в итоге, у вас же нет снапшота, а откатиться хочется, этот тип диска и позволяет это сделать путем обычной перезагрузки. Хороших примеров его использования полно, главный принцип один раз настроили, что то пошло не так ребутнули и все счастливы.
Варианты миграции виртуальных дисков в ESXI
- Если у вас, как и у меня есть кластер с общими хранилищами, то проблем быть не должно (я не беру в расчет вашу лицензию vCenter). Можно воспользоваться функцией Storage vMotion. Я как то несколько лет назад вам о ней рассказывал, тогда еще были ESXI 5.5.
- Если же у вас нет лицензии или общих хранилищ, то вам придется выключать виртуальную машину, удалять из инвентори диск, потом его переносить через файловый менеджер встроенный в vCenter и заново добавлять виртуальных диск в сервер.
Я пойду первым вариантом и произведу миграцию через Storage Vmotion.
Процесс миграции диска виртуальной машины ESXI в vCenter 5.5
В стареньком клиенте vCetner так же через правый клик вызовите меню "Migrate". В открывшемся мастере выберите пункт "Change datastore".
Далее нажмите на кнопку "Advanced".
Теперь у вас появится возможность изменить "Current Location" на другое хранилище. Нажимаем next.
Остается нажать кнопку "Finish" и запустить процесс миграции виртуального диска в vCenter 5.5.
Процесс миграции диска виртуальной машины ESXI в vCenter 7
Приступаем от слов к делу и выполним Storage vMotion. Щелкните правым кликом по нужному виртуальному серверу и выберите пункт "Migrate".
Выберите пункт "Change Storage only". Это позволит переместить только расположение файлов виртуальной машины, сам хост на котором она работает останется неизменным.
У вас появится список хранилищ, которые вы можете использовать для миграции виртуального диска. Выберите пункт "CONFIGURE PER DISK".
Выбираем нужный виртуальный диск и нажимаем кнопку "CONFIGURE".
Далее выберем нужный датастор на который вы хотите его переместить. Обратите внимание, что на данном шаге вы можете поменять тип диска, для этого есть пункт "Select virtual disk format".
- Same format as source - Используйте тот же формат, что и исходная виртуальная машина.
- Thick Provision Lazy Zeroed - Создается виртуальный диск в толстом формате по умолчанию. Место, необходимое для виртуального диска, выделяется во время создания. Любые данные, оставшиеся на физическом устройстве, не стираются во время создания. Вместо этого он обнуляется по запросу при первой записи.
- Thick Provision Eager Zeroed - Создается толстый диск, поддерживающий такие функции кластеризации, как отказоустойчивость. Пространство, необходимое для виртуального диска, выделяется во время создания. В отличие от формата с отложенным обнулением с толстым резервом, данные, оставшиеся на физическом устройстве, обнуляются во время создания. Создание дисков в этом формате может занять больше времени, чем создание дисков других типов.
- Thin Provision - Используйте формат с тонкой подготовкой. Сначала диск с тонкой подготовкой использует ровно столько места в хранилище данных, сколько изначально требуется диску. Если позже тонкому диску потребуется больше места, его можно расширить до выделенной ему максимальной емкости.
Также вы можете выбрать политику хранения виртуальной машины в раскрывающемся меню "VM Storage Policy". Политики хранения определяют требования к хранилищу для приложений, работающих на виртуальной машине. Вы также можете выбрать политику по умолчанию для хранилищ данных vSAN или Virtual Volumes.
Если на жестких дисках виртуальной машины используются разные политики хранения, новая политика, которую вы выбираете, применяется только к жестким дискам без PMem. Жесткие диски PMem переносятся в локальное хранилище данных PMem целевого хоста.
- Datastore Default - Общая политика хранения по умолчанию, которую предоставляет ESXi, применяется ко всем хранилищам данных и не включает правила, специфичные для любого типа хранилища.
- Management Storage policy - Encryption - можете создавать зашифрованные виртуальные машины
- Management Storage policy - Large
- Management Storage policy - Reqular
- Management Storage policy - Single Node
- Management Storage policy - Stretched
- Management Storage policy - Stretched Lite
- Management Storage policy - Thin
- VM Encryption Policy
- vSAN Default Storage Policy
- VVol No Requirements Policy
нажмите кнопку "CONFIRM" для продолжения миграции.
Далее вам еще раз нужно точно выбрать нужный виртуальный диск и начать процесс миграции.
Процесс миграции занимает разное время, все зависит от объема виртуального диска.
В задачах у вас появится задание "Migrating Virtual Machine active state".
Процесс миграции диска виртуальной машины ESXI в vCenter 6.5
Давайте еще покажу, как это выглядело в vCenter Server 6.5. Так же откройте веб клиента и щелкните правым кликом по виртуальной машине, из контекстного меню выбираем пункт "Migrate".
Чтобы переместить только файлы виртуальных винтов выбираем пункт "Change Datastore" и next
Видим список доступных датасторов, нам необходимо для выбора отдельных дисков нажать кнопку "Advanced".
Далее выберите нужный виртуальный диск и в столбце "Storage", у вас откроется список датасторов.
Далее вы можете выбрать другую политику хранилищ и выберите куда его нужно мигрировать.
На следующем шаге у вас есть возможность выбрать тип диска.
Проверяем, что все указано верно. Если так, то запускаем процесс миграции.
Как я и писал выше, время переезда зависит от размера виртуальных дисков и скорости вашего СХД.
Как работает thin provisioning
Концепция thin provisioning проста и заключается в следующем:
В момент создания логического тома (LUN) на дисковом массиве не происходит полное выделение всего объёма тома. Инициализируется таблица соответствия LUN LBA -> Backend physical address. Администратор системы хранения указывает максимальный возможный размер тома и порог заполненности тома, при котором он получит предупреждение.
Выделение новых блоков данных для логического тома происходит по мере заполнения тома.
При освобождении сервером блоков данных он должен сообщить о освободившихся блоках системе хранения для возврата их в общий пул. Технология называется thin reclamation и описана далее.
Как работает и зачем нужен thin provisioning-02
При запросе сервером размера тома (SCSI Read Capacity) система хранения отдаёт максимальный размер тома, который установил администратор СХД.
Сумма максимальных объемов всех томов на системе хранения может превышать физически доступное пространство на системе хранения.
Как работает и зачем нужен thin provisioning-03
Исходя из вышесказанного, представить схему работы thin provisioning не составляет труда. При получении системой хранения команды SCSI Write (инкапсулированной в стек FC, SAS, iSCSI и пр.) она выделяет очередную порцию данных и записывает туда данные из SCSI Write. В случае с 3PAR блоки выделяются размером в 16К.
Как работает thin reclamation
А теперь обсудим гораздо более интересные и не очевидные моменты – каким образом хост взаимодействует с системой хранения для возврата освободившегося дискового пространства в общий пул. Взаимодействие хоста и системы хранения – крайне важный нюанс, так как только хост знает какие блоки можно удалять, а какие нет. Технология thin reclamation была впервые реализована на массивах 3PAR и сегодня является индустриальным стандартом, утвержденным Международным Комитетом по стандартизации в сфере информационных технологий (INCITS). Документ называется T10 SBC-3 и расширяет стандарт SCSI новыми командами для взаимодействия с системами хранения (эти команды были добавлены в восемнадцатой ревизии документа 23 февраля 2009 года). Аналогичный стандарт есть также для ATA/SATA устройств.
Для реализации thin provisioning стандарт предусматривает 3 SCSI команды:
- UNMAP
- WRITE SAME
- GET LBA STATUS
Стандарт обязывает все системы хранения данных с thin provisioning в обязательном порядке поддерживать как минимум команду UNMAP или же команду WRITE SAME с битом unmap. Рассмотрим описанный протоколом API.
UNMAP
Сообщает системе хранения о необходимости освободить одну или несколько групп последовательных LBA (Logical Block Address). Система хранения должна пометить данные LBA как свободные (unmapped, в терминах SCSI), освободить место на бекэнде и фоновым процессом затереть данные которые там ранее находились на тот случай, если эти блоки будут потом выделены другому хосту. В этой команде передаётся исключительно служебная информация в виде множества пар состоящих из «LBA Address» и «Number of Logical Blocks».
Как работает и зачем нужен thin provisioning-04
Если по каким-то причинам хост не желает использовать команду UNMAP он может получить похожий эффект с помощью команды WRITE SAME. Для этого предусмотрено битовое поле unmap. Если команда WRITE SAME с установленным битом unmap придет на массив с thin provisioning и том на массиве тонкий, то массив сделает тоже что и в случае с командой UNMAP. Отличается от команды UNMAP (42h) тем, что используя WRITE SAME нет возможности указать большое количество блоков для освобождения. Можно указать только одну пару «LBA Address» и «Number of Logical Blocks».
Также не стоит забывать, что команда WRITE SAME это в первую очередь команда для записи данных. В том случае, если бит unmap не установлен, система хранения не поддерживает thin provisioning или том толстый, то будет выполнена обычная операция записи данных по заданным LBA. Из этого следует, что в данных случаях SCSI READ обязан вернуть именно те данные, которые туда были записаны. Тут некоторые производители вроде того же Хьюлета хитрят и вместо последовательной записи однотипных данных (например нулей) помечают в метаданных логического тома эти блоки как выделенные но «заполненные нулями». Называется эта технология – zero detection.
Как работает и зачем нужен thin provisioning-05
Это сервисная операция (специфичная для устройства) и она использует код команды SERVICE ACTION IN (9Eh). Она позволяет узнать серверу:
1. Поддерживает ли том thin provisioning.
2. Статус определенного блока на системе хранения (выделены ли для него реальные ёмкости на бекэнде или нет).
3. Гранулярность thin provisioning для тома.
4. Лимиты (тревожный уровень и максимальный объем).
Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.
Всем привет сегодня рассмотрим, в чем разница виртуальных дисков у 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
Диски типа Thin (тонкие диски)
Эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски наименее производительны (выделение нового блока и его очистка), однако наиболее оптимальны для экономии дискового пространства на системе хранения данных. Чаще всего их используют в тестовых средах и стендах, где нужно по экономить дисковое пространство или же для разработки.
На слайде пример виртуальной машины с тремя дисками общего объема 140 ГБ, а по фату на датасторе используется 80 гб.
Хочу заметить, что не важно какой у вас диск Thick disks, Zeroed thick disks, Eager zeroed thick disks, thin, рано или поздно они при заполнении до одинакового размера будут по скорости идентичны
Процесс миграции диска виртуальной машины ESXI через PowerCLI
Не могу не показать, как производить миграцию Storage vMotion с помощью PowerCLI.
Далее вы можете запустить сам PowerCLI или через PowerShell ISE вызвать его модуль, первое, что необходимо это подключиться к вашему vCenter Server, через команду:
В своем примере у меня есть виртуальная машины SVPRDLS04 у нее два виртуальных диска, я буду перемещать на другой датастор второй диск, объемом 100 ГБ. Чтобы посмотреть список дисков у виртуальной машины, номера дисков, так как это будет использоваться в командах, на каком датасторе сейчас лежат, выполните:
Нужный мне диск имеет параметры:
- CapacityGB - 100 ГБ
- Filename - указано, что лежит на датасторе DELL_05
- Name - Hard disk 2, то есть имеет второй порядковый номер
Далее нам нужно посмотреть список доступных хранилищ и свободное на них место, чтобы определиться куда мы будим мигрировать виртуальный диск. Для этого выполните:
Я буду перемещать второй диск на хранилище DELL_04, там достаточно свободного места.
Теперь зная вводные данные вы можете соорудить не сложную конструкцию.
$MoveDatastore = Get-Datastore -Name "DELL_04"
Move-HardDisk -HardDisk $MoveDisk -Datastore $MoveDatastore
Разрешаем миграцию и нажимаем "Y".
Через некоторое время, когда задние будет выполнено снова запросите свойства виртуальных дисков на нужном сервере, как видите все успешно мигрировало.
Читайте также: