В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с Thin Provisioning. И несмотря на то, что технология стала очень популярной и востребованной, мне до сих пор не удалось встретить внятного описания того, как она работает на низком уровне.
В этой статье я попытаюсь осветить самые «темные», на мой взгляд, стороны Thin Provisioning — технические основы этой технологии.
То есть, как именно хост взаимодействует с системой хранения данных.
Эти технологии уже не являются эксклюзивом 3PAR, поскольку теперь они являются промышленными стандартами, но поскольку технология Thin Provisioning впервые появилась в 3PAR, я позволю себе отдать все лавры этим массивам.
Зачем нужна тонкая подготовка?
Для тех, кто пропустил предыдущие 10 лет, я всё же вкратце напомню, что такое Thin Provisioning и для чего он нужен, а остальные могут с чистой совестью пропустить этот раздел.Thin Provisioning — это технология виртуализации системы хранения, позволяющая повысить эффективность использования ресурсов системы хранения.
Эта технология нужна для сокращения использования дискового пространства, которое напрямую не используется для хранения данных приложений.
В частности, в нормальных условиях файловые системы никогда не заполняются на 100%.
Однако всегда необходимо иметь определенное количество свободного места, чтобы обеспечить нормальное функционирование файловой системы и обеспечить готовность к росту данных.
Это практически неиспользуемое пространство распределяется по всем логическим томам системы хранения.
Логические тома, для которых дисковое пространство выделяется полностью в момент создания в системе хранения, называются «толстыми».
Эта модель использования дисковых ресурсов появилась вместе с первыми устройствами хранения данных и жива до сих пор.
Он имеет следующие недостатки:
- Пространство, выделенное (но не используемое) одному логическому тому, не может использоваться другим томом.
При быстром росте объема данных на одном логическом томе мы рано или поздно столкнемся с его размером и тот факт, что на других логических томах много неиспользуемого дискового пространства, нам никак не поможет. То есть свободное дисковое пространство не представлено общим пулом, из которого при необходимости может взять емкость любой том, а фактически жестко привязано к каждому тому.
Помимо того, что это жутко расточительно, такая схема еще и неудобна, если нужно перераспределить мощности между томами.
- Поскольку точно спрогнозировать рост данных приложения зачастую очень сложно, размер толстых томов обычно выбирают со значительным запасом.
По данным различных исследований, коэффициент использования систем хранения больших объемов колеблется от 30 до 50 процентов.
Однако неиспользуемое дисковое пространство для данных приложения стоит определенную сумму денег, которую можно было бы использовать для гораздо более полезных вещей.
- При репликации или использовании снапшотов на толстых томах дисковый массив работает как с неиспользуемыми хостом блоками, так и с уже использованными.
Хотя при репликации можно было бы копировать только занятые блоки, а при использовании снапшотов не копировать (см.
копирование при записи) свободный блок в снапшот, а просто отмечать его там как незанятый.
Аналогичная технология репликации реализована в массивах 3PAR.
Для решения таких проблем были придуманы Thin Provisioning и Thin Reclaimation, о которых мы поговорим подробнее.
Как работает тонкое обеспечение
Концепция тонкого обеспечения проста и заключается в следующем:
- Когда логический том (LUN) создается в дисковом массиве, весь том тома не выделяется полностью.
Инициализируется таблица сопоставления физических адресов LUN LBA -> Backend. Администратор системы хранения указывает максимально возможный размер тома и порог объема, при достижении которого он получит предупреждение.
- Новые блоки данных выделяются на логический том по мере его заполнения.
- Когда сервер освобождает блоки данных, он должен сообщить об освобожденных блоках системе хранения, чтобы вернуть их в общий пул.
Технология называется тонкой рекультивацией и описана ниже.
- Когда сервер запрашивает размер тома (емкость чтения SCSI), система хранения возвращает максимальный размер тома, установленный администратором хранилища.
- Сумма максимальных томов всех томов в системе хранения может превышать физически доступное пространство в системе хранения.
Основываясь на вышесказанном, нетрудно представить, как работает тонкое обеспечение.
Когда система хранения получает команду записи SCSI (инкапсулированную в стек FC, SAS, iSCSI и т. д.), она выделяет следующую порцию данных и записывает туда данные из записи SCSI. В случае 3PAR блоки выделяются размером 16 КБ.
Как работает тонкая мелиорация
Теперь обсудим куда более интересные и неочевидные моменты — как хост взаимодействует с системой хранения для возврата освободившегося дискового пространства в общий пул.Взаимодействие хоста и системы хранения — крайне важный нюанс, поскольку только хост знает, какие блоки можно удалять, а какие нет. Технология тонкой восстановления была впервые реализована в массивах 3PAR и сегодня является отраслевым стандартом, одобренным Международным комитетом по стандартизации информационных технологий (INCITS).
Документ называется T10 SBC-3 и расширяет стандарт SCSI новыми командами взаимодействия с системами хранения данных (эти команды были добавлены в восемнадцатой редакции документа от 23 февраля 2009 года).
Аналогичный стандарт также доступен для устройств ATA/SATA. Для реализации тонкого обеспечения стандарт предоставляет 3 команды SCSI:
- ЮНМАП
- НАПИШИТЕ ЖЕ
- ПОЛУЧИТЬ СТАТУС LBA
ЮНМАП Указывает системе хранения освободить одну или несколько групп смежных LBA (адрес логического блока).
Система хранения должна пометить данные LBA как свободные (несопоставленные, в терминах SCSI), освободить место на серверной стороне и использовать фоновый процесс для стирания данных, которые ранее находились там, на случай, если эти блоки позже будут выделены другому хосту.
Эта команда передает исключительно служебную информацию в виде множества пар, состоящих из «Адрес LBA» и «Количество логических блоков».
НАПИШИТЕ ЖЕ
Если по какой-то причине хост не хочет использовать команду UNMAP, он может добиться аналогичного эффекта с помощью команды WRITE SAME. Для этой цели предусмотрено битовое поле unmap. Если команда WRITE SAME с установленным битом unmap поступает в массив с тонким предоставлением и том на массиве тонкий, то с массивом будет действовать то же самое, что и в случае с командой UNMAP. Она отличается от команды UNMAP (42h) тем, что с помощью WRITE SAME невозможно указать большое количество блоков для освобождения.
Можно указать только одну пару «Адрес LBA» и «Количество логических блоков».
Также не забывайте, что команда WRITE SAME – это прежде всего команда записи данных.
В случае, если бит unmap не установлен, система хранения не поддерживает Thin Provisioning или том толстый, то будет выполнена обычная операция записи данных в указанный LBA. Из этого следует, что в этих случаях SCSI READ обязан вернуть именно те данные, которые туда были записаны.
Тут некоторые производители, вроде того же Hewlett, лукавят и вместо последовательной записи однотипных данных (например, нулей) помечают эти блоки в метаданных логического тома как выделенные, но «заполненные нулями».
Эта технология называется нулевым обнаружением.
ПОЛУЧИТЬ СТАТУС LBA
Это сервисная операция (зависит от устройства) и использует код команды SERVICE ACTION IN (9Eh).
Это позволяет серверу знать: 1. Поддерживает ли том тонкую подготовку? 2. Статус определенного блока на СХД (выделены ли под него реальные мощности на бэкенде или нет).
3. Тонкая детализация выделения тома.
4. Пределы (уровень тревоги и максимальная громкость).
Команда очень полезна, например, для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных, или при переходе с толстых томов на тонкие.
В заключение.
Я очень рада, что вы дочитали до последних строк! К сожалению, я ничего не сказал о поддержке Thin Provisioning со стороны файловых систем, баз данных и ОС, не сказал, когда вообще есть смысл его использовать — и это очень интересно, на мой взгляд. , но к сожалению объемная тема.
Возможно, я вернусь к этому позже.
Теги: #Виртуализация #системы хранения #hewlett-packard #SAN #3par #thin Provisioning #thin Reclamation
-
Санкт-Люсия
19 Oct, 24 -
Тайны Быстрого Преобразования Фурье
19 Oct, 24 -
Особенности Работы С Google Drive Api
19 Oct, 24
