HDD/SSD price

lexa - 04/Ноя/2011 11:45

В какой-то из презентаций этой осени, либо броузя веб, либо на Highload, я услышал/увидел следующую мысль:

Если вам не хватает производительности базы данных: замените HDD на SSD и все проекты по переходу на NoSQL можно будет надолго отложить.

И я с этой мыслью согласен.

Что делают (делали), когда не хватает IOPS-ов? Берут много дисков побыстрее. А какие диски побыстрее по IOPS-ам? 2.5" 15k RPM (т.е. Seagate Savvio 15k): они маленькие, голове нужно дрыгаться мало, поэтому seek time сильно меньше чем у 3.5", IOPS-ов там чуть не вдвое больше чем у 3.5".

А теперь смотрим картинку:

Ну то есть да, SSD дороже процентов на 20. И емкость меньше тоже процентов на 20 (а с учетом желательного резервирования части байтов - пусть даже на 40). Но мегабайт получается меньше чем вдвое дороже, а IOPSов - раз в 30 побольше.

То есть я к тому клоню, что все эти 10k/15k RPM диски (которые покупают ради IOPS-ов) - всё. Совсем всё. Разница в цене уже сильно меньше, чем разница в производительности. По всем метрикам, просто по IOPS-ам, по IOPS/W (что внезапно становится важным), по IOPS/$.

Емкие и медленные HDD - да, естественно, еще покувыркаются.

Comments

m1gel (not verified) - 04/Ноя/2011 11:55

Ага, винты ещё и дорожают теперь, ССД обещают подешеветь. Пряи г'еволюция онлайн

lexa - 04/Ноя/2011 12:09

быстрые SAS-ы вроде пока не дорожают, спрос маленький (а цена моторов в диске - наверное небольшая). Или дорожают мало.

Что прикольно, это что 3Tb подорожали относительно мало, раза в полтора. А вот 500Gb по 3-4 тыщи (столько 2.5Tb стоили месяц назад) - радуют глаз

m1gel (not verified) - 04/Ноя/2011 12:29

Мне другое иинтересно: насколько это длительные изменения. Полгодика то мож смогу потерпеть, а дальше то что делать?)

lexa - 04/Ноя/2011 12:45

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

Но у меня вот тоже - остался свободный терабайт в сервере и чуть более того - в WS. Тесно совсем!

Но 3Tb продолжают стоить относительно разумно, у меня кошелек вторую неделю чешется.

khmurik (not verified) - 04/Ноя/2011 13:28

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

lexa - 04/Ноя/2011 13:53

На эту тему у меня был пост: http://blog.lexa.ru/2011/09/15/o_prodolzhitelnosti_zhizni_ssd.html

Грубо говоря, можно записать 250Tb на 64Gb-диск. Т.е. ~1000Tb на 240-гиговик.
Это миллиард секунд или 11.5 тысяч дней или 30 лет непрерывной записи со скоростью 1Mb/sec.

Реальные паттерны надо смотреть, конечно. Но если речь идет про IOPS-limited т.е. сплошной random seek, то быстрые SAS - это скажем 500 seeks/sec * 4-8kb (разумный размер блока) = 2-4Mb/sec. А 2ms/seek - это очень оптимистичная оценка.

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

На практике - SandForce я еще ни одного не сточил (и все SandForce говорят про 100% здоровье), предыдущего поколения (Indilinx) - сточил один. Из не очень большого количества, около 10.

shaman007 (not verified) - 04/Ноя/2011 13:48

Я как про затопление почитал, пошел в магазин, мне как раз 2ТБ до бекапа 1-в-1 домашнего файлового сервера не хватало. Прихожу, лежат 2 HDD с USB, как надо. 2ТБ стоит дешевле на 300р, чем 1.5ТБ. Спрашиваю продавцов почему так, ответ убил: который дороже - вэдэ, а который дешевле - сиджит (Боже, "сиджит")! У Вэдэ мировое имя.

m1gel (not verified) - 04/Ноя/2011 22:46

Фабрики WD затопило, а seagate нет, нормальный такой ответ вполне

dmarck (not verified) - 04/Ноя/2011 13:48

Стой-стой, это в частном использовании всё хорошо, а на стораджи ты ssd не поставишь (кэш-уровень не считаем), потому что циклов записи мало, как ты контроллером ни исхитряйся. А в сервера нынче диски вообще ставить не надо, PXE или USB stick to boot

lexa - 04/Ноя/2011 13:55

Вот реальные измерения: http://blog.lexa.ru/2011/09/15/o_prodolzhitelnosti_zhizni_ssd.html

Все уже более чем прилично.

Ну то есть я потыкался в те сервера, где БД крутится - не вижу нигде write b/w выше пары мегабайт/сек (усредненного по uptime).

Но вообще интересно, возьми самый загруженный по IO сервер, скажи ему iostat -x и покажи что получилось....

ask_ripe (not verified) - 05/Ноя/2011 05:01

вообще-то нет. давно ставят. примерно в соотношении 1к40к160 (ssd к 15k к 10к). динамический перенос "горячих страниц" рулит. но есть небольшая проблема в стоимости - ssd, как таковые, делятся на 3 группы - простые(как в обычном пк), хорошие(раз в десять дороже, резервирование занимает 200%-300%), замечательные(раз в сто дороже)
те типовой hi-end массив 40*4*600тб 10k + 20*4*300тб будет стоит в два раза дешевле чем такой же, но с 1*4*300тб SSD. (1.5 кк vs 2.8 кк(ок, 2.5кк - 300к будут стоить лицензии на dynamic tiering)

в mid-range ситуация чуть лучще - ну а в лоу-кост, да цены упали очень заметно (те причин ставить быстрые диски на выделенный сервер уже не осталось - стоит ставить SSD(хотя не понятно, зачем там вообще диски))

lexa - 04/Ноя/2011 14:20

Кстати, я из своей работы в рамблере запомнил константу: падеж дисков составлял 1% в месяц (примерно). Интересно, как сейчас.

dmarck (not verified) - 04/Ноя/2011 14:25

Я бы процента три прикинул, что сходится с 3 годами гарантии. Well OK, реально из стро выходят реже, да.

lexa - 04/Ноя/2011 15:45

Не, гарантию считают так, чтобы под нее не попало большинство дисков :)

ask_ripe (not verified) - 05/Ноя/2011 05:06

не скажу за рамблер - но в одном смешном ОПС диски честно сыпались (3 года назад, 72gb и 146gb) из расчета 50000h mtbf - 1-2 в день
сейчас(300gb-600gb), при mtbf 350000h реже - 2-3 в неделю

число дисков не изменилось...

ask_ripe (not verified) - 05/Ноя/2011 05:02

s/тб/гб/
:)

lexa - 05/Ноя/2011 09:33

"Зачем диски" в сервере - очень даже понятно.

Есть два подхода к большим системам, "гугловый" (дешевый бокс со своими дисками) и "настоящий" (у сервера - только CPU и RAM, а сторадж - в системе хранения).

lexa - 05/Ноя/2011 09:27

Из скольких штук?

ask_ripe (not verified) - 05/Ноя/2011 19:17

~7000

ask_ripe (not verified) - 05/Ноя/2011 19:23

на самом деле только серверных раза в 4 больше - но они уже не HP - и меня не касаются...

lexa - 05/Ноя/2011 20:50

Ну то есть было ~50-60 в месяц - тот же 1%
А стало - 0.5%

Приятно слышать.

ask_ripe (not verified) - 05/Ноя/2011 19:22

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

да бог с ними - с большими системами - пусть она маленькая - но она ведь захочет на виртуалку? и что, тоже на дешевый бокс и синхронизация локальных дисков своими силами? но даже если да, так выгоднее - то зачем ей иопсы?

Gor
P.S. я про то, что я не знаю места, где "гугловый" подход работает в большой нагруженной среде с явно прописанными SLA - кроме как в гугл... :(

lexa - 05/Ноя/2011 20:59

Случаи - они разные бывают. Меня вот тошнит от MySQL, а люди - используют. Втч и в довольно больших инсталляциях, вроде facebook.

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

И упор в IOPSы очень быстро возникает, как только вы хотите раздавать файлы в очень много потоков, неважно - YouTube/RuTube это или фотохостинг или что-то подобное. Кэши спасают, конечно, но сильно меньше чем полностью.

Типичная задача для упора в bandwidth (а не в IOPSы) - это "отсортировать пяток терабайт". Задача которая прекрасно ложится на JBOD и омерзительно - на любой массив (а волнует надежность - поставьте три тазика и сортируйте одно и то же, глядишь до конца сортировки один и доживет).

Оно для энтерпрайза все дико выглядит. Равно как и энтерпрайз для Гугла-Яндекса-Мейла-итп.

edo_rus (not verified) - 02/Дек/2011 06:02

Меня вот тошнит от MySQL,

с учётом контекста - имеется опыт использования postgresql на ssd?

PS: и совсем глупый вопрос - эти диски в 3.5" hostwap корзины нормально встают?

lexa - 02/Дек/2011 08:55

С учетом того, что у меня своего продакшен-постгреса уже давно нет (тот что на сайтах *lexa.ru не считается - там нагрузка мало отличается от нуля) - весь позитивный тестовый опыт неинтересен. На поиске (RO-задача, спец-база) эксперименты были, эффект около десятичного порядка "в среднем" и полтора порядка на коротких запросах, где важен именно seek, а не linear read.

С салазками вопрос сложный. OCZ-шный переходник на 3.5, который идет вместе с дисками, в те салазки что у меня дома есть - встает нормально. Но вообще переходники и салазки бывают очень разные, возможно придется переходники закупать отдельно.

edo_rus (not verified) - 04/Дек/2011 03:55

начал искать информацию - оказалось всё не так радужно.

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

вот например ссылка:
http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/

есть два решения:
- raid-контроллер с bbu - стоит денег;
- ssd с конденсатором на кэше (например intel 320) - опять же стоит дороже vertex3.

PS: а ещё такие низкие значения iops на write с fsync вызывали у меня подозрения, что каждый fsync вызывает erase page. если оно вдруг действительно так - SSD умрёт намного раньше, чем через 1000Тб записанных данных.

lexa - 04/Дек/2011 09:59

Пробовать все надо. Я тоже читал, что дескать "Vertex убили за 2 часа" в тестовом окружении с миллионом транзакций в час.

То есть надо прямо вот воткнуть и померять write amplification. Утверждается, что современные (а не 2009г) контроллеры эту проблему успешно порешали каким-то способом (что-то про то, что следующий блок возьмется из пула пустых и page erase на каждый блок не будет), но только при условии запаса свободного места.

edo_rus (not verified) - 04/Дек/2011 16:21

ну write amplification - это одно.

а вот то, что на random write по всему диску нет особого роста в сравнении с 15k sas - это разбивает мечту о чудодейственном ssd.
у интела в даташитах в 320 серии заявлено 400 iops, в тестах примерно так и выходит.
остаются конечно read-only задачи, но сейчас они мне не так интересны.

lexa - 04/Дек/2011 16:46

А у 510-го заявлено 8000IOPS на full-stroke write.
Надо разбираться, если не лень.

edo_rus (not verified) - 05/Дек/2011 02:37

да, IOPS'ы большие, но при этом "Enhanced Power Loss Data Protection - No".

да, надо разбираться, но, похоже, "лучший критерий теории - практика"

PS: а ещё есть intel 710, у которого всё хорошо... кроме цены

edo_rus (not verified) - 05/Дек/2011 03:08

А какие диски побыстрее по IOPS-ам? 2.5" 15k RPM (т.е. Seagate Savvio 15k): они маленькие, голове нужно дрыгаться мало, поэтому seek time сильно меньше чем у 3.5", IOPS-ов там чуть не вдвое больше чем у 3.5".

btw, я тоже так думал.
потом присмотрелся - разница между 3.5" и 2.5" невелика на самом деле.

да оно и понятно, 15k - это 250 оборотов в минуту, на один io нужно время на позиционирование головки плюс в среднем полоборота; то есть теоретический предел - 500 iops.
вот только гонял свежий сервер с 300Gb cheetah - 400 iops с диска (в синтетике, iometer).
сам был удивлён, по предыдущему опыту ожидал увидеть не больше 300-350 с диска; то ли механику наоптимизировали, то ли прошивку дисков, а может дело вообще дело в более шустром проце на рейд-контроллере, но повторюсь - результат меня приятно удивил.

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

PS: и всё-таки SFF-диски мне симпатичны: не греются, меньше потребляют, тише, в равный корпус большее количество дисков помещается... но iops/$ у них меньше ;)