disk provisioning vmware что выбирать

Disk provisioning vmware что выбирать

Всем привет сегодня рассмотрим, в чем разница виртуальных дисков у 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

Диски типа Raw

Файловая система VMFS поддерживает схему Raw Device Mapping (RDM), которая представляет собой механизм для прямого доступа виртуальной машины к дисковой подсистеме (конкретному LUN) устройств хранения Fibre Channel или iSCSI. Этот тип виртуального диска доступен для создания из vSphere Client.

Если в сети хранения данных используется ПО для создания мгновенных снимков системами резервного копирования, которые запущены в виртуальных машинах, требуется прямой доступ к дисковой подсистеме устройств хранения. Кроме того Raw-диски используются для кластеров Microsoft Clustering Services (MSCS), включая кластеры типа «виртуальный-виртуальный» и «виртуальный-физический».

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

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

Описание типов виртуальных дисков vmdk виртуальных машин на VMware vSphere ESXI 5.x.x-01

Перед началом операций ввода-вывода виртуальная машина vmware посредством файла маппирования инициирует открытие тома Raw. Далее файловая система VMFS осуществляет разрешение адресов секторов физического устройства, а виртуальная машина начинает производить операции чтения-записи на физическое устройство.

Используя RDM возможно производить следующие операции:

Для RDM используются два режима совместимости:

Использование функций VMotion, DRS и HA поддерживаются в обоих режимах совместимости.

Диски типа Thick (толстые диски)

Это тип дисков vmdk на томах VMFS или NFS, размер которых предопределяется заранее (при создании) и не изменяется в процессе наполнения его данными. Давайте добавим для примера новый виртуальный диск.

Существует три типа дисков thick:

Thick disks

Zeroed thick disks (lazy zeroed thick disks)

Eager zeroed thick disks

Диски типа Thin (тонкие диски)

На слайде пример виртуальной машины с тремя дисками общего объема 140 ГБ, а по фату на датасторе используется 80 гб.

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, далее все начинаю херачить и ломать эту машинку, ставить там свой софт и тестить его, в итоге, у вас же нет снапшота, а откатиться хочется, этот тип диска и позволяет это сделать путем обычной перезагрузки. Хороших примеров его использования полно, главный принцип один раз настроили, что то пошло не так ребутнули и все счастливы.

Independent, Persistent, Non-Persistent диски-03

Источник

Типы дисков vmware esxi «Thick Provision Lazy Zeroed, Thick Provision Eager Zeroed, Thin Provision»

В Vmware Esxi cсуществует три типа дисков thick, пространство таких дисков выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Это может создавать потенциальные угрозы безопасности, поскольку виртуальная машина может получить доступ к данным на хранилище VMFS, которые ей не принадлежат. При обращении к блокам такого диска их содержимое предварительно не очищается со стороны ESX. Преимущество дисков типа thick — производительность и быстрота создания, а недостатком является — безопасность.

Читайте также:  bq25601 что за микросхема

Первый тип: Thick Provision Lazy Zeroed

Все пространство такого диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. При первом обращении виртуальной машины к новому блоку происходит его очистка. Таким образом, эти диски более безопасны, однако при первом обращении к блоку — теряется производительность системы ввода-вывода на операцию очистки. При последующих обращениях — производительность идентична дискам типа Eager zeroed thick. Этот тип диска создается по умолчанию через VMware vSphere Client для виртуальных машин. Преимущество дисков Zeroed thick disks — безопасность и быстрота создания, недостаток — производительность при первом обращении к блоку.

Второй тип: Thick Provision Eager Zeroed

Все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки. Преимущество такого диска — производительность и безопасность, недостаток — долгое время создания.

Третий тип: Thin Provision

Диски этого типа создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока — он предварительно очищается. Такие диски наименее производительны (выделение нового блока и его очистка), однако наиболее оптимальны со стороны экономии пространства на системе хранения данных.

Приведем примеры создание виртуального диска vmdk определенного типа на VMware ESXi

Если вы хотите создать диск определенного типа в ручную, то при ее создании выберите опцию «Do not create disk». Далее необходимо зайти в консоль сервера ESXi по SSH и выполнить команду (предварительно командой cd перейдите в папку с виртуальной машиной) для создания диска типа thin максимальным объемом 20 ГБ :

vmkfstools –c 20G –d thin thin.vmdk

команда для создания диска типа Thin Provision:

vmkfstools –c 20G –d thick thick.vmdk

команда для создания диска типа Thick Provision Lazy Zeroed:

vmkfstools –c 20G –d zeroedthick zeroedthick.vmdk

команда для создания диска типа Thick Provision Eager Zeroed:

vmkfstools –c 10G –d eagerzeroedthick eagerzeroedthick.vmdk

Конвертация типа существующего диска vmdk на ESXi

С помощью указанной команды диск thin затирает содержимое блоков до своего максимального размера и превращается в диск thick:

vmkfstools –j thin.vmdk

Конвертация диска vmdk типа thick в thin. С помощью указанной команды из диска vmdk типа thick копированием получаем диск типа thin (операция длительная):

После завершения процедуры замените исходный диск типа thick на вновь созданный thin, а исходный thick — можете удалить.

Источник

Thin Provisioning — «кредитная карта» для хранилища

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

Причины, стоявшие за созданием SAN, отчасти были теми же, что стояли ранее за созданием обычной локальной сети LAN и shared-устройств в ней. Вместо того, чтобы давать каждому клиентскому компьютеру по лазерному принтеру, который будет простаивать в 99% времени, лучше дадим ему доступ к коллективно используемому принтеру, пусть более мощному и дорогому, но используемому с более высокой средней загрузкой, и тем самым повысим уровень использования ресурса и его экономическую эффективность.
В том числе использование «общего дискового ресурса» решило и проблему «недоиспользования». Если минимально доступный диск SATA на сегодня обычно не менее 500GB, то если мы не используем его для хранения накачанного из торрентов видео, то обычно, в рядовом использовании, он пуст на 90-95%. Типовая установка OS занимает 2-8 GB, приложения и его данные еще сколько-то, чаще всего несколько гигабайт, все же остальное пространство остается свободным, но увы, недоступным для, возможно, нуждающихся задач на других компьютерах.

Так было до тех пор пока не появилась Storage Area Network — SAN — специальная сеть для хранения и передачи данных. В этой сети используется специальный высокоскоростной протокол передачи данных, например FC или iSCSI, который позволяет использовать дисковое пространство с централизованного устройства хранения, без значительных потерь доступности и быстродействия, нарезав и раздав потребителям участки общего пространства нужного им размера, словно это локальные диски данного компьютера, а не разделы на большом общем сторадже.

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

Дело в том, что в практической жизни системный администратор никогда не «нарежет» приложению раздел ровно по запрошенному или занимаемому им пространству, так как всегда нужно пространство на внезапное увеличение объемов, рост базы, в случае базы данных, место под логи для вебсервера, и так далее. Закон природы сегодняшнего дня состоит в том, что объемы информации растут, и, подчас, растут экспоненциально.
Поэтому ничего удивительного, что на дисковых разделах в SAN (обычно их называют LUN) весьма значительное место бывает распределено, но не занято данными соответствующего приложения, однако и для других, более нуждающихся приложений, уже более недоступно.

Для того, чтобы не начинать каждый день с увеличения разделов данных, и не сталкиваться с неожиданно «упавшей» из за исчерпания места задачей, любой администратор системы хранения создает разделы данных на SAN «с запасом», подчас значительным, так, в результатах соответствующего исследования мне встречалось упоминание, что до 60-80% пространства на SAN-хранилищах это распределенное «на будущее», но ничем настоящее время не занятое место.

Читайте также:  при каком давлении лучше клюет лещ летом на реке

Таким образом, всего лишь найдя и использовав способ динамически выделять место на дисках SAN-системы, мы можем, в общем случае, экономить до 60-80% пространства, причем дорогостоящего, быстродействующего дискового пространства, бесполезно «похороненного» в настоящий момент в «нарезанных» LUN-ах «про запас».

Методика выделения пространства хранения приложениям не сразу при создании диска, а по мере возникновения в нем потребности у данных приложения, «on demand», получило название «thin provisioning». К сожалению на русском языке все еще нет общепринятого перевода, поэтому я предпочитаю называть это «экономное распределение».

Как ни удивительно, но с принципом thin provisioning вы широко знакомы в быту.
Так, например, работает кредит в банке. Когда банк выдает десять тысяч кредитных карточек с кредитным лимитом в 500 тысяч, он не хранит в обеспечение на счетах пять миллиардов, так как рассчитывает, что пользователи карточек не станут немедленно тратить все предоставленные им по кредиту деньги, иначе у банка просто бы не хватило активов. Тем не менее, когда это необходимо, вы сможете воспользоваться подлимитной суммой, если общий «пул» средств банка не исчерпан.
Также работают водопроводные и электрические компании, предоставляя вам ресурс они полагают, что весь многоэтажный дом не станет разом открывать краны или включат стиральные машины и электрические чайники, а за счет более гибкого расхода удается сэкономить на цене ресурсов и мощности инфраструктуры.

Точно также работают многозадачные OS и системы виртуализации. Вы можете использовать множество программ одновременно, с условием, что они не захотят одновременно, в одно и то же время, загрузить процессор полностью. Общие ресурсы процессора выделяются приложению по мере необходимости, но каждая программа при этом «питает иллюзию», что ей доступны все 12 ядер вашего нового сервера. Это действительно так, но не разом для всех.

Точно также складывается ситуация при использовании thin provisioning. Если программа желает иметь раздел данных размером 50GB (даже несмотря на то, что в данный момент у нее есть на нем всего 10GB данных), то мы можем предоставить ей раздел, видимый приложением как раздел размером 50GB, однако 40 из них будут «виртуальными», не занимая в этот момент места на дисках системы, пока в них не будут записаны реальные данные. Это позволит нам не «запирать» место «про запас», а использовать его по мере возникновения в нем необходимости.

Насколько мне известно, первой принцип thin provisioning в SAN начала использовать в своих системах хранения недавно купленная HP компания 3Par, у которой эта возможность была ключевой (да и практически единственной) «фишкой» их систем, однако, в числе первых, thin provisioning реализовала и NetApp в своих системах FAS. Для вас должно быть уже не сюрприз, что так просто и быстро (фактически — с новым релизом обновления внутренней OS) это появилось в уже существующих системах потому, что уже не раз помянутая добрым словом, созданная в 1993 году NetApp «файловая система WAFL», лежащая в основе всех систем хранения NetApp, позволила это сделать очень легко и просто.

ВСЕ свободное место на дисках системы хранения, использующей thin provisioning, доступно для увеличения пространства ВСЕМ LUN-ам, любого приложения. Место на дисках сетевой системы хранения становится по настоящему совместно используемым ресурсом.

Не попадите в плен не вполне верной визуализации, при увеличении занятого объема приложением А, данные других приложений не перемещаются по дискам, просто разделу приложения А выделяются и добавляются дополнительные сегменты дискового пространства, лежащие в области свободного места. Теоретически это увеличивает фрагментацию данных, но практически негативным эффектом от него можно пренебречь, так как выделение пространства осуществляется сравнительно протяженными кусками мегабайтного порядка, и, как показывает практика, разница в производительности между thin и thick-данными обычно «ниже измеряемого уровня».

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

Источник

Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

VM Guru / News / Производительность различных типов дисков на флэш-массивах: Thin / Lazy Thick / Eager Thick.

Производительность различных типов дисков на флэш-массивах: Thin / Lazy Thick / Eager Thick.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

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

Использованная тестовая конфигурация:

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Источник

Основы тонкого выделения томов на системах хранения (или юбилей 3PAR thin provisioning)

В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с технологией Thin Provisioning. И несмотря на то что технология стала очень популярной и востребованной, толкового описания того как же это работает на низком уровне мне встретить до сих пор не удалось. В этой статье я попробую осветить наиболее «темные», на мой взгляд, стороны thin provisioning – технические основы данной технологии. То есть, то как именно хост взаимодействует с системой хранения данных. Эти технологии сейчас уже не являются эксклюзивом 3PAR, так как теперь это индустриальные стандарты, но так как технология thin provisioning впервые появилась в 3PAR, то позволю себе отдать все лавры именно этим массивам.

Зачем нужен thin provisioning

Для тех, кто пропустил предыдущие 10 лет, я всё же вкратце напомню, что такое thin provisioning и для чего он нужен, а остальные могут с чистой совесть пропустить этот раздел.

Thin provisioning – это технология виртуализации систем хранения данных, которая позволяет увеличить эффективность использования ресурсов системы хранения. Эта технология необходима для уменьшения использования дискового пространства, которое непосредственно не используется для хранения данных приложений. В частности файловые системы никогда в нормальных условиях не бывают заполнены на 100%. Однако всегда нужно иметь некий запас свободного места для обеспечения нормального функционирования файловой системы и для обеспечения готовности к росту данных. Это фактически не используемое пространство выделяют для всех логических томов на системе хранения данных. Логические тома, дисковое пространство для которых выделяется в полном объеме в момент создания на системе хранения, называют «тостыми». Такая модель использования дисковых ресурсов появилась вместе с первыми устройствами для хранения данных и жива до сих пор.

Для решения подобных проблем и были придуманы thin provisioning и thin reclamation о которых мы и поговорим более подробно.

Как работает thin provisioning

Исходя из вышесказанного, представить схему работы 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

Сообщает системе хранения о необходимости освободить одну или несколько групп последовательных 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. Лимиты (тревожный уровень и максимальный объем).

Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.

Источник

Читайте также:  что делать если кал не выходит полностью
Сказочный портал