Комментарии к записи: Reallocation в Data ONTAP. Часть 1.

Автор: ??лья

??лья — Thu, 14 Nov 2013 06:07:11 +0000

Рома, не совсем понял про заполненность томов. Насколько я помню NetApp всегда говорил про свободное место на агрегате и производительность, но про тома я слышу впервые. То есть, если я на томе с луном с резервацией места оставляю 1 Гб свободного места при общем объеме тома в 400 Гб, то у меня падает производительность? Есть какие то документы подтверждающие это?

По поводу производительности агрегата: сам недавно искал официальное подтверждение про 90% занятого места на агрегате. Думаю стоит добавить в статью: https://kb.netapp.com/support/index?page=content&id=2017993&locale=en_US

Автор: romx

romx — Thu, 26 Sep 2013 13:17:54 +0000

“Ничего-ничего, зовите меня просто “Александр Первый” :)

Автор: Александр

Александр — Thu, 26 Sep 2013 12:57:16 +0000

Офф: …Сколько Александров стало в блоге

Автор: Alexander

Alexander — Mon, 23 Sep 2013 20:59:01 +0000

Не могу сообразить, почему reallocation физических блоков (ключ -p) вызывает такие эффекты:
“Using the -p option may reduce the extra storage requirements in a flexible volume when reallocation is run on a volume with snapshots. It may also reduce the amount of data that needs to be transmitted by SnapMirror on its next update after reallocation is performed on a SnapMirror source volume”.

Автор: romx

romx — Mon, 23 Sep 2013 09:16:30 +0000

Александр:
Да, официальный Best Practices - оставлять на томе место (если на томе часто пишут). Это так для любых smart-стораджей с файловой системой, выше я это показываю для Windows и NTFS.
Да, это не так сильно проявляется для dumb SCSI LUN (но все равно есть, просто не так сильно, и немного по другой причине), но кто сегодня использует dumb LUN, даже у EMC сегодня всюду storage pools, а Чак вон из EMC вообще уволился (или, вернее, перешел в VMware), видимо так и не смирился с таким “кидком” со стороны его компании. ;D

Автор: Александр

Александр — Mon, 23 Sep 2013 09:10:07 +0000

Спасибо, как раз этот документ я и упустил. Все-таки правильный ответ делать некоторый буффер с запасом свободной емкости помимо WAFL reserve.

Автор: romx

romx — Mon, 23 Sep 2013 09:01:12 +0000

vladmv:
А что про это писать, это написано в документации. Это ограничение на данной модели контроллера, оно опубликовано, пресейлы должны это знать и говорит об этом покупателю, соответственно покупатель должен это учитывать.
Говоря технически, оно вызвано предельно небольшим объемом памяти контроллера для данной модели. Дедупликация это процесс, довольно крепко едящий при работе память. Если памяти начинает не хватать, то в первую очередь начнет страдать производительность (память же нужна не только дедупликации, но и другим процессам контроллера, да и просто кэшу). Поэтому было принято совершенно грамотное решение - ограничить потребление памяти дедупликацией, чтобы это не пошло в ущерб общей производительности системы.

Соответственно решение - если нужна дедупликация на слабой системе типа 2020, то дробить пространство хранения на тома размером не более 1TB. Причем обращу внимание, тома нельзя уменьшить shrink-ом до этой величины, они должны быть созданы такого размера.

Но вообще говоря, 2020 это уже несколько лет как не актуальная система, с появлением Data ONTAP 8.0 и контроллеров с ней работающих, эти лимиты стоят уже довольно высоко, а начиная с мидренджа и выше, кажется, и вовсе равны предельному размеру тома,

Автор: romx

romx — Mon, 23 Sep 2013 08:52:04 +0000

Александр:
Тут на самом деле есть темное место (одно из). Есть пространство на уровне aggregate (и оно в WAFL reserve, судя по всему, включено), и есть пространство на уровне тома (volume). При определенных условиях, например при большом (sic!) количестве перезаписей данных на томе, запас на томе даст прямой эффект в увеличении производительности.
Это, конечно, спор о наполовину полном или наполовину пустом стакане, но специально уточню, не “снижение производительности при заполнении”, а “увеличение производительности при наличии свободного места (и определенном типе workload)”. Это важно, потому что за “норму” NetApp принимает именно заполненный на 90% том (и именно сверх этого уровня вы получаете прибавку), и, во-вторых, речь идет не о любой рабочей нагрузке, а об определенной, с большим числом перезаписей мелкими блоками. Это я упомянул в тексте выше.
Кроме этого я в этом блоге постил на эту тему хороший перевод: http://blog.aboutnetapp.ru/archives/1083

Так что ответ на вопрос: это гибко и вы выбираете, хотите ли вы плюс, допустим, 20% за счет неиспользуемой емкости дисков, сверх того, что вы купили как “производительность на данной системе”, или же вам важнее хранимые объемы, тогда прироста нет, вы получаете то, за что заплатили.
Откровенно говоря, сегодня, в особенности для больших систем где число дисков измеряется десятками и полками, получить +20-30% для работающей системы просто по цене жестких дисков - отличный deal :)

Автор: vladmv

vladmv — Mon, 23 Sep 2013 08:09:23 +0000

Спросил у одного клиента, почему они не включают Дедупликацию на системе FAS2020A 12*1Tb Complete.
Оказалось, что ограничение на lun дедупликации - 1Тб. Естессно у них больше.
Хотелось бы больше говорить в блоге про такие штуки. ?? как с ними потом бороться.

Автор: Александр

Александр — Mon, 23 Sep 2013 07:47:40 +0000

Добрый день!
Хотелось бы уточнить по поводу WAFL reserve.

Неоднократно встречал упоминания, что при заполнении диска более чем на 90% приведет к ощутимой потере производительности. Так вот, WAFL reserve учитывает как раз это, или же рекомендации заказчику для систем с высокой нагрузкой не забивать до конца таки актуальны?

Ну то есть вопрос снова сводится к usable space…