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

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

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

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

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

Она обладает следующими минусами:

• Выделенное одному логическому тому (но не используемое) пространство не может использоваться другим томом. При стремительном росте объема данных на одном логическом томе мы рано или поздно упремся в его размер и тот факт, что на других логических томах есть достаточно много неиспользуемого дискового пространства нам никак не поможет. То есть свободное дисковое пространство не представлено общим пулом из которого любой том может брать ёмкости при необходимости, а по сути жестко привязано к каждому тому. Кроме того, что это жутко расточительно, эта схема ещё и неудобна в том случае, если нужно перераспределить емкости между томами.
• Так как точно предсказать рост данных приложения чаще всего весьма сложно, то обычно размеры толстых томов выбирают с солидным запасом. По различным исследованиям коэффициент использования систем хранения данных с толстыми томами колеблется от 30 до 50 процентов. Однако неиспользуемое под данные приложений дисковое пространство стоит определенную сумму денег, которые можно было бы направить на куда более полезные вещи.
• При репликации или использовании снапшотов на толстых томах дисковый массив работает с неиспользуемыми хостом блоками, так же как и с использованными. Хотя при репликации можно было бы копировать только занятые блоки, а при использовании снапшотов не копировать (см. copy-on-write) свободный блок в снапшот, а просто пометить его там не занятым. Подобная технология репликации реализована в массивах 3PAR.

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

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

Концепция 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 устройств.
Для реализации thin provisioning стандарт предусматривать 3 SCSI команды:

1. UNMAP
2. WRITE SAME
3. GET LBA STATUS

Стандарт обязывает все системы хранения данных с thin provisioning в обязательном порядке поддерживать как минимум команду UNMAP или же команду WRITE SAME с битом unmap. Рассмотрим описанный протоколом API.

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 не установлен, система хранения не поддерживает TP или том толстый, то будет выполнена обычная операция записи данных по заданным LBA. Из этого следует, что в данных случаях SCSI READ обязан вернуть именно те данные, которые туда были записаны. Тут некоторые производители вроде того же Хьюлета хитрят и вместо последовательной записи однотипных данных (например нулей) помечают в метаданных логического тома эти блоки как выделенные но «заполненные нулями». Называется эта технология – zero detection.

GET LBA STATUS

Это сервисная операция (специфичная для устройства) и она использует код команды SERVICE ACTION IN (9Eh). Она позволяет узнать серверу:
1. Поддерживает ли том thin provisioning.
2. Статус определенного блока на системе хранения (выделены ли для него реальные ёмкости на бекэнде или нет).
3. Гранулярность thin provisioning для тома.
4. Лимиты (тревожный уровень и максимальный объем).
Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.

В качестве заключения.

Я очень рад, что Вы дочитали до последних строк! К сожалению, я ничего не сказал, про поддержку thin provisioning со стороны файловых систем, баз данных и ОС, не рассказал когда вообще имеет смысл ею пользоваться – а это очень интересная на мой взгляд, но к сожалению объемная тема. Возможно я вернусь к ней позже.