The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Почему на нагруженных серверах лучше использовать SCSI диски, а не IDE.
1. Качество исполнения, запас прочности и надежность накопителей со SCSI
интерфейсом как правило выше, чем у IDE.

2. Два подключенных к одному каналу контроллера IDE накопителя, не могут
одновременно передавать данные по шине.

3. SCSI показывают значительно лучшую производительность в загруженной
многозадачной среде, при обилии разрозненных параллельных запросов за
счет более оптимального использования шины передачи данных. (конек IDE -
линейное чтение, сильная сторона SCSI - случайный доступ).

Поясняю: Специфика IDE такова, что запросы могут передаваться по одной
шине последовательно (одна труба передачи данных, однопоточный режим).
Допустим, если 100  процессов обращаются к данным на диске, запросы в
рамках одного канала контроллера будут обрабатываться один за другим, каждый
следующий после полного выполнения  предыдущего (связка: выдача
команды - получение данных).

При  использовании SCSI, допускается перекрытие запросов (организуется
очередь команд), ответы при этом  будут получены распараллеленно
(асинхронная передача), при этом устройство
заведомо зная подробности  по командам находящимся в очереди, производит
оптимизацию самостоятельно - минимизируя движение головок.
 
22.05.2004
Ключи: scsi, ide, disc, optimization / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Установка и синхронизация времени

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Anonymous (?), 08:31, 23/05/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    полностью согласен, но почему не говорите о минусах SCSI? цена например =)
     
     
  • 2.2, Single mode (?), 09:31, 31/05/2004 [^] [^^] [^^^] [ответить]  
  • +/
    а почему не говорят о альтернативе SATA ??
     

  • 1.3, Дмитрий Ю. Карпов (?), 18:16, 31/05/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Два подключенных к одному каналу контроллера IDE накопителя,
    > не могут  одновременно передавать данные по шине.

    А это никто не может, ибо это невозможно в принципе - каждое устройство занимает шину целиком. К тому же это малоактуально.

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

    Эту оптимизацию должна производить операционная система. А на разницу в цене IDE и SCSI я докуплю памяти, где эта оптимизация и будет производиться.

     
     
  • 2.4, uldus (ok), 20:52, 31/05/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Эту оптимизацию должна производить операционная система. А на разницу в цене IDE
    >и SCSI я докуплю памяти, где эта оптимизация и будет производиться.

    По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте, который будет дисковые операции планировать и расквантовывать ? :-)

     
     
  • 3.6, Дмитрий Ю. Карпов (?), 14:29, 01/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    > По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте,
    > который будет дисковые операции планировать и расквантовывать ? :-)

    Для начала давайте сравним объём кэша в операционке и в диске. Т.к. обычно объём оперативки >> кэша на брюхе у диска, то операционка в любом сучае должна оптимизировать свои запросы к диску. А оптимизировать на малой памяти то, что уже было оптимизировано на большой - это то же самое, что паковать плохим архиватором то, что уже упаковано хорошим.

     
     
  • 4.7, uldus (ok), 14:52, 01/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Для начала давайте сравним объём кэша в операционке и в диске.

    Зависимость вероятности попадания данных из кэша от объема кэша и параметров диска не линейная, есть оптимум, который и используют. Кэшировать то что уже считано и то что может быть будет считано разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.

    Другой контраргумент: ОС точно не знает где сейчас висит головка, а электроника диска знает.

     
     
  • 5.10, Дмитрий Ю. Карпов (?), 20:27, 02/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    uldus Расскажите, pls, как вычисляется этот оптимум Лично мне сей алгоритм нев... большой текст свёрнут, показать
     
  • 5.14, Константин (??), 10:01, 11/11/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Другой контраргумент: ОС точно не знает где сейчас висит головка, а >электроника диска знает.

    Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Seek - один в один оптимизация на уровне ОС. НО !!!!! работает только со СКАЗЯМИ !, т.к. у других ничего о _физическом_ положении головок сказать нельзя. Головки при этом перемещаются ЛИНЕЙНО по ВСЕЙ поверхности диска - что хорошо сказывается на ресурсе.

     

  • 1.5, AdVv (??), 12:17, 01/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если IDE винт на контроллере один, то по скорости он скизи почти не уступает. Про цену связки винт+контроллер умолчим :).
     
     
  • 2.8, bass (??), 17:33, 01/06/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Если IDE винт на контроллере один, то по скорости он скизи почти
    >не уступает. Про цену связки винт+контроллер умолчим :).

    По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что насмену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.

    имхо вообще не стоит рассматривать IDE в промышленной системе, поскольку нагрузка напорядок выше всяких офисных сервачков юзеров на 50. Вопрос о цене на винчестер 300$, где процессор стоит 1-2k USD (xeon пока дороже нет?) не рассматривается. (умолчим о ppc, spark)

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

     

  • 1.9, Тма (?), 17:01, 02/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В системе с одним винчестером на канал разницы в производительности можно не заметить. Я, например, взял i865GBF и повесил по одному диску на PATA-контроллеры и по одному - на SATA. Шустро вышло. ИДЕшники против скаженых винтов технологически слабее, другой уровень MTBF - факт. Но ценовой фактор еще более другой :( Хотя, если наткнуться на задачу 365х24 и высокой ценой простоя, то скаженым накопителям альтернативы нет. В конце концов, идешные винты почти тотально ушли в бытовой сектор, где приоритет отдан себестоимости. Оно хорошо сказалось на цене, но отвратительно на ТТХ.

    Насчет таггед кьюинга - тот еще вопрос. Примерно как с фрагментацией/дефрагментац%C

     
  • 1.11, shadowcaster (?), 22:53, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а google на чем вертится? не на ide ли винтах? вот только контроллеры у них не от интел, ессно :)
     
     
  • 2.15, Sergey (??), 16:47, 28/06/2005 [^] [^^] [^^^] [ответить]  
  • +/
    да, вертится гугль на иде-винтах, только не нужно стравнивать самосборные серваки с Савка и спецально заточеные под это системы хранения. К примеру знаете сколько стоит 146гиговый SАТА-шный диск в Хитачевский сторадж? Не всякая SCSI или FC столько денег просит..
    В среднем IDE дешевле и всякие конторы типа Hitachi, EMC, NetApp начинают предлягать хранилища не только на сказе или фибре, но и на ата-сата. Но там полки с 14-16 дисками, как правило 1-2 штуки стоят в hot-spare pool - т.е. подключены-раскручены, но операций чтения-записи не выполняют. Контроллеры там конечно не интел, хотя XOR-cpu обычно интелевский, что-то типа i960. В общем всегда нужно исходить из задач и желаемых затрат (минимизация времени disaster recovery очень затратная задача).
    Если у вас нагрузка на сервак 5-10к юзерей в час и час простоя стоит бизнесу хотя бы 10 килобаксов, то купить хранилище за 50к, которое будет обеспечивать 100% (это конечно если его не расстреливают из автомата, жгут напалмом или просто поливают из ведра, хотя для таких случаев делают распределенные резервные ВЦ) сохранность данных без простоев (несколько снижая реакцию во время ребилда массива при выходе диска из строя) очень хорошее решение. Даже 100к в этом случае не заоблачная цена, а бывают довольно небольшие хранилища (до 10Тб) которые стоят по 5-10 мегабаксов...
     

  • 1.12, Дима Авдеев (?), 23:26, 22/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а почему не расмотреть fibre chanell на серверах?
    помоему ни в чём не уступают скази да и ещё шина длиннее намного ,например для Oracle RAC(кластер) или microsofтовский кластер это рекомендованое решение!
     
  • 1.13, rippy (ok), 01:22, 27/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если Вы имеете в виду FC-AL, то, поверьте, они ОЩУТИМО уступают SCSI в производительности. Они другим берут...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру