about NetApp

Я уже упоминал, что начиная с DataONTAP 7.3.1 емкость aggregate в системах NetApp FAS рассчитывается исходя из “правильной” usable емкости дисков, “после налогов и вычетов” и без учета дисков parity.

Вот каковы right-sized емкости используемых в системах NetApp дисков, исчисленных в “двоичных” единицах (по основанию 1024):

При дальнейших расчетах также не забывайте про “основание 1024”, то есть, что
1695466 MiB = 1655,7 GiB = 1,62 TiB

При расчетах в “двоично-десятичной” арифметике для перехода от “мегабайтов” к “гигабайтам” недостаточно “сдвинуть запятую в числе на три позиции влево”, помните об этом . Разница между “терабайтом” и “тебибайтом” составляет почти 10%!

Вокруг ситуации с usable capacity на NetApp накручено очень много довольно низкопробного манипулирования и FUD-а, см. например мою же статью в блоге, посвященную разоблачению одного из таких текстов.

Как вы знаете, системы на поддержке отсылают в Support Center в NetApp данные о своем состоянии, в том числе и о конфигурации. ??нтересный график был обнаружен в одной из технических презентаций NetApp. Это анализ соотношения между raw и usable capacity для реальных, рабочих систем NetApp, установленных у клиентов компании, эксплуатирующихся в настоящее время и отсылающих сообщения autosupport. В среднем, для 7597 рассмотренных систем, их usable capacity, то есть доступная для использования емкость хранения, емкость дисков за вычетом RAID-penalty (parity drives), spares, WAFL-metadata, reservations и прочего, составила 66,27% от их raw.

Такие дела. Как видите, в реальной жизни достигнутая на системах NetApp средняя величина usable всего на 3% хуже теоретически рассчитанной мной в посте с разоблачением FUD-а.

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

Об опасности, связанной со смешением результатов "двоичной" и "десятичной" арифметик при расчете емкости я уже также писал, а сегодня углубимся в эту тему отдельно.
Как вы все, наверное, знаете, в IT исторически принято считать в "двоичной" арифметике, то есть "килобайт" у нас равен не тысяче, как следовало бы из использования приставки kilo- во всех прочих случаях, а 1024-м байтам. Казалось бы, какая ерунда, всего 24 байта на каждой тысяче, можно не обращать внимания. ?? мы часто не обращали, пока не выросли объемы.
В ранее опубликованной записи я уже показывал, как эта "незначительная разница" достигает 10 процентов на емкостях в терабайт и более.

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

С этой особенностью ближе всего знакомы те, кто используют жесткие диски. Производители жестких дисков указывают емкость своих продуктов в "десятичных" единицах (и при этом абсолютно правы, формально, кроме того, "в попугаях" их емкость "гораздо длиннее";), в то время, как в компьютере у нас всюду используются "двоичные" меры исчисления. Килобайт там состоит не из 1000, а из 1024 байт, мегабайт из 1024 килобайт, и так далее.

Если мы посмотрим на спецификации жестких дисков (возьмем для примера WD RE4 на "2TB") , то мы увидим там следующее:

Sectors per disk drive = 3 907 029 168
Formatted capacity = 2 000 398MB

Давайте проверим приведенные значения:

3 907 029 168 секторов x 512 байт = 2 000 398 934 016 байт
2 000 398 934 016 байт /1000 = 2 000 398 934kB /1000 = 2 000 398MB

Таким образом все верно, WD указал емкость в десятичных единицах, и емкость в них диска WD RE4 действительно равна 2 000 398 Мегабайт.

Однако для компьютера, который считает в "двоичной арифметике", в которой в “килобайте” не 1000, а 1024 байт, та же емкость будет следующей:

3 907 029 168 секторов x 512 байт = 2 000 398 934 016 байт
2 000 398 934 016 байт /1024 = 1 953 514 584 kiB /1024 = 1 907 729 MiB = 1 863 GiB

Обратите внимание на то, что, в отличие от компьютера, чтобы не путать вас, я указал в качестве единиц измерения именно "бинарные" приставки: kiB, MiB, GiB - "кибибайты", "мебибайты" и "Гибибайты".

??того, ваш компьютер, считающий в "двоичной" (Base2) арифметике, покажет вам емкость вашего диска примерно на 10% меньше. В этом нет никакого обмана (если этим не пользуются в корыстных целях), но не надо удивляться полученному результату. Однако 10% емкости “двухтерабайтного” диска это совсем не "24 байта на тысячу", которыми можно пренебречь, это без малого 200 "гигабайт".

Все только ухудшается, если емкости растут, например если вы собираетесь делать RAID из множества дисков 2TB, причем желали бы получить в итоге строго определенную емкость.

В эту ловушку попадали на моей памяти уже многие, при планировании емкости системы хранения.

"Если нам надо 50TB, то возьмем 2 полки DS14mk2-AT c 14 дисками 2TB в каждой, итого будет 28 помножить на 2 - 56TB, минус два на RAID parity, минус один на hot spare - вот и получается 50".

Не получается. Помните об этом.

Но это еще не все.

О затратах емкости на Zone и Block checksum - в следующем посте.

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Continue reading ‘Usable Space у NetApp – что стоит за FUD? (часть 2)’ »

У одного из нетапповских блоггеров увидел хорошую статью, перевод фрагмента которой хочу опубликовать у себя.

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
??так, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »