about NetApp

Серьезной проблемой при эксплуатации систем хранения является непроизводительный расход распределенного места на дисковом томе.

Одной из причин, приведших к использованию “сетей хранения” - SAN - было стремление уйти от жестко “распределеного” по серверам пространства хранения. Сервер с двумя дисками 144GB в RAID1 обладает пространством хранения в 144GB, даже если использует для своей работы значительно меньше (например 5GB OS + 15GB DB = 20GB, остаток неиспользуемого пространства - 124GB).
Но, к сожалению, использовать там где оно нужно это неиспользуемое место на локальных дисках DAS (Direct Attached Storage) для работы практически невозможно. Сейчас мы не рассматриваем разные попытки выхода из положения, например путем создания на свободном месте пространства дисков архивной “файлопомойки” с помощью DFS или просто в виде множества shares.

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

Однако довольно скоро использующие SAN столкнулись с другим вариантом непроизводительного расхода простанства.

Представим себе реальную практическую ситуацию в компании, использующей централизованный SAN-storage.
DB-админ создает новую базу данных, для размещения которой ему нужен новый дисковый раздел (LUN - Logical Unit Number - логический “диск” в SAN-сети). Текущий объем базы 10GB. Однако чтобы в случае необходимости была возможность роста объемов DB-админ намеревается просить больше. “Рост в течении года будет ну например вдвое. Ну хорошо, значит 20GB минимум, ну на всякие непредвиденные расходы попрошу еще 10. ??того 30GB. Как говорится ‘проси больше - дадут меньше’, напишу в заявке 50 GB. Должно хватить.”

Заявка попадает к администратору SAN, которому всегда есть чем заняться кроме как высчитывать место.
“Ох уж эти мне DB-админы. Куда они столько места расходуют? ?? все ходят, все просят еще и еще. Сколько там? 50GB? ?? через месяц опять придут просить увеличить? Такая морока. Ладно, нарежу им по 75GB, или даже по 100GB, чтобы два раза не вставать, может так хоть оставят в покое подольше?”

??так, реально используемые 10GB данных вольготно расположились на пространстве вдесятеро большем (ну или впятеро, если следовать заявке dbadmin). Беда заключается в том, что, несмотря на все технологические достижения SAN в области экономии пространства, то пространство хранения, которое “нарезано” на LUN-ы уже недоступно для использования, кроме как той системой, которой принадлежит LUN, даже в том случае, если оно физически не используется внутри этого LUN-а.
Дорогостоящее пространство на FC-дисках занято, хотя и не используется, и не может быть использовано там, где оно, вдруг может понадобиться. ?? так на каждом из десятков, возможно сотен, LUN-ов.

То есть мы получаем ситуацию, описанную выше с DAS, но на новом технологическом уровне и за значительно бОльшие деньги. ;)
??сследования показывают, что на современных системах хранения степень заполнения LUN-ов данными как правило от четверти до половины его общего объема. ?? это еще достаточно оптимистическая оценка.

??менно решению этой проблемы посвящена концепция thin provisioning-а. К сожалению термин этот достаточно новый, и адекватного перевода на русский для него пока не устоялось, я предпочитаю использовать словосочетание “экономное распределение”.

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

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

??спользование thin provisioning-а позволяет эффективно расходовать имеющееся пространство системы хранения, а экономия места на SAN-сторадже может выражаться во вполне осязаемых тысячах долларов, которые пожирает ежегодно бюджет IT-подразделения на неизбежное расширение емкостей хранения. При этом, прошу отметить, вы отнюдь не принуждены экономить и затягивать пояс. Нет, просто в рассмотренном выше случае про базу данных и ее админа, dbadmin получит свои 50GB, по крайней мере размер выделенного LUN-а ему будет такой. Однако из свободного пространства системы хранения вычтется те 10GB, которые он займет своей базой. Ну а когда через год она у него подрастет до 20, вот тогда и вычтется 20. То есть несмотря на выделение вашей кредитной карточке банка ‘SAN Bank’ ;) лимита в 20 тысяч долларов, которые вы вправе при необходимости потратить, общий объем доступных банку в этот момент для операций средств отнюдь не уменшается на 20K$.

Если не брать во внимание “динозавров иных эпох” типа IBM MVS и прочих мэйнфреймов, первой эту идею реализовала “в железе” компания 3PAR (и следом ряд других столь же малоизвестных пока компаний: Compellent, EqualLogic, Pillar Data), а уж затем о технологии thin provisioning-а заговорили все.

Одной из первых среди крупных вендоров “первого эшелона” thin provisioning для своих систем реализовала также и NetApp, причем, как и ранее, возможности thin provisioning-а стали доступны в том числе и для ранее выпущенных систем NetApp после обновления внутренней OS.
Это стало возможным не только за счет реализации многих ключевых особенностей систем хранения Network Appliance как встроенных функций внутренней OS, но и за счет продуманной и эффективной внутренней файловой системы WAFL и структур ”виртуализованных томов” FlexVol в OS Data ONTAP G7, которые позволяют реализовать возможности концепции thin provisioning просто, “бесшовно” и с минимальным возможным ущербом для производительности.

??з известных вендоров систем хранения безусловно стоит упомянуть также системы Hitachi Tagmastore USP, в которых этим летом также, в той или иной степени, наконец была реализована идея “экономного распределения” емкости с использованием их методов виртуализации (хотя, как оказалось, и со множеством ограничений по использованию).
Для NAS эту технологию в какой-то степени реализовала и EMC в своих системах Celerra.

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

Еще почитать:

NETAPP THIN PROVISIONING: BETTER FOR BUSINESS
Paul Feresten and Quinn Summers, Network Appliance, Inc.
March 2007 | WP-7017-0307

Thin Provisioning in a NetApp SAN or IP SAN Enterprise Environment
Richard Jooss, Network Appliance, Inc.
June 2006, TR-3483

NetApp eases storage provisioning pain
By Jo Maitland, News Director
15 Nov 2004 | SearchStorage.com

Deduplication, Thin Provisioning: Top Storage Trends
By Chris Preimesberger July 6, 2007

ESG group analysis: Thin Provisioning
By Tony Asaro Senior Analyst April 2006

3PAR Thin Provisioning
By: Geoffrey Hough, Sr. Marketing Manager with Sandeep Singh, Product Manager