Классика “говнилок”: серия 1 - фрагментация WAFL

Начнем с “классики”. Ни один наш конкурент не обходит вниманием “проблему” фрагментированности записи на том файловой системы WAFL.

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

Вопрос: Правда ли, что запись, даже последовательных фрагментов данных, происходит на системе хранения NetApp в “рандомном” порядке, и записанная порция данных оказывается фрагментированна по пространству диска?

Ответ: Да, в общем случае это так. Это прямое следствие того, что запись на WAFL (Write Anywhere File System) происходит “Anywhere”, повсюду, где это возможно, а не в строго заданные участки, как это происходит у практически всех других файловых систем.

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

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

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

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

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

Таким образом ответ на вопрос “существует ли проблема фрагментации на системах хранения NetApp?” довольно прост. Фрагментация - есть, а вот особых проблем, связанных с ней, как правило, - нет. Фрагментация, строго говоря, это проблема на файловых системах “каменного века”, типа FAT, но WAFL это отнюдь не FAT, поэтому переоценивать эту опасность, и уж точно считать ее “основным недостатком NetApp”, как мне порой приходится слышать - необоснованно.

Чтобы не перегружать пост я опубликую вторую часть этого поста, с ответом на вопрос: “так какова же фрагментация на WAFL в реальной жизни “в граммах” - завтра.

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

  1. Пару лет назад на каком-то мероприятии EMC именно этот аргумент закладывался в неокрепшие умы заказчиков, а именно “При заполнении дисков нетаппа до уровня 80-90% система начинает жестоко тормозить, это обусловлено их уникальной файловой системой, которая пишет когда-хочет-куда-хочет, тем самым вызывая сильнейщую фрагментацию”

  2. Ну так не зря эта тема идет у меня почетным первым номером :)

    Но как видите, все не так просто.
    Точнее это просто для того, чтобы сочинить говнилку, но совсем не так просто для того, чтобы разобраться как все обстоит не самом деле.

    Кстати говоря, никто из создателей “настоящих Fibre Channel”-систем не отвечает прямо на вопрос, а что же происходии с их системами, “при заполнении до 80-90%”? Догадайтесь почему ;)

  3. Дмитрий:

    2 rider.myopenid.com
    Блин исходя из другой статьи romx’a http://blog.aboutnetapp.ru/archives/881 я именно такой вывод и сделал: “При заполнении дисков нетаппа до уровня 80-90% система начинает жестоко тормозить”…
    Что-то не сходится.

  4. Дмитрий:

    На самом деле есть еще и вот такая статья:
    http://blog.aboutnetapp.ru/archives/1083

  5. bbk:

    Ответ на мой же вопрос в следующем же посте …

    romx%3E ухудшение производительности на фрагментированном с величной rate: 10 (bbk: том имеет 1/10 свободных блоков)[...] составило примерно 15 процентов.

  6. bbk:

    Спасибо. Но многое зависит также от соотношения random/sequental. На random ухудшение должно быть минимальным, на sequental - максимальным.

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

20/0.137

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.