Комментарии к записи: Учу матчасть :)

Автор: Алексей

Алексей — Sun, 31 Jul 2011 07:37:42 +0000

To Антон:

MirrorView/A does NOT have any checks to consider Thin Pool space on secondary array
Это значит, что массив с primary mirror image не проверяет, хватает ли места в storage pool для secondary mirror image и админ клариона должен проверить это сам

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

Александр — Sun, 24 Jul 2011 18:45:07 +0000

romx:

по поводу профиля нагрузки. Времени было в обрез (как всегда вообщем) поэтому тестил на скорую руку все подряд на заморачиваясь на профилях чтоб просто понять что лучше выбрать для задач, как случайный доступ так и последовательный разными блоками (4K 16K 64K). К сожалению, не скажу в каком случае пул меньше теряют производительности, а 10-15% это общая картина… “средняя температура по поликлинике”

P.S. В отпуске был поэтому затянул с ответом.

Автор: romx

romx — Fri, 22 Jul 2011 15:38:25 +0000

Антон:

Вы не по адресу вопросы задаете. Это вам надо специалистам по EMC задавать, тут таких нет, мы другими стораджами занимаемся, и говорим о них. EMC тут изредка, и с дилетантской позиции обсуждается.

Автор: Антон

Антон — Tue, 19 Jul 2011 21:04:13 +0000

Ребята, помогите перевести предложение, плиз!
MirrorView/A does NOT have any checks to consider Thin Pool space on secondary array
Я не имею представление, что значит Thin Pool space и все такое, т.к. не программист…
Буду оч. благодарен за ответ и возможные пояснения на примитивном уровне.
Спасибо.

Автор: Freedom

Freedom — Mon, 18 Jul 2011 17:55:10 +0000

Вышла новая дока, уже по VNX - EMC Unified Storage Best Practices for Performance and Availability

http://www.emc.com/collateral/hardware/white-papers/h8268-vnx-block-best-practices.pdf

Автор: firehunter

firehunter — Sun, 10 Jul 2011 04:46:12 +0000

romx:

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

Автор: romx

romx — Sun, 10 Jul 2011 01:30:35 +0000

firehunter:

Ну можно проще, взять какую-нибудь версию из ранних 7.0, какую-нибудь массовую 7.0.5, например, где только появился FlexVol, и сравнить.
Я ни разу не слышал ничего о значительной разнице в производительности, даже при первом появлении 7.0 (я еще вовсю 6.х в продакшне застал).

Автор: firehunter

firehunter — Sat, 09 Jul 2011 21:16:09 +0000

romx: Когда код становится сложнее, обычно он дольше выполняется. Не всегда, но обычно. Вы с этим согласны?
В любом случае, чтобы расставить точки на “и”, надо тестировать. Без теста - это теоретическая полемика, которая к реальности имеет опосредованное отношение.
Тест, на мой взгляд имеет смысл проводить на достаточно старой системе, которая будет способна работать под старой версией Ontap, где еще не было Flexvol. ?? проводить три теста: два на достаточно новой OnTap, с FlexVol и Traditional и отдельный тест на старой версии Ontap, в которой еще не было FlexVol. При этом желательно иметь достаточно кол-во шпинделей, чтобы центральный процессор был бы узким местом.

Автор: Firehunter

Firehunter — Sat, 09 Jul 2011 17:18:28 +0000

romx:

Собственно дискурсия носит теоритеческий характер. На практике надо сравнивать на каком либо старом оборудовании оба типа томов на современной версии ontap и плюс к этому на версии ontap где еще не было FlexVol.

Автор: romx

romx — Sat, 09 Jul 2011 02:45:35 +0000

> firehunter:

Не совсем так. Корневая директория - тоже директория. Механизмы работы файловой системы от того, лежит файл в корневой директории, или в поддиректории в ней, не изменяются.
С точки зрения кода это просто у файла чуть более длинное имя, не c:\filename.ext, а c:\folder\filename.ext
Возможно чуть больше времени занимает конкретная операция seek, если мы делаем просмотр директории с неизвестным содержимым, но, для NetApp, это не наш случай, к нашим томам для доступа к их данным мы всегда обращаемся по конкретному имени (пути).