Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Random Write | about NetApp

Posts tagged ‘random write’

Правда ли что производительность хранилища 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, каждый на своей виртуальной машине.

6a00d8341ca27e53ef0148c8700c6b970c-800wi

Каждый worker создал на своем LUN тестовый файл на всю его длину.
Тестирование продолжалось 240 часов (10 суток) для того, чтобы гарантировать полную многократную перезапись содержимого тестового файла.

Спустя 15 часов после начала теста IOmeter демонстрировал следующие результаты:

6a00d8341ca27e53ef0148c87010dd970c-800wi

Вы видите показатель производительности, равный 11248 IOPS при 4,2ms latency.
Довольно неплохо для 24 дисков SATA.

Спустя 60 часов:

6a00d8341ca27e53ef0148c8701996970c-800wi

Результат вырос до 12063 IOPS, а latency незначительно снизилась до 3,97ms.

На протяжении 10 дней тестирования на 4,5TB суммарного объема трех LUN было записано примерно 36TB тестового потока данных. В ходе тестирования был зарегистрирован рост показателя IOPS на 18% при незначительных изменениях latency в районе 4ms.

Общая картина изменений IOPS в ходе тестирования:

6a00d8341ca27e53ef0148c87024dd970c-800wi

По вертикали – IOPS, по горизонтали – часы. В дальнейшем, до конца тестирования, показатели не менялись.

UPD: Также упомяну, что еще в 2008-м году NetApp публиковала в SPC-1 результат 48-hours Sustainability Test системы FAS3040. Результаты и описание можно посмотреть на сайте SPC и по приведенной ссылке на PDF.

20/0.076

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