about NetApp

Новая заметка в блоге RecoveryMonkey, которые я всегда стараюсь переводить, так как Dimitris K. всегда пишет интересно и актуально.

Interpreting $/IOPS and IOPS/RAID correctly with SPC-1 results

Posted on October 19, 2011

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

Вот некоторые моменты, на которые стоит обратить внимание.

О соотношении price/performance:

Когда вы оцениваете приведенные $/IOP, убедитесь, что вы сравниваете цены list price (смотрите на отчет с полным описанием, который содержит все детали тестированной конфигурации).

В противном случае вы можете получить неверное представление о $/IOP, так как один вендор дает цены list prices, а другой в то же время показывает цену с большим дисконтом, "street price".

Например, система, показавшая $6.5/IOP после 50% дисконта, должна показывать $13/IOP по ценам list prices.

О RAID:

Как вы уже читали в предыдущих постах, RAID играет большую роль как в вопросе защиты, так и в вопросе производительности.

Все опубликованные результаты SPC-1 используют RAID10, с единственным исключением в виде NetApp (мы используем RAID-DP, математический аналог RAID6 с точки зрения уровня защиты данных).

Вот (очень) грубый способ конвертировать результаты RAID10 в RAID6, если вендор, которого вы рассматриваете, не приводит свои результаты для RAID6:

1. SPC-1 на 60% состоит из записей.
2. Возьмем любой результат RAID10, например пусть это будет 200 000 IOPS.
3. 60% от этого составляет 120 000, это будут операции записи. 40% это операции чтения, или 80 000 IOPS.
4. При использовании традиционного RAID6, вы получаете, грубо, четырехкратное замедление для операций записи: 120 000/4 = 30 000
5. Добавляем к этому 40% чтений, и получим результат:
6. 80 000 чтений + 30 000 записей = 110 000 SPC-1 IOPS в случае использования той же конфигурации с RAID6. Это примерно половина от результата RAID10…

Обязательно убеждайтесь, что вы "сравниваете яблоки с яблоками". Я знаю, в наше время информационной перегрузки мы всегда ленимся углубиться в детали, но все же, читая результаты SPC-1, потратьте немного времени на то, чтобы просмотреть полное описание результата, там всегда содержатся очень интересные детали…

Я в этом блоге уже несколько раз упоминал тот факт, что жесткий диск имеет определенную “конструктивно заданную” величину параметра IOPS – Input-Output Operations per Second – число операций ввода-вывода в секунду для random-операций. Отдельный жесткий диск имеет производительность в IOPS сравнительно небольшую. Так, для дисков SATA говорят о 75 IOPS, то есть отдельный диск может произвести за секунду 75 операций чтения или записи блока данных с “блинов”. Несколько производительнее диски SAS или FC, до 175 IOPS при скорости вращения 15000 оборотов в минуту. Это совсем не грандиозные объемы операций. Ну представьте, 75 операций ввода вывода (записи и чтения) в секунду. Всего лишь. Если у вас на компьютере работает примерно 30 процессов (программ и системных сервисов), то на каждый такой процесс приходится всего две с половиной операции чтения или записи в секунду.

Именно для повышения производительности в дисковых системах хранения данных используется множество дисков. Совсем не ради емкости, по крайней мере сегодня – как правило. Ведь чем на большее число физических дисков (на нашем птичьем языка-жаргоне прижилось калькированное с английского, и отдающее машинным маслом токарного станка словечко “шпиндель” (spindle), означающее физический жесткий диск) мы можем разложить наши данные, чем больше дисков задействовать для обслуживания ввода-вывода, по 75 (или 175) с каждого, тем выше получится суммарная производительность системы хранения на операциях random read/write.

Но откуда же берется это мистическое число “IOPS со шпинделя”, чем оно так жестко определяется?

На самом деле формула, определяющая эту величину довольно проста.

IOPS Estimated = 1 / ((seek time in ms / 1000) + (latency in ms / 1000))

Как вы видите, двумя основными параметрами диска, задающими величину в IOPS являются величина времени seek, то есть перехода магнитной головки от одной позиции до другой, и latency, то есть величины задержки от момента отправки команды, до получения запрошенного на выходе.

Возьмем, для примера диск Seagate SATA 1TB, 7200RPM:

Estimated IOPS = 1 / ( ( (average read seek time+average write seek time) / 2) / 1000) + (average latency / 1000) )

или с указанными в спеках данных для данного диска:

Estimated IOPS = 1 / ( (9.00 / 1000) + (4.16 / 1000) ) = 1 / ( (0.009) + (0.00416) ) = 75.987 - ~ 75 IOPS

Или для диска Seagate SAS 600GB 15KRPM:

Estimated IOPS = 1 / ( (3.65 / 1000) + (2.0 / 1000) ) = 1 / ( (0.00365) + (0.002) ) = 176.99 - ~ 175 IOPS

В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.

Нашлась вот такая картинка, с графиками тестирования различных типов дисков.

Ранее, в посте про надежность RAID-5 я уже писал про такой аспект дисков SATA, как надежность и величину UER (Unrecoverable Error Rate, иногда также называется UBE - Unrecoverable Bit Error).
Величина эта почти на порядок (в 10 раз) хуже, чем для дисков SAS/FC, причем причина тут конструктивная, а не просто в интерфейсе.
Однако, для небольших систем “начинающих”, в первую очередь роль играет цена.

Жесткий диск (и система хранения) характеризуется, в общем случае, двумя параметрами: емкостью (измеряется в Мегабайтах/Гигабайтах (MB/GB)), и быстродействием (измеряется в IOPS - Input-Output Operations per Second - Операций ввода-вывода в секунду ). И если емкости дисков непрерывно растут вот уже несколько лет, то показатели по IOPS замерли уже довольно давно.
Принято считать, что диск SATA дает 80-100 IOPS, диски SAS/FC - 140-160 для 10KRPM, 180-200 - 15KRPM.

Стоимость за мегабайт для дисков SATA весьма низка, на сегодня она составляет 0,17$/MB для диска SATA 1TB, однако около 0.83$/MB для диска SAS 300GB. (я оперирую ценами, взятыми из price.ru: SATA WD RE3 1TB 7200 - 170$, SAS Hitachi 300GB 15K - 250$)

Иная картина будет, если мы посчитаем стоимость IOPS-ов. Диск SATA при этом будет стоить 2,1$ за IOPS, а 15K SAS - 1.38$/IOPS

Допустим, перед нами стоит задача создать сторадж на 3 TB, при этом быстродействие его должно быть не хуже 3000 IOPS.

Рассмотрим два варианта:
Если мы рассматриваем только емкость, то будет все просто:
SATA 1TB нужно три штуки, при цене за диск в 170$ общая сумма хранилища заданного размера, без учета RAID будет 510$
Дисков SAS на 15KRPM емкостью 300GB будет нужно 10 штук, при цене за диск 250$ такая емкость будет стоить 2500$

Казалось бы вывод очевиден, SATA дешевле, причем раз в пять.
Но мы пока не учли второе требование, про 3000 IOPS.

Для быстродействия системы емкостью 3TB в 3000 IOPS, из расчета в 80 IOPS с каждого диска SATA, нам нужно распараллелить ввод-вывод не менее чем на 38 дисков. 38 дисков SATA, это будет стоить уже 6460$.
Однако для дисков SAS те же 3000 IOPS достижимы на всего 17 дисках, что стоит 4250$

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

Этот момент часто не учитывают люди, планирующие использование SATA на задачах primary storage.

Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение - хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего, то вам следует забыть про гигабайты, и ориентироваться, в первую очередь, на производительность дисков, на IOPS. Необходимый объем вы получите “автоматичски”.
Сегодня, во многих случаях, при планировании системы хранения, производительность есть ее “первичное”, ключевое свойство .
Или, иначе говоря: “GB are free, IOPS cost you money” - “Гигабайты бесплатно, вы платите только за доставку ИОПСы”

Тема измерения производительности столь велика и непроста, что стоит отдельной статьи только на эту тему. Однако без элементарных знаний, которые можно попробовать изложить кратко, для понимания рассматриваемой темы эффективной системы хранения не обойтись.

Для начала следует определить два основных общепринятых понятия, используемых для измерения производительности.
Первый из них – Input-Output Operations Per Second – IOPS - показывает количество операций ввода-вывода в секунду, которые способно обработать устройство. Этот параметр прежде всего характеризует скорость обработки коротких запросов, и наиболее часто применим для оценки таких задач, как OLTP-база данных и близких к ней.
Операции базы данных как правило характеризуются обменом относительно небольшими блоками (как правило 4-8KB). Каждая такая операция по считыванию или записи блока является одним IOPS-ом. Таким образом, чем выше показатель производительности в IOPS, тем выше производительность базы данных.

Другим параметром, характеризующим производительность, является Скорость передачи данных, так называемый traffic throughput, измеряемый в MB/s, то есть количеством мегабайт, проходящих по интерфейсу ввода-вывода в секунду.
Этот параметр характеризует скорость обработки в случае больших блоков, классическая задача, для которой критичен именно параметр MB/s, это аудио-видео обработка, резервное копирование и DSS-базы данных.

Какой же из этих параметров более «правильный», какой более важен? Разумеется оба.
Однако следует понимать, что оба этих параметра связаны между собой «обратно пропорционально». Увеличение величины в IOPS вызывает снижение величины в MB/s и наоборот.

Чтобы понять почему так, нужно рассмотреть простой пример и аналогию.
По дороге следует переместить из А в Б большое количество человек. Возможно два варианта: мы можем перевозить их в их личных автомобилях или же усадить в автобусы. Пропускная способность дороги конечно же будет выше в случае перевозки людей автобусами, то есть «большими блоками». Однако методы общественного транспорта обычно вступают в конфликт с индивидуальными целями и маршрутами. Хорошо если в Б у нас огромный завод, на который устремлен основной поток из А. Можно погрузить все «байты» в один большой пакет-автобус на входе, и выгрузить его на остановке у завода, куда собственно и направляются все наши «байты».
Однако если наши байты не едут на завод, а разъезжаются по индивидуальным и независимым делам-«операциям», каждый имея индивидуальный маршрут, то доставка их «автобусом»-большим пакетом приведет напротив к большим потерям времени. В этом случае транспортировка индивидуальными автомобилями будет более выгодна. Однако общий пропускной объем дороги заполненной индивидуальными «пакетами»-авомобилями везущими по нескольку байт каждый, разумеется будет ниже, чем при перевозке большим пакетом-«автобусом».
Таким образом увеличение пропускной способности в MB/s за счет укрупнения пакетов приводит к снижению IOPS, и наоборот, рост операций в секунду «доставленных к цели пассажиров» нашей дороги-интерфейса, запруженной автомобилями, приводит к снижению ее пропускной способности в MB/s. Нельзя одновременно достичь высоких показателей в IOPS и в MB/s просто по физическим свойствам существующего оборудования.
Либо большие пакеты-«автобусы» и их мало («операций в секунду»), либо маленькие индивидуальные пакеты-«автомобили», каждый осуществляющий индивидуальную «операцию» по доставке данных, но заполняющие всю дорогу, и общий human traffic в результате невелик.

Отсюда видно, что широко разрекламированная величина пропускной способности интерфейса SATA-II дисков в 300MB/s далеко не всегда (а чаще и вообще никогда) не будет достижима на практике. Более того, в случае использования таких дисков для операций с базой данных OLTP роль будет играть не столько потоковая производительность интерфейса, сколько гораздо реже публикуемая максмальная величина IOPS диска, в настоящий момент равная для SATA 7200rpm примерно 50 IOPS, и в случае OLTP-нагрузки выиграет не диск с самыми высокими данными по мегабайтам в секунду, а самый быстродействующий по IOPS - параметру, напрямую связанному с рассмотренной выше «латентностью», такой как, например, диск с интерфейсом FC и скоростью вращения 15Krpm, для которого величина IOPS достигает 200. При прочих равных диски SATA всегда проиграют в случае работы с базой данных не только дискам FC, но и традиционным SCSI.
Однако в случае использования дисков на задачах считывания и записи аудио-видеоданных, или резервного копирования, характеризующихся большим и постоянным потоком данных большими блоками, диски SATA вполне могут быть не хуже значительно более дорогостоящих FC или SCSI, легко выигрывая у них за счет цены за хранимый мегабайт.

Как мы видим, точное понимание решаемых задач безусловно необходимое требование при выборе того или иного решения дисковой системы хранения.