Space Reclamation

Недавно в новостях проскочил пресс-релиз NetApp, о том, что NetApp теперь поддерживает Thin Reclamation API компании Symantec. Эта новость имеет непосредственное отношение к теме Space Reclamation, которую я, кажется, в этом блоге еще не затрагивал.
Что такое Space Reclamation и зачем это вам нужно?

Задача Space Reclamation непосредственно соотносится с процессом использования так называемого Thin Provisioning.
Допустим, что мы создали в сети SAN на системе хранения LUN, на котором создана файловая система, и этот LUN постепенно заполняется данными. Мы решили использовать для этого LUN механизм Thin Provisioning, при котором место под LUN не выделяется сразу (хотя прикладная задача, использующая этот LUN "видит" сразу все заявленное место), а LUN может постепенно расти, по мере того, как на LUN записываются данные.
Настает момент, когда данные заполнили файловую систему, лежащую поверх LUN, и мы начали какую-то часть данных удалять, освобождая свободное место на диске.

Однако, у системы хранения НЕТ возможности понять, что ранее занятые блоки на LUN в созданной на нем файловой системе были освобождены. Вдобавок в современных файловых системах процесс освобождения блоков, использованных тем или иным файлом зачастую ограничивается пометкой в "таблице размещения файлов" (как бы она не называлась) блоков, занятых "удаленным" файлом, как "освобожденных", и только.

Таким образом, без "посредника" на уровне OS, драйвера файловой системы, или того или иного API к файловой системе, система хранения не имеет никаких средств, чтобы определить, что данный блок, ранее чем-либо занятый, больше не используется, и его можно не хранить, занимая место на диске.
Все что знает система хранения, что "вот эти" дисковые блоки были хотя бы раз "потроганы" со стороны хоста, а "вот эти" - нет. Понять, с какой целью они были "потроганы" система хранения не может.

По этой причине график использования места на LUN, с точки зрения системы хранения, почти всегда будет выглядеть примерно так:

clip_image001

Как вы видите, такая ситуация сильно снижает эффективность использования Thin provisioning, так как thin-provisioned LUN всегда однонаправленно растет, и единожды занятое место уже не освобождает, даже если фактически, со временем, он опустел.

Эта проблема присуща ВСЕМ системам хранения, независимо от того, как они работают, это не специфическая проблема NetApp, она присуща любым SAN-системам хранения, на которых хранятся LUN-ы в режиме thin provisioned.  
Повторюсь: без "посредника" на уровне OS узнать о том, что происходит на файловой системе поверх LUN, о том, какие из блоков ее теперь "пусты", и, значит, можно как-то их "оптимизировать" у системы возможности нет.

Так происходит с любыми LUN, в особенности это является проблемой при наличии thin provisioned LUN, так как, уверен, вы рассчитывали на то, что после удаления данных на LUN вы сможете использовать освободившееся место под распределение данных других LUN. Но не тут-то было.

То есть просто организовать использование thin provisioning в системе хранения зачастую недостаточно. Неплохо было бы как-то отрабатывать ситуацию с удаленными на LUN данными, иначе, как мы видим, LUN всегда "однонаправленно" растет в объеме, даже если в дальнейшем его содержимое и опустошается. Это, очень часто, сводит на нет все заманчивые перспективы использования thin provisioning в продакшне.

В 2007-м году в новой версии ПО SnapDrive for Windows появилась реализация механизма "hole punching" для файловой системы NTFS. Работая на уровне OS, SnapDrive "видит" содержимое файловой системы, лежащей на LUN, и коммуницирует с системой хранения, сообщая ей, какие из блоков более данных не содержат, и могут быть безболезненно освобождены.

Запуск процесса Space Reclamation в SnapDrive, может значительно уменьшить занимаемое LUN-ом место на дисках системы хранения, если мы создали его "нефиксированного размера", без "capacity guarantee", то есть в виде, который принято сегодня называть thin provisioned.

Недавно NetApp объявил, что он присоединился к инициативе компании Symantec, разработавшей в 2008 году Thin Reclamation API для своего продукта - Veritas File System (VxFS) и Veritas Volume Manager (VxVM). Ранее о реализации поддержки этого API объявили такие компании, как 3Par, IBM, EMC (Clariion), HP (XP), HDS.

Таким образом, пользователям NetApp теперь доступен механизм Space Reclamation для двух файловых систем - для NTFS через SnapDrive for Windows и для VxFS через Thin Reclamation API.

Механизм работы в принципе довольно прост и стандартен, возможно, со временем, мы увидим его реализацию и для других файловых систем. Используется стандартизованная комитетом T10 (организацией, которая занимается разработкой и стандартизацией протокола SCSI) команда SCSI-3 WRITE_SAME с флагом UNMAP. Также предложена для введения в стандарт собственно команда UNMAP, которая облегчает взаимодействие между инициатором и таргетом, в том числе и в таких задачах.

Широкое распространение этого метода откроет новые перспективы использования динамически распределяемого пространства на системах хранения.

5 комментариев

  1. Korj:

    Добавление в скедулер/крон ночью забивания нулями пустого пространства (таких утилиток пачка под любую ОС и ФС) решит проблему однозначно, как минимум при включенной дедубликации. Хотя, конечно, вместо этого шаманства честно сказать СХД об освобождённом пространстве - логичнее и быстрее.

  2. Не “решит”, а “ухудшит еще более”. Почему - читайте внимательнее.
    И, да, дедупликация никак не влияет на _размер_ LUN-а в мегабайтах.

  3. Korj:

    Всё зависит от того, что считать “проблемой”. Если размер LUN, и вытекающие из этого проблемы с размером volume и т.д. - то да, ухудшит. Если же место на aggr, то оно после такой операции будет свободно.
    Опять же, смотря что лежит на том LUN. Если на нём лежат образы дисков для виртуальных машин, то внутри у них будет та же ситуация, и во второй уровень вложенности уже только дедупликация добраться и сможет - там уже никакого snapdrive.

  4. Ну так я же и написал,”что считать проблемой”. Проблемой считать то, что thin provisioned LUN растут, даже если данные внутри них удаляются, и “логически” они пусты. Система хранения об этом не знает, и не может высвободить однвжды занятое таким томом место, что снижает эффекивность thin provisioning.

  5. Korj:

    “Система хранения об этом не знает, и не может высвободить однажды занятое таким томом место”

    Подождите, но ведь место-то как раз высвобождается дедупликацией! Что, кроме циферок в интерфейсе управления пострадает? Какие практические минусы, кроме “идеологически неверного” подхода?

Оставить комментарий

20/0.137

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.