File server & Raid. скорость доступа. необходимость raid?

Dasar

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

CapitanJack

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

Dasar

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

CapitanJack

20 операций? иопсов? или 20 файлов?
без рейда ты нагрузку будешь руками разносить по дискам?

Dasar

> 20 операций? иопсов? или 20 файлов?
допустим файлов.
> без рейда ты нагрузку будешь руками разносить по дискам?
но raid же все равно нагрузку не балансирует.
raid лишь в большей степени размазывает файлы по винтам, увеличивая лишь только рандомизацию распределения файлов

Dasar

т.е. получается, что как только на файл-сервер нагрузка возрастает до того положения, как в каждый момент времени с каждого винта есть хоть одно чтение, то смысл raid-а сразу пропадает.

CapitanJack

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

Chupa

если поставить raid1, то смысл есть, так как контроллер будет раскидывать операции чтения с учетом положения головок винтов
(по крайней мере, в линуховом software raid такая логика реализована)

Dasar

т.е. такая логика в обычном контроллере (не raid) не реализована?

Chupa

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

krishtaf

воопше конечно если посчитать то 4 диска без рейда выдадут максимально больше иопсов и потока чем те же диски в рейде 5.

странно от тебя это слышать
Одна и та же нформация лежит на одном винте и на N-дисках, собраных в raid1.
И кто больше выдаст блоков клиенту за одну и ту же единицу времени ?
P.S.
Будет считать что других узких мест в системе нет.

kruzer25

Сообщение удалил

krishtaf

Тут-то - много разной информации на разных винтах... а запрос - не на один файл поступает, а на кучу, которые примерно равномерно раскиданы (а в слуячае рэйда - размазаны) по этим винтам...

советую тебе посмотреть что такое raid1

kruzer25

Всё время путаю 0 и 1.
Но говорил про raid 5

krishtaf

правильно я понимаю, что ставить raid на файл-сервер ради увеличения скорости доступа бессмысленно?

в общем не бессмыслено.
P.S.
я о том, что нужно не рейд5 смотреть, а другое.
Подбирать подходящий режим рейда в зависимости от типа использования файл-сервера.
В большинстве случаев рейд 5 быстрее.

CapitanJack

один диск на парити - он нам иопсов не даст вообще
и мы решили не считать иопсы из кеша

krishtaf

ты все еще про рейд 5 что ли ?
P.S.
 

один диск на парити

на котором сумма хранится ?
 

man mdadm

       -p, --parity=

              Set  raid5 parity algorithm. Options are: left-asymmetric, left-

              symmetric, right-asymmetric, right-symmetric, la,  ra,  ls,  rs.

              The default is left-symmetric.

              This  option  is  also  used to set the failure mode for faulty.

              The options are: write-transient, wt, read-transient, rt, write-

              presistent,  wp,  read-persistent,  rp, write-all, read-fixable,

              rf, clear, flush, none.

              Each mode can be followed by a number which is used as a  period

              between fault generation.  Without a number, the fault is gener-

              ated once on the first relevant request.   With  a  number,  the

              fault  will  be generated after that many request, and will con-

              tinue to be generated every time the period elapses.

              Multiple failure modes can be current  simultaneously  by  using

              the "--grow" option to set subsequent failure modes.

              "clear"  or  "none"  will remove any pending or periodic failure

              modes, and "flush" will clear any persistant faults.

              To set  the  parity  with  "--grow",  the  level  of  the  array

              ("faulty") must be specified before the fault mode is specified.