Thin provisioning что это

Thin provisioning что это

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

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

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

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

Как работает и зачем нужен thin provisioning-01

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

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

Концепция thin provisioning проста и заключается в следующем:

Как работает и зачем нужен 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 команды:

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

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

Как работает и зачем нужен thin provisioning-06

Как работает и зачем нужен thin provisioning-07

Источник

Типы дисков 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 — можете удалить.

Источник

LVM Thin Provision: опыт эксплуатации на малом объекте

Краткая вводная

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

Грабли

Всем, кто начинает использовать тонкие тома, настоятельно рекомендуется чтение man lvmthin с пристрастием. Упущение, казалось бы, маловажного аспекта, что место в пуле томов может кончится, может привести к печальным последствиям.

Исчерпание места в Data space:

В зависимости от ФС. Обычно, после остановки io с переполненным томом, ФС остается целой, особенно если ФС журналируемая. Если вы успели расширить пул, и io-операции не успели отвалится по таймауту, то вообще все будет хорошо. Иначе откат журнала и небольшая потеря данных.

Исчерпание места в Metadata space:

Рекомендации:

Задавайте политику автоматического расширения тонких томов глобально. Задав разумные значения, вы потом сможете используя профили, настроить любую другую политику для пула. Однако, если система не применит профиль (в метаданных пула хранится имя профиля, который могли удалить), она сообщит об этом факте где-то в логах (чего можно и не заметить), но благодаря глобальной политике, все будет относительно неплохо.

LVM Thin Provision отлично работает в ситуации ленивого планирования. Это значит, что стоит под разные задачи создать пулы тонких томов разумно небольших размеров. В этих пулах создать тома, и просто наблюдать, как по мере заполнения растут размеры пулов. Выделять место сразу не стоит, не всегда можно предугадать под, что нужно место.

Размеры chunksize задавайте исходя из задачи. Большие размеры приведут к снижению накладных расходов в метаданных, но повлекут больший расход места на снимках (если совпадет с RAID5-6, то и тут бонус будет).

Zeroing — если отключить, получите чуть-чуть бонуса по скорости, но готовьтесь, в выделенных блоках может встретится всяких мусор.

Работа со снимками

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

По умолчанию снимки создаются с флагом отмены активации. Это может обескуражить, при попытке его подключить.

Источник

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

Источник

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

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

Источник