Jeff Garzik, разработчик Linux ядра занимающийся SATA (http://linux-ata.org/) подсистемой (libATA), опубликовал интересный документ "Linux: Why software RAID? (http://linux.yyz.us/why-software-raid.html)", в котором подытожил основные достоинства реализации программного RAID в Linux, по сравнению с аппаратными решениями.URL: http://linux.yyz.us/why-software-raid.html
Новость: http://www.opennet.me/opennews/art.shtml?num=8196
Преимущества WinModem'ов над нормальными на DSP.
Преимущества программных контроллеров Video над видеокартами.
Преимущества Realtek Ethernet контроллеров над полноценными.
Преимущества ПК над Мэйнфреймами и РК-86 над ПК.
И т.д. .Куда катится мир...
>Преимущества WinModem'ов над нормальными на DSP.Чем отличается прям./обр. преобразования Фурье на DSP от него же на CPU?
> Преимущества программных контроллеров Video над видеокартами.
Чем отличается декодирование на отдельной железке, от более мощной ( около 3GHz)?
> Преимущества Realtek Ethernet контроллеров над полноценными.
Это не анология.
> Преимущества ПК над Мэйнфреймами и РК-86 над ПК.
То же не сравнение. Что больше, соответственно производительней, 1024 процессора или 1?
Ты не понял на что я намекал. Преимущества выделенных самостоятельных контроллеров это то, что при правильном конструировании у них есть вычислительных ресурсов ровно столько сколько надо для выполнения задачи и эти ресурсы в их монопольном использовании. Не нужно боятся всяких там прерываний от мыши или очень жадной программы. А ещё специализированные аппаратные и программные средства: пятидолларовая микросхема делает то, что делает CPU стоимостью в $100. Специализированное ПО - ПО с обеспечением Real Time функций.
А угадай на чём больше денег можно заработать.
На одной PCI-X 64bit плате с 256-ми битным ЦАП/АЦП и частотой дискр. в 110КНz или
на 500 шт. C-Media 8738 :)
to Abel:
Видно человек не понимает сути вопроса
и начинает писать вообще не потеме
Как следует из текста новости, это размышления разработчика libATA, а следовательно, речь идет о SATA-недорейдах, и преимуществах полностью софтового решения над ними...Прям LOR-синдром какой-то...
Высокопроизводительное софтовое решение дрючит железные (SCSI, FC...) по цене немилосердно (250--300Mb/s sustained). Это сейчас факт. По надёжности -- не дрючит.> Прям LOR-синдром какой-то...
Ну так и не спорьте, не спорьте. :)
>Высокопроизводительное софтовое решение?А если сервер НАГРУЖЕН?
Понятно, что софтовый RAID лучше никакого.
Но когда тачка перестает отвечать на запросы - все просто бегут с парой косых в магазин за конроллером и SCSI винтами.
И слово "не-SCSI винчестер" забывают. Только вздрагивают и щурятся на "SATA", "SATA RAID" и "софтовое решение" :)
>
>И слово "не-SCSI винчестер" забывают. Только вздрагивают и щурятся на "SATA", "SATA
>RAID" и "софтовое решение" :)не порите ерунды. архитектура SCSI не очень уж и производительна, видали как работает полностью загруженный винтами контроллер? Недаром разработали SAS.
И врядли бы HP/Intel/IBM/Sun/Fuji-Sim и почие стали бы выпускать серваки/хранилища на SATA, ежели бы оно было так убого.
> Чем отличается прям./обр. преобразования Фурье на DSP от него же на CPU?
Результат тот же. Но DSP выполнит быстрее, при меньшей частоте, за счет гарвардской архитектуры, и наличия нескольких умножителей. Например TMS3206416T
выполняет 4 MAC - команды за такт - умножение с накоплением, а обычный ЦПОС одну от силы и то не всегда, как на конвейер ляжет :)
>> Чем отличается прям./обр. преобразования Фурье на DSP от него же на CPU?
>Результат тот же. Но DSP выполнит быстрее, при меньшей частоте, за счет
>гарвардской архитектуры, и наличия нескольких умножителей. Например TMS3206416T
>выполняет 4 MAC - команды за такт - умножение с накоплением, а
>обычный ЦПОС одну от силы и то не всегда, как на
>конвейер ляжет :)
2 года - 2 шт. 3ware 9500 8M - SATA RAID 5 + 1 Hot Spare, Seagate 7200.8 200 gb, батарейки нет, writeback, 25 раз минимум не штатных выключений, хоть бы хны. - плевать я хотел на всякие SCSI
тем более что есть SAS
3ware - это хардверный контроллер, соответственно с него и спрос, что ничего не упало. А scsi покупают тогда, когда используемые приложения до них "дорастают" -- какие цели ставишь, такое железо и покупаешь.
>3ware - это хардверный контроллер, соответственно с него и спрос, что ничего
>не упало. А scsi покупают тогда, когда используемые приложения до
>них "дорастают" -- какие цели ставишь, такое железо и покупаешь.
Ну я к посту о непригодности SATA RAID
Всё уже винты SCSI пора менять повсеместно на SAS винты,
например на вот таких "зверьков" http://www.seagate.com/support/disc/specs/sas/st3146854ss.html
мля не туда ткнул, даже непрочитал что квотировал 8)
То есть не обычный ЦПОС, а обычный процессор общего назначения :)
Да уж, куда мир катится.
Однако, как сказал Tester, до использования FC или SAS (в будущем) нужно дорасти.
Когда нет денег на мощное защищенное решение - Вам поможет SoftRAID.
P.S.:
А реплики типа "Да я!", "Да у меня" как правило, не содержат в себе полезной информации и люди, которые их бросают в своей жизни дальше одного "сервера" на платформе Intel ничего не видели, к сожалению.
Кажись камень в мой огород.
Сказёвых, софтовых, саташных раидов конфигурил немерянно каждых
fc и sas - мало, но были.Eсли sata-raid контроллер сделан правильно, как например железки
от 3ware, то скази становится очень невыгодным вложением.Самый же дибилизм - какой нибудь олух, свято верящий в превосходство SCSI решений, покупает за дурные деньги raid-контроллер на 8 SCSI-винтов 34Gb 10000rpm, для того что бы крутить на нём 1С на 5 клиентов. При этом ещё конфигурит его со страйпом 4kb, а затем сокрушается - "SCSI, а почему так медленно".
>Кажись камень в мой огород.
Да эт не камень был, скорее хмыканье. Мне много не надо (ну вот напрыгало 146Mb/s сырых попугаев -- ну и ладно), в отличие от коллеги , который в люстру засовывает куда более нужные сотни мегабайт в секунду. Так вот он последнее время был озадачен невыгодностью "железа" (SATA в т.ч.), если вопрос в пропускной способности более, чем в надёжности, при фиксированном бюджете. Относительно линуксового софтрейда.>Eсли sata-raid контроллер сделан правильно, как например железки
>от 3ware, то скази становится очень невыгодным вложением.
Насколько помню, всё-таки потолки параллельной нагрузки относительно количества шпинделей, которые ещё держатся, разные. Возможно, устарело, возможно, не про рапторы (хотя они от сказей толком не отличаются и ценой).>Самый же дибилизм
Ага, ещё терминаторы при этом не надо вешать. :]Недавно делали тут скромный тазик на замену старому ftp.linux.kiev.ua. Вышел IDE+SATA+SCSI -- основной сторадж на SATA SoftRAID5 (на варей как-то недоскинулись, 2420SA в округе не нашлось), плюс пока оставлены старые PATA (наверное, в зеркала и под бэкапы пойдут), плюс загрузка с пролежавшей на полке восемнадцатки. Так там самая большая (а также высокая и довольно толстая) проблема -- это DAC960PG: за диском не успевает, плюс умудрился накануне отпуска выплюнуть его (единственного за отсутствием собственно нагрузки) ночью в офлайн. Тоже пришлось похихикать над своим "а корешки мы посадим на сказю, чтоб стояло и не трогать"... ну мож найдётся что простое и дубовое, пока Alt-R>Tools>Online.
Любителей же 1С на неохлаждаемых дополнительно 10K SCSI -- ага, с четвёртого курса насмотрелся.
>Любителей же 1С на неохлаждаемых дополнительно 10K SCSI -- ага, с четвёртого
>курса насмотрелся.Ну я, допустим, любитель 1С на двух неохлаждаемых 10К maxtor'ах (которые quantum) в raid1 на adaptek'e (2720S, если мне не изменяет память) (в работе с октябре 2002 года) и чё?
>>Любителей же 1С на неохлаждаемых дополнительно 10K SCSI -- ага, с четвёртого
>>курса насмотрелся.
>Ну я, допустим, любитель 1С на двух неохлаждаемых 10К maxtor'ах (которые quantum)
>в raid1 на adaptek'e (2720S, если мне не изменяет память)
>(в работе с октябре 2002 года) и чё?
Ну ждите своего петуха -- зеркала порой тоже рассыпаются вдребезги. Я бы с 2000, наверное, дождался уже (там и с таким подходом -- хотя проще поставить хоть какой-то корпусной пропеллер напротив, чем ждать, пока лягут, по иронии партии, оба).У них же ресурс от температуры зависит что-то вроде обратно-экспоненциально -- припоминается, что в более-менее обычном интервале температур (20--50C) на десять градусов порядка полутора-двухкратная разница.
>горячие дискибред
конкретно, те maxtor'ы на ощупь теплые под нагрузкой (градусов 35 от силы)
читы десятитысячные после летней жары - 47 макс по внутреннему логу (на ощупь горячие, но те же maxtor'ы идешные горячее), сейчас теплые (37-39 градусов)
поэтому саркастическое замечание предыдущего оратора про неохлаждаемые диски под 1С - гон (именно касательно современных десятитысячников)
>Ну ждите своего петуха
барракуды 8 гиговые с девяностых годов крутятся - так руку держать было невозможно (вот к ним как раз и приделалось принудительное охлаждение), хрен знает, сколько они так крутились без оного
>>горячие диски
>бред
Бред -- это думать, что "так будет всегда".>конкретно, те maxtor'ы на ощупь теплые под нагрузкой (градусов 35 от силы)
Очень за Вас с ними рад. Там были WD, что ли.>>Ну ждите своего петуха
>барракуды 8 гиговые с девяностых годов крутятся - так руку держать было
>невозможно (вот к ним как раз и приделалось принудительное охлаждение), хрен
>знает, сколько они так крутились без оного
Меня вполне устроит, если каждый останется при своём мнении. Можете и дорогу почаще перебегать, хрен знает, сколько народу каждую минуту бегает и ничего.
>Бред -- это думать, что "так будет всегда".
Не приписывайте мне то, что я не говорил и не думаю, свою позицию я обосновал достаточно четко и вразумительно>>Там были WD, что ли
без комментариев>>Меня вполне устроит, если каждый останется при своём мнении.
вот и договорились>>Можете и дорогу почаще перебегать
отвечайте за себя
>Eсли sata-raid контроллер сделан правильно, как например железки
>от 3ware, то скази становится очень невыгодным вложением.
на правильности 3ware я бы не стал настаивать. есть в использовании 4 контроллера 8000 и 9000 серий, возникали проблемы: при удалении одного юнита контроллер удалял все юниты; один массив raid5 умудрялся делить на два юнита в inoperable-state после перезагрузки; опять же после нештатной перезагрузки терял диски в массиве; Все проблемы признаны 3ware как актуальные, на них оформлены багреборты. Поэтому 3ware - это совсем не идеал (особенно если учесть довольно низкий уровень саппорта (было общение как голосом, так и и долгая переписка мылом)). А потерянный массив, как думаете что спасло? софтовый raid: склеили, перелили инфу, поехали дальше.
конечно, потеря производительности сервера при softraid неизбежна, однако седины на голове будет явно поменьше
>на правильности 3ware я бы не стал настаивать...
Ну я пока все что можно не проверил в эксплуатацию железки не сдавал.
А за месяц проверил всё диски и кабели на ходу выдёргивал и питание вырубал во время rebuild, ставил пару заведомо испорченных дисков и т.д. и т.п. Несколько проблемм выявил, с саппортом пообщался (мылом) и вроде нормально помогали, новой прошивкой всё решалось.
Потом ещё опытная эксплуатация в течении 2 месяцев.
И только потом пуск в работу.
Если кто скаже долго - изначально до приобретения ставлю сроки, и лучше 3 месяца потратить на тестирование, чем в один прекрасный день хвататься за голову руками и искать спасения в софт-raid.Правда я всё равно страхуюсь, потому у меня не один дорогой сервер со SCSI-raid, а два по дешевле идентичных сервера SATA-RAID один из которых в одностороннем порядке синхронизируется с первым с суточным периодом накопления измениний.
>>на правильности 3ware я бы не стал настаивать...
>Ну я пока все что можно не проверил в эксплуатацию железки не
>сдавал.
>А за месяц проверил всё...
>Потом ещё опытная эксплуатация в течении 2 месяцев.
в моем случае не было только опытной эксплуатации - нужно было сдавать решение. а тестов было около месяца. тестились как штатные операции, так и варианты на грани абсурда, однако теоретически возможные в реальной работе (например, выведение одного диска из массива raid-5, через некоторое время вывод второго, возврат обоих дисков на свои физические места и автоматический(!) выход контроллера из inoperable state путем возврата с 50% вероятностью первого(!) диска. контроллер признает массив рабочим, что есть в корне неверно, ибо целостность данных теряется)
и все это работает и все славно. если находились непонятки - это уточнялось у саппорта, делались багрепорты. но когда в один прекрасный помомент при удалении одного юнита (spare-disk. могу же я его удалить, не так ли?) в штатной ситуцации, контроллер решил снести все массивы (причем примонтированные, что софт 3ware якобы отслеживает и не позволяет выполнять) - вот тут стало не по себе. далеко не все проблемы проявляются сразу и месяц-два-десять тут не срок, поскольку, как выяснилось, даже штатная операция при определенном стечении обстоятельств приводит к проблемамдаже сам 3ware признает проблему, например, когда после неоднократной нештатной перезагрузки контроллер становится неуправляемым и невидимым на шине. да, они пишут, что вероятность этой проблемы ооочень низка. но она-то есть! и что меня в ярость вводит, это то, что подобная проблема не исправляется и лишь помещается как известный баг в аннотациях к новым версиям прошив на протяжении нескольких выпусков обновлений! а если у меня система на их контроллере живет (врятли когда-то на такие вещи пойду :) )? сами ж написали: мы классные, мы дарим вам новую фичу! зайти на машину, чтобы ее ребутнуть не получится. не знаю, меня 3ware разочаровал очень сильно. особенно соотношение цена/качество продукта/уровень саппорта и его скорость (однажды вообще робот прислал письмо: ответим через 2 недели. какие 2 недели? а как же "решения для бесперебойной работы"?).
>>на правильности 3ware я бы не стал настаивать...
>...меня 3ware разочаровал
>очень сильно. особенно соотношение цена/качество продукта/уровень саппорта и его скорость...
Ну SCSI-железки той же Adaptec или Intel "сюрпрайзами" тоже нет-нет "радуют".
Я например, всё ещё недобрым словом вспоминаю интеловские STL2 с ихним SCSI vs net and ALL конфликтом по прерыванию, и ведь тоже писал, мусолил и если бы только я один, просто огромное кол-во народу, нет же не пофиксили, хотя это с успехом могло решиться новой прошивкой.
Все зависит от поставленных задач и количества денег. У софтового рейда один плюс: дешево. Для серьезных задач его использовать просто глупо.
Рейд разный бывает. Если рейд-5 - лучше аппаратный, если 1+0 - пофиг, т. к. проц по-любому практически не жрет (а гемора с дровами и т. п. меньше). Хотя аппарат за счет набортного кеша небольшой выигрыш может дать.
У софтового рейда есть неоспоримый плюс
Заключается он в конфигурабельности и предсказуемости
Я точно знаю, что могу спокойно вытащить винт из raid1, вставить на другой тачке с другим контроллером и все будет работать, я точно знаю что не буду ждать час-два пока биос не сребилдит рейд и даст загрузить ОС (многие недо- и дешевые рейды этим грешат)
То что Intel называет Matrix RAID - на софте делается на шару - два партишна в raid1, остальные в raid0По производительности и загрузке cpu - тут на 90% зависит от качества драйверов, и не только с рейдами а и другим железом
Что дешевле - поднять производительность проца на те 5% которые забирают операции с рейдом (то есть нивелировать дополнительную загрузку CPU) или купить за 5 сотен хардварный рейд который имеет свой процессор (то есть не нагружает основной CPU) ?
>Что дешевле - поднять производительность проца на те 5% которые забирают операции
>с рейдом (то есть нивелировать дополнительную загрузку CPU) или купить за
>5 сотен хардварный рейд который имеет свой процессор (то есть не
>нагружает основной CPU) ?
А здесь чуть сложней -- если молотить совсем есть чего, то не стоит забывать про кэш (который лишним потоком данных будет вымываться) и cs. Да и шиной оно торгует -- md не умеет пользоваться зачатками оптимизации во всяких Promise SX (AFAIR), которые имеют и чуточку своей памяти, чтоб на зеркало дважды то же не гонять.Бишь ответ неочевиден, хотя самому так тоже зачастую проще. У железных ещё другая неприятность есть -- клинить I/O, пока сбрасывается кэш (на DPT RAID5 ой как чувствуется).
Очень интересный диалог, только не понял в чем спор,
мое ИМХО таково: если человек хочет снизить стоимость владения, то тут все средства хороши и софтверный RAID и SATA диски, если нужна производительность и надежность, то только SCSI,SAS,FC и аппаратный RAID, по-моему это для всех очевидно. Для высоко нагруженных систем на мой взгляд ставить SATA, за исключением Raptor не целесообразно, в силу того, что десктоповые диски на такие жесткие режимы не расчитаны. И эти вопросы регулярно обсуждаются на конфах по серверному оборудованию с производителями хардов. Что же касается софтверного райда, если проц почти все время курит (Idle) то не вопрос, его нужно чем-то занять, хотя на мой взгляд в любом случае лучше пользовать отдельный проц для расчетов дисковой подсистемы, например Zero channel RAID, он значительно дешевле, но работает в любом случае быстрее чем софтверный RAID и он значительно дешевле чем полноценный с каналами.
Заметки из практики
-------------------
Software Raid при работе с БД не медленее Hardware Raid при одинаковом количестве шпинделей. Проверялось в следующих конфигурациях:1. Hardware RAID
10 шпинделей SCSI
Intel Accelerate RAID 1+0 и RAID 5
2 канала SCSI
2. Software Raid на Windows 2003
10 шпинделей SCSI
Intel Accelerate 2 канала по 5 дисков
RAID 1+0 и RAID 5
3. Software Raid на Linux 2.6
10 шпинделей SCSI
Intel Accelerate 2 канала по 5 дисков
RAID 1+0 и RAID 5Сквозная оптимизация диск/RAID/файловая/СУБД (размер страйпа/файлового кластера/блока в СУБД). Оптимизация по режимам работы RAID.
Быстрее всех на RAID 1+0 - SW на Win2003
Медленнее - HW RAID
Разброс лучший/худший - 3%
Максимальная утилизация CPU (2xXeon 2.8)- на Win 2003 (4.5%)Быстрее всех на RAID 5 - HW Raid
Медленнее - SW RAID на Win2003
Разброс лучший/худший - 5%
Максимальная утилизация CPU (2xXeon 2.8) - на Win 2003 (7%)Сравнение SCSI vs SATA в SW RAID
--------------------------------
Скорости вращения одинаковые. Диски одного производителя.1. Встроеные диски - 4 шт.
SCSI320 - MegaRaid и Intel Accelerate (двухканальные)
SATA - Promise
RAID 10 скорость (IOPS):
MR - 100%
IA - 102%
SATA - 102%
RAID 5 скорость (IOPS):
MR - 100%
IA - 105%
SATA - 101%2. Внешние массивы (SCSI/SCSI и SATA/SCSI) - 8 дисков на одном канале
SCSI320 - MegaRaid и Intel Accelerate (двухканальные)
SATA - Promise
RAID 10 скорость (IOPS):
MR - 100%
IA - 101%
SATA - 99%
RAID 5 скорость (IOPS):
MR - 100%
IA - 102%
SATA - 98%
Проверенные преимущества SW RAID на Linux
-----------------------------------------
1. Почти не зависит от аппаратуры (mda версии 2)
Попробуйте перенести диски с hw raid на другой контроллер/массив.
В hw часто наблюдается зависимость от конкретных прошивок (совместимость) на дисках и т.п.
2. Никогда не наблюдается резкой деградации при отказе диска (в hw решениях есть)
3. Большая гибкость конфигурации
Например, не требует идентичной конфигурации дисков, любые варианты разбиения дисков, возможность произвольного комбинирования уровней RAID и т.п.
4. Полный контроль над конфигурацией и процедурами обслуживания
5. Почти никогда нет значительной деградации при востановлении отказавшего диска
6. ЦенаНедостатки SW RAID на Linux
---------------------------
1. Недостаточная масштабируемость
больше 12-16 дисков или 10-15 RAID практически нереально реализовать на одной системе.
2. С увеличением числа дисков и RAID растет использование CPU
3. Сложноваты процедуры обнаружения отказов и восстановления (по-умолчанию)
>Заметки из практики
>-------------------
>Software Raid при работе с БД не медленее Hardware Raid при одинаковом
>количестве шпинделей. Проверялось в следующих конфигурациях:
>
>1. Hardware RAID
> 10 шпинделей SCSI
> Intel Accelerate RAID 1+0 и RAID 5
> 2 канала SCSI
>2. Software Raid на Windows 2003
> 10 шпинделей SCSI
> Intel Accelerate 2 канала по 5 дисков
> RAID 1+0 и RAID 5
>3. Software Raid на Linux 2.6
> 10 шпинделей SCSI
> Intel Accelerate 2 канала по 5 дисков
> RAID 1+0 и RAID 5
>
>Сквозная оптимизация диск/RAID/файловая/СУБД (размер страйпа/файлового кластера/блока в СУБД). Оптимизация по режимам работы
>RAID.
>
>Быстрее всех на RAID 1+0 - SW на Win2003
>Медленнее - HW RAID
>Разброс лучший/худший - 3%
>Максимальная утилизация CPU (2xXeon 2.8)- на Win 2003 (4.5%)
>
>Быстрее всех на RAID 5 - HW Raid
>Медленнее - SW RAID на Win2003
>Разброс лучший/худший - 5%
>Максимальная утилизация CPU (2xXeon 2.8) - на Win 2003 (7%)
>
>Сравнение SCSI vs SATA в SW RAID
>--------------------------------
>Скорости вращения одинаковые. Диски одного производителя.
>
>1. Встроеные диски - 4 шт.
>SCSI320 - MegaRaid и Intel Accelerate (двухканальные)
>SATA - Promise
>RAID 10 скорость (IOPS):
> MR - 100%
> IA - 102%
> SATA - 102%
>RAID 5 скорость (IOPS):
> MR - 100%
> IA - 105%
> SATA - 101%
>
>2. Внешние массивы (SCSI/SCSI и SATA/SCSI) - 8 дисков на одном канале
>
>
>SCSI320 - MegaRaid и Intel Accelerate (двухканальные)
>SATA - Promise
>RAID 10 скорость (IOPS):
> MR - 100%
> IA - 101%
> SATA - 99%
>RAID 5 скорость (IOPS):
> MR - 100%
> IA - 102%
> SATA - 98%
>
>
>Проверенные преимущества SW RAID на Linux
>-----------------------------------------
>1. Почти не зависит от аппаратуры (mda версии 2)
> Попробуйте перенести диски с hw raid на другой контроллер/массив.
> В hw часто наблюдается зависимость от конкретных прошивок (совместимость) на
>дисках и т.п.
>2. Никогда не наблюдается резкой деградации при отказе диска (в hw решениях
>есть)
>3. Большая гибкость конфигурации
> Например, не требует идентичной конфигурации дисков, любые варианты разбиения дисков, возможность
>произвольного комбинирования уровней RAID и т.п.
>4. Полный контроль над конфигурацией и процедурами обслуживания
>5. Почти никогда нет значительной деградации при востановлении отказавшего диска
>6. Цена
>
>Недостатки SW RAID на Linux
>---------------------------
>1. Недостаточная масштабируемость
> больше 12-16 дисков или 10-15 RAID практически нереально реализовать на
>одной системе.
>2. С увеличением числа дисков и RAID растет использование CPU
>3. Сложноваты процедуры обнаружения отказов и восстановления (по-умолчанию)Маловато конкретной технической информации (что за диски использовались, какие кеши на контроллерах) и все-таки слабо верится что SATA=SCSI по скорости. Потом есть вопросы по скорости REBUILD'а массивов при отказе, чем все это мерилось и все такое. Что касается идентичности дисков многие аппаратные райды тоже не требуют, главное чтобы не меньше, а там размечай луны как угодно и все дела, насчет полного контроля, большой вопрос, не очень понятно о чем речь, в аппаратных райдах естесно он есть и куча талзов, которые этим все рулят. "Никогда не наблюдается резкой деградации при отказе диска " - я не сталкивался.
>Маловато конкретной технической информации (что за диски использовались, какие кеши на контроллерах)
>и все-таки слабо верится что SATA=SCSI по скорости. Потом есть вопросы
>по скорости REBUILD'а массивов при отказе, чем все это мерилось и
>все такое. Что касается идентичности дисков многие аппаратные райды тоже не
>требуют, главное чтобы не меньше, а там размечай луны как угодно
>и все дела, насчет полного контроля, большой вопрос, не очень понятно
>о чем речь, в аппаратных райдах естесно он есть и куча
>талзов, которые этим все рулят. "Никогда не наблюдается резкой деградации при
>отказе диска " - я не сталкивался.Скорости практически одинаковы для SATA и SCSI по многим причинам:
1. Физика одинакова (привод, блины и т.п.)
2. в SATA реализованы многие механизмы SCSI (очереди команд, буферизация записи, предвыборки и т.п.)
3. Скорость интерфейса для одиночного диска не лимитирует общую производительность.Более того, у SCSI - общая шина, которая потенциально может послужить "узким местом" при большом количестве дисков на шине.
Косвенным подтверждением, что SCSI не имеет преимуществ по скорости перед SATA может служить тот факт, что большинство производителей SATA и SCSI дисков не выпускают SATA в одной скорости вращения со SCSI, а только ниже.
Маркетинг и удержание рынка!!! Их родственников...
>>Маловато конкретной технической информации (что за диски использовались, какие кеши на контроллерах)
>>и все-таки слабо верится что SATA=SCSI по скорости. Потом есть вопросы
>>по скорости REBUILD'а массивов при отказе, чем все это мерилось и
>>все такое. Что касается идентичности дисков многие аппаратные райды тоже не
>>требуют, главное чтобы не меньше, а там размечай луны как угодно
>>и все дела, насчет полного контроля, большой вопрос, не очень понятно
>>о чем речь, в аппаратных райдах естесно он есть и куча
>>талзов, которые этим все рулят. "Никогда не наблюдается резкой деградации при
>>отказе диска " - я не сталкивался.
>
>Скорости практически одинаковы для SATA и SCSI по многим причинам:
>1. Физика одинакова (привод, блины и т.п.)
>2. в SATA реализованы многие механизмы SCSI (очереди команд, буферизация записи, предвыборки
>и т.п.)
>3. Скорость интерфейса для одиночного диска не лимитирует общую производительность.
>
>Более того, у SCSI - общая шина, которая потенциально может послужить "узким
>местом" при большом количестве дисков на шине.
>
>Косвенным подтверждением, что SCSI не имеет преимуществ по скорости перед SATA может
>служить тот факт, что большинство производителей SATA и SCSI дисков не
>выпускают SATA в одной скорости вращения со SCSI, а только ниже.
>
>
>Маркетинг и удержание рынка!!! Их родственников...Ниче подобного, физика абсолютно разная 100% (вскройте и посмотрите)!!! В силу этого скорости абсолютно разные, Вы видели SATA диск, который на 15400 rpm вращается? и это не связано с тем, что производители просто не хотят, все дело как раз в исполнении носителя, блина и всего остального. При поддержке до 15 устройств на канал использование 5 на канал шину шагрузить не смогут тоже 100% проверено. И при подключении 15 устройств потерь в скорости практически нет. Так что с аргументами все равно слабовато. А про то, из чего сделаны SATA SCSI можно поговорить с производителями, особенно хорошо пытать на эту тему инженеров компании Seagate, по себе знаю, так что удачи.