about NetApp

Недавно в новостях проскочил пресс-релиз 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, с точки зрения системы хранения, почти всегда будет выглядеть примерно так:

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

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

NDMP – Network Data Management Protocol – это разработанный еще в 90-х годах компаниями NetApp и Legato(ныне EMC Software Group) сетевой IP-протокол, и концепция архитектуры резервного копирования для NAS-устройств. Основной идеей, создавшей концепцию NDMP, являлось желание дать NAS-системам хранения, представляющим из себя обычно довольно мощный сервер сам по себе, возможность самостоятельно, своими силами осуществлять резервное копирование своего содержимого.

(Дальше много текста с картинками)

Continue reading ‘NDMP – что это, и как использовать?’ »

Я уже поднимал в этом блоге тему оптимальных решений той или иной задачи. К сожалению, в нашей стране так до сих пор и остались пустыми словами понятия “стоимости владения”, которым так много внимания уделяется во всем мире.
Ну это наша традиционная болезнь. Чтобы уменьшить фотографию с пьянки нет лучше средства чем Adobe Photoshop CS3, а eсли ставить “венду” - то только Datacenter Edition. “Красть - так миллион, … так королеву” :)

Компания, на которую сваливаются нежданные IT-бюджеты ведет себя как “новый русский” из анекдотов в магазине: “Принесите мне все САМОЕ дорогое! Плачу наличными!”. ?? если бы в самом деле платил :) На деле понты не дают возможности купить не САМОЕ дорогое, а на дорогое денег… как бы… не особо-то. :) Особенно сейчас.

Однако предложение: “Ну зачем вам вот это вот, оно для вас сейчас совершенно ни к чему, вы его просто не сможете использовать в полной мере, а стоит оно тут ого-го, возьмите вот так вот, и все будет работать точно также” воспринимают не менее чем как оскорбление. “Как! Мы биг энтерпрайз (ну по крайней мере хотим ими быть), а вы нам какой-то едва ли не entry level подсовываете!”

Простой пример из жизни. У клиента сравнительно небольшая IT-система, в которой два сервера SUN, файлы (и в перспективе базу Oracle) которых надо бэкапить. Есть небольшая ленточная библиотечка для этого, будет еще какой-то дисковый массив. В общем все достаточно экономично.
Предполагается использовать для этого Symantec NetBackup.
Ну тут, в принципе, все просто: один NBU Server, два NBU Client for UNIX и лицензия на Tape Library, 1 Drive.

Затык один: клиент хочет “чтобы бэкап шел по SAN”, чтоб все “как у больших”.
Ну, если “как у больших”, то тогда нужны уже версии Enterprise для сервера и клиентов, только в них есть SAN Backup и SAN Client.
А это совсем другие деньги, тоже как для “больших”.

??того, в рекомендованных ценах от Symantec - более 39 тысяч долларов для всего двух серверов!
?? каждый следующий подключенный сервер обойдется как минимум в 15 тысяч!
?? это только за нашу прихоть “бэкапить по SAN” и больше ни за что (больше никакие другие функции Enterprise Client/Server использовать не планируется).

Но если мы не боимся, что нас “пацаны засмеют”, и воспользуемся стандартным бэкапом по сети (а ведь для бэкапа по сети, если уж мы ни в какую не хотим бэкапный трафик пустить в общую LAN, мы запросто можем поставить выделенный гигабитный сетевой адаптер), то нам будет достаточно версий Standard, и, для того же самого, всего около 14 тысяч (и плюс 1700$ за каждого дополнительного клиента).

А если мы еще чуть внимательнее отнесемся к экономии денег, и тщательнее посмотрим на прайс Симантека то обнаружим там такую чудесную вещь, как NetBackup Starter Kit, в который входит “NBU Server for UNIX Tier 2 + Tape Library License + 5 NBU Clients”, то есть все то что нам надо, плюс еще три клиента на будущее, в запас, и за все про все - 6000 долларов!

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

На следующей неделе я рассмотрю еще некоторые практические варианты эффективной экономии “стоимости владения” в области систем хранения NetApp, которые, возможно, помогут кому то более здраво взглянуть на свои затраты на IT-инфраструктуру в это непростое время.