ITBlogs

Сообщество IT-профессионалов
Welcome to ITBlogs Sign in | Join | Help
in Search

Сетевые системы хранения как объект разговора

Browse by Tags

All Tags » techtalks   (RSS)

  • Почему NetApp до сих пор не использует SSD?
    Несомненно одна из “горячих тем” 2008-09 года это SSD - Solid State Disks - “твердотельные” диски на технологии Flash. Они появились повсеместно, от недорогих нетбуков “до 300$” до дорогих серверных систем. В прошлом году использование SSD в системах хранения данных было анонсировано EMC для их линейки Symmetrix. Часто приходится отвечать на вопросы: “А что Read More...
  • Классика “говнилок”: серия 1 - фрагментация WAFL, часть 2

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

    Вопрос: А как понять величину фрагментированности? Это много, или мало? А если много, то что делать? И насколько оно влияет, если много?

    Ответ: Давайте разберем по порядку.

    В документации, в разделе, посвященном команде reallocate говорится:
    reallocate measure [-l logfile] [-t threshold] [-i inter_val] [-o] pathname | /vol/volname

    Запуск измерения реаллокации для LUN, больших файлов или томов.

    threshold - порог, ниже которого LUN, файл или том считаются неоптимизированными (фрагментированными) достаточно, для того, чтобы запустилась реаллокация, величина от 3 (средне оптимизирован) до 10 (очень сильно неоптимизирован). Значение порога по умолчанию равно 4.

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

    Но пока непонятно что же стоит за этой величиной, какой “физический смысл”?

    Хочу еще раз привлечь внимание админов NetApp к существованию на NOW большой подборки техдокументации. NOW сегодня не такой плюшевый как, например, MSDN, но пользоваться можно.

    “Еще раз”, потому что знаю, что многие админы, пользуясь тем, что системы NetApp на самом деле очень просты в эксплуатации, “настроил раз, за 15 минут, и они работают”, мало внимания уделяют копанию в документации, особенно англоязычной. А зря. В ней много интересного.

    Вот, например, статья в Knowledge Base
    What do the the WAFL scan measure_layout ratio and measure_layout numbers mean?
    “Что означают цифры measure_layout ratio и measure_layout при выполнении операции WAFL scan?”

    Для Data ONTAP versions 6.5 и позднее

    measure_layout ratio: Это отношение между числом записанных “чанков” (”chunks”, “кусков”) которые занял файл, и теоретическим минимумом числа таких чанков, которые были бы записаны для этой операции на полностью пустой файловой системе. Если ей ничто не помешает, то WAFL запишет данные в последовательные чанки размером 256 KB на каждый диск тома. Но если система не найдет куска последовательных 256 KB свободного места, то она запишет кусок меньшего размера.

    measure_layout считает число чанков, в которые попали данные, и делит это число на их минимально необходимое количество. Таким образом наилучший возможный результат равен 1 (число записанных чанков равно числу минимально необходимых для размещения данных), а наихудшее - 64 (когда только один блок данных WAFL, равный 4 KB, попадает в каждый чанк). Основное оценочное правило, если том имеет 1/N свободных блоков (включая 10% WAFL reserve, служебного резервирования файловой системы под ее собственные структуры), то ожидаемая величина будет близка к N (на практике, обычно лучше). Пример (romx): Половина диска пусты (1/2), то следует ожидать величину rate до 2. Четверть (1/4) свободна - до 4.

    Наихудшая возможная величина для систем с менее чем 3 GB RAM равна 16 (Sic! romx), исключая системы типа FAS250, FAS270 и FAS270c. Для этих систем наихудшая величина равна 64.

    Не спрашивайте меня почему так, я просто разместил объяву я просто перевел статью в KB.

    На практике вполне можно достичь значительных величин фрагментации, если поставить такую цель, например при тестировании, ссылку на статью о котором я давал раньше, человек создавал том с fragmentation rate равным 22. При этом, с помощью программы Iometer, в течении 6 часов проводилась непрерывная случайная запись в файл размером 100GB 64-мя одновременными потоками
    При этом, ухудшение производительности на фрагментированном с величной rate: 10 (как называет эту величину документация по reallocate - very unoptimized) составило примерно 15 процентов.

    Таким образом, наихудшего значения фрагментации для записываемых данных (не для уже записанных!) можно достичь интенсивно записывая на почти заполненный том, с объемом свободного пространства на нем менее 1/16 от общего пространства.

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

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

  • Классика “говнилок”: серия 1 - фрагментация WAFL
    Начнем с “классики”. Ни один наш конкурент не обходит вниманием “проблему” фрагментированности записи на том файловой системы WAFL. Будем считать, что люди здесь собрались взрослые, поэтому я уже могу рассказать вам правду откуда берутся дети как обстоит дело с фрагментацией на WAFL на самом деле. Вопрос: Правда ли, что запись, даже последовательных фрагментов данных, происходит на системе [...]
  • Классические говнилки :) или выражаясь интеллигентно: FUD.

    Необходимым элементом IT-шного ландшафта, не только в нашей стране, являются, как мы их называем у себя “говнилки”, на языке же наших партнеров (они же “вероятные противники”) это зовется более интеллигентно - “FUD” или “Fear, uncertainty and doubt” - “Страх, неопределенность и сомнения”.
    Это сведения, которые выставляют продукцию конкурента “в нелучшем свете”, заставляя клиента беспокоиться и сомневаться в своем мнении, причем зачастую это именно намеренное представление каких-либо свойств как отрицательных.
    Обычное дело, манипулировать впечатлением зачастую не слишком компетентного клиента.

    Способы существуют самые разнообразные.
    “Да это все голимая китайщина, да у них дисковые полки делает китайский Xyratex, тот самый Xyratex, который, ну вы знаете, гонит дешевку, их в энтри-левеле очень любят продавать.” (Далее подразумевается, что раз какую-то часть оборудования производит китайская компания, то и вся она тоже “китайская”, то есть низкокачественная, совсем как тот фен, который мы купили на рынке)” Дело сделано. Клиент уже смотрит на продукцию конкурента с подозрением. Мы ведь ему не рассказали, что наши дисковые полки тоже делал тот же Xyratex (а то кто и еще менее известный). ;)

    И неважно что Китай на сегодняшний день производит подавляющее большинство микроэлектроники в мире, что на сегодня хайтек-заводы Китая - лучшие в мире, что подобные претензии со стороны России, давно не имеющей вообще никакого конкурентоспособного электронного производства просто смешны - дело сделано. Сомнения посеяны, ведь для малообразованного (в этой области) клиента “Китай” и “низкое качество” синонимы со времен покупки пять лет назад фена на рынке.

    Казалось бы, ну что с того, что какие-то компоненты системы производятся на заводах компании-партнера. В наше время никто не делает ничего в одиночку, все компании связаны сотнями партнерских отношений между собой. Огромное количество оборудования производится по ODM-соглашениям. Наверное 95% ноутбуков, а то и все 100% производится 8-10 заводами малоизвестных массовому кругу китайских компаний, таких как Quanta, Compal, EliteGroup, Twinhead, а затем продаются как Apple, Toshiba, Compaq, Dell.

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

    “Да у них внутри, не поверите, Винда! Да-да та самая ЭксПи, как вот на этом компьютере!”
    “Действительно”, думает клиент, “о какой надежности можно говорить, если уменя сынишка на прошлой неделе “повалил” домашнюю машину свежим видеодрайвером для своей новой дурацкой “стрелялки”. Винда - масдай, это понятно”.

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

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

    Я намеренно в примерах привел говнилки на разные компании (sapienti sat), чтобы никому обидно не было. :) В последующх статьях я подробнее остановлюсь на основных темах FUD для NetApp, распространяемых нашими коллегами-конкурентами. Возможно это даст будущим клиентам NetApp, которые, я не сомневаюсь, читают этот блог, достойные аргументы в диалоге с ними.

This Blog

Syndication

Powered by Community Server (Personal Edition), by Telligent Systems