Лучше Чем Настоящий FibreChannel - Дедупликация
Несколько слов о том, почему, собственно, именно NetApp занял сейчас такую значительную долю рынка дедупликации, и что мешает сделать то же самое другим вендорам.
Ну конечно, в значительной мере, свою роль сыграло бесплатное предложение данного функционала, как я уже говорил ранее, лицензия на Deduplication поставляется бесплатно. ?? это, безусловно, способствовало широкому распространению технологии. Та же история была сыграна в свое время с рынком iSCSI, на котором NetApp так же занял значительную его часть (увы, не в России, которая до сих пор для себя iSCSI и его преимущества, по существу, не открыла)
Однако никакая бесплатность не сработала бы, если бы продукт был бы неработоспособен в принципе.
Что же мешает сделать то же самое, реализовать ту же, рассмотренную ранее модель с оффлайновой дедупликацией, ведь вроде все по описанию просто? В чем же дело?
А дело вновь в “волшебных пузырьках”, которые называются WAFL. :)
Один из блоггеров NetApp, за которым я внимательно слежу и читаю все его выпуски, уже не раз тут упомянутый Костадис Руссос, полемизируя с “блогорупором EMC” Чаком Холлисом, который использовал в одном из постов в приложении к продуктам EMC слова “Настоящий FibreChannel” (Real FibreChannel), в противовес “всяким там эмуляциям, SAN-ам из NAS-а, и прочим ‘виртуальным’ стораджам”, стал использовать термин “Лучше Чем Настоящий FibreChannel” (Better Than Real FibreChannel).
??так, чем же NetApp Лучше Чем Настоящий FibreChannel.
Вы уже знаете, что система хранения NetApp для организации и доступа к данным на дисках использует специальную логическую структуру, особую “файловую систему”, под названием WAFL - Write Anywhere File Layout. К подробностям о ней, ее устройстве и всяких интересных штуках, отсылаю к моим предыдущим постам на эту тему.
Для нас сейчас интересен один аспект.
Дело в том, что использование дедупликации для любой системы хранения влечет за собой немедленную и очень сильную фрагментацию данных. Очевидно, что если мы заменяем, в последовательно записанных данных, каждые несколько блоков на ссылку куда-то в недра ранее записанных данных, которые являются полностью идентичными вновь записанным, то старательно последовательно записанный фрагмент превращается в хаотически размазанный по всему стораджу.
Это настоящий кошмар для любого “класического стораджа”, который любой ценой стремится минимизировать random-компоненту доступа, так как на нем эффективность его резко падает как на записи (особенно), так и на чтении (большое “замусоривание” кэша и отсутствие эффективного “предсказания”/”read ahead”).
Но ведь вспомните, такой режим “постоянно-рандомной записи и чтения” есть по сути “нативный” режим для WAFL! Блоки WAFL записываются и считываются произвольно и рандомно не только в случае дедуплицирования данных, но и при обычной, естественной работе, которой стораджи NetApp занимаются уже много лет!
То есть переход от “классического” к “дедуплицированному” хранилищу, и вызванная этим “фрагментация данных”, такая катастрофическая для “классического” стораджа, вполне обычна и повседневна для NetApp, и включение дедупликации на быстродействии системы хранения никак не отразится!
Что, кстати подтверждают и реальные пользователи, которые называют величины падения производительности при переходе к дедуплицированным данным, там где их удается замерить, в считаные единицы процентов.
То есть, проблема использования дедупликации это, по сути, проблема решения задачи обеспечения производительности на фрагментированных данных со случайным чтением.
А так как NetApp давно и успешно решил для себя внутри проблему доступа к фрагментированным данным, то и переход к дедупликации не будет для него болезненным, или коль-нибудь заметно отражающимся на его производительности.
(я уже приводил цифры, когда тщательно, искуственно, и специально подготовленный не встречающемся в реальной жизни фрагментированием, дисковый раздел имел сниженную производительность всего на 10-15 процентов)
Вот что нам дает такая классная штука, как придуманная и написанная аж в 92 году специальная “файловая система”, вот в чем преимущества “виртуальных стораджей” над “настоящим FibreChannel”. Вот чего “настоящий FibreChannel” не может.
Вопрос о фрагментации от процесса дедупликации и её влияния на производительность системы, поднят очень интересный.
Но ответ не достаточно описателен.
??сходя из поста можно сказать, что проблема решается исключительно кешем на чтение и реалокацией (которая по умолчанию выключена).
Мне кажется, что вы здесь подменили понятие случайных данных собранных в страйп на блочную фрагментированность от процесса дедупликации. ?? тут встаёт вопрос есть ли разница между тем и другим?
Вопрос сводится к тому, как работает алгоритм сбора “случайных” данных в страйп. Другими словами: насколько дынные внутри страйпа фрагментированны и является ли длинна такого фрагмента, в страйпе, постоянной, если там не 100%-й рандум?
Если алгоритм совсем тупой, то скорее всего оба понятия одно и тоже. Похоже вы к этому и клоните: производительность не падает от случайного чтения случайно разбросанных данных.
Но если алгоритм умный и понимает, что случайные блоки относятся к одной логической цепочке, то не такие уж и фрагментированные данные получаются в нашем страйпе, а следовательно выше изложенные понятия не следует мешать в кучу. Продолжая эту логику, я бы заключил, что дедупликация всё-таки сильно фрагментирует данные, в то время как они расположены не случайно, а более или менее последовательно. Соответственно должна быть деградация производительности от фрагментации вызванной дедупликацией.
Как известно падения производительности от дедупликации всё-таки нет, но мы так до конца и не понимаем почему. Было бы неплохо закрыть эту дыру.
bkk:
> Мне кажется, что вы здесь подменили понятие случайных данных собранных в страйп на блочную фрагментированность от процесса дедупликации.
Несколько раз прочел, но смысла так и не уловил. Перформулируйте, и пропробуйте еще раз.
Я бы хотел еще раз, специально, обратит ваще внимание, что влияние фрагментации на 100% random workload по меньшей мере не доказано.
С точки зрения теории и логики, разницы между рандомным чтением рандомно расположенных данных и рандомным чтением секвентально расположенных ланных нет никакой. В обоих случаях это чтение 100% random. рандом на рандом не дает “рандом в квадрате”, он по прежнему остается 100% рандомным.
Секвентальное же чтение это довольно специфические задачи, типа традиционного бэкапа. На этих задачах фрагментация действительно будет ухудшать показатели sequental read, но в случае NetApp задачи бэкапа обычно решаются иными путями, не требующими лить секвентальный дамп с дисков.
bbk> Мне кажется, что вы здесь подменили понятие случайных данных собранных в страйп на блочную фрагментированность от процесса дедупликации.
Спрайтом я называю данные собранные одним большим куском в NVRAM оптимизированным для записи на диски.
Одно дело фрагментированность вызванная процессом дедупликации.
Другое дело фрагментированность данных внутри страйпа.
Другими словами я усомнился в том, что данные внутри страйпа 100% random.
Как работает алгоритм собирания данных в страйп?