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

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

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

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

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

Давайте разобьем вопрос исчисления usable space на две части. Сперва, в данной статье, рассмотрим, первым этапом, вопрос образования так называемого usable disk space, который образуется, когда мы от пространства raw disk space отнимаем объемы, занимаемые структурами RAID, spare и прочим подобным. А в следующей рассмотрим образование usable storage space, того пространства, которое образуется, когда от usable disk space отнимутся оверхеды логических структур системы хранения, резервы снэпшотов, и прочее.

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

http://www.pkguild.com/2010/05/emc-20-unified-storage-guarantee-exposed/

Давайте подойдем к задаче с реалистичных позиций. Не раз приходится видеть, как наши конкуренты сравнивают свои системы с системами NetApp на максимально удобных для себя задачах и конфигурациях. Не стану утверждать, что подбор максимально выгодной для себя конфигурации есть в таких сравнениях самоценной задачей, и что делается это исключительно злонамеренно, вовсе нет. Но тем не менее очень часто приходится в таких сравнениях видеть совершенно диковинные конфигурации “на стороне NetApp”, которые ни одному инженеру NetApp не придет в голову создавать. Кроме того, очень часто приходится видеть, как “сравнивают несравнимое”, например по разному подсчитанную дисковую емкость, или в одном случае берется рассчитанная емкость “без” оверхедов,а в другом случае – с ними. Тем более, что некоего единого стандарта для калькуляторов емкости не существует, и для того, чтобы понять какие именно данные вы от калькулятора олучаете надо углубиться в его описание (а это всегда лень). К тому же, как я уже писал ранее, спецалист в системах хранения одного вендора, зачастую бывает прискорбно невежественнен в системах другого, в особенности, если последние используют значительно иные принципы распределения емкости, как это получается в случае NetApp.

Итак, к делу

Итак, что же мы попробуем сконфигурировать и сравнить. Сконфигурируем примерно сравнимую по возможностям с NetApp FAS систему EMC, пусть это будет Celerra NS-480. Поскольку на стороне NetApp мы получаем unified storage, попробуем приблизиться к нему и на стороне EMC. Создадим конфигурацию, для работы как в SAN, так и как NAS. С некоторых пор в Celerra это возможно, что, по мнению EMC, позволяет называть их Unified Storage, как и NetApp FAS. Возьмем для простоты, что наша конфигурация Celerra будет поделена 50/50 между NAS и FCP. Хотя вы уже знаете, что Unified Storage в понимании NetApp не требует никакого специального жесткого деления между двумя “доменами”, NAS и SAN, тем не менее это лучшее, на что мы можем расчитывать со стороны EMC.

Конфигурация EMC, вариант A: 4+1 RAID-5

Вариантов конфигурации в случае EMC может быть довольно много. Несмотря на то, что в большинстве случаев в своих Best Practices EMC прямо рекомендует использовать тип RAID-10 (0+1) для большинства задач и рабочих нагрузок, но сравнение RAID-10 у EMC и RAID-DP, будучи корректным с точки зрения вендорских рекомендаций, вызвывает много критики “с той стороны”. Что-ж, дадим EMC шанс. Помня о всех принципиальных недостатках RAID-5 на больших дисках и в enerprise-задачах, давайте попробуем сравнить конфигурацию с RAID-5 и RAID-DP. Мы не будем использовать “на стороне NetApp” RAID 4, несмотря не то, что он существует до сих пор в Data ONTAP, и наиболее точно соответствует RAID-5 с точки зрения “расхода дисков”, но достаточно давно NetApp приняла решение рекомендовать для использования в своих системах только RAID-DP. Будем придерживаться этой линии и мы.

Возьмем структуру RAID-5 вида 4+1, то есть 1 диск parity на каждые 4 диска data. Такая конфигурация есть достаточно разумный компромисс между быстродействием и надежностью (напомню, что увеличение RAID-группы в RAID-5 ухудшает произвдительность на random write и увеличивает время RAID rebuild в случае выхода диска из строя). Некоторые референсные архитектуры, опубликованные EMC, также демонстрируют использование RAID-5 в такой конфигурации.

Воспльзуемся онлайн-конфигуратором EMC для систем Celerra NS.

image

Используем диски FC 450GB и заполним ими систему NS480, один шкаф целиком, используя конфигурацию RAID-5 4+1 и адекватное количество spares. При заполнении шкафа у нас останется еще место на одну группу 3+1. На картинке можно посмотеть схему, как ее рисует конфигуратор EMC.

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

Неожиданной для пользователя NetApp будет тот факт, что при конфигурировании EMC Celerra надо жестко и однозначно задать объемы, отводимые под дальнейшее использование в NAS и FCP, причем переопределить их в дальнейшем нельзя. Несколько странное поведение для системы, называющей себя Unified Storage. Ну ладно, не будем тут иронизировать по этому поводу, как получилосьсделали – так сделали.

image

Вот какой результат дает нам EMC capacity calculator. Используя 165 дисков, и руководствуясь рекомендациями  EMC, которые предлагают для такой конфигурации 6 дисков hot spares, у нас получается 24.86TB пространства NAS и 24.77TB для SAN. Суммарная емкость получается 49.63TB.

Конфигурация NetApp, вариант A: 20+2 RAID DP

Помните, мы сравниваем реальные конфиги, а не то, что, например, в данном контексте “удобно” EMC. Я регулярно рекомендую конфиг, подобный рассмотренному для NetApp как вполне реальный, практический конфиг для продакшна. NetApp на самом деле рекомендует использовать длинные группы RAID-DP, так как они лишены основных недостатков таковых у RAID-5 – снижения производительности и опасности “двойного дискового сбоя”, то есть отказа второго диска во время ребилда отказа первого, в длинных группах RAID (тем более под нагрузкой), который может занять вплоть до нескольких дней. 

Имеющийся “калькулятор емкости” для NetApp не позволяет задать точное количество дисков, мы можем оперировать только полками целиком. Для того, чтобы получить 165 дисков в калькуляторе, я задам 24 дисковых полки, которые дадут 168 дисков. Под spares NetApp рекомендует выделять диски следующим образом: 2 spares на первых 84 диска, на каждый контроллер, и по 1 диску на каждые последующие 84 диска. 168 дисков, поделенных на 2 контроллера потребуют суммарно 4 диска в spares. Но так как мы имеем 3 лишних диска, то я их тоже назначу как spares, чтобы они не считались в расчете емкости, и максимально уравнять подсчет с уже созданной конфигурацией EMC. Итого: 4 spares, плюс еще 3 spares, дискового излишка, всего 7 spares.

image

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

Вы видите на скриншоте рекомендуемую конфигурацию по приведенным входным данным. С дисками 450GB FC максимальное количество дисков в структуре “32bit aggregate” равно 44.  Оно делится поровну между двумя RAID-группами структуры 20+2. Обычным является использование RAID-групп размером от 16 до 22 дисков, но в принципе NetApp поддерживает для дисков FC размер групп вплоть до 28. Начнем с того же количества дисков (168 – 3 ненужных нам “spare”), оставшиеся диски разбиваются на 8 групп RAID-DP. После вычитания 138GB на root volume, суммарная емкость “usable” для NAS и/или SAN составляет почти точно 52TB.

Вариант A: Результат

EMC: 50TB usable

NetApp: 52TB usable (на 2TB или на 4% больше)

Реакция на получившиеся результаты может быть двоякая.  Если вы “болеете” на стороне команды EMC вы обязательно скажете, что сравнение нечестное, так как мы использовали небольшую группу RAID-5 против значительно большей группы RAID-6 (то что в NetApp называют RAID-DP). Это дает значительное преимущество в получающейся usable-емкости для NetApp. Да, все верно, но я предупреждал в самом начале, что мы будем сравнивать реальные конфиги, из реальной жизни. NetApp и его инженеры не рекомендуют для использования тип RAID менее RAID-DP (хотя по прежнему остается доступным RAID-4, если вы хотите использовать именно его) и его “длинные” группы вполне легальны, и рекомендуются в наших Best Practices. Напротив, EMC не рекомендует использовать RAID-6 для почти любых нагруженных конфигураций, в особенности при характере нагрузки с большом количеством random write.

Если вы болеете за команду NetApp, то вы тоже обязательно скажете, что сравнение нечестное, потому что вариант NetApp предлагает значительно более высокий уровень защиты данных, за счет наличия защиты от “двойного сбоя” в RAID с “двойным парити”, в отличие от варианта EMC. Согласен, но, во-первых, 4+1 рекомендуется EMC как допустимая, в ряде случаев, конфигурация, а потом мы говорим в данном посте прежде всего о емкости, а не надежности хранения.

Ну хорошо, чтобы удовлетворить и тех и этих давайте внесем эти требования в конфиги. RAID-группы большего размера позволят нам улучшить ситуацию с емкостью у EMC (сейчас мы уже не смотрим на производительность результата, только емкость) и рассмотрим только варианты с double disk failure protection.

Конфигурация EMC, вариант B: 12+2 RAID-6

В этой конфигурации я использовал максимальный размер RAID-группы, чтобы снизить количество дисков, уходящих под parity. Конфиг получился внешне немного странным, так как в нем получилось в 6 верхних полках по “пустому месту” размером в один диск. Но сейчас мы не анализируем эффективность заполнения дисками полок, только вопрос преобразования raw в usable, поэтому на эти 6 пустых слотов не обращаем внимания. У нас получилось 159 дисков и 6 spares. Так как первые 5 дисков (1,27TB usable capacity)  должны использоваться под  так называемый vault, и, так как мы оставим их в RAID-5, они не будут считаться в usable space с условием double failure protection.  Оставшиеся 6+2 сконфигурированы в RAID-6 и будут учтены. Утверждается, что EMC не рекомендует использовать пространство дисков vault под хранение данных. Как ранее, я конфигуирую достаточное количество hot spares, как рекомендует калькулятор.

image

Вот каковы результаты. Емкость total usable capacity только слегка выше, но то оттого, что общее число дисков уменьшилось. Когда мы вычтем из usable capacity объем 1.27TB, который не удовлетворяет условиям double disk failure protection, то есть RAID-группу vault, общий объем станет 49.54TB.

image 

Конфигурация NetApp, вариант B: 20+2 RAID-DP

Конфигурация NetApp по варианту B в целом та же, с одним изменением, в этом случае у нас уже 9 лишних spares, которые получились, чтобы уравнять емкость raw. В целом таких мы получаем 13 дисков (4 нужных + 9 лишних spares).

Конфигурацию в калькуляторе вы можете увидеть на картинке. После уменьшения root volume на 138GB, мы получаем итоговую usable capacity для SAN или NAS равную 49.7TB.

image

Результат Варианта B:

EMC: 49.54TB usable

NetApp: 49.70TB usable (примерное на 160GB или .03% больше)

И это даже несмотря на “фору” в 9 дисков, которые мы вынуждены были вывести в spare, чтобы уравнять условия, и которые, в реальной жизни, также могут быть использованы под данные!
И даже несмотря на то, что получившаяся система NetApp окажется значительно быстрее, так как использование RAID 6 приводит примерно к 30-45% падению на интнсивной загрузке ввода-вывода, чем не страдает RAID DP, поэтому, кстати EMC, имея возможность использовать RAID 6 не рекомендует его использование для любых задач, исключая малонагруженные, или где быстродействие некритично (например архивное хранение).

Конечно же, я уверен, что болеющие на стороне “команды EMC” немедленно укажут мне здесь на “необходимость” учета snapshot и fractional reservation, а также прочих “накладных расходов” систем NetApp.
Но чтобы не раздувать и так весьма объемный этот пост, я раскажу о том, как обстоят сегодня дела с этими параметрами в следующей статье.

9 комментариев

  1. Алексей:

    >>Неожиданной для пользователя NetApp будет тот факт, что при конфигурировании EMC Celerra надо жестко и однозначно задать объемы, отводимые под дальнейшее использование в NAS и FCP, причем переопределить их в дальнейшем нельзя.

    Это неправда. При работе с Celerra можно будет менять соотношения под NAS и FCP.

  2. Спасибо, Алексей.
    Как я уже говорил ранее не раз, когда специалист в одной области, например в системах хранения одного вендора, начинает что-либо утверждать в другой области, например о работе систем хранения другого вендора, безоговорочно верить всему сказанному им совершенно точно нельзя. :) Это касается любых специалистов, любых вендоров. В интернете “тому мы тьму примеров слышим”. Значительная часть любого FUD-а зачастую непредумышленная, просто от некомпетентности. Хотя, зачастую, есть и откровенно злонамеренная ложь.
    Поправил.

  3. Alex:

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

  4. Алексей:

    Я сам занимаюсь массивами EMC с инженерной части, поэтому не люблю все эти маркетинги. :)
    Хотя EMCишные ролики про гарантированные 20% на youtube прикольные. LOL.

    В любом случае этот блог почитываю, что даёт возможность трезво смотреть на вещи. Спасибо за это.

  5. Простите, поофтоплю немного. Давно читаю данный блог и все хотел отписаться, обучен как NetApp’у так и EMC (Clarrion, V-Max) поэтому могу оценивать правдивость того что тут пишется ;), и рад, что тут 99.99% правды, в отличии от бредней Чака Холлиса :)
    Добавлю свои пять копеек к посту - как EMC вообще может упрекать NetApp за snapshot reservation т.к. реализация snapshot’ов у EMC должна вызывать у них только чувство стыда и не более.
    Жду с не терпением следующего поста чтобы добавить свои, возможно, уже не 5 копеек :)

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

    Однако, судя по логам статистики немало людей приходят в этот блог по запросам типа “EMC vs. NetApp” и прочим подобным. (Теперь им будет куда целенаправленно с поисковика попадать по этому запросу, буагага.)
    Поэтому ненадолго отойду от своего принципа не затрагивать прямое сравнение продуктов разных вендоров, тем более, что наши конкуренты как раз напротив, часто этой возможностью злоупотребляют.

  7. kamiuchi:

    забыли про сектора на clariion(emc),входящего в Celerra NS, размер сектора у emc 520 а не 512 байт.

  8. bbk:

    kamiuchi> забыли про сектора на clariion(emc),входящего в Celerra NS, размер сектора у emc 520 а не 512 байт.
    Так у NetApp’а тоже сектора по 520 байт.

Оставить комментарий

20/0.154

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.