[Hardware] Fwd: Re: Q: inexpensive Software RAID setup

[Michael Shigorin]

----- Forwarded message from Serge Ryabchun <serge.ryabchun/gmail.com> -----

Date: Fri, 27 Apr 2007 14:19:15 +0300
From: "Serge Ryabchun" <serge.ryabchun/gmail.com>
To: "Dmitry V. Levin" <ldv/altlinux.org>
Subject: Re: [Hardware] Q: inexpensive Software RAID setup
Cc: "Michael Shigorin" <mike/altlinux.ru>

27.04.07, Dmitry V. Levin <ldv/altlinux.org> написал(а):
>On Thu, Apr 26, 2007 at 02:54:36PM +0300, Michael Shigorin wrote:
>> On Wed, Apr 25, 2007 at 03:51:19AM +0400, Dmitry V. Levin wrote:
>> > > 2 ldv: не бери Seagate 7200.9 ни за какие коврижки, у них
>> > > reportedly тонкие крышки -- 400Gb застучал сразу, один из
>> > > двух 200Gb (другого вендора год тому не выходило) -- через
>> > > неделю начал жаловаться в SMART.  На WD и Hitachi нареканий
>> > > пока нет, для FTP лучше хитачи -- у них seek заметно лучше
>> > > оптимизирован, хотя линейное чтение несколько меньше (заметно
>> > > меньше для 400-к, по словам sr@).
>> > Вопрос из другой оперы, но раз уж зашёл разговор:
>> > Имеются ли возражения против ST3750640NS?
>> > (планируется под raid10 из 4*750)


возражений нет, но если есть возможность, то попробуйте отобрать
диски с разлетом в показателях не больше 1%. Практика показывает,
что из десятка дисков 1-3 имеют вылет средних значений на 5-10% и
они же являются первыми кандидатами на выход со строя.


>>
>> Может быть проще засунуть 8*400/320 в отдельный корпус 2--3U
>> как raid50 или пару raid5.
>
>Корпус 1U не растягивается до 2-3U, да и оплата за colocation
>начисляется пропорционально U.
>
>> Очень не хочется верить экстремальным на данный момент дискам.
>
>Через полгода-год эти диски уже не будут казаться экстремальными.
>
>> sr@ на мой вопрос о raid10 отзывался неодобрительно о его
>> производительности --
>
>raid10 заведомо производительнее raid5.


по записи они практически одинаковы - скорость записи одного
диска по определению, при большом количестве дисков raid5
проваливается ниже изза read-write на записи вместо просто write
на мелких порциях, просто не хватает процессора-шины. на 2.6.18
при писателях больше одного проваливаются оба одинаково хорошо.
На чтении raid5 давал где-то (X-1.5)*R, где X к-во дисков, R
скорость чтения  диска на данном участке. Те в начале диска
75MB/s и RAID5 на 4 диска выдавал порядка 180-190, при нескольких
читателях падение до 100-130, при наличии писателей еще ниже. При
этом RAID10 вел себя вообще непредсказуемо и поваливался до
80-90. Ессейсно, данные точные где-то остались, но помоему только
на бумаге в институте, мерялось все на набортных AHCI на
вудкристах в 64bit режиме, другая платформа вполне может дать
другие результаты, другие ядра аналогично.  Оптимальным выходит
использование RAID1, запись 1*W, чтение 1.9*R на один массив.
Чтение одним читателем не масштабируется, те при одном читателе
имеем 1*R. Правда, использование везде RAID1 у меня связано еще и
с невозможностью сейчас заюзать софтовый RAID5 в LUSTRE, в
некоторых ситуациях LUSTRE умудряется изменить данные в страйпе
без пересчета контрольной суммы с последующим развалом данных.
Патчи для исправления есть только для ядер времен царя гороха и
они совсем не тривиальные.


>> если у суппорта есть время собрать десятый
>> и пятый и проверить, тоже был бы благодарен.
>
>Аналогично, хотя ответ мне известен заранее.


Не уверен, RAID10 в linux на 2.6.18 давал результаты хуже, чем
RAID10 на ареке, что очень подозрительно хотя бы потому, что
какой-то интеловский 500MHz risc гороздо медленнее i5140 и 256MB
DDR266 кеша гораздо хуже 4GB FB-DIMM. Вобщем, даже если RAID10 в
линухе будет или уже поправлен, то у меня все-равно на ближайшие
пару лет "впечатление осталось".

----- End forwarded message -----

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/