Показаны сообщения с ярлыком NetAPP. Показать все сообщения
Показаны сообщения с ярлыком NetAPP. Показать все сообщения
четверг, 24 ноября 2011 г.
четверг, 11 августа 2011 г.
NetApp WAFL
"NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним."
http://blog.aboutnetapp.ru/archives/863
Утверждение HP:
“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”
Ответ Dr.Dedupe:
NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.
http://blogs.netapp.com/drdedupe/2010/04/how-netapp-deduplication-works.html#tp
Откуда вообще берется фрагментация?
http://blog.aboutnetapp.ru/archives/881
О “дефрагментации”
http://blog.aboutnetapp.ru/archives/874
Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.
Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.
Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.
Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.
WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).
...
Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.
http://blog.aboutnetapp.ru/archives/936
Таким образом, WAFL сделана "для реального применения" в сферах, где много случайной записи. Но при таком подходе один из самых "неудачных" тестов будет... линейное чтение! Потому что системе придётся много бегать головами для сборки "кусочков". В такой системе обязан быть дефрагментатор, явный или коссвенный, в виде кэша SSD, который сбросит весь файл в новое место большим куском. (разумеется, это будет не дефрагментатор системы, который ничего не знает про реальное расположение данных)
И требуется большая глубина кэша чтения, чтобы максимально эффективно собирать данные по всем дискам.
В целом, для типового применения, а также БД - система хорошая. Но не систем видеомонтажа с линейной записью и чтением и подобными.
Как таковой кэш записи всё-равно может ускорить работу, хоть и многократно эффективнее на классических системах, тут позволит не просто "записали куда получилось", а выбрать оптимальные участки и дождаться, когда будем рядом. К тому же, "прямо под головкой" могут уже быть данные. Писать в "окна" между данными? Вообще каша получится. Ждать достаточно большого окна? Терять преимущество перед другими системами.
Дополнение
Из моей старой заметки, Почему я считаю, что WAFL это не файловая система?
http://blog.aboutnetapp.ru/archives/863
Утверждение HP:
“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”
Ответ Dr.Dedupe:
NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.
http://blogs.netapp.com/drdedupe/2010/04/how-netapp-deduplication-works.html#tp
Откуда вообще берется фрагментация?
http://blog.aboutnetapp.ru/archives/881
О “дефрагментации”
http://blog.aboutnetapp.ru/archives/874
Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.
Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.
Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.
Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.
WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).
...
Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.
http://blog.aboutnetapp.ru/archives/936
Таким образом, WAFL сделана "для реального применения" в сферах, где много случайной записи. Но при таком подходе один из самых "неудачных" тестов будет... линейное чтение! Потому что системе придётся много бегать головами для сборки "кусочков". В такой системе обязан быть дефрагментатор, явный или коссвенный, в виде кэша SSD, который сбросит весь файл в новое место большим куском. (разумеется, это будет не дефрагментатор системы, который ничего не знает про реальное расположение данных)
И требуется большая глубина кэша чтения, чтобы максимально эффективно собирать данные по всем дискам.
В целом, для типового применения, а также БД - система хорошая. Но не систем видеомонтажа с линейной записью и чтением и подобными.
Как таковой кэш записи всё-равно может ускорить работу, хоть и многократно эффективнее на классических системах, тут позволит не просто "записали куда получилось", а выбрать оптимальные участки и дождаться, когда будем рядом. К тому же, "прямо под головкой" могут уже быть данные. Писать в "окна" между данными? Вообще каша получится. Ждать достаточно большого окна? Терять преимущество перед другими системами.
Дополнение
Из моей старой заметки, Почему я считаю, что WAFL это не файловая система?
вторник, 9 августа 2011 г.
NetApp E-series, краткий FAQ
Прошло 3 месяца <заметка 27 июня 2011> с момента объявления о покупке NetApp-ом у LSI его подразделения про разработке и продаже внешних дисковых систем, которое было известно под именем Engenio (ESG).
Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.
К сожалению, я обратил внимание, что в рунете вокруг этой истории раздулся какой-то непонятно-скандальный "ажиотаж", и возникло много непонимания, поэтому я, этим постом, постараюсь ответить на основные вопросы, развеять слухи и заблуждения, вокруг этой истории возникшие.
http://blog.aboutnetapp.ru/archives/945
Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.
К сожалению, я обратил внимание, что в рунете вокруг этой истории раздулся какой-то непонятно-скандальный "ажиотаж", и возникло много непонимания, поэтому я, этим постом, постараюсь ответить на основные вопросы, развеять слухи и заблуждения, вокруг этой истории возникшие.
http://blog.aboutnetapp.ru/archives/945
четверг, 4 ноября 2010 г.
netapp - SAN + NAS
http://habrahabr.ru/company/netapp/blog/105936/
Вообще, интересная статья. Верной дорогой идут.
http://blog.aboutnetapp.ru/archives/282
Почему я считаю, что WAFL это не файловая система?
Вообще, интересная статья. Верной дорогой идут.
http://blog.aboutnetapp.ru/archives/282
Почему я считаю, что WAFL это не файловая система?
Подписаться на:
Сообщения (Atom)