Posts tagged ‘thin provisioning’

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, которая облегчает взаимодействие между инициатором и таргетом, в том числе и в таких задачах.

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

VMware на NFS: подробности о плюсах.

Я решил не раздувать прошлый пост, упихивая в него всю тему.
Сегодня подробнее о том, почему, и как именно вы получите “больше от того же NetApp” при использовании VMware на NFS.

Простое и эффективное использование всех фич NetApp, таких как thin provisioning (динамическое выделение пространства тому по мере его потребности в месте, а не сразу в момент нарезки тома или LUN), дедупликация, снэпшоты.

Почему оно хорошо работает с NFS и что ему мешает работать также хорошо на FC/iSCSI?

Схема работы VMware ESX по NFS с NetApp FAS

Thin Provisioning (подробнее было здесь)
Я уже ранее писал о thin provisioning. Это любопытная технология, которая позволяет экономить место на дисковой системе хранения за счет того, что, в отличие от традиционного метода, место для занимающего пространство объекта, будь то LUN или файл, например тот же VMDK, выделяется и резервируется не в момент создания, а по мере заполнения его реальным содержимым.

Простой пример. Вы администратор системы хранения и у вас есть 1TB. Но кроме терабайта пока свободного места у вас есть пользователи со своими проектами. Например к вам пришли трое, каждый желает получить по 500GB под свои базы данных. У вас есть несколько вариантов решения. Вы можете выделить первым двум запрашиваемые 500 и отказать третьему. Вы можете урезать их треования и выдать всем троим по 330GB вместо просимых 500.

В обоих случаях вы окажетесь с полностью “занятым” стораджем, при том, что вы точно знаете, что в ближайший год все три базы едва ли по 50-70GB объема наберут, остальное же выданное место будет лежать “про запас”, “чтобы два раза не ходить”, распределенным и не доступным другим нуждающимся. Обычное дело, всем знакомо.

В случае использования thin provisioning-а вы смело выдаете всем троим по просимым 500GB. Все трое видят для себя доступным LUN размером 500GB, ура. Они создают на нем базы, каждая из которых постепенно растет и использует место. С точки зрения же вас, как администратора, свободное пространство на дисках, общей емкостью в 1TB, несмотря на то, что на нем лежит три якобы 500GB LUN, уменьшилось всего на 50*3=150GB, и вы все еще имеете 850GB свободного места, постепенно уменьшающееся по мере роста реального размера баз. Придет к вам четвертый - получит пространство под свои задачи и он.

Традиционный вопрос и традиционный ответ.
Q: А как же фрагментация? Ведь мы еще со времен Windows 95 привыкли отключать динамически изменяемый своп и фиксировать его для достижения лучшей производительности? Если мы предоставим LUN-у рсти как ему вздумается, то он начнет писаться куда попало, а не подряд?

A: Ну наверное для Windows на FAT это действительно верно. Но в случае WAFL это особого смысла не имеет. WAFL как файловая система устроена так, что он в любом случае будет писать “вразнобой” (см. статью про устройство WAFL), “куда попало” AKA “Write Anywhere”. То есть выделили-ли вы фиксированный LUN, или предоставили ему расти самостоятельно (autogrow), хоть так, хоть сяк, оно будет работать, с точки зрения файловой системы, одинаково. ?? если вас устраивало быстродействие в случае традиционного provisioning-а “одним куском”, то нисколько не медленнее оно будет и в случае thin provisioning-а.

Почему это хорошо работает для NAS, и часто не так хорошо для SAN?
Дело в том, что в случае NAS система хранения обладает полной информацией о хранимых данных. Ведь она создает и поддерживает на своей стороне файловую систему, и знает все о том, что у нее хранится. В случае же хранения LUN, она просто предоставляет внешнему пользователю “массив байт”, и далее не знает ничего о том, что и как там на нем происходит.
Вся информация, которой она располагает, это то, что вот эти байты были “потроганы”, и, значит, скорее всего, содержат информацию, а вот эти - нет, и скорее всего они пусты и не используются.

Простой пример, приведший к созданию опции Space Reclamation в новых версиях SnapDrive for Windows.
Мы создаем LUN размером 500GB и размещаем на нем файловую систему, например NTFS. Мы форматируем ее, создаем на ней некую структуру файловой системы, и начинаем записывать данные. Спустя какое-то время мы записали на данный LUN 90% его емкости и решили его почистить от ненужного, надеясь за счет thin provisioning-а получить больше свободного места на системе хранения. Но, после удаления более ненужной информации, наш LUN на системе хранения продолжает занимать все те же 450GB, как и до чистки. Почему?

Потому что SAN-сторадж ничего не знает о том, что на нем произошла чистка. Вы знаете, что отличие свободного от занятого блока, с точки зрения файловой системы, это просто наличие специального атрибута блока “свободен, можно использовать повторно”. С точки зрения системы хранения все 450GB нашего LUN-а несут какую-то информацию, а таблица “занято-свободно” файловой системы для стораджа недоступна.

??менно для решения такой проблемы и была создана опция Space Reclamation. SnapDrive, работая “послом” на уровне OS и взаимодействуя с драйвером файловой системы, сообщает “вниз”, своему стораджу, что там “наверху” происходит, какие из ранее использованных блоков можно опять считать незанятыми и освободить их.
Но такое доступно, повторюсь, только при использовании нового SnapDrive.

Зато просто и естественно получается при использовании стораджа как NAS. Веь в данном случае он сам следит за тем, какие блоки занимаются и высвобождаются.
Следовательно, thin provisioning на NAS получается, обычно, гораздо эффективнее.

Дедупликация.

Подробнее и в деталях о дедупликации можно почитать на русском языке в статьях “A-SIS: Дедупликация созрела” и “Насколько безопасна дедупликация?”
Кроме того, хочу обратить ваше внимание на русскоязычную рассылку, которую проводит российский дистрибутор NetApp - компания Verysell. Ссылка на уже вышедшие выпуски находится справа, в колонке “Ссылки” - “Русскоязычные документы”.

Это технология, при которой система обнаруживает в хранимых данных идентичные блоки, оставляет один, а на второй ставит своеобразные “хардлинки” на уровне файловой системы WAFL. То есть, с точки зрения пользователя, как раньше у него лежал в его домашней папке разосланный всем по компании документ, так и сейчас лежит, также как у сотни его коллег. На деле блоки данных этого документа хранятся в единственном экземпляре, просто логически доступны из множества пользовательских папок системы хранения.

Deduplication

Точно также все обстоит и в случае использования, например, баз данных. Если в базе данных у вас есть, например, пустые поля, или повторяющиеся записи, то эти поля не будут занимать блоки, в которых они расположены, а лишь одну копию, и “линки” на этот блок из множества других мест.

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

Если вы используете “классический метод” подключения LUN к ESX-серверу, с созданием на нем VMFS и хранением в ней файлов виртуальных дисков VMDK, то вы тоже можете воспользоваться дедупликацией. Так как она работает на уровне тома WAFL, то она заработает и для LUN-ов.

Однако вот в чем хитрость. При использовании дедупликации для LUN, экономию места вы увидите на уровне “администратора системы хранения”, а не “администратора VMware”. То есть после завершения postprocess-цикла дедупликации вы не увидите больше места на LUN. Но вот зато на томе NetApp, где располагается этот LUN, вы действительно получите больше места (например для размещения снэпшотов), так как физический объем LUN-а уменьшился, относительно содержащего его тома.
А вот если мы дедуплицируем содержимое NFS-шары, то вот прямо свободное место, непосредственно доступное админу VMware на этой шаре, в результате и получаем. Опять же по вышерассмотренной причине.

Снэпшоты - один из краеугольных камней системы хранения NetApp и одна из ее самых главных технических фишек. Мгновенные копии состояния системы хранения, не занимают в момент создания места, не ухудшают при использовании производительность системы в целом и весьма просты в применении.

Традиционный подход это подключение LUN по FC или iSCSI, форматирование его в VMFS и создание на нем datastore, для размещения в datastore файлов виртуальных дисков VMDK.
Обычно, когда мы не ограничиваемся одной-двумя виртуальным машинами, мы объединяем и группируем диски виртуальных машин по датасторам. Тут у нас Эксченджи, тут файловые сервера, а тут - базы данных. Это облегчает администрирование, увеличивает надежность сервисов, и улучшает производительность, группируя сходную нагрузку в пределах одного потока ввода-вывода.

Но, как известно бэкап - ничто, без процесса восстановления. А вот с восстановлением все будет непросто. Так как в снэпшоте у нас окажется LUN целиком, то и восстановить его, привычным образом через “snap restore ” мы можем только целиком, вместе со всеми VMDK от разных машин. Хорошо ли будет из за сбоя на одном сервере откатывать всю группу? Сомневаюсь.
Конечно есть выходы, можно смонтировать снэпшот как отдельный датастор, и из получившегося “датастор-прим” вытащить только нужные нам VMDK, а затем перенести их в основной датастор, заменив ими текушие файлы…
Но как-то… неаккуратненько.

Какой же выход?
Можно перейти от LUN/VMFS, рассмотренных выше, к LUN/RDM. То есть каждой виртуальной машине мы цепляем свой, созданный специально для нее LUN (или, чаще, два LUN. Один под систему, второй под swap и temp или /var). Казалось бы, мы решаем проблему с недостаточной гранулярностью восстановления, так как в данном случае мы сможем восстановить любой желаемый виртуальный диск, любой виртуальной машины по выбору.

Однако это хорошо работает только при сравнительно небольшом количестве виртуальных машин. Во первых, “датацентр” VMware, включающий в себя все входящие в него ESX-сервера, объединенные процессом VMotion, ограничен в количестве используемых на нем LUN-ов числом 254 LUN-а.
Да и управление, например, двумя-тремя десятками виртуальных машин, каждая по два-три LUN в RDM, все эти LUN, как их не документируй, обязательно блудят и путаются. Решение для сильных духом и очень аккуратных админов.

Во вторых, мы в полный рост столкнемся с проблемой “заблудившихся LUN-ов”. Если наша виртуальная машина на одном из ESX-серверов использует LUN/RDM, то _все_ остальные ESX-сервера, входящие в “датацентр” будут видеть этот LUN как неиспользуемый, не понимая, что это RDM LUN для виртуальной машины. ?? существует весьма серьезная опасность, что однажды вы его таки отформатируете как незадействованный, в VMFS, вместе со всем его содержимым. Спрятать его нельзя, так как он должен быть доступен всем входящим в “датацентр” серверам для работы VMotion и перемещении нашей виртуальной машины между хостами. Это на самом деле серьезная опасность.

Таким образом при использовании снэпшотов на NFS-томе вы можете получить гораздо более “гранулярный” и удобный в использовании результат как при бэкапе, так и при восстановлении.

Как, вы все еще думаете, использовать ли для вашего VMware наш NFS? ;)