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%!

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

Текст этот писался как развенутый ответ человеку, спросившему “Почему у NetApp такие дорогие диски, и почему они даже дороже, чем у EMC VNX?” и как ответ на вообще-вопрос “Отчего ж все так дорого у вас в энтерпрайзе вообще и у NetApp в частности?”

Мне показалось, что ответить коротко и исчерпывающе будет не так просто, потому что ответ требует разъяснения ряда основополагающих принципов, и насчет ценообразования в “ынтерпрайзе” в том числе. Вот так и родился текст, который, в слегка сокращенном виде, я и предлагаю вам сегодня.

Continue reading ‘О “цене за гигабайт” и о “цене за решение”’ »

Тему преобразования 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 - в следующем посте.