Правда ли что производительность хранилища NetApp падает со временем из-за фрагментации?
Несколько слов по поводу того, что пост этот случайно появился в понедельник, а затем исчез из блога. Как вы догадываетесь, я не в 8 утра в понедельник пишу посты, они у меня обычно написаны в некотором количестве впрок, обычно на месяц вперед, с “автопостилкой”, которая их “раскрывает” по мере наступления соответствующего дня и времени. Случайно оно взглючило и расскринился пост за четверг. Так что не надо conspiracy theory привлекать, это просто глюки базы блога. Вот вам этот текст, раз уж он все равно в rss-ленту для многих утек.
Любопытный эксперимент провел John Fullbright отвечая на вопрос, являющийся, пожалуй, второй по популярности темой FUD наших конкурентов: “Производительность NetApp (якобы) падает с течением времени, из-за увеличения фрагментации WAFL на дисках, при постоянной случайной записи”.
У него дома стоит сравнительно небольшая система “позапрошлого” поколения – FAS3050, с двумя полками дисков SATA 320GB 5400RPM, которую он использует под домашнюю лабораторию для хранения виртуальных машин MS Hyper-V.
Система эта, к слову, имеет свой собственный твиттер, и пишет туда, с помощью скрипта на Powershell, новости своей жизни :)
Вот каковы были исходные данные:
The Test Platform:
- FAS3050
- ONTAP 7.3.4
- (2) DS14MK2-AT drive shelves – dual looped
- (28) 320GB Maxtor MaxLine II 5400RPM SATA drives
- Storage for Checksums ~8%
- Right-sized (for hot-swap) = ~2% across the industry
- WAFL Formatted = 26.8 GB per drive (reserved for storage virtualization)
- 11ms average seek time
- 2MB buffer
- Internal data rate 44MBps
- Drive transfer rate of 133 MBps
- Storage Efficiency/Virtualization Technologies Employed:
- Volume-level Deduplication
- Thin Provisioning
- RAID-DP
- RAID-DP RG size = 24
- Tuning options:
- optimize_write_once = off
- read_reallocate = on
??з 28 имеющихся дисков, на 3 расположен root volume, 1 диск hot spare, остальные 24 целиком собраны в одну группу RAID-DP, на которой расположен один aggregate.
Общая usable space системы равна 5,18TB (5.18 TB = 5304 GB = 22 drives * 241.2 GB). Кроме тестовых данных на системе расположены 26 виртуальных машин Hyper-V (показатели дедупликации для данного тома – 78%), а также шара CIFS с образами ISO.
Для теста на пространстве хранения было создано 3 LUN по 1,5TB размером каждый, которые по iSCSI были подключены к трем виртуальным машинам, с запущеным на них IOmeter Dynamo.
Таким образом, пространство хранения системы было заполнено тестировочными LUN-ами примерно на 88%.
В IOmeter был конфигурирован тестовый паттерн с 100% random write блоками по 4KB (также было выставлено выравнивание по границе 4KB, о нужности и смысле чего я писал ранее).
Для тестирования были сконфигурированы три workers, каждый на своей виртуальной машине.
Каждый worker создал на своем LUN тестовый файл на всю его длину.
Тестирование продолжалось 240 часов (10 суток) для того, чтобы гарантировать полную многократную перезапись содержимого тестового файла.
Спустя 15 часов после начала теста IOmeter демонстрировал следующие результаты:
Вы видите показатель производительности, равный 11248 IOPS при 4,2ms latency.
Довольно неплохо для 24 дисков SATA.
Спустя 60 часов:
Результат вырос до 12063 IOPS, а latency незначительно снизилась до 3,97ms.
На протяжении 10 дней тестирования на 4,5TB суммарного объема трех LUN было записано примерно 36TB тестового потока данных. В ходе тестирования был зарегистрирован рост показателя IOPS на 18% при незначительных изменениях latency в районе 4ms.
Общая картина изменений IOPS в ходе тестирования:
По вертикали – IOPS, по горизонтали – часы. В дальнейшем, до конца тестирования, показатели не менялись.
UPD: Также упомяну, что еще в 2008-м году NetApp публиковала в SPC-1 результат 48-hours Sustainability Test системы FAS3040. Результаты и описание можно посмотреть на сайте SPC и по приведенной ссылке на PDF.
Что за письма из будущего?
Поправьте меня, но насколько я понимаю, нужно мерить random read, чтобы понять как по мере заполнения хранилища падает производительность.
Все мы знаем что нетапп отлично справляется с записью (даже кэш под это не используется - поправьте меня если не так), собрал страйп и бросил на все шпиндели в агрегате - отсутствует пенальти на запись. Поэтому определять влияние фрагментации при операциях записи мне кажется не разумно. Важнее именно рандомные операции чтения - вот здесь в случае нетапп, фрагментация оказывает влияние.
Верно отчасти. Да, действительно, тест 100% random write не дает исчерпывающего ответа, но такого измерения еще не было. Был, к слову сказать, sustainability test, на который я даю ссылку, посмотрите его тоже.
Что же касается влияния фрагментации на _random_ read, то тут тоже не все однозначно, об этом я уже тоже писал, например тут:
http://blog.aboutnetapp.ru/archives/455
Просто оцените с точки зрения логики: у нас случайно расположенные по диску блоки, которые мы случайно же читаем, или у нас последовательно расположенные блоки, которые мы случайно читаем. При случайном чтении “случайность” не возводится в квадрат. В обоих случаях это один и тот же random read. “Последовательность” или “непоследовательность” блоков никак не делает 100% random более “random”-ным или менее.
?? в чем смысл теста? 100% random write … Netapp и так сам в рандомное место пишет. ??з-за фрагментации будет падать время линейного чтения, т.е. из-за WAFL при дикой фрагментации скорость будет как на рандом чтении. Понятно что 100% random write никак не может деградировать со временем.
К этим workers на запись добавте еще один на линейную запись+чтение и посмотрите его деградацию.
А у вас правда много задач с характеристиками sequental read? Какие, если не секрет?
Вот я, сколько ни думал, кроме ветхозаветного backup на ленты, ничего не придумал.
Ну DSS database еще возможно. Все же остальное преимущественно random, OLTP, VM, multiuser fileservice, webserver - все random близкий к 100%.
А про влияние фрагментации на random read смотрите комментарий над вашим.
У нас к счастью вообще нет linear нагрузки. Поэтому netapp справляется. Хотя пока где-то 15% от планируемой нагрузки, тестируем. Проблем с бюджетом видимо тоже не предвидится, так что мы - самые приятные клиенты. Хотя и задаем вопросы, почему 3 полки c sas выдают на iometer в тесте DB меньше, чем домашний ssd.
Ой, не sas, а fc конечно. Вообщем стыдно за hdd. В такие недешевые железки, как netapp, можно было и ssd ставить. FlexCache видимо как спасательный круг. Но помогает временно, при дальнейшей нагрузке корабль пойдет на дно, все.
P.S. У WAFL ествественно единственный существенный изъян - при фрагментации просядет линейное чтение до показателей рандом чтения в экстремальных случаях. Если конечно есть дикая и постоянная линейная запись в несколько потоков, то там тоже будет плохо без дефрагментации, хотя на “обычных” железках тоже не факт что будет хорошо. (вроде как характерно к видео-серверам, видимо на этот кусок рынка netapp никак не претендует) Собственно, чем тут внутренняя фрагментация СХД отличается от фрагментации hdd? Проблема одна и таже! Но это кончено при обычных hdd, при переходе на ssd все поменяется, хотя и wafl на ssd потеряет всякий смысл ибо ssd уже внутренне работает по аналогичной схеме.
Allilya:
У вас, для новичка, какие-то немного смешные претении к NetApp. :)
“Корабль пойдет на дно…” - “Вах, баюс” ;)
Это претензии к статье - меряли совсем непонятно что. Я бы такой позор либо удалил, либо перетестил по-нормальному.
Allilya:
Если вы “перетестите по нормальному” я с удовольствием опубликую ваши результаты, пока же - публикую те данные, что есть.
“Вы видите показатель производительности, равный 11248 IOPS при 4,2ms latency.
Довольно неплохо для 24 дисков SATA.”
Это 486 IOPS с диска Maxtor MaxLine II 5400RPM ? Что я не понимаю?
panvartan:
Ну почему нет? На что кэш даден?
Гм, насколько я помню IOmeter , если не указано иное, заполняет тестовыми данными все доступное дисковое пространство, 1,5 тб. в кэш есно не поместится. За 10 дней со скоростью 47 мб/с действительно 36тб перепишется, но каким образом диск на 5400 переварит 486 IOPS записи, они телепатически на нем изменятся?
Чуть ниже описывалась другой тест “протестированный FAS2020 был сконфигурирован с 16 LUN-ами по 8GB каждый, на общем томе FlexVol, лежащим на 24 дисках SAS/FC 15KRPM (12 SAS + 14 FC)… дразмер блока - 8KB, 70% random, read/write=40/60 … При указанных условиях, система FAS2020 достигла показателей в 6000 IOPS” Это 240 IOPS на диск, что похоже на индивидуальную производительность диска. Да в этом тесте присутствует чтение, а в первом размер блока совпадает с блоком wafl, неужели это и есть факторы дающие такие разные результаты?
panvartan:
> неужели это и есть факторы дающие такие разные результаты?
Ну отчего нет? Вполне возможно. У NetApp на самом деле очень эффктивная random write.
Сравнивать же по абсолютной величине разную по характеру нагрузку нельзя совершенно точно, это азбука нагрузочного тестирования.
> 1,5 тб. в кэш есно не поместится
Все - не поместится, но может поместиться какая-то часть, а так как доступ - random, то есть вероятность, что этот random произойдет в пределах фрагмента в кэше. Таким образом, при random access, даже при dataset-е значительно больше кэша, кэш не простаивает без дела, а улучшает показатели производительности.
panvartan:
А дело не в кеше. Почитайте внимательно про wafl, все плюсы и минусы будут ясны, как разберетесь в принципах!
Если объем раздела на котором тестировали был меньше полного объема дисков, то тест на рандом запись при wafl должен показывать скорость линейной записи на raid6! Почему так? Ну очевидно, данные пишутся туда, куда проще, т.е. в свободное место дисков (незадействованное, и явно что lun не ограничивает) и пофиг сколько потоков и что они рандом, все пишется последовательно в свободное место. Попутно создается таблица соответствия “виртуальных” и “реальных” секторов. Как “свободное” место заканчивается, если под lun’ы было отведено не более половины места, значит то “физическое” место уже свободно и туда продолжается запись потоком и т.д. Вот если сделать рандом тест на объем равный физическому месту на диске, то после записи первого полного объема (назовем инициализацией) начнется настоящая рандом запись со всеми вытекающими… при этом даже линейная запись на wafl привратится в рандом. О ужас. Вообщем синтетику сделать, чтобы netapp был в попе видимо не сложно. Куда интересней, как в реальной жизни он поведет.
> Почитайте внимательно про wafl
Спасибо за предложение “почитать про WAFL”. Я тронут :)
Пожалуй вы первый в этом блоге мне такое предложили ;) Надеюсь это было от чистого сердца. ;)