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

Диски типа 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 — производительность и быстрота создания, а недостатком является — безопасность.
Первый тип: 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. |
|











