О “дешевизне” SATA-дисков

Ранее, в посте про надежность 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” - “Гигабайты бесплатно, вы платите только за доставку ИОПСы”

10 комментариев

  1. alex nop:

    Согласен почти со всем. Могу только добавить, что количество IOPS, которое выдает железка, еще сильно зависит от размера блока. Приведенные цифры справедливы по нижней границе на 8К блоках. На блоках большего размера разница между SATA и SAS/FC нивелируется. На эту тему у, как ни странно, Symantec, есть презентация о методике расчета IOPS для вполне конкретных параметров. Пару лет назад, когда было сильно надо, я ее находил и исходя из нее делал сайзинг для своих задачек.

    И кстати, например, для работы с фильмами хотябы в 2K уже интересней использовать SATA, чем SAS/FC, потому что размер кадра 12Mb и соответственно использовать мелкие блоки нерационально. А средний размерчик “кина” около 5Tb. Так что с “только одно применение - хранилище архивных и резервных копий” - эт вы, коллега, погорячились.

    Все зависит от задачи, как всегда.

  2. Это вы просто меня невнимательно читаете. “Хранилище архивных и резервных копий” приводилось как пример стораджа, создаваемого исключительно исходя из объема хранения.

    Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение - хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего… далее по тексту

    Вы же приводите пример совсем другого порядка. Производительность в вашем случае весьма важна.

  3. alex nop:

    Цитата:”вообще говоря имеет только одно применение - хранилище архивных и резервных копий”. Не хочу придираться к словам. Предлагаю перейти сразу к производительности :)

    В случае с киношниками - это не random IO, это throughput IO. Т.е. нужно получить 24 кадра/сек, при объеме кадра 12Mb (если говорим о 2K). Итого 24*12=288Mb/s. Берем размер блока 256k. 12Mb (размер кадра) / 256 k = 48 винтов SATA. Поскольку работа всега идет покадровая, нам нет смысла брать маленькие блоки.

    Вы допускаете, что с 48 винтов SATA можно читать со скоростью 288 Mb/s? Как вы думаете насколько % будет отличаться производительность в IOPS между SATA и SAS/FC винтами при 256k блоках?

  4. Нашел в инете калькулятор IOPS - вопрос, а правильно ли указана производительность SSD дисков? Что-то про 48000 IOPS не верится.
    http://www.storage-expert.ru/index.php/section-table/42-disk-array-faq/63-online-iops-calc

  5. Честно сказать, сложно сказать однозначно. В отличие от HDD, где IOPS напрямую и детерминированно зависят от скорости вращения, в случае SSD этот параметр зависит от множества вещей, от конструкции контроллера и организации блоков flash в перву очередь.

    Второй момент, о котором надо помнит, что есть у HDD IOPS “линеен” для записи и чтения, то у Flash это не так. Операция записи на SSD значительно медленнее, чем чтение.

  6. Алексей:

    А если есть FlashCache - можно ли SATA делать primary storage, как считаете?
    Ну, допустим, это несколько СУБД, серверы приложений, Exchange, AD, профили пользователей и прочая стандартная mid-Enterprise требуха.

  7. Алексей:

    Строго говоря, на такие вопросы нельзя отвечать “да” или “нет”, не проводя дополнительных исследований. Случаи (и характер задач) бывают разные.
    Но вот, например, на задачах файлового сервиса, как показывает пример тестирования SPEC sfs2007, такой вариант вполне может пр определенных конфигурациях, существовать.

    Результаты можно посмотреть на сайте spec.org в соответствующем разделе.

  8. Алексей:

    Видел-видел. Там красивая дуга. Одинаковая для вариантов тестирования: 224 disk FC15k vs 56 disk FC15k vs 96 disk SATA 7.2k.
    Прям аж так вкусно выглядит (я про SATA). Наверняка подвох. Строго под определенный тип задач, опять же на счет SATA + PAMII. То есть с ходу про универсальность такой системы говорить не следует. Надо сайзить и тд и тп. В общем, ясно.

  9. Алексей:

    Пардон, так правильнее:
    (224 disk FC15k) vs (56 disk FC15k + PAMII) vs (96 disk SATA 7.2k + PAMII).

  10. Алексей:

    Вот именно. Навскидку, результат для 96 дисков SATA может не быть таким, например, для 24 таких дисков. Поэтому нельзя дать компетентный ответ в предложенных рамках.

Оставить комментарий

20/0.142

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