Когда, весной 2007 года, я начинал вести этот блог, я совершенно не представлял, что его жизнь протянется так надолго и так далеко. Тогда я просто экспериментировал с Wordpress, и, работая пресейлом в компании-партнере NetApp, захотел изложить то, что на тот момент знал о технических “фичах” этих систем хранения “человеческим языком”, для тех, кому это может быть тоже интересно. Но совершенно не предполагал, что все это растянется на 6 с лихом лет!
К сожалению, такая недальновидность предопределила ряд недостатков этого блога. Например, в нем практически отсутствуют средства “навигации” по старым постам, многие его читатели никогда не залезают “вглубь”, и даже не представляют, сколько там за шесть лет накопилось полезного. Как я вижу по статистике, основная масса моих читателей, свыше 90%, никогда не читают более двух-трех страниц блога за посещение. В “глубины” обычно попадают только те, кто пришел через поисковики, и которые ищут что-то конкретное, например мою популярную статью про IOmeter, или сравнительно недавний перевод Recoverymonkey про то, что такое IOPS. ??ли уж совсем древнюю, и в значительной мере утратившую актуальность заметку про то, что такое “кластер” (вот уже много лет из топа запросов этого блога не выходит поисковая строка “кластер это” ;), или “чем отличается NAS от SAN”.
Конечно здесь есть некое подобие рубрик, и даже теги, упорно мною расставляемые, но все равно, очень, очень мало людей читает что-то кроме “витирины” первой страницы. В этом я убедился, когда на прошлой неделе мне довелось поговорить с некоторыми моими читателями “пока-не-покупателями” на темы анти-нетапповского FUD-а наших коллег-конкурентов. ?? я даже загорелся написать статьи-ответы по каждой из таких тем, и даже начал писать, но вдруг понял, что все вот это, просто другими словами, я уже излагал тут раза четыре-пять. Темы FUD-а не меняются уже много лет, ничего нового к ним не добавляется уже давно (это плюс NetApp-у в каком-то смысле ;) раз ничего нового “плохого” даже злейшие конкуренты не находят). Все те же, все там же. Конечно же рассказывают про оверхед блочного доступа на WAFL, про низкий выход usable с данного объема raw, про “снижение производительности” при высокой заполненности тома, Как всегда педалируют “фрагментацию” и “отсутствие балансировки” и доступа к дискам одновременно с обоих контроллеров.
Поэтому, вместо того, чтобы еше раз писать другими словами все то же, что я уже не раз писал в этом блоге, я просто приведу тут ссылки на по-прежнему актуальные статьи о FUD-е и последующем его разоблачении.
Про WAFL и гипотетическом оверхеде для блочного доступа стоит начать с того, что разобраться, что же такое WAFL. Поэтому, прежде всего, стоит начать с отлично написанной работы на тему, которая лежала в основе NetApp как компании, и опубликованной на самой заре ее истории “отцами основателями” ее, двумя инженерами Дейвом Хитцем и Джеймсом Лау: она в переводе опубликована на сайте компании Netwell, которая спонсировала огромную работу по переводам Best Practices. Работа эта, опубликованная впервые на научной конференции USENIX, называется Разработка файловой системы для специализированного файлсервера NFS. Напомню, тогда, в самом начале, NetApp занимался только серверами NFS, но впоследствии, десять лет спустя, в 2003 году, он достаточно легко добавил блочный доступ к данным поверх структур WAFL. То, как это было сделано, и почему WAFL, вопреки ее названию “не файловая система”, или, вернее, нечто, отличающееся от того, что обычно принято называть в IT “файловой системой”, можно прочитать в статье нетапповского инженера Костадиса Руссоса “Почему я считаю, что WAFL – это не файловая система”. Там, в частности, объясняется то, почему блочный доступ на WAFL не является “эмуляцией поверх файлов” (тоже популярная страшилка конкурентов), и почему оверхед в WAFL сравнительно невелик как для файлового, так и для блочного доступа.
О низком результате usable на данном объеме raw-дисков стоит начать чтение со статьи “О цене за гигабайт” и “цене за решение”, где я попытался объяснить, из чего складывается и как формируется итоговая емкость системы хранения NetApp. Полезным также будет прочитать о RAID-DP, и почему именно этот тип RAID используется в NetApp, и о том, как организована иерархия “объектов хранения”, что такое и как соотносятся между собой aggregate, физические диски, тома, LUN-ы, и так далее. Детальный расчет емкости покажет нам, что реальный usable space зачастую первышает таковой у систем, инженеры которых любят указывать на низкий уровень usable у систем NetApp. Наконец, фактические результаты 7 с лишним тысяч работающих у клиентов систем хранения, сообщающие свои данные через Autosupport, показывают весьма высокие результаты – 66,27% составляет фактическая величина usable от имеющегося объема raw-дисков. Это не теоретическая, рассчитанная величина, это фактическое среднее значение usable space реально работающих у клиентов стораджей. Хорошо резюмирующим тему usable space является текст инженера NetApp Dimitris K. “Что стоит за FUD о usable space?”
Про “снижение производительности при заполнении дисков данными” отвечает Richard J. Martin, сотрудник австралийского отделения NetApp в статье Как заполненность данными системы хранения влияет на ее производительность?. Кроме того, можно посмотреть и на официально опубликованный в 2007 году ответ NetApp, когда это утверждение впервые появилось в competitive-материалах компании EMC. Также очень показательным будет и тот факт, что тестирование по методике SPC-1 NetApp проводит с уровнем заполнения дисков данными в 84% от usable (и 60% от raw), а некоторые другие вендоры, показывющие свои результаты в этом бенчмарке – с уровнем 57% от usable и 29% от raw. Если они не боятся “снижения производительности при заполнении данными”, то отчего не покажут результат при 100% заполнения usable?
Про “фрагментацию” и ее влияние – писалось многократно, и для случая рандомного доступа (обычно) к данным, и для случая секвентального (иногда) доступа, я измерял изменения показателей при экстремально высоких, для наглядности, значениях фрагментации, и приводил теорию того, почему фрагментация чаще всего не так велика, как себе воображают. Там же рассматривался вопрос, падает ли производительность системы хранения, в случае правильной ее настройки, при “фрагментации” даных, с помошью простого эксперимента, и давался на это ответ – нет.
Про то, почему Flash Cache не используется на запись – в статье про устройство Flash Cache и того, как он взаимодействует с WAFL.
О том, почему у NetApp нет tiering-а, а также о том, почему flash-кэширование лучше, чем tiering – в статье про VST – Virtual Storage Tiering, использующий Flash Cache.
В следующих статьях – краткий индекс других полезных постов почитать, опубликованных в этом блоге за 6 лет. А пока же, в комментариях приветствуется, если кто вспомнит, какие еще темы FUD нынче у наших конкурентов актуальны. Может быть я и правда не на все темы написал?
