О сторадж-боксах

[alextutubalin]

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

Comments

[shuvayev]

Не жарко им там?

[alextutubalin]

Пока это на столе/под столом - все отлично (продув хороший). Как будет в шкафу - будем посмотреть.

[_slw]

кто-то про zfs на линухе считает что одни грабли и падучая, а кое-кто -- что если знать как осткрегаться -- все замечательно. так что надо пробовать

[alextutubalin]

Мне для iscsi/srp оттуда нужно только умение создавать тома. Буду пробовать, да.

[dmarck]

только не gjournal, а SUJ

[alextutubalin]

А как загнать журнал на отдельное устройство (SSD в моем случае)?

[dmarck]

Никак -- но: Тебе это не нужно, trust me. gjournal удваивает весь поток, не только метаданные, SUJ кладёт в специальный инод, размещённый contiguously эффективно близко к началу FS, изменения метаданных, в виде кольцевого буфера.

[alextutubalin]

То есть там никак не надо готовить диски, прямо вот в текущей FS все работает?

[dmarck]

Бенчмарка -- iometer

[alextutubalin]

Я не понимаю как интерпретировать результаты. Ну то есть совсем.

[dmarck]

Ну, да, кстати, у тебя довольно специфический паттерн использования. Хотя, наверное, для iometer'а и твой можно описать, там гибкий язык.

iometer в основном на жестокий concurrent заточен, это да, и это не твоё.

[alextutubalin]

параллельные потоки IO на крутящихся дисках - это же вообще катастрофа.

И на WS я этого ну почти не допускаю. Там где могу контролировать - там совсем не допускаю. По очевидным таким причинам.

Т.е. у меня два крайних паттерна, оба понятные: что-то делаем с большими файлами (гигабайтными). Пишем или читаем. Ну и что-то с мелкими (килобайтными в пределе), ну скажем компиляция читает мешок исходников.
Т.е. интересные мне на WS параметры - это throughput и latency, но без всякой конкуренции.

[rezdm]

Я бы ещё ответил на такой вопрос, чтобы ответить на исходный: что происходит, если вылетает материнка (или адаптек), какова процедура восстановления работоспособности этого "носителя" тогда? Насколько легко будет в будущем переподцепить все эи веники при переезде на другою версию ОС? Т.п.

[alextutubalin]

В адаптек я просто верю, что от смены контроллера на "не худший" - тома подцепятся. У меня такой опыт был, но раньше, еще с SCSI и я надеюсь что искусство не утеряно.
Про ZFS - знаю (про FreeBSD/солярку), что тома можно нормально таскать, таскал.
Про линуксовый mdadm - просто надеюсь на лучшее. Про линуксовый ZFS - ни на что не надеюсь, но проверю что созданные тома видны на FreeBSD.

Вообще, я на эти грабли уже наступал с дешевым контроллером (т.е. вообще он дорогой, просто достался с распродажи) и наступив - перешел на адаптек. Собственно, вот же мы обсуждали в январе: http://blog.lexa.ru/2012/01/13/q_korpus_dlya_hdd.html#comment-23646

[thinker8086]

Собственно, а какой Адаптек сейчас стоит, и насколько RAID в данном конфиге ускоряет работу с дисками, по сравнению, скажем, с "голым" терабайтником?

[alextutubalin]

5805.
До вчерашнего дня в WS было 6 дисков (старые терабайтные барракуда ES.2, 7200rpm). RAID6.
Сейчас - вместо них стоит два одиночных медленных (какие были под рукой) двухтерабайтника.

Разница по скорости линейного чтения/записи - просто в разы. Были сотни мегабайт/сек (типа 300), сейчас заметно меньше 100 (особо не мерял, по данным виндового перформанс-монитора)
Бэкап вместо 15 минут идет полтора часа.