Thin provision что это
Основы тонкого выделения томов на системах хранения (или юбилей 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. Лимиты (тревожный уровень и максимальный объем).
Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.
LVM Thin Provision: опыт эксплуатации на малом объекте
Краткая вводная
О тонких томах я уже писал в более ранней статье. Производительность хорошая, слабо зависит от количества снимков, за более чем год, не было сбоев по вине именно LVM, все проблемы были созданы лично мной для себя любимого.
Грабли
Всем, кто начинает использовать тонкие тома, настоятельно рекомендуется чтение man lvmthin с пристрастием. Упущение, казалось бы, маловажного аспекта, что место в пуле томов может кончится, может привести к печальным последствиям.
Исчерпание места в Data space:
В зависимости от ФС. Обычно, после остановки io с переполненным томом, ФС остается целой, особенно если ФС журналируемая. Если вы успели расширить пул, и io-операции не успели отвалится по таймауту, то вообще все будет хорошо. Иначе откат журнала и небольшая потеря данных.
Исчерпание места в Metadata space:
Рекомендации:
Задавайте политику автоматического расширения тонких томов глобально. Задав разумные значения, вы потом сможете используя профили, настроить любую другую политику для пула. Однако, если система не применит профиль (в метаданных пула хранится имя профиля, который могли удалить), она сообщит об этом факте где-то в логах (чего можно и не заметить), но благодаря глобальной политике, все будет относительно неплохо.
LVM Thin Provision отлично работает в ситуации ленивого планирования. Это значит, что стоит под разные задачи создать пулы тонких томов разумно небольших размеров. В этих пулах создать тома, и просто наблюдать, как по мере заполнения растут размеры пулов. Выделять место сразу не стоит, не всегда можно предугадать под, что нужно место.
Размеры chunksize задавайте исходя из задачи. Большие размеры приведут к снижению накладных расходов в метаданных, но повлекут больший расход места на снимках (если совпадет с RAID5-6, то и тут бонус будет).
Zeroing — если отключить, получите чуть-чуть бонуса по скорости, но готовьтесь, в выделенных блоках может встретится всяких мусор.
Работа со снимками
Снимок создается без проблем, а вот его применение может вызвать некоторую проблему. Все дело в том, что пока том активен (хотя и не используемый), снимок к нему не применяется до следующей активации (или применяется в ленивом режиме). Поэтому, перед накатом снимка, дезактивируйте целевой том.
По умолчанию снимки создаются с флагом отмены активации. Это может обескуражить, при попытке его подключить.
О производительности Thin Provision в LVM2
С версии RHEL 6.4 в LVM2 включена поддержка thin provision. На русский я бы перевёл это как «тонкое резервирование», хотя перевод неточен и совершенно не согласуется с реальностью, поэтому далее наравне с русским будет использоваться английское написание.
Thin provisioning — это создание логических томов, которые изначально используют немного места и «растут» по мере записи в них данных. В ZFS это реализовано давно по самой философии этой ФС. В VMware это используется в каждом продукте. Дошло дело до LVM2, широко применяемом в Linux в наши дни. Также одним из основных нововведений является thin snapshots, когда для снэпшотов нет необходимости резервировать место заранее, а он «растёт» вместе с изменёнными данными. Также разрешаются и поощряются вложенные снэпшоты (снэпшоты снэпшотов c любой глубиной), при этом заявляется об отсутствии при этом падения производительности. О нескольких нюансах использования будет рассказано в статье.
Меня больше интересовали не снэпшоты, а производительность «тонких логических томов» (Thin Logical Volume) для использовании на серверах. Для нетерпеливых скажу сразу — падение производительности наблюдается, и существенное. Подробности ниже.
На одном и том же сервере с CentOS 6.4 2.6.32-279.2.1.el6.x86_64 на RAID1 сделанном при помощь mdadm, создаём «пул тонкого резервирования» (thin pool):
и обычный логический том (LV):
Измерим производительности линейного чтения и записи на эти устройства:
Thin pool:
Запись:
Чтение:
Как видно производительность при этом не различается для LV и thin pool.
Создаём thin volume (тонкий логический том) в thin pool
Запись:
Чтение:
Очень хорошо заметно, что линейная запись на thin volume производится в 2 раза медленнее, чем на обычный LV (27.1 MB/s против 66.2 MB/s). При этом скорость случайной записи даже возрастает, а для случайного чтения вообще не удалось замерить реальную производительность — показывает только уровень чтения из кеша, при этом сброс кеша не помог.
Падение производительности линейной записи настораживает и есть вероятность, что это связано с наличием RAID1 от mdadm, поэтому пришлось протестировать на другой машине, также посмотрим на производительность на уровне файловой системы. Виртуальная машина VMware Workstation Debian Wheezy 7.3 3.10-0.bpo.3-amd64 SSD диск.
Запись:
Чтение:
Thin LV:
Запись:
Чтение:
Производительность случайной записи измерить не удалось.
И снова наблюдаем падение скорости линейной записи в два раза, как и в предыдущем тесте. Возможно это связано с нюансами виртуальной машины.
UPDATE: Произвёл ещё одно тестирование на «чистом» сервере без RAID и вирт.машин. Падение производительности линейной записи не наблюдается! Прошу прощения уважаемой аудитории за введение в заблуждение в связи с однобокостью тестирования в первые два теста. В результате считаю необходимо тестировать производительность для каждого конкретного случая.
LVM Thin Provisioned volume, тонкие (разреженные) тома
RedHat (и CentOS) начиная с версии 6.4 поддерживают Thin provisioned storage разряженные тома. Основная мысль похожа на разреженные (sparce) файлы. Том выглядит большим, но на самом деле занимает мало места — только то, которое нужно для хранения данных.
1. Уже должна существовать группа дисков (VG) и в ней должно быть свободное место, например storage
2. Создается пул разреженных томов, например на 100Гб. Эти 100Гб сразу отмечаются в VG как занятые и их нельзя исползовать под обычные LVM-разделы. Разреженные тома создаются внутри этого пула. Пул разреженных томов нигде симлинками не отмечен и напрямую не используется.
3. Создается разреженный том. Видимый размер разреженного тома может быть больше чем доступное место в пуле и даже больше размера самого пула, пока данные фактически могут поместиться в пул. Для разреженного тома так же как и для обычного создается симлинк (/dev/storage/test) и далее с ним можно работать как с обычным LVM-томом.
Просмотр фактически занятого места в пуле и на томе:
Если место в пуле будет полностью израсходовано и кто-то в этот момент попробует записать данные на диск — операция ввода/вывода будет приостановлена пока в пуле не появится место (можно что-то удалить или расширить пул через lvextend), после появления места операция записи будет завершена.
Кроме постепенного выделения места поддерживается и освобождение в пуле места которое раньше было занято, но теперь не нужно. Например на каком-то разделе потребовалось место чтобы создать/распаковать большой архив. А потом архив удаляется. Освобождение места поддерживается через механизм TRIM (аналогично очистке места на SSD) и в LVM называется discard_data.
освобождать место можно двумя путями:
1. Вручную, командой fstrim — место освобождается только при запуске команды в указанной точке монтирования
2. монтировать файловую систему с опцией discard. например — тогда место освобождается сразу после удаления данных с диска. (прим. XFS активно кеширует все изменения, так что в случае использования XFS нужно сделать sync если нужно очистить место быстро, либо подождать несколько минут пока изменения фактически применятся на диск сами).
Thin provision что это
В этом году исполняется 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