информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
"Кажется" и "соответствует действительности" - разные вещи... 18.01.05 16:18  Число просмотров: 1489
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.01.05 16:35  Количество правок: 5
<"чистая" ссылка>
> Если в массиве будет 15 дисков, это не значит, что скорость
> записи с чередованием в RAID0 увеличиться в 15 раз по
> сравнению с записью на 1 диск. Слишком много ограничивающих
> факторов начиная с пропускная способность SCSI шины и
> реализацией SCSI контроллера, заканчивая правилами
> взаимодействия между ОС и контроллером.

"Кажется" и "соответствует действительности" - разные вещи. Суммарная скорость записи 15 современных дисков превысит скорость передачи по интерфейсу, а я оговаривался "при условии, что скорость передачи по интерфейсу выше скорости записи на поверхность". В случае огромного количества дисков скорость массивов любых уровней будет равна скорости интерфейса. Для 15 дисков обычно берут многоканальные РАИД-контроллеры. Если дисков два, три, четыре, а интерфейс 160 или 320, то перечитайте все то, что я написал в предыдущем топике.

> RAID5 использует чередование, поэтому чтение с 10-ти дисков
> будет примерно в десять раз быстрее (несколько сотен
> (тысяч) мегабайт в секунду).
> Скажем, с массива из 9-ти дисков читается информация в
> объеме 4Мб. Запись производилась с чередованием на 8
> дисков, а блок контрольной суммы лег на 9-ый диск, но один
> блок данных оказался на вышедшем из строя диске. Скорость
> чтения и получения данных контроллером будет примерно равна
> скорости чтения одного сектора, т.е. максимально быстро.
> Если RAID имеет прошивку/firmware (что обычно и бывает), а

Прошивчивость его тут не причем. Софт может наглухо лежать в ПЗУ или прошиваться в флэш или еще где угодно, но при отработки он ляжет в кэш со скоростью доступа не более одного процессорного такта.

> не аппаратно реализованый алгоритм вычисления данных по
> контрольной сумме, то вычисления 512Кб данных будут
> производиться со скоростью обычного, далеко не самого
> быстрого процессора. Все это время ОС будет ожидать ответа
> от SCSI контроллера.

Не будет. В ОС крутится куча процессов, ей будет чем заняться. Пока проц считает, параллельно могут происходить еще как минимум три важных процедуры: обмен между пластинами диска и его буфером, передача из буфера по интерфейсу, обмен между памятью контроллера и ОЗУ. У контроллера в очереди может стоять много запросов на ввод/вывод, выполнять он их может в любом порядке.

Процы на современных РАИД-контроллерах стоят современные окологигагерцовые РИСКи. То есть за наносекунду он обработает сотню байт (100 Гб/сек.). Все упрется в скорость памяти (а она, на РС3200 - 3.2 Гб/сек на один канал). Для сравнения скорость интерфейса 0.32 Гб/сек. максимум, а дисков на порядок меньше.

> Иногда, при использовании не самых свежих RAID контроллеров
> и при пиковой нагрузке на массив в event log'е можно
> увидеть сообщение, типа - устройство (имеется ввиду
> контроллер RAID'а) не ответило за установленный промежуток
> времени.

Это можно увидеть и не на РАИДе, а на обычном диске.

> :) Мы вообще о каком RAID'е говорим? Об аппаратном (RAID
> SCSI контроллер) или программном (RAID на уровне ОС)? Я,
> например, имею ввиду аппаратный.

Естестно. Штатный проц будет сильно тормозить, причин туева хуча. Причем их и аппаратных куча бывает (АРО, например, не имел на борту интерфейса/шины).

> Еще как вылетают. Я видел. :)))
> Минимум, может быть и предохранитель, а вот максимум:
> источник БП APC Smart-UPS 1500VA, 2xSCSI HDD LowProfile
> 40Gb, ECC RAM и что-то там еще...

Не знаю что и сказать - "повезло" или "не повезло".

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

По определению. Можно ли назвать ИБП хорошим, если у него ничего нет, не смотря на то, что все заявлено. Наличие всего не всегда делает ИБП хорошим. Если ИБП в нужный момент не спас, а Вы на него так надеялись, думая, что он хороший, значит Вы просто заблуждались и этот ИБП не будем называть хорошим.
<sysadmin>
Несколько томов на серваке - смысл? 17.01.05 12:22  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 17.01.05 12:25  Количество правок: 2
<"чистая" ссылка>
На серваке можно завести несколько томов. Причем в большинстве ситуаций они получатся автоматически.
Если будет несколько дисковых массивов. Это редкая ситуация, поскольку целесообразнее все имеющиеся емкости включать в один массив.
Если в массиве будет несколько логических драйвов. Это чуть более частая ситуация, поскольку в серваке найдется информация, которую можно положить и на РАИД0, и на РАИД1, и на РАИД5.
В конце концов несколько томов на одном драйве.

Предположим Вы заряжаете новый сервак. Чем Вы будете руководствоваться при разбиении дискового пространства?
Например: "Разобью массив на РАИД5 и РАИД0. На 5 будет лежать все нужное - быстро, с избыточностью, экономичнее чем РАИД1. На 0 будет валяться все не нужное, своп и пр. Скорость максимальная, использование объема по максимуму, избыточность не нужна.".
Или: "Весь массив на РАИД5, раздел один. Не нужен этот геморрой с разделами, 5 и так оптимальна включая в себя избыточность и скорость. Знаем, проходили, разбили диск на кучу одинаковых разделов, нужно было что-то большое слить, в сумме на всех разделах места хватало, а со сливом проблема.".

Короче имеет ли смысл разбивать - "ЗА" и "ПРОТИВ"?
Имеет ли смысл создавать два драйва с различными уровнями РАИД?
Наверное так: 17.01.05 13:05  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
RAID0 - Своп и всякая хрень.
RAID1 (Mirroring) - ОС, ПО и т.п. (можно и своп сюда же, если ЖД не лишний)
RAID5 - DATA (все, что нужно - одним разделом)
У кого на серваке с гигом оперативки сильно используется... 17.01.05 14:37  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 17.01.05 14:39  Количество правок: 1
<"чистая" ссылка>
> RAID0 - Своп и всякая хрень.

У кого на серваке с гигом оперативки сильно используется своп?
ТМПшники - мелочи.
Логи - можно, но им скорость не нужна.
По-моему он нужен только там, где нужна огромная скорость обработки огромных файлов с некритичной информацией. Например перекодирование видео, тестирование БД.

> RAID1 (Mirroring) - ОС, ПО и т.п. (можно и своп сюда же,
> если ЖД не лишний)

Зачем ОС и ПО нужен РАИД1? Тем более если имеем 3 диска - при вылете одного все и на РАИД5 будет работать, при вылете двух не спасет и РАИД1. В нем "пропадает" 1/2 часть емкости, а в 5 - 1/3. При свопе чтение-то с РАИД1 быстрее, а запись самая медленная из всех уровней.
Архаизм после появления умных контроллеров, поддерживающих уровни 4 или 5.

> RAID5 - DATA (все, что нужно - одним разделом)

Логика понятна исходя их свойств РАИДов (скорость, избыточность, эффективность использования емкости).
Так и витает навязчивая мысль все на РАИД5 все закатать. Есть ли смысл от того, что будут присутствовать 0 и 1 и будут использоваться как предложено, насколько эффект будет ощутим? Не будет ли эффект ничтожно мал, а гемор от разбивки велик?
Откуда такая информация по RAID1? 17.01.05 16:25  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> > RAID0 - Своп и всякая хрень.
>
> У кого на серваке с гигом оперативки сильно используется
> своп?
> ТМПшники - мелочи.
> Логи - можно, но им скорость не нужна.
> По-моему он нужен только там, где нужна огромная скорость
> обработки огромных файлов с некритичной информацией.
> Например перекодирование видео, тестирование БД.

Надо? Ставь! Не надо - не ставь. ;)

> > RAID1 (Mirroring) - ОС, ПО и т.п. (можно и своп сюда
> же,
> > если ЖД не лишний)
>
> Зачем ОС и ПО нужен РАИД1? Тем более если имеем 3 диска -
> при вылете одного все и на РАИД5 будет работать, при вылете
> двух не спасет и РАИД1. В нем "пропадает" 1/2 часть
> емкости, а в 5 - 1/3. При свопе чтение-то с РАИД1 быстрее,
> а запись самая медленная из всех уровней.
> Архаизм после появления умных контроллеров, поддерживающих
> уровни 4 или 5.
>
> > RAID5 - DATA (все, что нужно - одним разделом)

Откуда такая информация по скорости RAID1?
В RAID1 одна и таже информация пишется на два диска сразу и контроллеру не требуется выщитывать контрольную сумму, как в RAID5 и писать ее на "избыточный" диск. IMHO, RAID1 fastest then RAID5.
К тому же, потеря 1/3 физической емкости дискового пространства на RAID5 - это максимальная потеря. При использовании десяти ЖД - потеря физической емкости для обеспечения избыточности будет 1/10.

> Логика понятна исходя их свойств РАИДов (скорость,
> избыточность, эффективность использования емкости).
> Так и витает навязчивая мысль все на РАИД5 все закатать.
> Есть ли смысл от того, что будут присутствовать 0 и 1 и
> будут использоваться как предложено, насколько эффект будет
> ощутим? Не будет ли эффект ничтожно мал, а гемор от
> разбивки велик?

Сколько потребуется времени, чтобы восстановить работоспособность ОС на сервере, если ОС стоит на RAID5 c десятью 120Gb дисками? Я имею ввиду время на перестройку RAID массива после горячей замены вышедшего из строя диска.
И сколько времени требуется на восстановление работоспособности ОС, если она стоит на "зеркале", а в зеркале накрылся один из дисков?
Все просто - полезно рассмотреть стрип, а он приличного... 17.01.05 17:37  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 17.01.05 17:41  Количество правок: 3
<"чистая" ссылка>
> Откуда такая информация по скорости RAID1?
> В RAID1 одна и таже информация пишется на два диска сразу и
> контроллеру не требуется выщитывать контрольную сумму, как
> в RAID5 и писать ее на "избыточный" диск. IMHO, RAID1
> fastest then RAID5.
> К тому же, потеря 1/3 физической емкости дискового
> пространства на RAID5 - это максимальная потеря. При
> использовании десяти ЖД - потеря физической емкости для
> обеспечения избыточности будет 1/10.

Все просто - полезно рассмотреть объем данных приличного объема (десятки секторов). В РАИД1 он должен быть записан дважды, в РАИД5 одинажды последовательно (как на РАИД0), плюс код восстановления. В РАИД5 код восстановления в любом случае меньше самих данных. Те есть писать нужно меньше от 1/3 до 1/N. Коэффициент скорости чтения в РАИД5 (N-1)/N, в РАИД1 равен 1. В современных контроллерах стоят хорошие специализированные процессора, скорость вычисления кодов коррекции больше скорости чтения/записи во много раз.

> Сколько потребуется времени, чтобы восстановить
> работоспособность ОС на сервере, если ОС стоит на RAID5 c
> десятью 120Gb дисками? Я имею ввиду время на перестройку
> RAID массива после горячей замены вышедшего из строя диска.
> И сколько времени требуется на восстановление
> работоспособности ОС, если она стоит на "зеркале", а в
> зеркале накрылся один из дисков?

Перевод из состояния "Критикал" в "Онлайн" займет приблизительно равное время. К тому же за весь срок службы такой ситуации может вообще не произойти.
Может я не прав, но... 18.01.05 11:23  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 18.01.05 12:04  Количество правок: 1
<"чистая" ссылка>
> Все просто - полезно рассмотреть объем данных приличного
> объема (десятки секторов). В РАИД1 он должен быть записан
> дважды, в РАИД5 одинажды последовательно (как на РАИД0),
> плюс код восстановления. В РАИД5 код восстановления в любом
> случае меньше самих данных. Те есть писать нужно меньше от
> 1/3 до 1/N. Коэффициент скорости чтения в РАИД5 (N-1)/N, в
> РАИД1 равен 1. В современных контроллерах стоят хорошие
> специализированные процессора, скорость вычисления кодов
> коррекции больше скорости чтения/записи во много раз.

Пропускная способность SCSI шины намного выше, чем пропускная способность самого SCSI диска, поэтому скорость записи на RAID1 почти такая же как на RAID0, так как, по сравнению с EIDE, контроллер SCSI может писать одновременно на несколько дисков.

> Перевод из состояния "Критикал" в "Онлайн" займет
> приблизительно равное время. К тому же за весь срок службы
> такой ситуации может вообще не произойти.

На сколько мне известно, в RAID5 запись данных выполняется с чередованием блоков(частей) данных равного объема, затем вычисляется блок контрольной суммы, который по размеру такой же величины, как блок(часть) данных. Конечно это немного утрированное представление RAID5, т.к. в действительности это реализовано немного по другому и с большим коэффициентом надежности.
Если из строя выходит диск/блок, хранящий контрольную сумму, то производительность массива почти не падает.
Теперь представим ситуацию, когда из строя выходит диск/блок данных - массив продолжает работать, но для получения необходимой информации контроллеру необходимо вычислить содержимое блока данных, опираясь на блок контрольной суммы и "живые" блоки данных. В этом случае производительность массива резко снижается.
Хорошо, когда такого не происходит, но иногда случаются ситуации (электрики фазу с нулем перепутали или что-то подобное), когда не спасает даже источник бесперебойного питания и есть вероятность потерять более одного диска в массиве (и не только диска).
Рекомендую включать ИБП в хороший сетевой фильтр.
Мне кажется не прав. Скорость записи на РАИД0 равняется... 18.01.05 15:00  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.01.05 15:23  Количество правок: 4
<"чистая" ссылка>
> Пропускная способность SCSI шины намного выше, чем
> пропускная способность самого SCSI диска, поэтому скорость
> записи на RAID1 почти такая же как на RAID0, так как, по
> сравнению с EIDE, контроллер SCSI может писать одновременно
> на несколько дисков.

Мне кажется не прав. Скорость записи на РАИД0 равняется скорости записи на один диск умноженной на количество дисков. Скорость записи на РАИД1 равняется скорости записи на один диск умноженной на количество дисков деленное на два. Это все при условии что скорость записи на массив меньше скорости передачи информации по SCSI шине. И при условии, что SCSI контроллер все-таки не умеет писать на два диска одновременно. Даже если это так, все равно это не имеет значение при условии что скорости по интерфейсу значительно больше скорости записи на поверхность.
Узкое место "бутылочное горлышко" - поверхность диска. Предположим, что на диск пишется одна порция информации за единицу времени, диски не простаивают, в массиве 4 диска, нужно записать кусок размером 4 порции информации. Для РАИД0 это будет одна единица времени, поскольку каждая порция будет писаться на свой диск одновременно. Для РАИД1 потребуется две единицы времени, потому что в течение первой единицы времени будет писаться первые две порции на диски - первая на первый и второй, вторая на второй и третий. В течение второй единицы времени будут записываться две вторые порции соорветственно третья на первый и второй диски, четвертая на третий и четвертый. Итого РАИД1 в два раза медленнее по записи и такой же шустрый как и РАИД0 по чтению.

> На сколько мне известно, в RAID5 запись данных выполняется
> с чередованием блоков(частей) данных равного объема, затем
> вычисляется блок контрольной суммы, который по размеру
> такой же величины, как блок(часть) данных. Конечно это
> немного утрированное представление RAID5, т.к. в
> действительности это реализовано немного по другому и с
> большим коэффициентом надежности.
> Если из строя выходит диск/блок, хранящий контрольную
> сумму, то производительность массива почти не падает.

До сих все верно в первом приближении.

> Теперь представим ситуацию, когда из строя выходит
> диск/блок данных - массив продолжает работать, но для
> получения необходимой информации контроллеру необходимо
> вычислить содержимое блока данных, опираясь на блок
> контрольной суммы и "живые" блоки данных. В этом случае
> производительность массива резко снижается.

При условии последовательного чтения необходимые данные уже прочитаны и остаются в памяти контроллера. Прочтение "испорченной" порции данных заменяется на чтение контрольной суммы и вычисление "испорченной" порции. То есть время увеличивается на время вычисления. Согласитесь, что суммирование или вычитание нескольких килобайт на спецпроцессоре пройдет со скоростью работы его оперативки, а это несколько гигабайт в секунду. Чтение же с винта - несколько мегабайт (десятков мегабайт) в секунду. То есть потеря времени ~1% на чтение "испорченых" данных. При условии, что в массиве 3 диска, общая потеря времени ~0.3%. Причем параллельно можно читать очередные порции информации с дисков, так что время, потраченное на вычисление будет не заметно.

> Хорошо, когда такого не происходит, но иногда случаются
> ситуации (электрики фазу с нулем перепутали или что-то
> подобное), когда не спасает даже источник бесперебойного
> питания и есть вероятность потерять более одного диска в
> массиве (и не только диска).

Если это происходит часто, то надо что-то делать.
Как правило это может произойти раз за несколько лет.
От перенапряжения питающей сети диски не вылетают. Минимум предохранитель, максимум БП.
На то РАИД и ставится, чтоб при вылете диска все оставалось в рабочем состоянии.
Не забывать про резервное копирование.

> Рекомендую включать ИБП в хороший сетевой
> фильтр.


В хороших ИБП уже стоят фильтры, защиты и даже АВР.
:)) А мне кажется, что прав. 18.01.05 15:48  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 18.01.05 15:49  Количество правок: 1
<"чистая" ссылка>
> Мне кажется не прав. Скорость записи на РАИД0 равняется
> скорости записи на один диск умноженной на количество
> дисков. Скорость записи на РАИД1 равняется скорости записи
> на один диск умноженной на количество дисков деленное на
> два. Это все при условии что скорость записи на массив
> меньше скорости передачи информации по SCSI шине. И при
> условии, что SCSI контроллер все-таки не умеет писать на
> два диска одновременно. Даже если это так, все равно это не
> имеет значение при условии что скорости по интерфейсу
> значительно больше скорости записи на поверхность.

Если в массиве будет 15 дисков, это не значит, что скорость записи с чередованием в RAID0 увеличиться в 15 раз по сравнению с записью на 1 диск. Слишком много ограничивающих факторов начиная с пропускная способность SCSI шины и реализацией SCSI контроллера, заканчивая правилами взаимодействия между ОС и контроллером.

> При условии последовательного чтения необходимые данные уже
> прочитаны и остаются в памяти контроллера. Прочтение
> "испорченной" порции данных заменяется на чтение
> контрольной суммы и вычисление "испорченной" порции. То
> есть время увеличивается на время вычисления. Согласитесь,
> что суммирование или вычитаник нескольких килобайт на
> спецпроцессоре пройдет со скоростью работы его оперативки,
> а это несколько гигабайт в секунду. Чтение же с винта -
> немколько мегабайт (десятков мегабайт) в секунду. Причем
> параллельно можно читать очередные порции информации с
> дисков, так что время, потраченное на вичисление будет не
> заметно.

RAID5 использует чередование, поэтому чтение с 10-ти дисков будет примерно в десять раз быстрее (несколько сотен (тысяч) мегабайт в секунду).
Скажем, с массива из 9-ти дисков читается информация в объеме 4Мб. Запись производилась с чередованием на 8 дисков, а блок контрольной суммы лег на 9-ый диск, но один блок данных оказался на вышедшем из строя диске. Скорость чтения и получения данных контроллером будет примерно равна скорости чтения одного сектора, т.е. максимально быстро. Если RAID имеет прошивку/firmware (что обычно и бывает), а не аппаратно реализованый алгоритм вычисления данных по контрольной сумме, то вычисления 512Кб данных будут производиться со скоростью обычного, далеко не самого быстрого процессора. Все это время ОС будет ожидать ответа от SCSI контроллера.
Иногда, при использовании не самых свежих RAID контроллеров и при пиковой нагрузке на массив в event log'е можно увидеть сообщение, типа - устройство (имеется ввиду контроллер RAID'а) не ответило за установленный промежуток времени.

:) Мы вообще о каком RAID'е говорим? Об аппаратном (RAID SCSI контроллер) или программном (RAID на уровне ОС)? Я, например, имею ввиду аппаратный.

> Если это происходит часто, то надо что-то делать.
> Как правило это может произойти раз за несколько лет.
> От перенапряжения питающей сети диски не вылетают. Минимум
> предохранитель, максимум БП.
> На то РАИД и ставится, чтоб при вылете диска все ставалось
> в рабочем состоянии.
> Не забывать про резервное копирование.

Еще как вылетают. Я видел. :)))
Минимум, может быть и предохранитель, а вот максимум: источник БП APC Smart-UPS 1500VA, 2xSCSI HDD LowProfile 40Gb, ECC RAM и что-то там еще...

> В хороших ИБП уже стоят фильтры, защиты и даже АВР.

Я бы не был так категоричен в подобных утверждениях. То, что заявлено не всегда соответствует тому, что на самом деле.
"Кажется" и "соответствует действительности" - разные вещи... 18.01.05 16:18  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.01.05 16:35  Количество правок: 5
<"чистая" ссылка>
> Если в массиве будет 15 дисков, это не значит, что скорость
> записи с чередованием в RAID0 увеличиться в 15 раз по
> сравнению с записью на 1 диск. Слишком много ограничивающих
> факторов начиная с пропускная способность SCSI шины и
> реализацией SCSI контроллера, заканчивая правилами
> взаимодействия между ОС и контроллером.

"Кажется" и "соответствует действительности" - разные вещи. Суммарная скорость записи 15 современных дисков превысит скорость передачи по интерфейсу, а я оговаривался "при условии, что скорость передачи по интерфейсу выше скорости записи на поверхность". В случае огромного количества дисков скорость массивов любых уровней будет равна скорости интерфейса. Для 15 дисков обычно берут многоканальные РАИД-контроллеры. Если дисков два, три, четыре, а интерфейс 160 или 320, то перечитайте все то, что я написал в предыдущем топике.

> RAID5 использует чередование, поэтому чтение с 10-ти дисков
> будет примерно в десять раз быстрее (несколько сотен
> (тысяч) мегабайт в секунду).
> Скажем, с массива из 9-ти дисков читается информация в
> объеме 4Мб. Запись производилась с чередованием на 8
> дисков, а блок контрольной суммы лег на 9-ый диск, но один
> блок данных оказался на вышедшем из строя диске. Скорость
> чтения и получения данных контроллером будет примерно равна
> скорости чтения одного сектора, т.е. максимально быстро.
> Если RAID имеет прошивку/firmware (что обычно и бывает), а

Прошивчивость его тут не причем. Софт может наглухо лежать в ПЗУ или прошиваться в флэш или еще где угодно, но при отработки он ляжет в кэш со скоростью доступа не более одного процессорного такта.

> не аппаратно реализованый алгоритм вычисления данных по
> контрольной сумме, то вычисления 512Кб данных будут
> производиться со скоростью обычного, далеко не самого
> быстрого процессора. Все это время ОС будет ожидать ответа
> от SCSI контроллера.

Не будет. В ОС крутится куча процессов, ей будет чем заняться. Пока проц считает, параллельно могут происходить еще как минимум три важных процедуры: обмен между пластинами диска и его буфером, передача из буфера по интерфейсу, обмен между памятью контроллера и ОЗУ. У контроллера в очереди может стоять много запросов на ввод/вывод, выполнять он их может в любом порядке.

Процы на современных РАИД-контроллерах стоят современные окологигагерцовые РИСКи. То есть за наносекунду он обработает сотню байт (100 Гб/сек.). Все упрется в скорость памяти (а она, на РС3200 - 3.2 Гб/сек на один канал). Для сравнения скорость интерфейса 0.32 Гб/сек. максимум, а дисков на порядок меньше.

> Иногда, при использовании не самых свежих RAID контроллеров
> и при пиковой нагрузке на массив в event log'е можно
> увидеть сообщение, типа - устройство (имеется ввиду
> контроллер RAID'а) не ответило за установленный промежуток
> времени.

Это можно увидеть и не на РАИДе, а на обычном диске.

> :) Мы вообще о каком RAID'е говорим? Об аппаратном (RAID
> SCSI контроллер) или программном (RAID на уровне ОС)? Я,
> например, имею ввиду аппаратный.

Естестно. Штатный проц будет сильно тормозить, причин туева хуча. Причем их и аппаратных куча бывает (АРО, например, не имел на борту интерфейса/шины).

> Еще как вылетают. Я видел. :)))
> Минимум, может быть и предохранитель, а вот максимум:
> источник БП APC Smart-UPS 1500VA, 2xSCSI HDD LowProfile
> 40Gb, ECC RAM и что-то там еще...

Не знаю что и сказать - "повезло" или "не повезло".

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

По определению. Можно ли назвать ИБП хорошим, если у него ничего нет, не смотря на то, что все заявлено. Наличие всего не всегда делает ИБП хорошим. Если ИБП в нужный момент не спас, а Вы на него так надеялись, думая, что он хороший, значит Вы просто заблуждались и этот ИБП не будем называть хорошим.
Я же не опровергаю... Truth any there... 18.01.05 17:12  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> "Кажется" и "соответствует действительности" - разные вещи.
> Суммарная скорость записи 15 современных дисков превысит
> скорость передачи по интерфейсу, а я оговаривался "при
> условии, что скорость передачи по интерфейсу выше скорости
> записи на поверхность". В случае огромного количества
> дисков скорость массивов любых уровней будет равна скорости
> интерфейса. Для 15 дисков обычно берут многоканальные
> РАИД-контроллеры. Если дисков два, три, четыре, а интерфейс
> 160 или 320, то перечитайте все то, что я написал в
> предыдущем топике.

На этом и остановимся...

> Прошивчивость его тут не причем. Софт может наглухо лежать
> в ПЗУ или прошиваться в флэш или еще где угодно, но при
> отработки он ляжет в кэш со скоростью доступа не более
> одного процессорного такта.

Возможно, но аппаратная реализация была бы существенно быстрее, против гибкости замены алгоритма.

> Не будет. В ОС крутится куча процессов, ей будет чем
> заняться. Пока проц считает, параллельно могут происходить
> еще как минимум три важных процедуры: обмен между
> пластинами диска и его буфером, передача из буфера по
> интерфейсу, обмен между памятью контроллера и ОЗУ. У
> контроллера в очереди может стоять много запросов на
> ввод/вывод, выполнять он их может в любом порядке.

Конечно не будет, у нас же не MS DOS на серверах крутится... Я утрировал.
Не думаю, что процессор RAID контроллера использует многопоточность - это не совсем эффективно для контроллера, да и наверное ни к чему. Хотя как знать...

> Процы на современных РАИД-контроллерах стоят современные
> окологигагерцовые РИСКи. То есть за наносекунду он
> обработает сотню байт (100 Гб/сек.). Все упрется в скорость
> памяти (а она, на РС3200 - 3.2 Гб/сек на один канал). Для
> сравнения скорость интерфейса 0.32 Гб/сек. максимум, а
> дисков на порядок меньше.

Ты считаешь только скорость работы с памятью или все же скорость выполнения алгоритма вычисления над определенным блоком данных?

> Это можно увидеть и не на РАИДе, а на обычном диске.

Можно.

> Естестно. Штатный проц будет сильно тормозить, причин туева
> хуча. Причем их и аппаратных куча бывает (АРО, например, не
> имел на борту интерфейса/шины).

Просто меня смущает твое утверждение, что RAID5 по чтению/записи быстрее чем RAID1.
Никак не могу в это поверить. :)

> Не знаю что и сказать - "повезло" или "не повезло".

Что тут говорить... И так все ясно. Хорошо, что это случилось не у меня.

> По определению. Можно ли назвать ИБП хорошим, если у него
> ничего нет, не смотря на то, что все заявлено. Наличие
> всего не всегда делает ИБП хорошим. Если ИБП в нужный
> момент не спас, а Вы на него так надеялись, думая, что он
> хороший, значит Вы просто заблуждались и этот ИБП не будем
> называть хорошим.

Ну незнаю... APC вроде бы качественный брэнд...
А какие сейчас упсы лучшие? Ну или нормальные?

З.Ы. Может не будем на Вы? ;)
Думаю, мы пришли к некоторому консенсусу. Как сам думаешь?
Угу, но у меня фантазии не хватает оценить затраты на... 18.01.05 19:07  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.01.05 19:11  Количество правок: 3
<"чистая" ссылка>
> Возможно, но аппаратная реализация была бы существенно
> быстрее, против гибкости замены алгоритма.

Угу, но у меня фантазии не хватает оценить затраты на разработку/производство даже 512 байтного аппарата, а стрип в РАИДах достигает нескольких килобайт. Естественно для 0 и 1 хитрой железяки не надо, рассмотрим 5 уровень, где код коррекции считать надо или восстанавливать инфу по нему. Этак получается секторок с каждого диска надо в четырехкилобитные регистры закатать. Потом все просто - обработка за несколько тактов, подаются сигналы на четырехкилобитный исключающийИЛИ элемент, далее на хитрую матрицу из восьми тысяч элементов И-НЕ. Представляем шинки на плате по четыре тысячи в ряд или микруху в восемью тысячами ножек!!!
Быстрее - наверняка, но зачем все это делать за одну наносекунду? Может и 16 выше крыши хватит. Не только гибкость, что приятно, но и функциональность, экономическая выгодность.

> Не думаю, что процессор RAID контроллера использует
> многопоточность - это не совсем эффективно для контроллера,
> да и наверное ни к чему. Хотя как знать...

Только старые СимбосЛоджики-810 и АХА-416 могли очереди не отрабатывать - зачем какому-нибудь сканеру или стримеру многопоточность. В современных - от 16 и более тэгов поддерживается, за что скайзя и выигрывает перед ИДЕ. В контроллере за несколько сотен долларов (цена приличного настольного писюка) вполне вероятно многопоточность есть. В ИДЕшниках, которые только уровни 0 и 1 поддерживают наверняка нет.

> Ты считаешь только скорость работы с памятью или все же
> скорость выполнения алгоритма вычисления над определенным
> блоком данных?

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

Что-то мы все о скорости, как будто РАИД контроллеры ставят для этого. Расшифруем мнемонику и вспомним о том, что эти контроллеры ставят в серваки для повышения отказоустойчивости дисковой системы, а скорость - это побочный приятный эффект.

> Просто меня смущает твое утверждение, что RAID5 по
> чтению/записи быстрее чем RAID1.
> Никак не могу в это поверить. :)

5 это фактически 0 при количистве дисков стремящемся к бесконечности, но с избыточностью. Мало того, по чтению 1 будет равен 5, поскольку все диски будут нагружены чтением равномерно (к стати 1 будет заведомо быстрее 4). По записи 1 будет тормознее, поскольку на единицу записи полезной информации на диски будет писаться больше. И дело тут не в расчетах кодов восстановления а в факте их записи.

> Ну незнаю... APC вроде бы качественный брэнд...
> А какие сейчас упсы лучшие? Ну или нормальные?

АРС - классные, если не брак и не подделка. Еще уважаю РСМ.
Из двух классов ОНЛАЙН и ОФЛАЙН, первые действительно защищают, вторые можно использовать на случай провала напряжения чтоб без света на сидеть :).
ИБП двойного преобразования - идеал.
Вполне достаточно наличия фильтра ВЧ, наличия разрядника (защита от резкого перенапряжения) и наличия AVR (Automatic Voltage Regulator).

> З.Ы. Может не будем на Вы? ;)

Согласен, уже давно пора.

> Думаю, мы пришли к некоторому консенсусу. Как сам думаешь?

Лады, буду новый сервак ставить - все на РАИД5 и оставлю 1/5 емкости на другие виды для экспериментов. На основном массиве два раздела - небольшой для системы, все остальное - под рабочую инфу.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach