Про тестирования и про производительности
Некоторое время назад по IT-новостям прокатилось сообщение что “Система хранения Oracle 7320 победила в тестах NetApp FAS3270!! адинадин”. На прошлой неделе у меня дошли руки посмотреть все же что там, как, кто, и кого победил. О результатах рассказываю.
Тема “тестирований производительности” (кавычки мои, romx) есть любимая тема любого сисадмина.
Допустим, вы читаете в новостях сообщение, что “Мотоцикл Honda CBR150 обошел на стометровке с места болид Formula1 Ferrari!”. “Ну, круто” – подумаете вы, “но кому интересно соревнование с формульным болидом на стометровке с места? Они бы еще соревновались по параметру “экономия бензина” с велосипедом!” А вот нет, оказывается, прекрасная новость и информационный повод проспамить прессрелизом IT-издания.
Уже не раз в этом блоге я писал, что “дьявол – в деталях”, “всегда читайте мелкий шрифт”, и не ограничивайтесь одними лишь заголовками смотрите вглубь, мы – инженеры, именно за умение смотреть вглубь и читать портянки текстов на английском нам платят наши деньги.
Но, для начала, несколько вводных слов.
Тестирование – тема очень непростая. Очень важный аспект в любом бенчмарке это создание повторяемой среды, отражающей реальные условия использования тестируемого предмета. Результаты процесса “копирования ISO в тотал коммандере” совершенно неприменимы для оценки быстродействия системы хранения на задаче OLTP database, а данные чисто “синтетического” теста могут не отражать адекватно ваши реальные рабочие результаты, на вашей реальной рабочей задаче, в жизни.
Но если в том что касается бенчмарка, то есть создания повторяемой среды тестирования идентичной для всех тестирующихся систем, можно положиться на авторитет общепризнанных тестов, каковыми на сегодня являются, например SPECsfs2008 для файловых протоколов (NFS и CIFS), и SPC-1 для блочных протоколов (FC и iSCSI), то вот в подготовке тестируемой системы есть некоторая свобода, которой иногда (довольно часто, к сожалению) пользуются некоторые производители с целью создать “систему хранения”, единственная цель которой – победа в тестировании. В англоязычном сегменте такое называется lab queen, по-русски я слышал название “звездолет”.
Вариантов как построить звездолет есть масса. Например можно взять хай-энд систему и набить ее SSD, получив систему за шесть миллионов долларов на 19TB usable . Можно поставить вместе четыре стораджа, и в результатах тупо просуммировать показанные ими по отдельности результаты. Можно, наконец, тестировать систему на голых дисках без RAID или на RAID-0. ??спользовать множество дисков малого объема. Разбить пространство тестирование на большое количество мелких разделов, снижая “разбег” random access seek, и так далее. Полученные таким образом результаты окажутся неприменимыми в реальной жизни и в реальной эксплуатации того, что вы можете купить, однако очень эффектно смотрятся в пресс-релизах об очередной победе.
В этом отношении позиция NetApp в тестировании достаточно ясна и четко выражена. NetApp тестирует реальные конфигурации, которые вы можете купить и использовать. Не “звездолет” для получения эффектных результатов бенчмарка, а реальную практичесую систему. Хорошо настроенную специалистами, но без вышеперечисленных “серых мулечек”. Результаты тестирования у NetApp это реальные результаты практической, “покупабельной” системы хранения.
А теперь перейдем собственно к теме. Что же скрывает за собой барабанная дробь прессрелиза?
Согласно требованиям проведения тестирования SPECsfs2008, протестированная конфгурация должна быть хорошо и детально документирована и описана. Эти данные доступны на сайте SPEC.org всем желающим. Пожелаем и мы проверить, какую же в точности конфигурацию тестировали в Oracle.
Вот как описывает протестированную конфигурацию сайт SPEC.org:
http://www.spec.org/sfs2008/results/res2012q1/sfs2008-20120206-00207.html
Система Oracle Sun ZFS storage 7320
136 дисков SAS 15K на 300GB в 6 дисковых полках, обшим usable space емкостью 37,1TB и общей экспортируемой емкостью в 36,96TB были поделены на 32 файловые системы, по 16 на каждый из двух контроллеров (каждая экспортируемая FS имела размер примерно 1,1TB), доступ к которым осуществлялся с трех loadgenerator Sun Fire X4270 M2, подключенных по 10G Ethernet.
Также тестированный сторадж оснащен 8 дисками SSD по 512GB каждый, для кэширования чтения, (так называемый L2ARC), общей емкостью 4TB, пополам на каждом из двух контроллеров, и 8 дисками SSD 73GB в качестве кэша записи (ZIL), суммарно 584GB, без RAID в обоих случаях. Кроме этого, два контроллера системы хранения имели RAM емкостью 288GB (ARC, по 144GB на контроллер), что дает 4968GB суммарной емкости кэша (SSD и RAM).
Суммарная, участвующая в тестировании емкость (fileset) составила 15587,3 GB, то есть емкость кэша составила примерно треть от используемого файлсета.
Далее цитата:
The storage configuration consists of 6 shelves, 4 with 24 disk drives, 2 with 20 disk drives and 4 write flash devices. Each controller head has 4 read flash accelerators. Each controller is configured to use 68 disk drives, 4 write flash accelerator devices and 4 read flash accelerator devices. The controller is then set up with pools by dividing the disk drives, write flash accelerators and read flash accelerators into 4 pools. Each of the controller’s pools is configured with 17 disk drives, 1 write flash accelerator and 1 read flash accelerator. The pools are then set up to stripe the data (RAID0) across all 17 drives. The write flash accelerator in each pool is used for the ZFS Intent Log (ZIL) and the read flash accelerator is used as a level 2 cache (L2ARC) for the pool. All pools are configured with 4 ZFS filesystems each.
“Конфигурация системы хранения содержала 6 дисковых полок, 4 полки на 24 диска и 2 полки на 20 дисков, плюс 4 SSD-кэша на запись. Каждый контроллер использовал 4 SSD-диска в качестве кэша чтения. Каждый контроллер был сконфигурирован на работу с 68 дисками, 4 SSD кэша на запись и 4 SSD кэша на чтение. Каждый контроллер использовал пулы дисков, между которыми были разделены диски, по одному SSD-кэшу на чтение и на запись на каждый пул. Пулы были настроены таким образом, чтобы данные страйпились на все входящие в него 17 дисков (RAID-0). Write flash accelerator (SSD емкостью 73GB) в каждом пуле использовался в качестве ZFS Intent Log (ZIL), а read flash accelerator (SSD емкостью 512GB) как level 2 cache (L2ARC). На каждом из пулов было создано по 4 файловые системы.”
Как мы видим, несмотря на использование ZFS, для организации дисков в пулах был выбран простой stripe, без RAID (фактически RAID-0!). Кроме того стоит отметить, что общая тестируемая емкость дисков была поделена на сравнительно маленькие файловые системы, всего около 1,1TB каждая, числом 32 (зачем такой финт – см. выше).
Очевидно, что такая конфигурация довольно далека от реально эксплуатируемой на такого рода системах. Кто в здравом уме будет класть данные на 17-дисковую группу в RAID-0?! А как планируется использовать пространство, разбитое на 32 отдельных FS для хранения, например, больших объемов? А каковы 512GB write cache на SSD, без малейшей защиты от сбоя?
Кстати интересный вопрос: Если ZFS так хороша и производительна, и так хорош RAID-Z и RAID-Z2, то почему его не использует при выкатке систем на тестирование даже сам Oracle? Что за засада с ним, господа из Oracle? Вот NetApp показывает свой результат на реальных, эксплуатируемых конфигурациях, с RAID-DP и даже со включенным thin provisioning, а в результатах Oracle в SFS2008 – Stripe (RAID-0), а в SPC-1 – mirror (RAID-1). Почему не RAID-Z(2)? Почему бы не показать результаты с ними? Может быть они совсем не так хороши?
Для сравнения давайте посмотрим на упомянутую конфигурацию NetApp FAS3270, которую “побеждали”.
FAS3270 в конфигурации с SAS-дисками и без Flash Cache, поставки таких систем начались в ноябре 2010 года, около полутора лет назад.
360 дисков 450GB 15K, общая usable емкость дисков 125,7TB (в RAID-DP), экспортированная емкость равна 110,08TB (88% от usable) в 2 файловых системах (по одной на контроллер). Диски организованы в два aggregate из 11 RAID-групп 14d+2p в RAID-DP (RAID-6), тестовая нагрузка генерировалась с помощью 12 Loadgenerators типа IBM 3650M2.
Exported capacity равна 110TB, файлсет, на котором проводилос тестирование - 11749.7 GB Размер RAM, используемого как кэш на системе хранения, равен 36GB, что составляет 1/326 от fileset.
SPECsfs2008_nfs.v3=101183 Ops/Sec (Overall Response Time = 1.66 msec)
У “победившей” его полтора года спустя системы с RAID-0, с кэшами разного уровня, составляющими суммарно до трети тестируемого файлсета, включая около 4,5TB на SSD, с в шесть раз большим RAM контроллера и с тестируемым пространством побитым на 32 кусочка-FS:
SPECsfs2008_nfs.v3=134140 Ops/Sec (Overall Response Time = 1.51 msec)
На 32,5% больше IOPS и на 8,5% лучше latency.
Ребята из Oracle, что называется "при всем уважени”, но вы правда считаете, что таким результатом, при описанном выше устройстве тестируемой системы, и способе проведения тестирования, это победа и этим стоит гордиться? Нет, ну правда?
Оно дешевле стоит? Ну, согласен, дешевле. Мотоцикл порвал Феррари на стометровке. Но кто гоняет на Феррари на стометровке? Какой смысл сравнивать по цене лоу-мидрендж (“Entry-level cluster option for high availability”, цитата из техспеков на 7320), ZFS-сервер, со стораджем, в максимуме тянущем в 6,6 раз большую чем 7320 емкость, используещем RAID-6, и демонстрируемом даже близко не на пределе своих возможностей по тестируемой емкости?
Впрочем, несколько слов и о цене. В тесте SPECsfs2008 условия тестирования не требуют называния цены тестируемой системы, поэтому спекуляции о цене делаются на довольно мутном базисе “нашли гуглом какой-то прайс нетаппа, где-то в интернете, и прикинули”. Однако в случае SPC-1 требуется указывать такой параметр, как IOPS/$ и цена всей тестируемой конфигурации называется. Тут, однако, тоже есть поле для… ну-у… скажем так, для “оптимизации” :). Например на тестировании SPC-1 NetApp называет цену листпрайса (см стр. 18 отчета), а Oracle, ничуть не смущаясь приводит цену с “вшитой” 30% скидкой по всем позициям (см. стр. 14 отчета) и именно ее берет в расчете IOPS/$ в SPC-1.
Так что, повторю сказанное мной в начале поста: Читайте мелкий шрифт, не ленитесь разбираться в конфигурациях и их деталях, и оставьте пресс-релизы (и выводы только на их основании) для С*O-менеджеров. :)